Intermittent One Way Audio

Status
Not open for further replies.

adamhunt.gsl

Silver Partner
Basic Certified
Joined
Mar 11, 2020
Messages
6
Reaction score
0
Hi,

Pulling my hair out over this one!

Client is experiencing random intermittent drop outs of the callers voice. The caller can hear our client but the client cannot hear the caller. This happens briefly for 2-10 seconds and largely happens when there are multiple calls happening.

Client is using 3CX Pro hosted on AWS with an SBC running on a Windows Server at the office where 18 handsets are used, all Fanvil supported handsets.

We've rebooted and updated the hosted 3CX server, on-site windows server which hosts the SBC and they did have one day without issue. We've rebooted the gateway/router and checked SIP ALG is disabled, SIP traffic has priority and we do see the below in logs when the issue occurs.

ERR | 20200311-101312.747 | 3CX | SBC | 5316 | rtpcodec.h:370 | Large leap in SEQ: last seen 773863, received 774803
ERR | 20200311-101408.331 | 3CX | SBC | 5316 | rtpcodec.h:370 | Large leap in SEQ: last seen 776531, received 777264

ERR | 20200311-101535.871 | 3CX | SBC | 5316 | tunneludp.cpp:221 | UDP channel has been silent for more than 30 seconds, temporarily disabling UDP
ERR | 20200311-101535.887 | 3CX | SBC | 5316 | rtpcodec.h:370 | Large leap in SEQ: last seen 780058, received 781129
ERR | 20200311-101631.830 | 3CX | SBC | 5316 | rtpcodec.h:370 | Large leap in SEQ: last seen 782621, received 783439
ERR | 20200311-101745.213 | 3CX | SBC | 5316 | rtpcodec.h:370 | Large leap in SEQ: last seen 784373, received 784793


Which to me means that voice packets are not reaching the SBC intermittently.

Has anyone seen this and can offer any advice?
 
So this is a hosted system with no software firewall in front of it.

and checked SIP ALG is disabled

Despite the above due to the random nature of the issue I would of said SIP ALG on the local side however if you can confirm this 100% I would ask how much knowledge have you of the local site ?

I had a similar issue once before where the customer (and third party IT) despite the settings on the edge router had calls routing via internal Layer 3 devices (which were unknown until checking).

I would also consider if you can easily replicate the call to capture it using Wireshark as it would give a good indication of where the audio path is being stopped.
 
Thanks for the reply.

Correct, disabled SIP ALG or as it's known Conntrack SIP Module on the Edge Max Router.

We manage the whole site on-site and the hosted server on AWS which is just using the standard AWS security groups.

We're going to run Wireshark for a bit trouble it, it can go hours without doing it. After rebooting the Windows server night before last we had an entire day without issue.

We're also going to try running the SBC on a different box to eliminate the server being the issue.
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,939
Messages
589,844
Members
164,826
Latest member
Ravex comms