Remote Site - Calls Choppy, Echo. 5

[dsm600rr]

Hello All,

I have a customer with a Main Site that has 8 Remote Sites. One Remote Site is having issues in particular. They are all set up on Avaya 3526T-PWR+ Switches and running Avaya 9608 Phones. The Switches were Configured and VLAN'ed running the Verbose Script. All Sites Point Back to the Main Site which has the 3 PRI Circuits.

This Site in particular is experiencing the following:
• Calls are Choppy and sometimes Echo
• When they First Answer the call - The beginning of the conversation is not heard.
• Will hear one audible ring and then a delay before the call actually connects
• Randomly on answered calls their is no one on the other end. They hear dead air.

We did not set up the VPN Connection between their sites - their data guys did. I am thinking the issue may be the link between the sites? This is the only location experiencing these issues.

Any pointers would be appreciated before I contact their Data Guy.

Thank you.

 

[Pepp77]

Are they SCN, H450, SIP links between the offices?

| ACSS SME |

 

[dsm600rr]

They are not SCN - Not sure on the actual link their vendor set up between the offices. I can find out if that would help.

 

[Westi]

Aegis
you need to have all the information before asking for help.

It is definitely a problem with IP because PRI's don't have issues (normally) you need to know the bandwidth between sites and the setup if it is using QoS settings.
Your issue is that you have to fix something that is not your issue and the IT guys most likely point the finger at you because it is phones that have problems and their computers are fine.

Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[gknight1]

what type of connection is between the sites? if its just a VPN over an open internet connection that would be the first place to start and most likely the problem.

for basic troubleshooting you could ping from the main site to all the remote sites, see how the response times differ. i would to a ping -t and watch it for at least 60 seconds for each site.

 

[jayjr1105]

It's probably H323 going over a site to site VPN. Make sure SIP alg stuff is disabled. Make sure you prioritize the voip traffic through a policy. Also, maybe their internet is spotty. That's all it takes to wreck voip traffic.

 

[DaIPOTek]

Run 2 persistent pings side by side from the remote site to the HQ, one pinging the IPO and one pinging their default gateway. Notice any spikes or response times over 180ms? Dropped packets? Do issues show up on their gateway too? If so great, give that information to their IT department. You can't guarantee quality of voice over a bad connection.

 

[Westi]

when you do the ping also to a -l 1000 so that you use more than just the 32 bytes and 100 bytes instead which will put at least a little strain on the connection.
If I use ping to test some basics I use at least 4 windows simultaneously and with 1000 or 1500 bytes each. If one or more of those fail you know you have a shitty connection.

Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[IPGuru]

general Voip trouble shooting guide

1 Check data network
2 if not resolved go to step 1

almost certainly QOS on the VPN Link, are they transferring data as well?

was the Data company aware of the need for voice when this was set up (is it the same data company that configured the other sites?)
Does the data company understand the requirements of Voice (recently we had one "data" company ask "Whats a VLan!"





Do things on the cheap & it will cost you dear

 

[dsm600rr]

Hello all,

I apologize on the Delayed Reply.

First, here is what their "Network Administrator" Said about the VPN:

"The Remote Location is connected back to our Main location the same as all other branches, site to site VPN.
I have all the VPN’s setup the same, full tunnel (all traffic including voice and data comes back to Main branch 1st along the same VPN). Voice traffic is also prioritized over data.
To my knowledge in regards to VoIP high latency causes issues and this is what I assume you mean by “bad connection” however I have attached a screenshot of latency average for this location through the VPN for the last week and see no change."

They have 10 Remote Sites - All Pointing back to Main, and apparently they are all configured the same way. This is the only site having issues.

I will send all of your suggestions over to their "Network Administrator" and let you know the results. Thanks again.

 

[DaIPOTek]

Its a tough spot to be in. I am very afraid of any network admin that can blindly say "Yes its setup correctly and no I wont look". Latency is one thing that can cause your issues, another is jitter. Either way, this will turn out to be a problem that is outside of the phone system. If possible run your own tests as suggested. Don't take the network guy at his word. Also make sure to run your pings over a long period of time during normal hours, not 10pm on a Sunday. PingPlotter is a great utility that has a free trial. Makes a nice graph showing network suckiness with pretty colors for you to give to them as you say "Fix your ****".

 

[dsm600rr]

Here is what their "Network Administrator" send me: He is currently at the Main Location.

"I cannot ping the 172 subnet (Voice) from my PC or any for that matter because we are on another subnet (192). I can ping from the Remote firewall to the IP office and Gateway, however cannot manipulate the pings very much. I have included the results from the Remote Meraki back to the two IP’s. SIP ALG is not turned on and voice traffic is prioritized over data.

Cant see much from his tiny screenshot.

 

[gknight1]

it doesn't matter if you are going over a VPN and they are prioritizing voice traffic, that VPN is travelling over the open internet, which does NOT provide any sort of prioritization or QoS. basically the firewall is saying, "here send this voice traffic first and keep it a priority", but realistically that is getting lost by the internet provider as they don't care.

 

[janni78]

What gknight1 said =)
QoS won't be considering while the packets are in the VPN tunnel, and their netadmin should know that.

In a few cases where they insisted that this was an issue with the phone system I've setup Wireshark on both sides.
Listening on a call sounding fine on starting end and sounding bad when coming out on the remote firewall should prove what you've been saying from the beginning.

"Trying is the first step to failure..." - Homer

 

[dsm600rr]

Thanks everyone for the suggestions and support. This is definitely one of my weak points as we don't deal Firewalls and VPN Tunnels and what not.

 

[janni78]

If they have Meraki on both sites they can easily set up a packet capture (save as pcap) on the Meraki devices through the Meraki Dashboard.

Just specify the IP of one of the IP phones that have the issue and you'll capture only traffic to and from that device.
After that you can load it to Wireshark and listen to the calls.


"Trying is the first step to failure..." - Homer