<div dir="ltr"><div dir="ltr">On Thu, May 14, 2020 at 11:31 AM John Hughes <<a href="mailto:john@calva.com">john@calva.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 14/05/2020 08:10, John Hughes wrote:<br>
</div>
<blockquote type="cite">
<p>I am having a problem with one of my callers who is using
either g729 or alaw. I can do alaw but not g729 so asterisk
should negotiate alaw right? In fact from the sip debug it
looks like it does, but then I get the dreaded "channel.c:5630
set_format: Unable to find a codec translation path: (g729)
-> (alaw)" and the call hangs up. Why?</p>
<p>Last minute thought: Is it possible that the caller is sending
g729 in RTP even though the SIP negotiation clearly chooses
alaw? Maybe I need some RTP debugging.<br>
</p>
</blockquote>
And in fact that is exactly what's happening.<br>
<blockquote type="cite">
<p> </p>
<--- SIP read from UDP:SUPPLIER:5060 --->
<pre>INVITE <a>sip:LOCAL@ASTERISK:5060</a> SIP/2.0
Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5ab9c8e55f864da9
From: <a><sip:REMOTE@SUPPLIER></a>;tag=gK02498cb1
To: <a><sip:LOCAL@ASTERISK></a>
Call-ID: 205665777_90679951@SUPPLIER
CSeq: 539098 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <a><sip:REMOTE@SUPPLIER:5060></a>
P-Asserted-Identity: <a><sip:REMOTE@REMOTE-SUPPLIER;user=phone></a>
Supported: timer,100rel,precondition
Session-Expires: 1800
Min-SE: 90
Content-Length: 282
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=Sonus_UAC 176880 320591 IN IP4 SUPPLIER
s=SIP Media Capabilities
c=IN IP4 213.41.124.6
t=0 0
m=audio 8526 RTP/AVP 18 8 101
<b>a=rtpmap:18 G729/8000</b>
a=fmtp:18 annexb=no
<b>a=rtpmap:8 PCMA/8000</b>
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
<-------------></pre>
</blockquote>
<p>So he says he wants g729 or alaw<br>
</p>
<blockquote type="cite">
<pre>Found RTP audio format 18
Found RTP audio format 8
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format PCMA for ID 8
Found audio description format telephone-event for ID 101
Capabilities: us - (alaw|ulaw|gsm), peer - audio=(alaw|g729)/video=(nothing)/text=(nothing), combined - (<b>alaw</b>)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)</pre>
</blockquote>
<p>And asterisk calculates that the common codecs are just alaw, <br>
</p>
<p>So asterisk says: "let's do alaw":<br>
</p>
<blockquote type="cite"><---
Reliably Transmitting (no NAT) to SUPPLIER:5060 --->
<pre>SIP/2.0 200 OK
Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5ab9c8e55f864da9;received=SUPPLIER
From: <a><sip:REMOTE@SUPPLIER></a>;tag=gK02498cb1
To: <a><sip:LOCAL@ASTERISK></a>;tag=as4502927f
Call-ID: 205665777_90679951@SUPPLIER
CSeq: 539098 INVITE
Server: Asterisk PBX 13.14.1~dfsg-2+deb9u4
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <a><sip:LOCAL@ASTERISK:5060></a>
Content-Type: application/sdp
Require: timer
Content-Length: 264
v=0
o=root 227409966 227409966 IN IP4 ASTERISK
s=Asterisk PBX 13.14.1~dfsg-2+deb9u4
c=IN IP4 ASTERISK
t=0 0
m=audio 13948 RTP/AVP 8 101
<b>a=rtpmap:8 PCMA/8000</b>
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
<------------></pre>
</blockquote>
<p>And when I look at the RTP debugging I see the data from the
remote is:<br>
</p>
<pre><blockquote type="cite">Got RTP packet from xx.xx.xx.xx:50644 (type 18, seq 001338, ts 610458, len 000020)
</blockquote></pre>
<p>AAArgh! Type 18 is g729. Why on earth is the remote sending me
g729 when I clearly said the only thing I could do was alaw.</p>
<p>Is this legal?</p>
<p>Is the other side broken?</p></div></blockquote><div><br></div><div>It shouldn't be sending it, but as well we should be ignoring it. I believe we do ignore in modern versions, I can't speak for your old one. As for why... I don't really have an answer.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></div></div>