1 of 100 calls has no incoming audio! Please help!

Hello, I have two different FreePBX installations for two different companies. One is running Asterisk 11.16.0 (PBX Firmware: 6.12.65-24) and the other 13.2.0 (PBX Firmware: 6.12.65-25). Both are on completely different hardware/internet/etc.

Both companies are reporting this intermittent issue where on rare occasion the incoming caller can hear the person, but the receiver (internal) cannot hear the caller (external). It is a 1-way audio issue! Right now they tell the caller “I cannot hear you, but if you call right back I will be able to”. When the caller calls back a few seconds later, then the audio is fine.

As far as I know all of the port forwarding is set up fine (5060-5080, 10000-20000), and FreePBX has the proper NAT settings.

Searching Yahoo/Google about this problem only returns results based on constant audio issues, not intermittent.

Does anyone have any idea what may cause this problem?

Do you have webmin installed by any chance?

Each call’s audio (RTP) is on a sequential pairs of UDP ports starting on an even number, Webmin uses UDP 10000 by default, try a smaller port range starting on an even number in /etc/asterisk/rtp.conf (or the GUI in sip settings) and align your firewall PNAT rules to suit.

I am not sure what webmin is, but netstat -npa does not show any process listening on port 10000. I also do not have a process running called webmin.

I will try the range 15,000 - 16,000 for now to see if it fixes it.

That should be good for 500 concurrent calls. (technically 15000-15999, 16000 will be bad but that was always how the math is still done wrongly :slight_smile: )

Well ever with the port range changes, the problem still occurred today.

Then I would go the “tcpdump/wireshark with a sip filter” route. Because the SIP/SDP session data would probably contain the necessary clues and you would have time to explore exactly what is amiss.

Here are two short excerpts from the log files. Time-wise they come right after the the log says all of the phones in the Ring Group are ringing, for example, after:

PJSIP/1100-000000aa is ringing…
PJSIP/1101-000000ab is ringing…
PJSIP/1102-000000ac is ringing…
PJSIP/1103-000000ad is ringing…

Success log: http://pastebin.com/CXinMRHK

Error log: http://pastebin.com/tfLT3QQ9

The error log seems to show when the phone is picked up, the “call” is randomly jumped to a completely weird spot (time condition) that has nothing to do with the route in any way at all. It’s completely random.

tc-maint is a red herring it is a scheduled “call” to maintain your “time conditions”.

Ah ok thanks. Upon looking the logs of 2 errors and 2 successes, there does not seem to be any difference at all.

As I said previously:-

That is the trouble with random events, otherwise you are just PITW :wink:

Do you know of a good tutorial on how to packet log SIP traffic then? I am a complete noob when it comes to linux. But I have used Wireshark a lot on Windows.

It’s probably much the same, Google/Youtube to the rescue

Thanks for the videos, I’ll watch them tonight. Since the problem is intermittent, is there a way to start TCPDump through SSH and then it keeps running if I log out? We will have to likely capture 8-15 hours at a time hoping the bug pops up.

something like adding these arguments to your tcpdump invocacation, and using “screen” to isolate the process from your terminal

screen tcpdump -C 128 -W 100 -w /var/log/packetlog.pcap

start with the logfile dated next after a failure.

Thanks, I have it running now. Hopefully a buggy call comes in soon!

We got a packet log of a 1-way call. It seems no incoming RTP packets are arriving. Do you know of any reasons for this? Is it possible a NAT can block a port less than 1% of the time? There was also about 10~ or so ICMP packets that said “destination unreachable” but it was difficult to tell who was the originator of those packets. Any thoughts?

PS: Thanks for all of your help!

Almost always the fault of your router/firewall/gateway device(s), You are presumably looking at the traffic on the inside (LAN side) of that device if the traffic is not there it just “won’t work” :wink: , so go replace/reconfigure it/them.

p.s.

Make sure the SDP session that the SIP invite started is rational as to requested port also.

I’ve been having this exact same problem for the past few months.

In order to help diagnose the cause of the problem, I suggest that we exchange details to see if there are any similarities…

  1. What router are you using? I’m using the Ubiquiti Edgerouter.
  2. Which version of Asterisk are you using (I see you already answered this). I’m using a version of 1.8. Since we’re using different versions of Asterisk, I doubt Asterisk is the cause of this problem.
  3. Who is your inbound provider? I’ve seen the problem using voip.ms, and I use one of the Seattle servers.

