Missed packets in Monitor? 9

[atcom]

Anybody know what these messages mean in monitor? It would sure help if it told us why the packets were "missed"!

********** Warning: Missed 13 packet(s) Total late 0 packet(s) **********

The context is a SIP trunk that's acting up - this issue seems to come up far more often after an upgrade from 9.0.x to 9.1.3

-----------------------------------

Calgary Telephone Systems, Avaya LG Asterisk (FreePBX) VOIP & TDM

 

[amriddle01]

Monitor uses UDP and if you understand networking and protocols etc then you'll know UDP packets can't be resent, monitor can't tell you why, it just knows some packets that left the system didn't reach it.

 

[atcom]

So your saying it's just paying attention to the incoming RTP packets and realizes there's a gap in the numbering/timing? If it sends the message saying 12 packets were missed then another one that says 7 packets were missed does that mean it received a few in between the missing ones?

-----------------------------------

Calgary Telephone Systems, Avaya LG Asterisk (FreePBX) VOIP & TDM

 

[amriddle01]

Yep, it tells you as soon as some are missed, so if it happens a lot that tells a story about the network it's using

 

[atcom]

For sure, I just wish there was a bit more info as far as what ports the packets are arriving on etc.

-----------------------------------

Calgary Telephone Systems, Avaya LG Asterisk (FreePBX) VOIP & TDM

 

[amriddle01]

Monitor uses port 50794 (UDP)

 

[janni78]

Just to clarify, it doesn't mean that the IPO lost RTP packets.
It means that Monitor missed log packets from the IPO.

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

 

[intrigrant]

Now I'm lost

 

[sizbut]

You also need to be aware that the screen trace is not just showing you the packets as recieved, It is interpreted, ie. monitor reads the packets and replaces some of the cryptic values with text (ie. replaces common protocol numbers with the protocol name). That may take milliseconds but it still takes time. So if you have a lot of trace options enabled from a busy system packets will be missed as it can only buffer so many.

If all packets are vital then log to file and not screen and only log trace options that are needed.

Also watch out for LAN port mismatches. Don't expect a monitor PC with a 10Mbps port to monitor all traffic on a busy SE system with Gigabit ports. There is even a setting in WCP to slow down the sending of packets at times in order not to flood monitor.

Stuck in a never ending cycle of file copying.

 

[intrigrant]

Monitor has a usefull function build-in which is often missed by many users : the F4 key.
If you do a trace on lets say a single SIP call then all SIP calls and extension are traced.
What do do? If you have gathered all data which holds the event you are looking for then pause the trace, search for the call you want to study, select a unique common parameter in that call and
press F4.
A new window opens only with the data af that specific call.
You can have multiple windows opened with F4.

 

[derfloh]

I didn't know that either. I will check that tomorrow. Have a star for that good hint!

 

[intrigrant]

Doesn't work on lost packets though

 

[Jimmyjoe1975]

I am also receiving those messages.
From Avaya Support told me that I should check the box of "Enable Traffic Control" in WebManager but it didn't make the trick for me.
I have a ticket open in Avaya about it. We will see...

 

[sizbut]

What ticket! just wasting time and effort. Read the answers above. If you need to track every packet of external communications (eg. SIP, H323, ...) then use a tool such as Wireshark. IP Office Monitor's niche is the internal communications between the various IP Office interfaces.

Stuck in a never ending cycle of file copying.

 

[amriddle01]

You're focusing on the wrong thing here, I have yet to see he system cause such SIP issues, this will be the network/internet connection/SIP provider, you are just delaying a resolution raising this with Avaya

 

[janni78]

Accidently found that you can enable this on the interface if it's a Server Edition.

Enable Traffic Control
When enabled, the server throttles the rate at which it sends UDP packets from the IP Office service to IP Office System Monitor. This may be necessary if the IP Office System Monitor traces indicate a high number of lost packets.


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

 

[sizbut]

Indeed, though the original poster believes 13 mixed UDP packets is a lot!

Stuck in a never ending cycle of file copying.

 

[amriddle01]

I often monitor systems with loads of filter options selected through an ISDN dial in connection (64k) and with SSA running at the same time, I rarely see any missed packets, so if you are seeing missed packets regularly on a local network something isn't right

 

[tlpeter]

Or the IPO LAN port is broken.
No matter what this is a network issue and if you say that SIP isn't working well either than 1+1=2 for sure

BAZINGA!

I'm not insane, my mother had me tested!

 

[Jimmyjoe1975]

Hi,

Getting deep with this issue, I have been testing and connecting Monitor with TCP protocol it works fine not missing any packets, but UDP protocol is the one missing it.
This is a huge problem for the ones who has Chronicall as the Reporter Application because it is reciving the info via Monitor with UDP protocol, so when there is missing packets Chronicall is not realizing when the call is hanged up, for example.
I don't know if somebody found out the way to solve it with UDP protocol.
Thanks