>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&#39;s already decided on ulaw and the egress leg only accepts g729.<div>
<br></div><div>If this is design intent I&#39;m wondering if there is demand enough to justify a feature request?</div><div><br></div><div>Any advice on how I can work around this issue?</div><div><br></div><div>Thanks,</div>
<div><br></div><div>-Ryan<br><br><div class="gmail_quote">On Tue, Aug 2, 2011 at 3:51 PM, Ryan McGuire <span dir="ltr">&lt;<a href="mailto:rdmcguire01@gmail.com">rdmcguire01@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Running build 1.8.5.0 (compiled from source) I seem to be having an issue with codec negotiation. I have a Grandstream HT503 FXO port connected to a pstn line, a Polycom SP501, and a SIP trunk with callwithus.<div><br></div>

<div>What I&#39;m essentially looking to accomplish is for ulaw or g729 (preferably ulaw) to be used to the Grandstream FXO or any other internal endpoint, and for g729 only to be used outbound to my SIP trunk.</div><div>

<br></div><div>Here are the basics of my config, showing the codec list from &quot;sip show peer &lt;peer&gt;&quot;:</div><div><br></div><div>Polycom SP501 (desk phone):</div><div>--------------------------</div><div>disallow=all</div>

<div>allow=ulaw&amp;g729</div><div><div>  Codecs       : 0x104 (ulaw|g729)</div><div>  Codec Order  : (ulaw:20,g729:20)</div></div><div><br></div><div>Grandstream HT503 (fxo gateway):</div><div>--------------------------</div>

<div>disallow=all</div><div>allow=ulaw&amp;g729</div><div><div>  Codecs       : 0x104 (ulaw|g729)</div><div>  Codec Order  : (ulaw:20,g729:20)</div></div><div><br></div><div>CallWithUs (SIP trunk):</div><div>--------------------------</div>

<div>disallow=all</div><div>allow=g729</div><div><div>  Codecs       : 0x100 (g729)</div><div>  Codec Order  : (g729:20)</div></div><div><br></div><div>When I place an outbound call from the Polycom to callwithus, the invite from the pcom shows both ulaw and g729 in the SDP:</div>

<div><div>INVITE sip:************@<a href="http://192.168.0.1" target="_blank">192.168.0.1</a>;user=phone SIP/2.0</div><div>Via: SIP/2.0/UDP 192.168.0.201;branch=z9hG4bKc8aa981a8B8FF58D</div><div>From: &quot;Office&quot; &lt;<a href="mailto:sip%3A2001@192.168.0.1" target="_blank">sip:2001@192.168.0.1</a>&gt;;tag=4CD2B2A0-B94A2531</div>

<div>To: &lt;<a href="mailto:sip%3A919785013620@192.168.0.1" target="_blank">sip:919785013620@192.168.0.1</a>;user=phone&gt;</div></div><div>[...]</div><div><div>m=audio 2258 RTP/AVP 18 0 8 101</div><div>a=rtpmap:18 G729/8000</div>
<div>a=fmtp:18 annexb=no</div>
<div>a=rtpmap:0 PCMU/8000</div><div>a=rtpmap:8 PCMA/8000</div><div>a=rtpmap:101 telephone-event/8000</div></div><div><br></div><div>Asterisk sees this:</div><div><div>[Aug  2 15:00:31] VERBOSE[1918] chan_sip.c: Capabilities: us - 0x104 (ulaw|g729), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x104 (ulaw|g729)</div>

</div><div><br></div><div>The call goes out the callwithus trunk:</div><div><div>[Aug  2 15:00:31] VERBOSE[1315] pbx.c:     -- Executing [s@macro-dialout-trunk:19] Dial(&quot;SIP/2001-00000047&quot;, &quot;SIP/CallWithUs/**********,300,tTwW&quot;) in new stack</div>

</div><div><br></div><div>And then this, no INVITE goes out to callwithus at all:</div><div><div>[Aug  2 15:00:31] WARNING[1315] chan_sip.c: No audio format found to offer. Cancelling call to **********</div><div>[Aug  2 15:00:31] VERBOSE[1315] app_dial.c:     -- Couldn&#39;t call SIP/CallWithUs/**********</div>

</div><div><br></div><div>Similarly, if I set the Grandstream FXO trunk to ulaw only, the call fails as well. It seems as if allowing only a single codec is the issue, if I change the priorities of all codecs to g729 first and ulaw second, the call goes through as g729 successfully.</div>

<div><br></div><div>Smells like a bug to me, but I may be overlooking something in my config.</div><div><br></div><div>Thanks,</div><div><br></div><font color="#888888"><div>-Ryan</div>
</font></blockquote></div><br></div>