Packet Loss on video when using Expressway in DMZ

[carl_townshend]

Hi All

We have an issue with outgoing Video calls

We have an internal VCS server and and Expressway in the DMZ used for external calls.

Basically when I set the DX80 VC unit to go direct to the internet and not be registered and controlled by the VCS server it has no loss and calls are fine.

As soon as we manage the DX80 with the VCS server, the calls go via the Expressway in the dmz and we get around 6% packet loss and bad picture quality.

I did a packet capture and noticed the flow of udp rtp traffic goes from DX80>VCS, then VCS goes to Expressway in DMZ, then Expressway to external VC, Thats 3 call legs.

How does it route the stream?

Any ideas why I am getting these bad video issues?

cheers

[Justin Ferello]

- Check VCS-C & VCS-E interfaces & switch ports, make sure there are no duplex mismatches or CRC errors.

- Check the firewall interfaces for the same duplex mismatches & CRC errors.

- Does the firewall have an application inspection for SIP & H323?  If so, turn them off, you might be overloading the processor if it is a small firewall.

- Check QoS settings in VCS-C and VCS-E & DX80, if you use QoS on your network.

- Does the VCS-E use a different internet circuit than the DX80 does when set to direct?

[carl_townshend]

Hi

Everything looks fine on the firewall, its a powerful one

We do use QOS on the LAN side, so all OK there.

The VCS E uses the same Internet Circuit as direct.

Why are there 3 legs to the call? seems suboptimal to me.

Is there a way of checking the interfaces from the VCS-C and VCS-E end?

Any other ideas?

[PJMack]

Since you know it's not a bandwidth issue, I'm with Justin on his first bullet - I'd guess you have a duplex mismatch on either the VCSC or E or both. From my experience you will get a consistent packet loss in that 5-10% range in that case. The call traffic goes through both devices when going to/from the internet - that's so you don't need to allow the traffic through the firewall from all inside IP addresses, only the one that is the VCSC. I get your comment that it's suboptimal, but when everything is configured correctly you can easily handle 100 HD calls through that one connection as long as you have the licenses and bandwidth. 

Do you have the LAN ports on the devices set to 100/full or something like that? If so that will only be correct if you are certain the switch port is set the same - if you have auto on one side and full duplex set on the other side the auto side will fall to half duplex and you'll have lots of packet loss. 

If you're not sure - here's what I'd do - set the port on the VCS to auto (if it isn't already), and see (using CLI) what speed/duplex it negotiates to. If it comes back gig/full or 100/full you should be fine, that is a solid indication the switch port is set to auto. If it comes back 100/half then you can bet the switch port is set to 100/full, so in that case you should set your VCS port to 100/full. Do this for the ports on both boxes. 

good luck!

[kurt.clifford]

I have the same symptoms you are currently experiencing with the same setup (SX 80). I am yet to find a root cause.

We have about 20 TPs setup in which this only sometimes the 30-40% packet loss problem will occur. Out of 30 calls we might have only 2 that have high packet loss. Reconnecting a bunch of times will eventually fix the problem.

Can you let me know what firewall you are using? Is it virtual or physical? I am not getting any reports of packet loss on the Expressway C or E which I think is strange. I would have though that the VCS would register the packet loss in the call media report.

[carl_townshend]

In the end we traced the issue to a faulty cable from our Firewall to our DMZ switch, issues were not showing under TCP due to the normal operation, but when UDP RTP traffic hit the port we saw the loss even more.

cheers

[goranpilat]

Hi, 

Did you perhaps manage to resolve this issue?

BR

Goran