Endless loop of blaming and finger pointing from IT vendor 2

[eaglepromopro]

Has anyone been accused by the IT vendor of being the one who is at fault for the QOS problems on remote 9608IP sets?

I have an 9.1 IPO 500v2 that has been in service for about 5 years with no problems using 9508 sets at the local office a PRI and a UCM drive with VMP.

It replaces their old reliable Nortel workhorse and works like a dream. It's on a long term APC UPS.

We put in a few remote 9608IP sets and all has been well with those for over a year months. They are all connected to local commercial locations via Cox coax

Now we have QOS problems, rebooting and all the classic QOS problems with it pointing to it being the IT network.

I have checked with Cox and all modems in the remotes commercial offices are just fine. As a matter of fact those remote offices were using DSL and now they are using coax.

It just frustrating when the IT vendor who is on site all the time adding and changing their network that will not help resolve this problem.

"It's the phone guys Avaya system causing the problems and not our network". Of course they sell a VOIP product.

Any experiences or suggestions would really help so I can go to the owners.

Thanks!

 

[IPid10t]

Always fun when the network guy's get involved. Not many understand VoIP networking and love to point their fingers. First thing i would do is have them make sure that SIP ALG/SIP transformations is disabled on the firewall, as well as Deep packet inspection, or really anything on the application layer as they are usually the number one culprit for quality issues on SIP, and H.323 traffic. VoIP traffic is so particular that even if a packet is sent out of order or dropped it can cause noticeable problems.On the IP office side you can also go to the Extensions tab and find the H.323 extensions and make sure you have "Allow direct media path" disabled. What firewall do they have?

 

[Westi]

If I get angry enough I usually put an IP phone locally to the system and give it to the receptionist or some other high volume caller. You can even use the second LAN port but that skews the result slightly as it is a different LAN port.

If they do not have any issues locally then I tell the customer that they do the exact same thing but not use the network resources as much aka the firewall and the Internet connection.

The problem is also that customers do not get the role that the network plays for remote phones. There are only 2 devices involved that belong to the phone system and 30 devices that belong to the network team, the ISP and then the Internet which means it could be anything.

Wireshark traces on the LAN port are also a great thing and impresses customers if you play them the lousy audio that comes in and the good audio going out. Then a second wireshark trace for the same call on the remote end that has the opposite quality shows it crystal clear. It is a lot of work but it ends the finger pointing pretty quick.

I don't do that for a 5 phone customer because that is not worth the effort TBH unless the time is paid for if I can proof that it is not a system issue.

Lastly the issue seems ALWAYS to be the firewall if it has Sonicwall written on it. Not that the firewall can't do it but there are next to no people out there can can get this thing working properly and that includes Sonicwall support.

Joe
FHandw, ACSS, ACIS

https://www.millsidetc.com/

 

[nnaarrnn]

the issue seems ALWAYS to be the firewall if it has Sonicwall written on it. Not that the firewall can't do it but there are next to no people out there can can get this thing working properly and that includes Sonicwall support.

Weird. I've never had an issue with SonicWalls of varying sizes and IP Office setups, using SCNs, SIP trunks, remote phones, VPN phones, etc...

I will say that I have had a hiccup here and there where DPI-SSL inspection messed with Encrypted RTSP streams when the Voice "Zone" wasn't in the DPI-SSL bypass list.