I have an E20. I'm getting transmit (TX) packet loss above 15 percent. However, my receive (RX) packet loss is 0 percent. The distant endpoint is the inverse - TX = 0 percent & RX = 15 percent plus. Looking at the switch port, I've got no dropped packets or CRC errors. So, one question I have is how is the packet loss being calculated? More importantly, what can I look at? I've checked my cables and they are good. One E20 is in campus bldg. A and the other is across the city if that helps.
Have you check the ethernet speed of both endpoints? Have they negotiated 100/Full as expected? What about your QoS in the network, are the endpoints marking QoS correctly? Are the network devices ready to prioritize the video traffic according to the marking used by endpoints? What is the bandwidth used in the call? If you try to decrease the bandwidth, does something change?
Those are things which I think you should investigate.
Please rate replies and mark question as "answered" if applicable.
Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
You could to a tcpdump directly on both devices (check that all involved systems have their time synced with ntp, that makes it easier to find packets in different traces) and compare both and see if you already send out some damaged packet.
You could do the same with mirror ports on the network.
If you have the chance to grep one of the systes and place both in the same network you could see if this is the problem.
Replacing the networr cables and check the network cables could also be worth a try.
Also check that the right interface on the e20 is used.
In general thats generic troubleshooting, just try to elimiate different factors and see what happens, ....
My money would be on the good old duplex mismatch somewhere along the path. This doesn't have to be between the CODEC and the local switch, but could be at ANY point in the chain - even on equipment out of your visibility.
For instance, we had a nightmare recently trying to track down packet loss issue at a remote campus site that was connected via a GRE tunnel to the main campus. The network manager looked at every port on every switch and router on both campus', but couldn't find an issue. It was only after I visited the site and noticed that the traffic LEDs on a port on a switch (belonging to the provider that connected their edge router to a fibre link) was merrily blinking slow Orange indicating a fault on the port. Turns out that this had been configured incorrectly with one side forced to 100/full (on the their) router), and the other set to Auto Negotiate. This is the classic mismatch where the Auto negotiate side will default to 100/half.
Whilst the entire remote campus was affected, no one really noticed any problem apart from with the videoconfernceing that result in a multitude of lost packets in one direction.
I take it that this call does NOT route through VCS? Are you able to make remote calls via a VCS to a separate know good remote site? The VCS is a great tool to narrow down where a problem lies as you can check the media stats on the INCOMING leg, so combined with stats from the endpoint, you can at least narrow down the network segment where the issue is occurring.
To fault find the issue further, I would suggest testing the local campus first. A simple test is to locate a CODEC as close to the egress of the network as possible, then make a call to the first CODEC and the second. This again narrow down you search. Do the same at the other end and you can then eliminate either your own network or the providers.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...