[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?

[Joshua C. Colp]

On Thu, May 14, 2020 at 11:31 AM John Hughes <john at calva.com> wrote:

> On 14/05/2020 08:10, John Hughes wrote:
>
> 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?
>
> 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.
>
> And in fact that is exactly what's happening.
>
> <--- SIP read from UDP:SUPPLIER:5060 --->
>
> INVITE sip:LOCAL at ASTERISK:5060 SIP/2.0
> Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5ab9c8e55f864da9
> From: <sip:REMOTE at SUPPLIER>;tag=gK02498cb1
> To: <sip:LOCAL at ASTERISK>
> Call-ID: 205665777_90679951 at 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: <sip:REMOTE at SUPPLIER:5060>
> P-Asserted-Identity: <sip:REMOTE at REMOTE-SUPPLIER;user=phone>
> 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*a=rtpmap:18 G729/8000*
> a=fmtp:18 annexb=no*a=rtpmap:8 PCMA/8000*
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=sendrecv
> a=ptime:20
> <------------->
>
> So he says he wants g729 or alaw
>
> 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 - (*alaw*)
> Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
>
> And asterisk calculates that the common codecs are just alaw,
>
> So asterisk says: "let's do alaw":
>
> <--- Reliably Transmitting (no NAT) to SUPPLIER:5060 --->
>
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5ab9c8e55f864da9;received=SUPPLIER
> From: <sip:REMOTE at SUPPLIER>;tag=gK02498cb1
> To: <sip:LOCAL at ASTERISK>;tag=as4502927f
> Call-ID: 205665777_90679951 at 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: <sip:LOCAL at ASTERISK:5060>
> 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*a=rtpmap:8 PCMA/8000*
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
>
> <------------>
>
> And when I look at the RTP debugging I see the data from the remote is:
>
> Got  RTP packet from    xx.xx.xx.xx:50644 (type 18, seq 001338, ts 610458, len 000020)
>
> 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.
>
> Is this legal?
>
> Is the other side broken?
>

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.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200514/1a5f7c68/attachment.html>