Codec madness: all except alaw disabled yet "Unable to find a codec translation path: (g729) -> (alaw)"

Asterisk Asterisk SIP
1

Hi all,

I’m trying to get a service going between a few soft-phones (Twinkle, SIPDroid), an ATA (Grandstream HT814) and the Internode NodePhone service. Server is Asterisk 16.6.2 on OpenBSD 6.6 (AMD64):

Asterisk 16.6.2 built by _pbuild @ amd64-stable.ports.openbsd.org on a amd64 running OpenBSD on 2019-11-22 09:21:53 UTC

I realise up front that “OpenBSD” is not an officially supported platform. I am assuming I have screwed up something configuration wise. If my configuration is fine, and what I’m doing should work, then I’ll take it to the OpenBSD misc list to sort out their port.

Outbound calls work fine, however, when I try an inbound call (via yee olde PSTN, we haven’t gotten rid of that yet), I get this:

[Apr  5 16:27:40] WARNING[-1][C-00000001] channel.c: Unable to find a codec translation path: (g729) -> (alaw)

Now, I originally had these settings for the SIP endpoints (in pjsip.conf):

allow=g722,ilbc,g726,g729,alaw,ulaw,g723

I tried adding disallow=all above this. No dice. Finally, I tried the nuclear option: disallow=all allow=alaw. (i.e. disallow everything except ALAW). Still no dice. The caller gets hung up on for no reason. It’s getting rather expensive ringing my SIP line from the PSTN at 25c a pop just for it to hang up on me. Outbound calls work fine.

The following is what I have loaded:

vk4msl-gap*CLI> module show like codec_
Module                         Description                              Use Count  Status      Support Level
codec_a_mu.so                  A-law and Mulaw direct Coder/Decoder     0          Running              core
codec_adpcm.so                 Adaptive Differential PCM Coder/Decoder  0          Running              core
codec_alaw.so                  A-law Coder/Decoder                      0          Running              core
codec_g722.so                  ITU G.722-64kbps G722 Transcoder         0          Running              core
codec_g726.so                  ITU G.726-32kbps G726 Transcoder         0          Running              core
codec_gsm.so                   GSM Coder/Decoder                        0          Running              core
codec_ilbc.so                  iLBC Coder/Decoder                       0          Running              core
codec_lpc10.so                 LPC10 2.4kbps Coder/Decoder              0          Running              core
codec_resample.so              SLIN Resampling Codec                    0          Running              core
codec_ulaw.so                  mu-Law Coder/Decoder                     0          Running              core
10 modules loaded

That to me says g729 shouldn’t be included in the list, but even if I drop it to alaw only, it still gets chosen. How do I tell all parties concerned to “never EVER use G.729”?

2

The remote endpoint is part of the negotiation and can be configured to prefer/use G729. What happened when you did only “allow=alaw”? Did the call immediately fail? If so, then I’d suspect the endpoint is set for only G729 and you’d need to change that.

3

The remote endpoint is part of the negotiation and can be configured to prefer/use G729. What happened when you did only “allow=alaw”? Did the call immediately fail? If so, then I’d suspect the endpoint is set for only G729 and you’d need to change that.

Pretty much, call went from “ringing” to “engaged signal” the moment I clicked answer.

