my System is an Asterisk 13.10 and I have many SIP devices that forces G722 Codec.
So If I call anyone who only support alaw, Asterisk should translate to G722, that the Device can handle this.
But Asterisk do not transcode.
In Sip.conf for Test my Provider: Telekom has:
disallow=all
allow=alaw
And the SIP Device has:
disallow=all
allow=g722
So if I make a Call from the Device, the other can hear me but I can’t hear the other side.
So I think Asterisk do not transcode correctly.
In CLI output of “core show translation paths g722” is:
--- Translation paths SRC Codec "g722" sample rate 16000 ---
g722:16000 To g723:8000 : No Translation Path
g722:16000 To ulaw:8000 : (g722@16000)->(slin@8000)->(ulaw@8000)
g722:16000 To alaw:8000 : (g722@16000)->(slin@8000)->(alaw@8000)
g722:16000 To gsm:8000 : (g722@16000)->(slin@8000)->(gsm@8000)
g722:16000 To g726:8000 : (g722@16000)->(slin@8000)->(g726@8000)
g722:16000 To g726aal2:8000 : (g722@16000)->(slin@8000)->(g726aal2@8000)
g722:16000 To adpcm:8000 : (g722@16000)->(slin@8000)->(adpcm@8000)
g722:16000 To slin:8000 : (g722@16000)->(slin@8000)
g722:16000 To slin:12000 : (g722@16000)->(slin@16000)->(slin@12000)
g722:16000 To slin:16000 : (g722@16000)->(slin@16000)
g722:16000 To slin:24000 : (g722@16000)->(slin@16000)->(slin@24000)
g722:16000 To slin:32000 : (g722@16000)->(slin@16000)->(slin@32000)
g722:16000 To slin:44100 : (g722@16000)->(slin@16000)->(slin@44100)
g722:16000 To slin:48000 : (g722@16000)->(slin@16000)->(slin@48000)
g722:16000 To slin:96000 : (g722@16000)->(slin@16000)->(slin@96000)
g722:16000 To slin:192000 : (g722@16000)->(slin@16000)->(slin@192000)
g722:16000 To lpc10:8000 : (g722@16000)->(slin@8000)->(lpc10@8000)
g722:16000 To g729:8000 : (g722@16000)->(slin@8000)->(g729@8000)
g722:16000 To speex:8000 : No Translation Path
g722:16000 To speex:16000 : No Translation Path
g722:16000 To speex:32000 : No Translation Path
g722:16000 To ilbc:8000 : (g722@16000)->(slin@8000)->(ilbc@8000)
g722:16000 To siren7:16000 : No Translation Path
g722:16000 To siren14:32000 : No Translation Path
g722:16000 To testlaw:8000 : (g722@16000)->(slin@8000)->(testlaw@8000)
g722:16000 To g719:48000 : No Translation Path
g722:16000 To opus:48000 : No Translation Path
g722:16000 To none:8000 : No Translation Path
Asterisk 13.11.2 here and I am experiencing the same issue:
Inbound call from ITSP (alaw) -> Asterisk -> IP Phone (g722) = works with asterisk transcoding
Outbound call from IP Phone (g722) -> Asterisk -> ITSP (alaw) = cannot hear the called party.
This happens with all endpoints being configured to allow for g722,alaw,ulaw. I also tried to restrict the IP-phone’s endpoint to allow g722 only, but with the same outcome. Changing the IP-phone’s configuration to only allow g722 and no other codeds however seems to work. NAT should not be an issue, as there should be none (asterisk running on the gateway machine, with access to both public/private interfaces).
Somewhere I’ve read about problems with SIP phones from various manufacturers that could be caused by Asterisk/PJSIP using different codecs for sending/receiving data from a single device. Could this issue possibly be related? IP-Phone used here is a gigaset S850A GO.
If your router also performs NAT, then this is likely the cause of your problems. Getting SIP to work behind NAT will likely require port forwardings to be set up on your router and/or opening pinholes in your firewall from the inside, by sending out packets at regular intervals to keep these pinholes open. It may also require additional configuration on the router to have it use the same port numbers on the public interface as in the packets received on the internal interface (static-port).
Have you checked the output of ‘pjsip show channelstats’ during a call (with and without your fix) ?
From my observation so far, I have found the following things:
‘pjsip show channelstats’ seems to outright lie about the codec used on the channel. It displays ‘ulaw’ although rtp debug indicates packets are actually exchanged in alaw format. For channels where the expected codec is g722, it displays no codec at all.
Combinations where ‘pjsip show channelstats’ shows one channel to use ‘ulaw’ and the other displays no codec at all seem to work, whereas a combination where both channels are indicated as using ‘ulaw’ have one way audio.
In a failing scenario with one-way audio, rtp debug seems to indicate that asterisk is receiving type 09 (g722) packets from my IP-phone (expected behaviour), but is sending type 08 (alaw) RTP P2P packets to the IP-Phone (this I did not expect).
ASTERISK01*CLI> pjsip show channelstats
No such command 'pjsip show channelstats' (type 'core show help pjsip show channelstats' for other possible commands)
Sounds like your issue is the native bridge, not the trascoding, as such. You should not get a native bridge if the codecs offered by the remote sides are not compatible.
Raise a bug report. You will need to enable the full log, set debug and verbose levels to 5 and use “sip set debugging on” to get the level of evidence needed to show that a native bridge is being created in error.
Did you ever raise a ticket for this or find some other workaround? I was experiencing a similar issue where one endpoint was sending ulaw and the other alaw, and I was getting a native bridge. Using your workaround fixed the problem for me as well. Running 13.1.0 packaged in Ubuntu 16.04.