No audio on outgoing trunk call

Hi. I have a successful setup, internal conversations are fine, and some outbound external (via sip trunk) calls as well, but not all. Inbound is fine too. For some outbound trunk calls to specific external destinations, the internal caller can’t hear the remote side’s audio for about 10-20 seconds although the remote can hear the caller. My setup is a CentOS 6.10, FPBX-13.0.192.19, Asterisk 13.23.0.

Here’s a link to the network diagram.
drive[dot]google[dot]com/file/d/1oFFO6T3fIScmhMAXT6zwiCaHxP52Xj2Q/view

Also here are some settings:

SIP:

[general]
disallow=all
allow=ulaw
allow=alaw
allow=gsm
allow=g726
allow=g722
allow=h264
allow=mpeg4
context=from-sip-external
callerid=Unknown
notifyringing=yes
notifyhold=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
alwaysauthreject=yes
limitonpeers=yes
match_auth_username=yes
accept_outofcall_message=yes
outofcall_message_context=astsms
rtpend=20000
rtpstart=10000
context=from-sip-external
callevents=yes
tcpenable=no
bindport=5060
jbenable=no
tlsbindaddr=[::]:5060
notifyhold=yes
tlsclientmethod=sslv2
tlsenable=no
srvlookup=yes
allowguest=no
defaultexpiry=120
minexpiry=60
rtptimeout=30
g726nonstandard=no
videosupport=yes
maxcallbitrate=384
canreinvite=no
rtpholdtimeout=300
rtpkeepalive=1
checkmwi=10
notifyringing=yes
registertimeout=20
maxexpiry=3600
registerattempts=0
nat=force_rport,comedia
ALLOW_SIP_ANON=no
callerid=Unknown
externip=d.d.d.d
localnet=a.a.a.a/22
;I have to set the SBC IP address as localnet otherwise all internal-to-external (vice-versa) calls can’t hear each other
localnet=c.c.c.c/32
language=en

Typical extension:

[XXXX]
deny=0.0.0.0/0.0.0.0
secret=XXXX
dtmfmode=rfc2833
canreinvite=no
context=from-internal
host=dynamic
defaultuser=
trustrpid=yes
sendrpid=pai
type=friend
session-timers=accept
nat=yes ;other settings have no effect
port=5060
qualify=yes
qualifyfreq=60
transport=udp
avpf=no
force_avp=no
icesupport=no
rtcp_mux=no
encryption=no
namedcallgroup=
namedpickupgroup=
dial=SIP/XXXX
permit=0.0.0.0/0.0.0.0
callerid=whatever
callcounter=yes
faxdetect=no
cc_monitor_policy=generic

SIP trunk:

[SIPTRUNK-1]
disallow=all
username=ZZZZZZZZZZ
; provider does not require secret
type=peer
qualify=yes
nat=force_rport,comedia
insecure=invite,port
host=c.c.c.c
dtmfmode=rfc2833
context=from-trunk
allow=ulaw
allow=alaw
allow=gsm

What’s weird is that when I did a TCPDump on my server, in Wireshark → Telephony → VoIP Calls → Play Streams, the remote side’s audio is there. It just did not arrive at the caller.

Here is also the link to the PCAP file.
drive[dot]google[dot]com/open?id=17QMZcFL933gfDytp3x9vRk8wGXJNiv4k

Sorry for the links, I just registered, I can’t post URL links nor attach files.
Any help appreciated. I’m prepared to pay if necessary. TIA. Edwin

Short answer - the NAT settings for your system are not set correctly. Since it’s the outbound leg, I’d guess that the NAT setting on the extensions is not getting set correctly. Also, double-check your SIP-ALG settings in the border router and make sure they are off. SIP-ALG can cause symptoms like this as well.

Your .pcap shows Asterisk receiving RTP from the SBC but not sending it to the extension, except for a few ‘comfort noise’ packets, until it suddenly switches to ulaw.

Packet 4 shows Zoiper requesting GSM as its first priority codec. I suspect that Asterisk is trying to transcode from the trunk’s ulaw to gsm and that’s not working right. However, unless you have a very unusual requirement, you don’t need GSM at all and disabling it in Zoiper may fix the issue. If not, it will at least make debugging easier. (I would also disable speex and iLBC. If you have a legitimate need for a low bandwidth compression codec, IMO it’s worth the effort to get Opus working. I would guess that the LTE in Cebu is adequate to do G.711 over mobile data.)

I disagree with @cynjut on this one, as it appears that both the extension and trunk have non-NAT connections to the PBX.

Many thanks @cynjut and @Stewart1, really appreciate your prompt replies.

@cynjut, I have tried all different kinds of NAT configurations as I can from suggestions on different forums. Sadly nothing worked. I’ve read about SIP-ALG, it’s not in my internet gateway. I will ask my SIP trunk provider to check the SIP-ALG settings on their Cisco 4221 VPN router.