|Time     | ${PROVIDER}                           |
|         |                   | ${ASTERISK_BOX}   |                   
|0.000000 |         INVITE SDP (g711A g7          |SIP INVITE From: <sip:${MYPSTNNUM}@${PROVIDER}29;user=phone> To:"${PROVIDER_NAME}"<sip:${MYSIPNUM}@${PROVIDER_DOMAIN}> Call-ID:BW061858648050420-1965318496@${PROVIDER}29 CSeq:612303213
|         |(5060)   ------------------>  (5060)   |
|0.003443 |         100 Trying|                   |SIP Status 100 Trying
|         |(5060)   <------------------  (5060)   |
|0.025416 |         180 Ringing                   |SIP Status 180 Ringing
|         |(5060)   <------------------  (5060)   |
|0.954015 |         200 OK SDP (g711A g7          |SIP Status 200 OK
|         |(5060)   <------------------  (5060)   |
|0.986287 |         RTP (g711A)                   |RTP, 6 packets. Duration: 0.099s SSRC: 0x4F53507
|         |(27642)  <------------------  (18024)  |
|1.092729 |         RTP (g729)                    |RTP, 3 packets. Duration: 0.041s SSRC: 0xCD74F85
|         |(27642)  ------------------>  (18024)  |
|1.097523 |         ACK       |                   |SIP Request INVITE ACK 200 CSeq:612303213
|         |(5060)   ------------------>  (5060)   |
|1.099552 |         BYE       |                   |SIP Request BYE CSeq:29850
|         |(5060)   <------------------  (5060)   |
|1.149521 |         200 OK    |                   |SIP Status 200 OK
|         |(5060)   ------------------>  (5060)   |

|Time     | ${ASTERISKBOX}                        |
|         |                   | ${SOFTPHONEIP}    |                   
|10.628404|         INVITE SDP (g711A g7          |SIP INVITE From: <sip:${MYPSTNNUM}@${MYWANIP}> To:<sip:${USER}@${SOFTPHONEIP}> Call-ID:412ec7d3-f09d-42cd-94a8-0363dba5dfe2 CSeq:28756
|         |(5060)   ------------------>  (5060)   |
|10.634386|         100 Trying|                   |SIP Status 100 Trying
|         |(5060)   <------------------  (5060)   |
|10.636614|         180 Ringing                   |SIP Status 180 Ringing
|         |(5060)   <------------------  (5060)   |
|11.562440|         200 OK SDP (g711A te          |SIP Status 200 OK
|         |(5060)   <------------------  (5060)   |
|11.565383|         ACK       |                   |SIP Request INVITE ACK 200 CSeq:28756
|         |(5060)   ------------------>  (5060)   |
|11.599020|         RTP (g711A)                   |RTP, 8 packets. Duration: 0.142s SSRC: 0x4F53507
|         |(26800)  <------------------  (8000)   |
|11.721225|         BYE       |                   |SIP Request BYE CSeq:28757
|         |(5060)   ------------------>  (5060)   |
|11.725505|         200 OK    |                   |SIP Status 200 OK
|         |(5060)   <------------------  (5060)   |

The question in my mind is which endpoint needs to be configured to allow other codecs… if it’s in my softphones/ATA, no problem, the setting will be in there somewhere.

I don’t think the provider would be so silly as to require G.729 since there’s a lot out there that doesn’t support it (it was patented until recently) and in the past when I’ve called out, it’s negotiated G.711a. So I think they do support G.711a.

I was using Twinkle on Debian Buster at the time as my softphone. I did re-start the application (and Asterisk) when changing codec settings.

What point does the codec negotiation? Surely Asterisk is in a position to say “no” to some given CODEC? Looks like in the OK response the client sends back, there’s an opportunity for options to be chosen there.

Otherwise I’m staring down the barrels of trying to shoehorn G.729 CODEC support into the OpenBSD port of Asterisk.

4

Funny thing is, that initial INVITE does list G.711a:

Frame 1: 924 bytes on wire (7392 bits), 924 bytes captured (7392 bits)
PPP-over-Ethernet Session
Point-to-Point Protocol
Internet Protocol Version 4…
Session Initiation Protocol (INVITE)
    Request-Line: INVITE sip:… SIP/2.0
    Message Header
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): BroadWorks 793194686 1 IN IP4 …
            Session Name (s): -
            Connection Information (c): IN IP4 …
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 27642 RTP/AVP 8 0 18 106 101
                Media Type: audio
                Media Port: 27642
                Media Protocol: RTP/AVP
                Media Format: ITU-T G.711 PCMA ← see here
                Media Format: ITU-T G.711 PCMU
                Media Format: ITU-T G.729
                Media Format: DynamicRTP-Type-106
                Media Format: DynamicRTP-Type-101
            Media Attribute (a): rtpmap:106 G.729b/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 106
                MIME Type: G.729b
                Sample Rate: 8000
            Media Attribute (a): rtpmap:101 telephone-event/8000
                Media Attribute Fieldname: rtpmap
                Media Format: 101
                MIME Type: telephone-event
                Sample Rate: 8000
            Media Attribute (a): fmtp:101 0-15
                Media Attribute Fieldname: fmtp
                Media Format: 101 [telephone-event]
                Media format specific parameters: 0-15
            Media Attribute (a): bsoft: 1 image udptl t38
                Media Attribute Fieldname: bsoft
                Media Attribute Value: 1 image udptl t38
5

On an outbound call Asterisk provides a list of configured codecs, and the remote side has to choose within it.
On an inbound call Asterisk uses the configuration codecs to scope its own response. The remote has to use a codec in that response.

I’d need to see a complete SIP log to understand what is going on.

6

Yep, I’ll turn some logging options on and make another call…

7

@jcolp I’ve enabled debugging options and gave it another try… the log is a bit big to paste here so I’ve put it up as a “gist” on Github:

I also censored some fields (phone numbers, IP addresses, user names), but hopefully there’s enough to work out what’s going on.

To my untrained eye, it definitely looks like my assertion to not use G.729 is being ignored by the provider. Wireshark seems to confirm this.

I think given the host platform (OpenBSD) licensing Digium’s G.729 codec is not an option… there are a few open-source options out there but I’ll have to investigate that separately (I can understand Digium can’t provide support for code they didn’t write).

Is there something I can do at my end config-wise to force the provider to pay attention, or do I have to give my provider a blast for ignoring CODEC negotiation?

8

There’s nothing you can do to force them. They are violating the standard by sending you an un-negotiated payload type. That being said a fix went in to ignore such packets[1].

[1] https://issues.asterisk.org/jira/browse/ASTERISK-28139

9

No problems, well thanks anyway. At least I know where to start looking. Helpdesk… here I come.

10

You could also upgrade or backport that fix, which may resolve the problem. They may be sending traffic before negotiation is complete, assuming that G729 will be negotiated when it won’t be. After a period of time it may switch to what was negotiated.

11

Turns out, there is a asterisk-g729 package in OpenBSD which uses bcg729. Not supported by the Asterisk project itself, but having installed it:

vk4msl-gap*CLI> core show translation paths g729
--- Translation paths SRC Codec "g729" sample rate 8000 ---
        g729:8000        To codec2:8000     : No Translation Path
        g729:8000        To g723:8000       : No Translation Path
        g729:8000        To ulaw:8000       : (g729@8000)->(slin@8000)->(ulaw@8000)
        g729:8000        To alaw:8000       : (g729@8000)->(slin@8000)->(alaw@8000)   
…

So it would appear there are four ways to crack this little nut:

  1. Purchase and install Digium’s module (preferred if support is required)
  2. Obtain and install the open-source codec_g729.so from asterisk.hosting.lv (no support provided by Digium, do this at your own risk)
  3. Update Asterisk to a later version with the aforementioned “ignore unknown codec” patch. (Backports available for Asterisk 16, see gerrit)
  4. Raise a ticket with your voice service provider

I did (4) last night, others have had success with (3) and I’ve just done (2) now but haven’t tested it yet.

12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.