SCN Voice Quality Issues

[cmnstr]

We are troubleshooting an issue where there are 4 sites connected via SCN. Call quality was good until 3 weeks ago until switching carriers. Now, when someone calls into a remote site the auto attendants are garbled and voice mail messages are so poor you are unable to hear them. Voice mail server was originally in site 2 but when someone called site 1, 3 or 4 the quality was poor but site 2 was fine. Moved voice mail server and licenses to site 1. Now site 1 is clear but calls to/from site 2, 3 and 4 are poor. Carrier states they do not have packet loss on their network. When I ping site 1 to other sites using SSA I am able to ping consistently. However, when I try to ping from the voice mail server I get "destination host unavailable." Also, when trying to pull a config from the voice mail server to other sites I can see the system but get a network error if I attempt to log in. Can pull a config from local system with no problem.

Carrier states it is a problem with the IP Office but can't give me any reason why they feel that except they say they are seeing packet loss. I changed the NIC from LAN to WAN to try to rule out a NIC issue. With the ping issue from vm server I just don't see this as a IP Office issue. Has anyone experienced this before? Also, IT group is asking for voice packet size. Does anyone have this info? I am unable to find it in documentation.

 

[IPGuru]

Call quality was good until 3 weeks ago until switching carriers.

That is all you need to know
The problem is with your new carrier.

They probably do not have any QoS guarantees on the network.
VoIP Quality will be poor even with no packet loss if packets are delayed.




A Maintenance contract is essential, not a Luxury.
Do things on the cheap & it will cost you dear

 

[cmnstr]

While I agree with your statement, the carrier has assured us they have QoS on their network.

 

[IPGuru]

if I had £5.00 for every time a data guy told me their end was ok only to prove them wrong I would not have a mortgage any more

A Maintenance contract is essential, not a Luxury.
Do things on the cheap & it will cost you dear

 

[cmnstr]

Again, I agree with everything you are saying. I can only go by what the carrier is telling us regarding QoS. I have dealt with this carrier for years and am certain this is their issue but need to do all I can to try to eliminate the IP Office as the source of the problem. Do you happen to know the voice packet size across the SCN?

 

[StubbedmytoeonIPO]

Is this network connected via VPN, MPLS, Private circuits?

Depending on the answer to the above question, when the carrier was changed did you keep the same routers and switches? What else changed in relation to the switch to the new carrier?

Customers and carriers need to understand that the PBX is a the mercy of everything else connected to it. All it can do is send a receive. If I take two IPOs and put them on a bench next to each other and connect them with a patch cord everything works perfectly every time.

I need more facts to help you.

 

[amriddle01]

You can indeed believe the carrier, but you must absolutely believe the facts, those being 1) call quality issue in VoIP are 99.9% due to the network and cannot be rectified via system programming or hardware changes and 2) This happened at the exact time you switched carriers.

This is the carriers issue, it's as clear as day. They may well have QoS enabled on the circuit but this just means that the fault isn't that QoS is off it's something else. It's not end of story not their fault just because they say it's on, they need to find out why it's still happening despite them configuring QoS. Perhaps why it's not being honoured, why its not having an effect etc etc

End of the day no point coming here, there is pretty much F all we can help with here

 

[janni78]

If you want to prove them wrong put packet logger on each site, listen to the call going out from the site and the same call when it comes into the other site.
If it goes in fine and comes out bad it's clearly their fault. You can also send them a bill for the time it took you doing their job =)

Telecom always gets blamed first, then we have prove them wrong.

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

 

[cmnstr]

After 12 years with IP Office and 25 years in IT I completely agree with everything you guys are saying. As far as the question about the network, it is MPLS between all sites except 1, where they have 3 bonded T-1s. I have been trying to find the answer to the packet size question to give to their IT person and have found anything from 20 to 100kb. Does this sound accurate? I know a voice packet is not as large as a data packet so if they use the 1500kb setting it should be fine, correct?

I appreciate the feedback from everyone. At no time have I ever felt this to be an IP Office problem.

 

