IPO + Chronicall - Missed Packets

[liquidshokk]

Tearing my hair out trying to resolve an issue with Chronicall reporting missed packets in it's tomcat logs. This is causing agent's status across 6 sites to be incorrect and for calls to be shown as being in progress for many hours, as it sometimes doesnt see the hang up message.

Have spoken to Xima, who say it is a network issue, however the customers network is a PWAN so should be completely open between sites! The PWAN provider has provided proof that there isnt any packet loss on the network, however my understanding is that this will only relate to TCP traffic and Chronicall takes the UDP stream from each system. The only hardware at each site is the IPO, a flat data switch and a cisco router for connecting to the PWAN.

Anyone had similar issues before or know of a way to prove that there is UDP packet loss on the network??

 

[twitchy087]

Has anyone found a fix for the main issue, with missing packets? I have been able to find nothing on the network front which is disheartening. I am at the point where I am considering a full wipe and reinstall of Chronicall...

 

[amriddle01]

If you log on with monitor does that show missed packets? Xima uses the monitor feed so if the packets are actually missing due to network/system issues then messing on with Chronicall isn't going to help

 

[liquidshokk]

How/Where would you look for missed packets in monitor?

I thought I had fixed the problem but changing the "Order UDP Packets" to "True" and the "packet reordering threshold" from 1 to 5 (hold shift when clicking advanced settings), but I've just seen entries for missed packets again..... possibly not as many as before though.

I'm not sure if this is the cause of the realtime stats screen not updating itself correctly or if it's just a bit unstable. Clicking the refresh button suddenly shows most users as logged out in the agent statistics window, but going out and back in again shows the users status correctly.

One user's status showed as ringing for 5 minutes, before I refreshed the data and went back in again.

 

[amriddle01]

You don't need to look for it, it will show up while the trace is running in clear text saying "4 missed Packets" or whatever, it's quite clear if it's happening

 

[liquidshokk]

Straight away I can see missed packets reported in monitor for a couple of sites on the MPLS.. so I'll let Xima off....

 

[twitchy087]

Unfortunately, I am not seeing the lost packets via monitor. What filter options had you used, the default or...?

 

[liquidshokk]

Yeah just default,

Just checked and there havent been any missed packets in the last 4 hours, so they may be less frequent since amending the missed UDP timer..

 

[amriddle01]

Bear in mind if the routers are configured to drop certain packets before transmission then they will not show on the link as dropped packets as they were never sent to be lost, but anything on the end of the link waiting for the packets will see them as missing

 

[twitchy087]

Liquidshokk,

What version are your IPOs running on?

 

[liquidshokk]

6 x IP500 V2s on 9.0.9
Upgraded from 9.0.4, 9.0.8 and recently 9.0.9
Didnt have chronicall installed when on v8, but can't remember if we had the issues with rotary/longest waiting SCN huntgroup routing that we also have now back then..

 

[twitchy087]

Gotcha, I am running 9.0.4 on all 5 control units. I am also seeing the issue within monitor such as you however I am just getting no love from the MPLS provider as I have not much else to provide as evidence.

La la la... Thanks

 

[liquidshokk]

I fail to see how proof can be given that there isnt any packet loss on the MPLS, yet monitor is missing loads of packets...

I'm sure one of us will have a eureka moment before long. Actually, I'm not sure at all....

 

[amriddle01]

Hire an independent company to measure for Packet loss/ do a network assessment across the MPLS links, you can't rely on the people running them to be honest or run unbiased testing really

 

[twitchy087]

What a headache..