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

[Ryan McGuire]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110804/00933a48/attachment.htm>