[mattKnight]

As far as the question about the network, it is MPLS between all sites except 1, where they have 3 bonded T-1s

Couple of questions...

1) Is the bonded t1 access to the MPLS cloud or a PTP

2) Are the routers on site managed by the carrier or the customer?

Can you ask the carrier to tell you, rather tthan a bold QoS is enabled, what the bandwidth for EF and the other categories are.

It is worth checking witha packet capture that you are marking your traffic correctlt inbound and receiving the markings ok.

I've had carriers apply bandwidth incorrectly and then drop out of contracted traffic....

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[amriddle01]

Monitor will show you how much packet loss etc the far end experiences (better than SSA) in the RTP steams, this can only be due to the network, if that figure approaches 8+ then you'll notice issues as that's 8% packet loss and that's when you tend to start hearing anomalies in my experience

 

[gknight1]

i believe packet loss usually indicates a mismatch in speed and/or duplex. I know some carriers lock down the port they are giving for connectivity, make sure it matches the IPO if you have it plugged in directly to the IPO.

 

[StubbedmytoeonIPO]

I read your original post again and I realize you only say the audio is garbled in relation to the voice mail. Does this mean that regular calls are fine? You try to ping and get destination unreachable. Is the voice mail server on the LAN port and the SCN on the WAN? If the only time you are getting garbled call is to the voice mail then I would say it is not a carrier problem.

 

[cmnstr]

Each location has analog trunks so regular calls are fine once connected to a live body. Auto attendant, voice mail and site to site calls are garbled. Voice mail server and IP Office are connected via the LAN, I am just using the WAN port of the IP Office to try to eliminate the IP Office NIC as a possible cause of the problem. AA and VM calls to the main site where VM server is located are fine. Only affected calls are those to the remote sites where they are using the H.323 trunks to connect to VM server. There is really no doubt it is a network or carrier problem. It is just that my 12 years of IP Office and 25 years of data networking experience are not good enough and they want an opinion from someone else. Of course, the answer is always the same. Einstein said it best. "Insanity: doing the same thing over and over again and expecting different results.

 

[amriddle01]

What about loading VM Pro on another machine and then testing again, sounds like the server/server port/switchport settings now

 

[cmnstr]

When this all started, the voice mail server was in South Carolina at site 2 and their audio was fine. Orlando (site 1) had such poor audio they couldn't do business. Carrier blamed the IP Office (big surprise!) So we went through the process of a dongle swap and moved voice mail to Orlando with all new hardware, clean VM Pro installation, different OS. Now the voice mail in Orlando is fine but calls to the other locations are poor. Carrier still wants to blame the IP Office so we swapped the NIC on the IP Office Tuesday evening but still have the same issue. I even suggested swapping the NIC in the voice mail server in Orlando but I am not convinced this is the problem since the problem existed prior to bringing the new vm server online. My opinion is either something wrong with the network or a switch, or possibly some routing that was missed when changing carriers. Of course, there is still the carrier as a possibility.

 

[gknight1]

ask them what their NIC speed and duplex are set to on the port they are handing off to you, if they can't tell you then there is your problem? is that port going into a router/firewall before it goes to the IPO, or is their port directly into the IPO?

 

[cmnstr]

The IP Office and VM server are both behind the router on the same subnet. I will have to check on port speeds on their switches but knowing this customer I am guessing it will be gigabit.

 

[mattKnight]

>I will have to check on port speeds on their switches but knowing this customer I am guessing it will be gigabit

That's not the point.

As GKnight has pointed out, if the switch port is set to auto-negotiate speed & duplex, but the carrier route interface is configured to 100 FD, you will have problems.

if the customer can supply something like (in cisco world) a show interface gi0/x (the port to the router) that will go a long way to helping


Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[StubbedmytoeonIPO]

I think this is a carrier issue. The voice is on a VLAN or is all traffic handled the same? On windstream MPLS jobs I have done I have seen this be an issue. Don't know who your carrier is but I'm going to guess this is a routing issue or the design of the carrier solution is misconfigured.