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 --->
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
<------------->
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@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 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?
--
_____________________________________________________________________
-- 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
