CMS showing zero second calls

[RTMCKEE]

We are having a strange issue where whe we run a vdn real time report we are gettin X amount of calls showing as call waiting with zero seconds. (okay i figured someone just hung up and its legit for the interaval) issue is when interval renews the stats showing X amount of zero second calls STAY?

They show as call waiting, but they are not really there and they have not time on hold?

I checked to see if they were acually there by looking at BCMS in the phone system.

FYI we just turned up BSR routing. Anyone seen this?

RTMCKEE

 

[RGarcia87]

When's the last time you rebooted your CMS? You may have to reboot.

 

[RTMCKEE]

rebooted the cms just before we turned up the second ACD that we are sending the BSR routing to.

RTMCKEE

 

[ctr999]

Are you looking at a trunk group report or a skill report? I have seen something like that on trunk group reports. I am pretty certain it is because of BSR. It looked to me like during part of the BSR process it would hold up a trunk for a split second. If it did not interflow, the trunk would free up. All of that seemed to take less than a second, but it would reset the trunk's idle timer.

So maybe what you are seeing at the refresh is not a single call but multiple calls taking less than a second that are all part of the BSR process???

Hope that helps.

 

[RTMCKEE]

coud be i guess.... when we first fired up BSR i watch one of the VDNs showing a call waiting for while (more that 30 min) however, once a lot of calls started flowing it appeared that the we were still getting the phatom calls, but they would cycle quicker. I havent looked in a day, but I dont think I'm still getting them as frequently.

RTMCKEE

 

[RTMCKEE]

Still looking for an answer on this. These calls are not showing up in BCMS so I suspect its a CMS issue.

RTMCKEE

 

[portcity]

"li trace VDN XXXX"

Possibly something will show up in the trace. Also are you using a Standard CMS VDN report or is it a custom report?

 

[RTMCKEE]

I'll give the list trace a try, however as i said these calls dont show up in BCMS which means the switch knows they are not there, but the CMS is confused.

They do show up in both the "vdn real time report" in both supervisor and the standard unix shell cms window.

I've checked the processor utilization, which is very low, and also the cms has been rebooted several times, but its been no more than 30 days since last reboot.

 

[portcity]

You may also want to use the "display events" command and see if there is any vector errors.

 

[RTMCKEE]

UPDATE:

Who would have thunk it... after a week and a half of working with avaya Tier 3 on this, the system is "working as designed".

Actually the avaya guy i was working with was very good and bird-dogged this issue.

As it turns out our agents were using conf to transfer calls and dropping off the call. The calculation for "Calls waiting" in a VDN Report (real-time) is cvdn.INPROGRESS-cvdn.ATAGENT. the in progress is the important part. When a call comes into the call center for a VDN it ties up a trunk bound for a vdn and its considered "in progress" the whole time that orginal port is tied up. (unless it gets an tranfer even, hang up event, etc). When an agent conf and then drops off the call the CMS never gets a call ending event, so its still tied up on the orignal port, and the CMS knows the call is not "at an agent".

To test this the Avaya guy suggested building a custom report that instead of cvdn.INPROGRESS-cvdn.ATAGENT, use cvdn.INVECTOR-cvdn.ATAGENT. That did correctly track a conf/transfer call, BUT and this might be of interest to some here, it showed -1 while the phone was at my agent phone until i transfered it off.

anyways... my problem is solved.. i've got the CC mngt off my back because now its not "my system is broke" its "your agents causing the issue"

RTMCKEE