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 <br>Falves1<br> <br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 3:06 PM, David Vossel <span dir="ltr">&lt;<a href="mailto:dvossel@digium.com">dvossel@digium.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
<br>
&gt; On 2010-10-14 14:06:09, David Vossel wrote:<br>
&gt; &gt; Looks great! From conversation with twilson &quot;Terry Wilson: yep, if they don&#39;t support the same codecs, we back out of trying a native bridge.&quot;<br>
<br>
</div>I am for this making it into 1.8 as well.  I believe it has a low risk of causing a regression.<br>
<font color="#888888"><br>
<br>
- David<br>
</font><div class="im"><br>
<br>
-----------------------------------------------------------<br>
This is an automatically generated e-mail. To reply, visit:<br>
<a href="https://reviewboard.asterisk.org/r/967/#review2841" target="_blank">https://reviewboard.asterisk.org/r/967/#review2841</a><br>
-----------------------------------------------------------<br>
<br>
<br>
</div><div><div></div><div class="h5">On 2010-10-06 00:04:42, Terry Wilson wrote:<br>
&gt;<br>
&gt; -----------------------------------------------------------<br>
&gt; This is an automatically generated e-mail. To reply, visit:<br>
&gt; <a href="https://reviewboard.asterisk.org/r/967/" target="_blank">https://reviewboard.asterisk.org/r/967/</a><br>
&gt; -----------------------------------------------------------<br>
&gt;<br>
&gt; (Updated 2010-10-06 00:04:42)<br>
&gt;<br>
&gt;<br>
&gt; Review request for Asterisk Developers.<br>
&gt;<br>
&gt;<br>
&gt; Summary<br>
&gt; -------<br>
&gt;<br>
&gt; From the issue:<br>
&gt;<br>
&gt;<br>
&gt; It is &quot;well known&quot; 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.<br>

&gt;<br>
&gt; PROBLEM: In its simplest form, the problem is (I believe) as follows:<br>
&gt;<br>
&gt; 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.<br>

&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt; 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).<br>
&gt;<br>
&gt; 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)<br>
&gt;<br>
&gt; Of course this results in A using g722, and B using alaw - Resulting in silence.<br>
&gt;<br>
&gt; The patch (to be attached) changes:<br>
&gt;<br>
&gt; main/rtp.c to make it choose a single audio and video codec where possible before passing the directmedia request on to the channels.<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt;<br>
&gt; This addresses bug 17403.<br>
&gt;     <a href="https://issues.asterisk.org/view.php?id=17403" target="_blank">https://issues.asterisk.org/view.php?id=17403</a><br>
&gt;<br>
&gt;<br>
&gt; Diffs<br>
&gt; -----<br>
&gt;<br>
&gt;   /trunk/channels/chan_sip.c 290542<br>
&gt;<br>
&gt; Diff: <a href="https://reviewboard.asterisk.org/r/967/diff" target="_blank">https://reviewboard.asterisk.org/r/967/diff</a><br>
&gt;<br>
&gt;<br>
&gt; Testing<br>
&gt; -------<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Terry<br>
&gt;<br>
&gt;<br>
<br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br>