VoIP One-way Audio and Voice drops
-
@Dashrender said:
I think I agree with Scott.. I wonder if you have a failing switch. Can you replace it.. or for starters.. move the meraki to a different port on that switch?
Switch? The PBX is directly connected (ok it is going through a hyper-v virtual switch but it is the only on it) to the Meraki firewall which is our internet gateway.
At the suggestion of NTG support I directly connected the PBX server to the internet (which is a bit of a chore here) and there was no packet loss and ping/response times were marginally better. I forgot to grab a screen shot of it though.
That pretty much means it is the firewall correct?
-
Well before jumping to that (hopefully correct) solution, have you tested calls to ensure that packet loss is correlating to bad phone calls?
-
Have you looked at wireshark any using port mirroring?
-
@scottalanmiller said:
Well before jumping to that (hopefully correct) solution, have you tested calls to ensure that packet loss is correlating to bad phone calls?
I wasn't able to test the calls outside of the network I didn't have enough time. It takes a good 15-30 minutes to swap out devices with our ISP and I only had an hour to test.
-
I see
That sucks, but it does suggest that the issues are all on the network. -
Should have gone hosted... I would still see these problems but at least people could bring their phones somewhere else to use them.
-
@coliver said:
Should have gone hosted... I would still see these problems but at least people could bring their phones somewhere else to use them.
Sorry that it has to be BUT.... great example use case for where hosted can protect you
-
@scottalanmiller said:
@coliver said:
Should have gone hosted... I would still see these problems but at least people could bring their phones somewhere else to use them.
Sorry that it has to be BUT.... great example use case for where hosted can protect you
I would have done it originally but I couldn't get the numbers from anywhere else and until ~3 days prior to the go live date it was going to be over a PRI.
-
Considering my internet bandwidth (10/10) NTG just suggested that I go locally hosted for my PBX.
How many phones do you have @coliver, how often are they used for internal to internal calling? and what size pipe to the internet?
-
@coliver said:
@Dashrender said:
I think I agree with Scott.. I wonder if you have a failing switch. Can you replace it.. or for starters.. move the meraki to a different port on that switch?
Switch? The PBX is directly connected (ok it is going through a hyper-v virtual switch but it is the only on it) to the Meraki firewall which is our internet gateway.
At the suggestion of NTG support I directly connected the PBX server to the internet (which is a bit of a chore here) and there was no packet loss and ping/response times were marginally better. I forgot to grab a screen shot of it though.
That pretty much means it is the firewall correct?
Oh yeah, well in that case, it's definitely sounding like the firewall - but I thought you swapped the firewall yesterday and it made no difference?
-
@scottalanmiller said:
Well before jumping to that (hopefully correct) solution, have you tested calls to ensure that packet loss is correlating to bad phone calls?
I've been testing calls for the last 20 minutes, just my phone to my cell phone. Watching a ping from the pbx to the SIP Trunk. When the sequence numbers skip I get a drop out in voice.
A small sample size, but there is a correlation.
-
And one more thing, I connected my phone to a testing PBX we have in NC, this is connected over the VPN (so over the Meraki) calling in and out over this line also has the same issues.
-
But you removed the Meraki, put in a Ubiquiti, and had the same issues? That's the part that is confusing me.
-
@scottalanmiller said:
But you removed the Meraki, put in a Ubiquiti, and had the same issues? That's the part that is confusing me.
I can't think of anything else that it could be at this point in time. Everything (at least from what I am seeing) is pointing to the Meraki device as the culprit. Especially since I've factored out all the other networking devices in the chain, even my phone is directly connected to the Meraki.
I'm going to try and get someone to help me configure the Ubiquiti device, I must have made a configuration error when I originally implemented it.
-
Sounds like a plan. For it to be the Meraki is the one thing that would not be surprising.
-
It seems that it is only audio going out not audio coming in. During the periods of packet loss I can still hear the 2nd person (or myself if it is my cell phone) talking but I can't talk to them. Our Network Extender and the Vitelity SIP trunk are also experiencing the same thing.
-
That's because you have RTP. Each direction is unrelated to the other. So the stream of your voice and the stream of their voice are just two unidirectional streams that don't know about each other. So something causing them to fail would not necessarily impact you and vice versa.
-
@scottalanmiller said:
That's because you have RTP. Each direction is unrelated to the other. So the stream of your voice and the stream of their voice are just two unidirectional streams that don't know about each other. So something causing them to fail would not necessarily impact you and vice versa.
Yep, I found it interesting that RTP is only being affected one way regardless of packet loss.
-
@coliver said:
It seems that it is only audio going out not audio coming in. During the periods of packet loss I can still hear the 2nd person (or myself if it is my cell phone) talking but I can't talk to them. Our Network Extender and the Vitelity SIP trunk are also experiencing the same thing.
Interesting. This is a similar problem I'm having with my C@C hosted FPBX and G-Voice sample box, and I'm behind a SonicWall NSA 2400.
I can hear the outside caller, but they get blips when they can't hear me. -
@coliver said:
@scottalanmiller said:
That's because you have RTP. Each direction is unrelated to the other. So the stream of your voice and the stream of their voice are just two unidirectional streams that don't know about each other. So something causing them to fail would not necessarily impact you and vice versa.
Yep, I found it interesting that RTP is only being affected one way regardless of packet loss.
Typically packet loss is one directional. When a ping fails, normally either the ping makes it out but can't return. Or it doesn't make it out but it could have returned. For both directions to fail (when the entire connection is not dead) is unlikely.
