VoIP One-way Audio and Voice drops
-
@coliver I have read that a lot of NIC drivers do the VMQ implementation poorly in drivers which can kill performance, so I usually disable it, just to be safe. Most notably, this problem is especially prevalent on the Broadcom chipsets... I see you have intel.
It may be worth a shot, but there will be a brief blip if you use the powershell command to disable VMQ.
get-help VMQ
will list the commands.
get-netadaptervmq|where {$_.Name -eq 'NIC1'}|disable-netadaptervmq
Just replace NIC1 with whichever NIC is currently running your PBX VM.
-
@dafyre said:
@coliver I have read that a lot of NIC drivers do the VMQ implementation poorly in drivers which can kill performance, so I usually disable it, just to be safe. Most notably, this problem is especially prevalent on the Broadcom chipsets... I see you have intel.
This was the issue I had. Poor performance. and it was a Dell server with Braodcom chipset.
-
@Dashrender said:
yeah, I would say this could be your whole problem (only the fact that SIP directly to a phone still had the same problem tells us it's not this error that's likely the problem).
His VM is not the problem because a PHONE with the credentials directly entered has the same problem.
-
lol maybe the brackets around the second part of my statement made it invisible? lol
-
It is obviously a load issue. After ~3-4 pm I no longer see any issues. During the weekend I also saw no issues.
-
@JaredBusch said:
@dafyre said:
@coliver I have read that a lot of NIC drivers do the VMQ implementation poorly in drivers which can kill performance, so I usually disable it, just to be safe. Most notably, this problem is especially prevalent on the Broadcom chipsets... I see you have intel.
This was the issue I had. Poor performance. and it was a Dell server with Braodcom chipset.
IBM server with Intel NICs.
-
Just in case I've updated the integration services for Linux.
-
Moving the VM to my lab server, trying to see if maybe that will resolve it. Currently nothing is running on the lab server. Wishful thinking I know but worth a shot.
-
Try your phone again directly to the SIP trunk.
-
@Dashrender said:
Try your phone again directly to the SIP trunk.
I will tomorrow when the issues start up again. Right now everything is working as expected.
-
@coliver said:
It is obviously a load issue. After ~3-4 pm I no longer see any issues. During the weekend I also saw no issues.
A network load issue. Maybe on the ISP's end? It could be, while unlikely, that RTP traffic is being completely dropped under saturation, kind of like inverted QoS.
-
@coliver said:
@Dashrender said:
Try your phone again directly to the SIP trunk.
I will tomorrow when the issues start up again. Right now everything is working as expected.
I thought that I read that that was tested already?
-
@scottalanmiller said:
@coliver said:
@Dashrender said:
Try your phone again directly to the SIP trunk.
I will tomorrow when the issues start up again. Right now everything is working as expected.
I thought that I read that that was tested already?
I tested a third party SIP Trunk. Haven't done that with the ISP trunk yet.
-
Ah, okay. Thanks.
-
@scottalanmiller said:
@coliver said:
It is obviously a load issue. After ~3-4 pm I no longer see any issues. During the weekend I also saw no issues.
A network load issue. Maybe on the ISP's end? It could be, while unlikely, that RTP traffic is being completely dropped under saturation, kind of like inverted QoS.
Came in this morning to the same issues. I'm in early before most people. The only difference between now and last night is that the manufacturing facility is here and working. Generally they shutdown ~3:30-4:30pm.
-
Do you have good traffic monitoring to get a history on the network saturation and compare it to phone issues?
-
@scottalanmiller said:
Do you have good traffic monitoring to get a history on the network saturation and compare it to phone issues?
No.
-
Might be worth looking into that. There are some free options for that. Ubiquiti and Meraki both have some built in options that are better than nothing. But you can use free tools to collect total traffic from them (at least from the Ubiquiti) that will provide you some historical numbers which should help a lot for correlating that. I would start by tracking when the phones are good and bad in a manual "log".
My guess is that Solarwinds has something free and easy to use for this scale.
-
@scottalanmiller said:
Might be worth looking into that. There are some free options for that. Ubiquiti and Meraki both have some built in options that are better than nothing. But you can use free tools to collect total traffic from them (at least from the Ubiquiti) that will provide you some historical numbers which should help a lot for correlating that. I would start by tracking when the phones are good and bad in a manual "log".
My guess is that Solarwinds has something free and easy to use for this scale.
The problem is that they are always bad. Seems to be every 5-10 seconds that they cut out.
-
@scottalanmiller said:
Might be worth looking into that. There are some free options for that. Ubiquiti and Meraki both have some built in options that are better than nothing. But you can use free tools to collect total traffic from them (at least from the Ubiquiti) that will provide you some historical numbers which should help a lot for correlating that. I would start by tracking when the phones are good and bad in a manual "log".
My guess is that Solarwinds has something free and easy to use for this scale.
Thanks, I grabbed a SolarWinds Real-Time monitor (under their free section) lets see if that will help.
