I Can Do Alaw, Ulaw And Gsm; Remote Can Do G729 And Alaw; Asterisk Wants To Translate G729 -> Alaw. WHY?

Home » Asterisk Users » I Can Do Alaw, Ulaw And Gsm; Remote Can Do G729 And Alaw; Asterisk Wants To Translate G729 -> Alaw. WHY?
Asterisk Users 7 Comments

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

7 thoughts on - I Can Do Alaw, Ulaw And Gsm; Remote Can Do G729 And Alaw; Asterisk Wants To Translate G729 -> Alaw. WHY?

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

  • 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

    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.

  • And in fact that is exactly what’s happening.

    So he says he wants g729 or alaw

    And asterisk calculates that the common codecs are just alaw,

    So asterisk says: “let’s do alaw”:

    And when I look at the RTP debugging I see the data from the remote is:

    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.

  • Argh. That was for chan_pjsip and you are using chan_sip. Be aware that chan_sip is effectively dead.

    Richard

  • 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…