John Hughes
2020-May-14 06:10 UTC
[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
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 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 --->
ACKsip: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:
BYEsip: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200514/8a4f6cae/attachment.html>
Michael L. Young
2020-May-14 14:08 UTC
[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
> From: "John Hughes" <john at calva.com> > To: "Asterisk Users Mailing List, Non-Commercial Discussion" > <asterisk-users at lists.digium.com> > Sent: Thursday, May 14, 2020 2:10:45 AM > Subject: [asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and > alaw; asterisk wants to translate g729 -> alaw. WHY?> 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.Hi John, Maybe a newer version of Asterisk would help? The latest release for 13 is version 13.33. The version you are on was released 3 years ago. Here is an issue which looks like what you describe and was fixed in 13.16 [ https://issues.asterisk.org/jira/browse/ASTERISK-26143 | https://issues.asterisk.org/jira/browse/ASTERISK-26143 ] Not sure if this is the answer to your problem but thought that I would throw that out there. Michael L. Young (elguero) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200514/0089aafe/attachment.html>
John Hughes
2020-May-14 14:30 UTC
[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
On 14/05/2020 16:08, Michael L. Young 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. > > Hi John, > > Maybe a newer version of Asterisk would help? The latest release for > 13 is version 13.33. The version you are on was released 3 years ago.Well, like I said I'm on Debian, using the packaged version. If I want to upgrade I'll have to compile it myself, or upgrade to Debian buster to get 16.2.1> > Here is an issue which looks like what you describe and was fixed in 13.16 > https://issues.asterisk.org/jira/browse/ASTERISK-26143That doesn't seem to be the same problem. My problem is that the other end is sending g729, which my asterlsk can't do at all, and tells the remote it can't do. I'm shocked that the remote is trying to send me stuff using a codec that I didn't say I could handle. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200514/6b9439b7/attachment.html>
John Hughes
2020-May-14 14:30 UTC
[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
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 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200514/d8d8b1e8/attachment.html>
Joshua C. Colp
2020-May-14 14:41 UTC
[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
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>
Richard Mudgett
2020-May-14 14:50 UTC
[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
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>
Richard Mudgett
2020-May-14 15:01 UTC
[asterisk-users] I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
Argh. That was for chan_pjsip and you are using chan_sip. Be aware that chan_sip is effectively dead. Richard On Thu, May 14, 2020 at 9:50 AM Richard Mudgett <rmudgett at digium.com> wrote:> 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/8876fcdb/attachment.html>
Reasonably Related Threads
- I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
- I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
- I can do alaw, ulaw and gsm; remote can do g729 and alaw; asterisk wants to translate g729 -> alaw. WHY?
- Attempting to get BLF working with linphone
- Attempting to get BLF working with linphone