One thing that I’ve noticed is that all of the failures I have observed have been on calls coming from Sprint (or Sprint MVNO) mobile phones. I get a lot of inbound calls from Sprint phones because my immediate family and many of my friends use Ting (a Sprint MVNO) for our mobile phone service.

I’ve also consulted with a number of friends who also have Sprint and they have reported having similar problems on outbound calls using their Sprint phones (they can hear the person they are calling, but the person they are calling cannot hear them). One of my buddies reported that it has happened several times when he was calling his wife on her Sprint phone, i.e. a mobile-to-mobile call not involving a FreePBX system or a SIP provider.

I’m not absolutely sure that the problem is Sprint’s, but there are several reasons why it might be. Sprint has a product called “Sprint IMS” which essentially integrates Sprint phones with SIP switches. If Ting or other MVNOs is using Sprint IMS for call routing (which they might be in order to save money), we could be experiencing one-way audio for reasons unrelated to our setups at all. Other Sprint MVNOs may be doing the same. For that matter, Sprint may have switched its call routing over to 100% SIP and that could be causing the problem…

Any thoughts?

[quote=“AdHominem, post:18, topic:27658”]I’ve been having this exact same problem for the past few months.

In order to help diagnose the cause of the problem, I suggest that we exchange details to see if there are any similarities…

  1. What router are you using? I’m using the Ubiquiti Edgerouter.
  2. Which version of Asterisk are you using (I see you already answered this). I’m using a version of 1.8. Since we’re using different versions of Asterisk, I doubt Asterisk is the cause of this problem.
  3. Who is your inbound provider? I’ve seen the problem using voip.ms, and I use one of the Seattle servers.

One thing that I’ve noticed is that all of the failures I have observed have been on calls coming from Sprint (or Sprint MVNO) mobile phones. I get a lot of inbound calls from Sprint phones because my immediate family and many of my friends use Ting (a Sprint MVNO) for our mobile phone service.

I’ve also consulted with a number of friends who also have Sprint and they have reported having similar problems on outbound calls using their Sprint phones (they can hear the person they are calling, but the person they are calling cannot hear them). One of my buddies reported that it has happened several times when he was calling his wife on her Sprint phone, i.e. a mobile-to-mobile call not involving a FreePBX system or a SIP provider.

I’m not absolutely sure that the problem is Sprint’s, but there are several reasons why it might be. Sprint has a product called “Sprint IMS” which essentially integrates Sprint phones with SIP switches. If Ting or other MVNOs is using Sprint IMS for call routing (which they might be in order to save money), we could be experiencing one-way audio for reasons unrelated to our setups at all. Other Sprint MVNOs may be doing the same. For that matter, Sprint may have switched its call routing over to 100% SIP and that could be causing the problem…

Any thoughts?[/quote]

In your case, if the person calls back 5~ seconds later, does the call then work? In my environment, I will have the same people calling in multiple times per day, from the same phones/phone number. They will phone a few times and the call works fine, then they will hang up and call back a few minutes later, and the 1-way audio problem happens. Since we know they can hear us, we tell them to call us right back. They do this and the call, once again, works properly.

[quote=“dicko, post:17, topic:27658, full:true”]Almost always the fault of your router/firewall/gateway device(s), You are presumably looking at the traffic on the inside (LAN side) of that device if the traffic is not there it just “won’t work” :wink: , so go replace/reconfigure it/them.

p.s.

Make sure the SDP session that the SIP invite started is rational as to requested port also.[/quote]

Hey dicko, I have a screenshot that may be of the problem and I am wondering if you can help out (see below). The SIP protocol is properly communicating the IP & Port’s for both devices. The remote device in this case is a FreeSWITCH machine I assume is owned and operated by my trunk provider (Prodosec). The local device is a simple and pretty default FreePBX Distro install. The RTP packets are both being sent & received properly, but the received RTP packets have the data of all -1’s (FFh in the screenshot). Could this mean my trunk provider has an error on their side? A pretty large sample of all 608 RTP packets received look to be all completely filled with -1’s in the data segment.