Choppy Audio on Linux VM Pro in Clound 2

[dsm600rr]

All,

I have a client that provided me a Linux Cloud Server that is running the CentOS .ova

The audio is randomly choppy during testing. This applies to Default Factory .wavs as well as migrated ones from a previous windows VM Pro.

I had the same setup in my test lab (Voicemail Pro running on the CentOS .ova on a VM) and the audio was perfect (Default Factory .wavs as well as migrated ones from a previous windows VM Pro)

I also have Enghouse (Formally Zeacom) running on a Windows Cloud Server, and the audio is perfect on the Auto Attendants.

Suggestion on where to start looking?

I am wondering if there may be an issue on the link between the Cloud Server (which is halfway across the country in a very large companies data center) and the IPO on Premises. Possibly the .ova install got corrupted?

Thank you.

 

[IPGuru]

My 1st suspect would be a problem with the data connectivity
My 2nd suspect would be a problem with the data connectivity*


*I know this is technically the same as the 1st but i is s likely it was worth mentioning twice (apologies to Kryten)


Do things on the cheap & it will cost you dear

 

[dsm600rr]

IPGuru: My initial thoughts as well, however the Zeacom is using the same pipe and is fine?

 

[splittingcodec]

Check the NIC types on the Cloud Server. I've had much more success using VMXNET3 NIC interfaces, and seen other types like E1000 cause QoS issues like you're describing.

 

[dsm600rr]

splittingcodec: I will have them confirm. Thank you for the suggestion!

 

[dsm600rr]

splittingcodec: They are on E1000 - Star for you.

 

[TouchToneTommy]

Seen the same issue - call to the auto attendant is choppy, data connectivity isn't part of the mix at this point.

In addition to changing the NIX to VMXNET3, here are some notes my tier 4 engineer provided working with Avaya

Avaya had me disable RTCP monitoring agent, clear its IP address and enable keepalives. Settings changed eased up on processing of all RTCP reporting and gave more bandwidth to Avaya system. Per Avaya support, R10 Avaya systems are more feature rich and require more processing power. In the long run, It is recommended to increase CPU and Memory resources for RTCP processing. Also, with configured Alarms in the system, Avaya recommends to split programmed reporting alarms into 2 categories, all minor alarms with Minor filter checked and All major alarms under Critical drop down.

Items modified
-On both LAN1 and LAN2 changed RTCP collector IP to 0.0.0.0
-On LAN2, unchecked option to Enable RTCP monitoring on port 5005( was already unchecked on LAN1)
This item can stay on as sends keepalive signal to external devices:
-on both LAN1 and LAN2 enabled keepalives and set interval to 60 seconds

 

[dsm600rr]

TouchToneTommy: Thank you for all of the great information. Star for you as well.

I have the Linux Server Engineer updating the NIC Interface to VMXNET3 as we speak. I will update once I can test if the issue has been resolved.

 

[ACSscott]

Please let us know. I had choppy audio on all calls, also auto-attendant and VM when dialing the shortcode from a system phone so it wasn't SIP trunks. This happened twice, in both instances they couldn't figure out a fix and had to replace the cloud instance...

 

[dsm600rr]

All: Just a heads up, updating the NIC Interface from E1000 to VMXNET3 did not resolve the issue.

 

[dsm600rr]

ACSscott: When you say "had to replace the cloud instance" - did you just blow away the VM and re-create?