[asterisk-dev] [Code Review] Force directmedia sessions to use a common codec

[CDR]

I wonder if we could include this patch in 1.6.2. I can test it right away
in production. Maybe somebody can write  patch for 1.6.2
Falves1


On Thu, Oct 14, 2010 at 3:06 PM, David Vossel <dvossel at digium.com> wrote:

>
>
> > On 2010-10-14 14:06:09, David Vossel wrote:
> > > Looks great! From conversation with twilson "Terry Wilson: yep, if they
> don't support the same codecs, we back out of trying a native bridge."
>
> I am for this making it into 1.8 as well.  I believe it has a low risk of
> causing a regression.
>
>
> - David
>
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/967/#review2841
> -----------------------------------------------------------
>
>
> On 2010-10-06 00:04:42, Terry Wilson wrote:
> >
> > -----------------------------------------------------------
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviewboard.asterisk.org/r/967/
> > -----------------------------------------------------------
> >
> > (Updated 2010-10-06 00:04:42)
> >
> >
> > Review request for Asterisk Developers.
> >
> >
> > Summary
> > -------
> >
> > From the issue:
> >
> >
> > It is "well known" that setting up directmedia paths between SIP devices
> with different preferred-codec lists can be problematic. The solution has
> previously been to either disable directmedia, or use the codec-negotiation
> patch which is available for Asterisk 1.2 and 1.4.
> >
> > PROBLEM: In its simplest form, the problem is (I believe) as follows:
> >
> > When RTP tries to set up a direct media path, it does so by setting each
> party separately, and giving each party free reign over their codec choice.
> Thus under some circumstances the 2 remote devices can make 2 choices which
> are different. If the 2 parties disagree on the negotiated codec, you
> generally get silence in both directions.
> >
> > SOLUTION: Make rtp.c just a bit more clever about what codecs each party
> is offered - In fact, do not allow a choice, just tell them what is
> acceptable.
> >
> > EXAMPLE: Device A (g722|alaw) calls via asterisk to device B (alaw) -
> Initially a transcoded path is setup between the 2 parties. directmedia is
> enabled, and they have a common codec (alaw).
> >
> > At present, during negotiation, RTP tells A to use (alaw) and B to use
> (g722|alaw) - chan_sip.c then notes those codec requests, ignores them and
> tells A to use (g722|alaw) and B to use (alaw)
> >
> > Of course this results in A using g722, and B using alaw - Resulting in
> silence.
> >
> > The patch (to be attached) changes:
> >
> > main/rtp.c to make it choose a single audio and video codec where
> possible before passing the directmedia request on to the channels.
> >
> > channels/chan_sip.c to make it use the passed in codec offering from RTP
> as long as it is doing a directmedia reinvite - At any other time, old
> behaviour remains, allowing better codec choices where possible.
> >
> >
> > This addresses bug 17403.
> >     https://issues.asterisk.org/view.php?id=17403
> >
> >
> > Diffs
> > -----
> >
> >   /trunk/channels/chan_sip.c 290542
> >
> > Diff: https://reviewboard.asterisk.org/r/967/diff
> >
> >
> > Testing
> > -------
> >
> > I verified the issue by recreating the aforementioned scenario. I ported
> the patch to trunk and verified that audio was negotiated properly for that
> scenario.
> >
> >
> > Thanks,
> >
> > Terry
> >
> >
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20101016/a734fe53/attachment.htm