[asterisk-users] Codec negotiation issue (no audio format found to offer)

[Ryan McGuire]

This is an excerpt from rfc3264 in regards to modifying an existing
session by the way:

"At any point during the session, either participant MAY issue a new
   offer to modify characteristics of the session.  It is fundamental to
   the operation of the offer/answer model that the exact same
   offer/answer procedure defined above is used for modifying parameters
   of an existing session."

I understand the implementation would likely be complicated -- I
noticed a ticket dating back to 2005 in regards to this. I'm wondering
if the user communities' demand for this functionality is enough to
justify adding it to the roadmap?

-Ryan

On Thu, Aug 4, 2011 at 11:06 AM, Ryan McGuire <rdmcguire01 at gmail.com> wrote:
>
> Thanks for the reply David,
> I guess I don't understand an issue in implementing the offer/answer model (rfc3264). If asterisk receives an invite and knows the egress peer's capabilities, why not respond to the sdp in the initial invite with modified sdp containing only g729?
> So asterisk knows that it is going to dial a peer that supports only g729 when it gets an invite from a peer that supports both ulaw and g729. Using the offer / answer model it would look like this:
> Peer -> Invite (SDP:ulaw,g729) -> Asterisk
> Peer <- 100 Trying (w/ SDP -- g729 only) <- Asterisk
> Peer -> 200 OK (w/ SDP g729) -> Asterisk
> I understand your point about not knowing what may happen after initial call setup, but the same implementation would apply in the event of a reinvite.
> Maybe this could be an option (allow_rfc3264=yes or something of that nature).
> Thanks again,
> -Ryan
>
> On Thu, Aug 4, 2011 at 9:58 AM, David Vossel <dvossel at digium.com> wrote:
>>
>> ----- Original Message -----
>> > From: "Ryan McGuire" <rdmcguire01 at gmail.com>
>> > To: asterisk-users at lists.digium.com
>> > Sent: Wednesday, August 3, 2011 9:47:42 AM
>> > Subject: Re: [asterisk-users] Codec negotiation issue (no audio format found to offer)
>> > From looking into this, it appears as if this is due to Asterisk
>> > negotiating the legs separately as if they were not related to the
>> > same call. So the ingress leg negotiates ulaw, and despite it knowing
>> > that the peer also supports g729 fails the call since it's already
>> > decided on ulaw and the egress leg only accepts g729.
>> >
>> >
>> > If this is design intent I'm wondering if there is demand enough to
>> > justify a feature request?
>> >
>> >
>> > Any advice on how I can work around this issue?
>> >
>> >
>> > Thanks,
>> >
>> >
>> > -Ryan
>>
>> This is a much more complicated issue than Asterisk negotiating each call leg separate of one another.  Even if we give one call leg information about call setup occurring on the other call leg it is about to be bridged to, we are dependent on the endpoints honoring the codec preference priority we send them to avoid translation between one codec and another during the bridge... Honoring the preference order in the SDP does not always occur, which means that any effort in this area would only work in a perfect scenario.
>>
>> Even if we get call legs to negotiate perfectly before being bridged during call setup, we are not guaranteed that translation will not occur later if the call is transfered or parked.  Regardless of what we do, if your setup allows ulaw and g729 for sip peers, you will always run the risk of a codec mixmatch...  You may however be able to avoid this for some cases by using the sip.conf preferred_codec_only option.  I believe that will limit the codecs negotiated during call setup to the single codec currently chosen on the other call leg. The problem with this is that we are not guaranteed the call leg supplying the codec will not change later.
>>
>> --
>> David Vossel
>> Digium, Inc. | Software Developer, Open Source Software
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at: www.digium.com & www.asterisk.org
>> The_Boy_Wonder in #asterisk-dev
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>               http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>