Recurring Complaint - "cutting out" on calls

[aschear1]

Background:
Running vers. 4.5.16 on Debian 9.13
Hosted on Vultr - Using 50% Dedicated Server (4 CPU, 16 GB RAM) (This still does have a virtualization layer - The true dedicated & bare metal offering is sold out in my preferred and most other DCs)
No NAT

In an attempt to fix the problem, I recently migrated the customer from vers 4.5.12 on Debian 8.11 Hosted on AWS on t2.medium (2 CPU, 4GB RAM - NAT)

The problem:
On a server with 5 tenants and 40 extensions, I have 1 extension who consistently complains that calls "cut out" and they have to hang up and use their cell phone. This customer has 14 other phones in the domain who have never made a single complaint. Almost every single call in the log is 4.5 MOS. I have seen some that are 4.45-4.46 but the MOS never correlates to when the client complains.

The local network has Verizon Fios 75/75, Sonicwall TZ SOHO. Consistent NAT enabled. SIP Transformations off.

I've replaced the clients phone multiple times with brand new T46S and T27g models. I have swapped phones with people who don't complain and the issue persists.

Call recording was on during on AWS and Vultr, and if I listen to the calls where the client complains I hear no discernible breaking up or audio issue, but the client is like "The audio is really bad I have to call you back (and both sides sound crystal clear on the recording!)"

Edit: We use Flowroute for trunking in and out. Registration via TCP.

I am going crazy. Can someone give me an idea of what do here? is the client just messing with me at this point?

 

[bdmonsey]

Firstly, SonicWall in general doesnt give you the easiest time with VOIP in general.
Have you tried switching him to TCP?
If I remember correctly, there is a timeout setup on the sonicwall for voip CLICK HERE .
I would divide the network and put the phones on a more simple router, be aware that if you use the FIOS router that verizon offers you might have issues with that itself since some of their routers dont allow to change the SIP Alg settings.

Hope I was somewhat helpful
Good luck

 

[DigitalDaz]

Is it possibly the physical wiring to that particular clients desk? Do they have a PC plugged into the phone?

 

[aschear1]

Is it possibly the physical wiring to that particular clients desk? Do they have a PC plugged into the phone?

Interesting that you say this.

Months ago, I took a fairly high end cable tester to the site to try to rule this out. I plugged in and got an "OVER VOLTAGE" alert - consulting the manual said this meant >60v was on the ethernet line.

I tested all the neighboring jacks and did NOT have this issue. I installed dumb PoE switch on an unaffected jack and the client is still reporting issues.

 

[KonradSC]

A couple of thoughts. Do a packet capture of the full call (SIP + RTP). Best if you can do this directly on the server or a mirror port of the server.

In Wireshark, select Telephony -> RTP Streams, then Analyze. Look at the Graph. Do you see big jumps correlating with the dropped audio? Also, in the Forward & Reverse chart do you see of Marker bits correlating with the dropped audio? If so, I'm guessing that FreeSWITCH is root cause of the issue & not the network. I've seen LUA scripts that use some sort of "blocking" process that causes FreeSWITCH to reset the RTP timestamp on calls. When the timestamp is reset a Marker Bit is set in RTP.

So what in LUA could cause this? I've seen two things on my system. The first was if lua issued a "mkdir" function. These mkdir functions are in a couple places throughout the voicemail script. The second is voicemail transcriptions.

The easiest test is to disable vm transcriptions. The other way to test the 'mkdir' stuff is to comment it out or maybe to add a bunch of 'mkdir' lines in the voicemail lua and see if you make it better or worse.