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

2020-05-14 Thread John Hughes 

On 14/05/2020 16:41, Joshua C. Colp wrote:
On Thu, May 14, 2020 at 11:31 AM John Hughes > 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.

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 20) 


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.


Ok, so maybe upgrading my asterisk would be a good idea, but I don't 
think it'll fix this problem, they sent me 6 g729 packets before the 
communication was cut, I'm pretty sure they've just ignored the results 
of the negotiation.


I hope I can get them to fix their system...

-- 
_
-- 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

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

2020-05-14 Thread Richard Mudgett 
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  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  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@ASTERISK:5060 SIP/2.0
>> Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5ab9c8e55f864da9
>> From: ;tag=gK02498cb1
>> To: 
>> 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: 
>> P-Asserted-Identity: 
>> 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: 
>>
>> 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: ;tag=gK02498cb1
>> To: 
>> 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: 
>> 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: ;tag=gK02498cb1
>> To: ;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: 
>> 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: ;tag=gK02498cb1
>> To: ;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: 
>> 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
>>

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

2020-05-14 Thread Richard Mudgett 
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  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@ASTERISK:5060 SIP/2.0
> Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5ab9c8e55f864da9
> From: ;tag=gK02498cb1
> To: 
> 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: 
> P-Asserted-Identity: 
> 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: 
>
> 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: ;tag=gK02498cb1
> To: 
> 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: 
> 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: ;tag=gK02498cb1
> To: ;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: 
> 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: ;tag=gK02498cb1
> To: ;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: 
> 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

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

2020-05-14 Thread Joshua C. Colp 
On Thu, May 14, 2020 at 11:31 AM John Hughes  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@ASTERISK:5060 SIP/2.0
> Via: SIP/2.0/UDP SUPPLIER:5060;branch=z9hG4bK02B5ab9c8e55f864da9
> From: ;tag=gK02498cb1
> To: 
> 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: 
> P-Asserted-Identity: 
> 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: ;tag=gK02498cb1
> To: ;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: 
> 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 fromxx.xx.xx.xx:50644 (type 18, seq 001338, ts 610458, 
> len 20)
>
> 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
-- 
_
-- 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

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

2020-05-14 Thread John Hughes 

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:;tag=gK02498cb1
To:
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:
P-Asserted-Identity:
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:;tag=gK02498cb1
To:;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:
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 20) 


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

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

2020-05-14 Thread John Hughes 

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-26143


That 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.



-- 
_
-- 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

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

2020-05-14 Thread Michael L. Young 
> From: "John Hughes" 
> To: "Asterisk Users Mailing List, Non-Commercial Discussion"
> 
> 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) 
-- 
_
-- 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

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

2020-05-14 Thread John Hughes 
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:;tag=gK02498cb1
To:
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:
P-Asserted-Identity:
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:

   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:;tag=gK02498cb1
To:
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:
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:;tag=gK02498cb1
To:;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:
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:;tag=gK02498cb1
To:;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:
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:;tag=gK02498cb1
To:;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-31da]: 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  for address/port