g 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.<div> <br></div><div>If this is design intent I'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=3D"gmail_quote">On Tue, Aug 2, 2011 at 3:51 PM, Ryan McGuire <span dir=3D"ltr"><<a href=3D"mailto:rdmcguire01 at gmail.com">rdmcguire01 at gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"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'm essentially looking to accomplish is for ulaw or g729=A0(preferably ulaw)=A0to 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 "sip show peer <peer>":</div><div><br></div><div>Polycom SP501 (desk phone):</div><div>--------------------------</div><div>disallow=3Dall</div> <div>allow=3Dulaw&g729</div><div><div>=A0 Codecs =A0 =A0 =A0 : 0x104 (ulaw|g729)</div><div>=A0 Codec Order =A0: (ulaw:20,g729:20)</div></div><div><br></div><div>Grandstream HT503 (fxo gateway):</div><div>--------------------------</div> <div>disallow=3Dall</div><div>allow=3Dulaw&g729</div><div><div>=A0 Codecs =A0 =A0 =A0 : 0x104 (ulaw|g729)</div><div>=A0 Codec Order =A0: (ulaw:20,g729:20)</div></div><div><br></div><div>CallWithUs (SIP trunk):</div><div>--------------------------</div> <div>disallow=3Dall</div><div>allow=3Dg729</div><div><div>=A0 Codecs =A0 =A0 =A0 : 0x100 (g729)</div><div>=A0 Codec Order =A0: (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=3D"http://192.168.0.1" target=3D"_blank">192.168.0.1</a>;user=3Dphone SIP/2.0</div><div>Via: SIP/2.0/UDP 192.168.0.201;branch=3Dz9hG4bKc8aa981a8B8FF58D</div><div>From: "Office" <<a href=3D"mailto:sip%3A2001 at 192.168.0.1" target=3D"_blank">sip:2001 at 192.168.0.1</a>>;tag=3D4CD2B2A0-B94A2531</div> <div>To: <<a href=3D"mailto:sip%3A919785013620 at 192.168.0.1" target=3D"_blank">sip:919785013620 at 192.168.0.1</a>;user=3Dphone></div></div><div>[...]</div><div><div>m=3Daudio 2258 RTP/AVP 18 0 8 101</div><div>a=3Drtpmap:18 G729/8000</div> <div>a=3Dfmtp:18 annexb=3Dno</div> <div>a=3Drtpmap:0 PCMU/8000</div><div>a=3Drtpmap:8 PCMA/8000</div><div>a=3Drtpmap:101 telephone-event/8000</div></div><div><br></div><div>Asterisk sees this:</div><div><div>[Aug =A02 15:00:31] VERBOSE[1918] chan_sip.c: Capabilities: us - 0x104 (ulaw|g729), peer - audio=3D0x10c (ulaw|alaw|g729)/video=3D0x0 (nothing)/text=3D0x0 (nothing), combined - 0x104 (ulaw|g729)</div> </div><div><br></div><div>The call goes out the callwithus trunk:</div><div><div>[Aug =A02 15:00:31] VERBOSE[1315] pbx.c: =A0 =A0 -- Executing [s at macro-dialout-trunk:19] Dial("SIP/2001-00000047", "SIP/CallWithUs/**********,300,tTwW") in new stack</div> </div><div><br></div><div>And then this, no INVITE goes out to callwithus at all:</div><div><div>[Aug =A02 15:00:31] WARNING[1315] chan_sip.c: No audio format found to offer. Cancelling call to **********</div><div>[Aug =A02 15:00:31] VERBOSE[1315] app_dial.c: =A0 =A0 -- Couldn'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=3D"#888888"><div>-Ryan</div> </font></blockquote></div><br></div> --20cf305e25815d4dc004a99af2b7--