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 --->
INVITEsip:LOCAL@ASTERISK:5060 SIP/2.0
Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5ab9c8e55f864da9
From:<sip:REMOTE@SUPPLIER>;tag=gK02498cb1
To:<sip:LOCAL@ASTERISK>
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:<sip:REMOTE@SUPPLIER:5060>
P-Asserted-Identity:<sip:REMOTE@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@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@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@SUPPLIER>;tag=gK02498cb1
To:<sip:LOCAL@ASTERISK>
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:<sip:LOCAL@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@SUPPLIER>;tag=gK02498cb1
To:<sip:LOCAL@ASTERISK>;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:<sip:LOCAL@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@SUPPLIER>;tag=gK02498cb1
To:<sip:LOCAL@ASTERISK>;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:<sip:LOCAL@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 --->
ACKsip:LOCAL@ASTERISK:5060 SIP/2.0
Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5bc037285f864da9
From:<sip:REMOTE@SUPPLIER>;tag=gK02498cb1
To:<sip:LOCAL@ASTERISK>;tag=as4502927f
Call-ID: 205665777_90679951@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@SUPPLIER' in 32000 ms
(Method: ACK)
set_destination: Parsing<sip:REMOTE@SUPPLIER:5060> for address/port to send to
set_destination: set destination to SUPPLIER:5060
Reliably Transmitting (no NAT) to SUPPLIER:5060:
BYEsip:REMOTE@SUPPLIER:5060 SIP/2.0
Via: SIP/2.0/UDP ASTERISK:5060;branch=z9hG4bK156fd67d
Max-Forwards: 70
From:<sip:LOCAL@ASTERISK>;tag=as4502927f
To:<sip:REMOTE@SUPPLIER>;tag=gK02498cb1
Call-ID: 205665777_90679951@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@ASTERISK>;tag=as4502927f
To:<sip:REMOTE@SUPPLIER>;tag=gK02498cb1
Call-ID: 205665777_90679951@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@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