@Stewart1, yes that’s what had me very confused about, RTP not being passed to the extension. The extensions are on the same net as the server. The SIP trunks are provisioned by the provider thru their own VPN router. I’m not sure if NAT is used. My externip is the public IP of my internet router. I’ll set ulaw & alaw as the only codecs on all endpoints and on the server as well. Noted on Opus. Btw this issue persists across all my endpoints; CSipSimple/Zoiper/XLite softphones, Grandstream ip phones, and analog/PSTN phones connected via Grandstream FXS gateways. Yes, LTE here is more than good specially when you’re not far from the canopies. I have no issues using my mobile’s CSipSimple even when I’m on the move.

Thanks again guys. I’ll try to do your recommendations above and get back with the results.

P.S. Keep in mind though that I have a good number of similar outbound calls which are successful. The issue is just to some numbers; IVRs and PSTN endpoints, local area codes or NDDs. That capture is to an IVR, not sure whether it’s a PSTN or VoIP line.

Hi @Stewart1, here is another PCAP file.
drive[dot]google[dot]com/open?id=1216caIfA7mocbp4wRBioKCKsvNpSGLZ4

call conditions:

  • using X-Lite, only ULAW codec used
  • OpenVPN connection to office Asterisk server from home, via the office internet gateway/vpn server
  • in Asterisk server SIP settings, only ULAW and ALAW are checked
  • call is answered by a real person, I did not hear him but I’m sure if I talked he’d hear me
  • when eventually he hanged up, I heard that MOH which comes from my Asterisk (as if I was put on hold)
  • a few seconds later connection was cut (I did not hangup)

Appreciate your help. Thanks.

P.S. In our Grandstream phones I found out I have to select the 7 available codecs via 7 dropdowns. Not sure if it would work if I choose ULAW for all 7.

I suspect that something is going wrong with the ICE negotiation. In packet 2391 (after about 16 seconds), the trunking provider re-invites the audio without ICE and RTP is passed properly from then on. Unfortunately, the remote party has already hung up, so it is silent.

Try setting
icesupport=no
in the [general] section; ICE provides no benefit in this application.

If you still have trouble, post both the .pcap and the Asterisk log for a failing call.

Is there a reason the PBX is set to an external IP it never uses? You’re PBX should be routing requests to the provider over their VPN connection. So whatever the IP of your VPN side is, that’s your external IP. So whatever b.b.b.b is that is your external IP.

None of these calls are going to be going over your public WAN IP to the VPN (as in public Internet). So you’re telling Asterisk to set your RTP to an IP that they’ll never route to and if they are it’s going to the wrong place.

IMO there is nothing wrong with that, provided that localnet is set correctly. Having externip set allows for external non-VPN extensions and supplementary trunking providers.

I assume that the OP has:
externip=120.89.37.181
localnet=172.16.0.0/22
localnet=10.202.141.84/32

In capture.pcap, I see no evidence of network misbehavior. I found two anomalies but don’t understand how they are related. First, audio coming in from the trunking provider (presumably ETPI) is not being sent out to the extension. But Asterisk clearly knows where to send it because it’s sending comfort noise packets to 172.16.3.254 port 8000, the correct address/port that Zoiper is using.

The OP pressed option 2 about 6.1 seconds into the call and the incoming audio stopped about 0.2 seconds later, which seems reasonable. But there is then silence (other than a little noise) until a disconnect tone is played about 12 seconds later. I can’t see anything wrong with signaling or audio on the trunk that could have caused it. Possibly, there was an unrelated problem at Manulife.

In capture3.pcap, X-Lite is at 10.0.0.2 which isn’t covered by localnet, so I’d expect a NAT problem, but there isn’t one; the behavior is similar to the first case, even though codec issues have been eliminated, which is why I now suspect ICE.

If turning off ICE support doesn’t help, I hope that the Asterisk log will give some clue as to why the RTP is not being properly relayed.

Hi guys. Thank you all for the inputs. I have solved the problem, icesupport=no was the solution. You’re my heroes in this one, special mention @Stewart1, I owe you man.

@BlazeStudios, Tom I need to connect the Asterisk server to the internet, hence its default gateway, thus externip too, is set to the public IP address for various reasons; one for updating CentOS 6.10 and the Asterisk/FPBX modules, another for directly connecting mobile softphone users (opened up VoIP protocols in the internet router), and still another purpose is when I’m outside I connect to the office via OpenVPN for server/network administration tasks. The internet router is a pfSense machine, not only functions as a router/firewall but OpenVPN server as well. Our branches connecting to HO thru the VPN also have their phones register to Asterisk. Right now I’m 10.0.0.2 connecting from home administering the Asterisk box and doing tests from my X-Lite/Zoiper clients as well.

I have tried disconnecting the Asterisk box from the internet, set it’s default gateway to the provider’s “Cisco VPN Gateway” LAN-side IP, externip to WAN-side IP. And still the same problem.

Again thank you very much guys. Problem solved. Edz

Hello everyone
I have problem like your post or the same idea
please go to my post:

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