Audio issue

[ClearCall]

On about 10% of our inbound calls neither party can hear anything. When I check the recording of these calls, I can hear my agent but nothing from the caller. I have tested myself by calling multiple times until the behavior is repeated then check the recording. I hear the agent on the recording but not myself so it is not just that the caller isn't saying anything.

This behavior occurs on different In_groups, DIDs, agents, computers, from different callers and at different times.

I have read elsewhere that it is probably a firewall issue but if that were the case wouldn't it affect all calls as opposed to some? The asterisk log and pcap logs look the same on a "good" call and a "bad" call as far as I can tell.

UDP ports 10000 to 30000 are open.

Any suggestions?

[bobchaos]

It's a common SIP issue usually associated with NAT. You can try editing your /etc/asterisk/sip.conf and set nat=yes and set the values for externip, fromdomain and localnet. As for the udp ports to open, they must match the value found in /etc/asterisk/rtp.conf. If you need more info this just google "asterisk SIP one way audio" and you'll find just about a zillion articles o.O

If editing sip.conf is not enough, you may need to setup a STUN server, never had to do it myself but its also well documented on the internet.

*Edit*
Just reread your post, if it's only 10%, there's a solid chance it's because your open ports don't match rtp.conf everywhere, or you have some other service interfering with those ports.

[ClearCall]

Thanks bobchaos. Nat is set to yes. We tried opening all udp ports, tried adding every possible block of our carrier's IPs and even tried disabling the firewall altogether. The behavior persisted.
We ran a test with our carrier with them handling all the media traffic so our server only had to communicate with their signaling IP and all calls came through perfectly. When they set the line back so we had to handle the rtp requests again the problem returned.

Any suggestions?

[bobchaos]

What are you using for timing? Got a telephony card or are you using dahdi_dummy? Try running dahdi_test and see if you get high accuracy, if not you'll need to use a different device for timing (like a Sangoma USB timer, a Digium telephony card or maybe just the timing data provided by your carrier over the wire like you did during your test).

If your timer looks all good (like 99.975+ accuracy at it's lowest) then it may be time to break out Wireshark or similar tools and start following RTP streams :/ it's somewhat painful work but it WILL narrow down the problem for you.

Also don't forget, when using NAT sometimes you need a STUN server. I've personally never needed one, but then very few of the systems I install/support are exposed to the internet.

*Edit*

It's unlikely given the symptoms, but it could be a capacity issue. How many agents do you have, on what kind of campaign and hardware?

[ClearCall]

Timing is between 99.989 and 99.999. One line read 99.96.

We ran a Wireshark log which included a no audio call and sent it to our carrier but that didn't seem to provide any hints.

It's not a capacity issue. We have less than 10 agents in inbound manual mode who only receive inbound calls. Server load is low and the no audio occurs even when there is only one call.

[bobchaos]

Sadly, unless you have the coolest carrier in the world, you can't really trust them to look at the pcap for you. They will look at it just long enough to prove it's not on their end (if they even know what they are talking about ) and then wish you good luck. Best to load up Wireshark GUI yourself and look for anomalies in the relevant streams.

That being said it may be time to setup a STUN server and see if that does the trick. It will rule out NAT traversal issues.