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

Thu May 14 09:50:29 CDT 2020

The other end is sending g729 even though it was not negotiated.  The other
end should not do this and it usually seems that the other ends that do
send g729.
This was recently fixed.  See
https://issues.asterisk.org/jira/browse/ASTERISK-28139

Richard

On Thu, May 14, 2020 at 1:11 AM John Hughes <john at calva.com> 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.
>
> Asterisk 13.14.1 on Debian, using chan_sip.
>
> Here's the trace:
>
> <--- 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
> <------------->
> --- (17 headers 13 lines) ---
> Sending to SUPPLIER:5060 (no NAT)
> Sending to SUPPLIER:5060 (no NAT)
> Using INVITE request as basis request - 205665777_90679951 at SUPPLIER
> Found peer 'supplier' for 'REMOTE' from SUPPLIER:5060
> 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|)
> Peer audio RTP is at port 213.41.124.6:8526
> Looking for LOCAL in supplier-in (domain ASTERISK)
> sip_route_dump: route/path hop: <sip:REMOTE at SUPPLIER:5060>
>
> So, all looking good here, we've worked out that the combined capabilities
> are (alaw)
>
> <--- Transmitting (no NAT) to SUPPLIER:5060 --->
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5ab9c8e55f864da9;received=SUPPLIER
> From: <sip:REMOTE at SUPPLIER>;tag=gK02498cb1
> To: <sip:LOCAL at ASTERISK>
> 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-Length: 0
>
>
> <------------>
>
> <--- Transmitting (no NAT) to SUPPLIER:5060 --->
> SIP/2.0 180 Ringing
> 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-Length: 0
>
>
> <------------>
> Audio is at 13948
> Adding codec alaw to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
>
> <--- 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 that's good to, we've sent the OK for the INVITE saying that we want
> alaw.
>
>
> <--- SIP read from UDP:SUPPLIER:5060 --->
> ACK sip:LOCAL at ASTERISK:5060 SIP/2.0
> Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5bc037285f864da9
> From: <sip:REMOTE at SUPPLIER>;tag=gK02498cb1
> To: <sip:LOCAL at ASTERISK>;tag=as4502927f
> Call-ID: 205665777_90679951 at SUPPLIER
> CSeq: 539098 ACK
> Max-Forwards: 70
> Content-Length: 0
>
> <------------->
> --- (8 headers 0 lines) ---
> [May 13 13:46:58] WARNING[7245][C-000031da]: channel.c:5630 set_format: Unable to find a codec translation path: (g729) -> (alaw)
>
> What's this nonsense!  Why is set_format trying to use g729!
>
> Scheduling destruction of SIP dialog '205665777_90679951 at SUPPLIER' in 32000 ms (Method: ACK)
> set_destination: Parsing <sip:REMOTE at SUPPLIER:5060> for address/port to send to
> set_destination: set destination to SUPPLIER:5060
> Reliably Transmitting (no NAT) to SUPPLIER:5060:
> BYE sip:REMOTE at SUPPLIER:5060 SIP/2.0
> Via: SIP/2.0/UDP ASTERISK:5060;branch=z9hG4bK156fd67d
> Max-Forwards: 70
> From: <sip:LOCAL at ASTERISK>;tag=as4502927f
> To: <sip:REMOTE at SUPPLIER>;tag=gK02498cb1
> Call-ID: 205665777_90679951 at SUPPLIER
> CSeq: 102 BYE
> User-Agent: Asterisk PBX 13.14.1~dfsg-2+deb9u4
> X-Asterisk-HangupCause: Normal Clearing
> X-Asterisk-HangupCauseCode: 16
> Content-Length: 0
>
>
> ---
>
> <--- SIP read from UDP:SUPPLIER:5060 --->
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP ASTERISK:5060;branch=z9hG4bK156fd67d
> From: <sip:LOCAL at ASTERISK>;tag=as4502927f
> To: <sip:REMOTE at SUPPLIER>;tag=gK02498cb1
> Call-ID: 205665777_90679951 at SUPPLIER
> CSeq: 102 BYE
> Content-Length: 0
>
> <------------->
> --- (7 headers 0 lines) ---
> SIP Response message for INCOMING dialog BYE arrived
> Really destroying SIP dialog '205665777_90679951 at SUPPLIER' Method: ACK
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>       https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200514/3cb96791/attachment.html>