E Got a Pkto TimeOut

[bpieslak]

I am trying to troubleshoot call quality issues with VTL over a 3Mbps MPLS circuit.



In looking at the NBXLog files on the 2 V3001 call processors that I have, I see a ton of the following:



E Got a Pkto TimeOut - Application Should Mark Device 0xN 0xN 0xN DOWN



I have no idea what this means. Does anyone know how to interpret this log statement or how to respond to it?



Thanks,

-Brian

[merlin_1]

Packet timeouts are due to the tel not talking to the NBX at certain times . The last part of this message is the mac address in hex . Use the last octets and match it to your mac address for your tel , pri board etc .

Unless the user reports an issue , I would not worry about it . Just means the tel sent a packet and said here I am and the NBX did nto hear it . Happens once in a while , but if you start getting a lot of them  on random Mac addresses , it may be your network . That type of issue ,  you may want to trace out and review your switch config . These are layer 2 only messages . IPcall failed are layer 3 . Mean the same thing .

What kind of quality issues ? Audio issues are very common and either Quality of service or no Multicast for conferencing / updates on the tel are the biggest issues we see a lot of

[bpieslak]

Users have reported static or choppy conversations where the person speaking sounds like parts of words are cut off or there is some kind of interference.



I'm certain it is a QoS issue, as we're only having these problems with our VTL calls across our MPLS corporate WAN.



Currently, Multicast is not supported by our MPLS provider, so we aren't able to conference using VTL.



To add, we're also running Citrix WANScaler (Branch Repeater) devices in both offices to accelerate network traffic. The firm that implemented these for us assures me that they aren't interfering, but that could *also* be a culprit.

[merlin_1]

So it could be bandwidth or the MPLS ....

Well in any event it sound slike you are getting clos e. A network trace on both ends and check for packet times going in both directions is the fastest way to find out QOS issues . Kind of tough to do to count packets , but very efficient .

Good Luck !