One-way audio for incoming calls - codec negotiation prb?

Asterisk Asterisk Support
1

My problem is that for incoming calls, I can hear the other person, but the other person cannot hear me. I am theorizing it has something to do with codec negotiation.

My setup is like this:

I have a regular phone number through my SIP provider, www.cellip.com.
I have an asterisk installation running Asterisk 1.8.5.0 on Debian linux. Asterisk registers with the sip provider fine and gets the incoming call.
I have an X-Lite softphone that registers with Asterisk.

I can place outbound calls from the softphone through asterisk to an outside number and they work fine, sound goes both ways.

When I get an incoming call, if the call goes to the voicemail in asterisk, everything works fine (you can hear the voicemail prompt, and the message you leave doesn’t end up silent), so I would assume that the Provider<->Asterisk side of things is ok.

When I get an incoming call and answer it with X-Lite, I can hear the other person fine, but they cannot hear me.

Both the X-Lite and the Asterisk are behind nat, different nats. The nat setup seems to be fine. I have configured asterisk with externip= and localnet= and I can see the packets for the rtp stream going through. I have run tcpdump on the asterisk server and wireshark on the X-lite machine and I can see rtp packets containing audio data coming from the provider, getting sent out by asterisk, and received by x-lite. I can also see packets sent by x-lite containing audio data getting received by asterisk and getting sent out by asterisk to my provider.

However, one thing is confusing me. This is from the packet capture from the asterisk machine (local ip 172.26.44.8):

No.     Time        Source                Sport  Destination           Dport  Protocol Info
   2431 31.340843   <xlite machine>       4992   172.26.44.8           5070   RTP      PT=ITU-T G.711 PCMU, SSRC=0x995F41DC, Seq=5184, Time=172280 
   2432 31.341082   172.26.44.8           5076   <sip provider>        40914  RTP      PT=ITU-T G.711 PCMU, SSRC=0x995F41DC, Seq=5184, Time=172280 
   2433 31.359743   <sip provider>        40914  172.26.44.8           5076   RTP      PT=ITU-T G.711 PCMA, SSRC=0xEB8C83C, Seq=14571, Time=1008742139 
   2434 31.359926   172.26.44.8           5070   <xlite machine>       4992   RTP      PT=ITU-T G.711 PCMA, SSRC=0xEB8C83C, Seq=14571, Time=1008742139

As you can see, the incoming audio from the provider is in a-law format, but the outbound audio to the provider is in u-law format. Is this supposed to work?

sip.conf has:

disallow=all
allow=alaw
allow=ulaw

I used “sip show channel” to look at the parameters for the channel between asterisk<->provider:

  * SIP Call
  Curr. trans. direction:  Incoming
  Call-ID:                AA98CBE9-870111E1-A43AE433-C5F01355@62.80.200.60
  Owner channel ID:       SIP/cellip13-00000022
  Our Codec Capability:   0xc (ulaw|alaw)
  Non-Codec Capability (DTMF):   1
  Their Codec Capability:   0x90f (g723|gsm|ulaw|alaw|g726|g729)
  Joint Codec Capability:   0xc (ulaw|alaw)
  Format:                 0x8 (alaw)
2

Usually if the codec negotiation fails you can not establish the call.

I suggest first to get a trace of the SIP messages (SipDebug).

3

If you calling out without problem both way, and experience dial in one-way voice.
It is very likely the codec has the problem.
It could be that your SIP trunk provider try to offer G711 ulaw as priority and your Astersk offer G711alaw.
Some SIP provider cannot allow both way media with different codecs.

My suggestion is to disable the alaw only using the G711u as Xlite will support G711u as well. Most IP phone will accept G711u

Dan
TieUs Technology - Canada SIP Trunk

4

What should I look for in the SIP messages? The log with sip debug is really long. As far as I can tell it looks OK. The channels get established, and the only weird thing I am seeing is that both u-law and a-law are being used at the same time depending on the direction of the data packets.

I think Dan is on the spot though. I changed my X-lite to alaw only and lo and behold, it sends out audio in alaw and when I try calling my X-lite from the cellphone, sound works both ways. The sound coming from my sip provider was in alaw, so I am assuming that is the format they prefer. Even though, from the sip debug log, they seem to claim to support an awful lot of formats:


<--- SIP read from UDP:SIPPROVIDER:5060 --->
INVITE sip:s@ASTERISK:5060 SIP/2.0
Via: SIP/2.0/UDP SIPPROVIDER:5060;branch=z9hG4bK-d8754z-292a386ec7292369-1---d8754z-;rport
Via: SIP/2.0/UDP SIPPROVIDER:5061;branch=z9hG4bK-irtnr2vq5li22bop;rport=5061
Max-Forwards: 69
Record-Route: <sip:SIPPROVIDER;lr>
Contact: "Anonymous"<sip:SIPPROVIDER:5061>
To: <sip:MYPHONENNUMBER@SIPPROVIDER>
From: <sip:MYCELLNUMBER@SIPPROVIDER>;tag=rdt4hed3j4vfgecw.o
Call-ID: 456EA808-89A911E1-936CE433-C5F01355@SIPPROVIDER
CSeq: 207 INVITE
Expires: 300
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
cisco-GUID: 2467822242-2365108000-2820692334-2847467820
h323-conf-id: 2467822242-2365108000-2820692334-2847467820
Content-Length: 417

v=0
o=Sippy 35655624 0 IN IP4 SIPPROVIDER
s=SIP Call
t=0 0
m=audio 54616 RTP/AVP 8 18 4 98 99 2 0 3 101
c=IN IP4 SIPPROVIDER
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=yes
a=rtpmap:98 G726-16/8000
a=rtpmap:99 G726-24/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Anyway, with only allowing the one codec in X-Lite, this seems to be resolved!

5

You are looking for the clearing cause code if the outgoing call was rejected, or any comment in the BYE, if the remote side dropped the call quickly, together with information on the time until the drop.

In principle, the SDP codecs are the ones that the system is prepared to receive, although Asterisk won’t offer ones that it knows the other side can’t handle in the other direction. The RTP stream can use any of the permtted codecs and can change mid-session without any re-invite.

mu-law should be used by ISPs in the Americas, and A-law should be used by those in most of the rest of the world, as those are the codecs used on the PSTN.

6

Ahh, but for a call like this that connects and stays connected until I hang it up manually, there isn’t any interesting information to look for in the sip debug messages? I thought there would be a negotiation process somewhere, where both sides present their supported codecs, and then some kind of agreement is made on what codec shall be used. That was what I was looking for in the sip debug messages.

Essentially you are saying that any codec that the other side has stated it is willing to accept should work, and that the codec can be switched on the fly, without any new negotiation process, just by putting a different codec (from the rtpmap) in the rtp packet? Meaning that the problem I was having is a definite bug in my provider’s software? (if they are not willing to accept u-law audio, then that codec shouldn’t be in the sip invite that they send out)

I reside in europe and so does my provider so a-law would be the codec in use on the PSTN here.