No Audio - Also unable to accept incoming calls

I am using Twilio as my SIP Trunk and the latest version of RasPBX. I had this working for a year or more until recently some field technicians from my ISP came to upgrade my internet speed. They also added a VoIP system using Grandstream. Ever since I’ve had no luck with my FreePBX / Asterisk system. When I make outbound calls using Zoiper I hear the ringing for like a fraction of a second and then it’s completely silent afterwards. I have port forwarded 5060 UDP and 10000-20000 UDP to my Raspberry Pi. I’m using a DIR-880L as my router. I’m really pulling my hair trying to figure out what changed to make this a problem. On Twilio’s side there aren’t any errors and the calls are being completed with no error reporting. I have tried rtp debugging and it seems like I’m sending and receiving packets just fine. Anyone have any ideas? I put some sample debugging calls below.

Here is a sample call made to a burner phone number that I have. It automatically hangs up after 3-4 seconds:

Here is a sample call made to a random 800 number. In this case I chose to use Target’s phone number. The difference here is that it does not hang up automatically.:

Here is PJSIP logging:

Here is my RTP debug (just a snippet as it’s repeating):

[2021-02-03 17:07:13] ERROR[1200]: res_pjsip_header_funcs.c:410 remove_header: No headers had been previously added to this session.
Got RTP packet from 192.168.0.143:8000 (type 95, seq 014894, ts 2468431455, len 000001)
Got RTP packet from 192.168.0.143:8000 (type 95, seq 014895, ts 2468431455, len 000001)
Got RTP packet from 192.168.0.143:8000 (type 00, seq 014896, ts 2468431455, len 000160)
Sent RTP packet to 34.203.251.242:11684 (type 00, seq 015362, ts 2468431448, len 000160)
Got RTP packet from 192.168.0.143:8000 (type 00, seq 014897, ts 2468431615, len 000160)
Sent RTP packet to 34.203.251.242:11684 (type 00, seq 015363, ts 2468431608, len 000160)
Got RTP packet from 192.168.0.143:8000 (type 00, seq 014898, ts 2468431775, len 000160)
Sent RTP packet to 34.203.251.242:11684 (type 00, seq 015364, ts 2468431768, len 000160)
Got RTP packet from 192.168.0.143:8000 (type 00, seq 014899, ts 2468431935, len 000160)
Sent RTP packet to 34.203.251.242:11684 (type 00, seq 015365, ts 2468431928, len 000160)
Got RTP packet from 192.168.0.143:8000 (type 00, seq 014900, ts 2468432095, len 000160)
Sent RTP packet to 34.203.251.242:11684 (type 00, seq 015366, ts 2468432088, len 000160)
Got RTP packet from 192.168.0.143:8000 (type 00, seq 014901, ts 2468432255, len 000160)
Sent RTP packet to 34.203.251.242:11684 (type 00, seq 015367, ts 2468432248, len 000160)
Got RTP packet from 192.168.0.143:8000 (type 00, seq 014902, ts 2468432415, len 000160)
Sent RTP packet to 34.203.251.242:11684 (type 00, seq 015368, ts 2468432408, len 000160)
Got RTP packet from 192.168.0.143:8000 (type 00, seq 014903, ts 2468432575, len 000160)
Sent RTP packet to 34.203.251.242:11684 (type 00, seq 015369, ts 2468432568, len 000160)
Got RTP packet from 192.168.0.143:8000 (type 00, seq 014904, ts 2468432735, len 000160)

As your using zoiper try iax2, forwarding port udp/4569 as you did with 5060. That should narrow the problem if it succeeds to either the phone-pbx leg or the pbx-pstn leg, but it looks like the sdp negotion failed with twilio, often sngrep gives a more concise 10000 foot view

What would you like to see from sngrep? I’m not really sure how to move forward with iax2.

Its what you can sip session messages nicely navigable, drill down to see the the conversation , drill down further to see the packet, you will see where the traffic is going and the answers or lack thereof, you will need to identify the cause of that lack

For iax2, create an iax2 extension, register to it from zoiper, that’s it.

Ok I will try the iax2 extension and let you know if there’s any changes. Here’s sngrep of a failed called.

imgur . c o m /a/czDP4UU

Edit: I tried the iax2 extension with zoiper and opened up the port you specified to by PBX however I’m encountering the same problem. No audio but call connects.

When the guys at HTC upgraded your speed, it appears that they took away your public IP address and put you behind a NAT; see


The 67.212.54.164 address that Asterisk thinks is yours is actually shared by many HTC customers.

Further complicating matters, they have a SIP ALG in the path. In the 100 Trying responses from Twilio, note that the Via header has a received=100.100.20.139 tag, which has to have been faked because 100.100.20.139 is not routable on the internet.

The best solution would be if HTC could give you back a dedicated public IP (it need not be static). Talk nicely with them and with luck they will honor your request. Without a dedicated IP address, external extensions would not be possible.

Possibly, if you set (in Asterisk SIP settings) External Address to 100.100.20.139 you may be able to make or receive a call. Otherwise, running SIP over TCP (or better, over TLS) will likely solve the problem.

Other options include giving up on the Pi and setting up your PBX in the cloud, where it will have its own public IP. IMO Vultr is a good choice; they give a small free trial for testing. Or, switch to a trunking provider that can sort out the NAT anomalies on their end, e.g. VoIP.ms.

Yeah setting it to 100.100.20.139 doesn’t do the trick. I’ll give them a call thanks for troubleshooting this I was lost. I’ll keep you updated.

Edit: Spot on answer. Everything working again. Thanks a bunch.

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