Call hung up on queue blocking all calls

[loubear]

We are having a problem with a call getting hung up in a split queue and causing all other incoming calls to be stackup up in the queue and never delivered to an agent. The only way we have found to delete the offending call is to either reset the system or have Avaya use the go command (not available to us). The only work around we have found is to move all the agents to a new skill/split and change the vector. This isn't a great work around as there are quite a few agents. Has anyone else run into this problem and are there any other ways to release a call from queue.

 

[AvayaTier3]

Hardware platform? Definity / CM software version?

Avaya uses "go tcm" to look at the call record that is hung in queue for the split.
From tcm, the call can be dropped.

If you know the entry point to the queue (i.e. trunk-group number) busy trunk-group x and release trunk-group x will drop the call. The reason you cannot drop the call is you don't know the source.
reset system 2 or higher drops all calls.


A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
Avaya. Too little or no help? Expensive?
For FAST switch support at bargain rates, give bsh a call.

bsh

40 years Bell, AT&T, Lucent, Avaya
Tier 3 for 30 years and counting
[URL unfurl="true"]http://bshtele.com[/url]

 

[loubear]

Thanks for the response. Software/Hardware CM 4.x/S8720
All trunk calls were knocked down but the queue was still blocked by a call that was no longer connected to a trunk. This split has been in place for quite some time, but the problem just surfaced for the first time in December. It has happened twice since then.

 

[AvayaTier3]

4.x is not a software load

These are software loads:
R014x.00.0.730.5 CM 4.0.0 QPPCN 1596B s8x00
R014x.00.1.731.2 CM 4.0.1 QPPCN 1596B s8x00
R014x.00.3.737.4 CM 4.0.3 QPPCN 1596B s8x00
R014x.00.4.739.0 CM 4.0.4 QPPCN 1596B s8x00 Sup 2
R014x.00.5.742.0 CM 4.0.5 QPPCN 1596B s8x00 Sup 3


A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
Avaya. Too little or no help? Expensive?
For FAST switch support at bargain rates, give bsh a call.

bsh

40 years Bell, AT&T, Lucent, Avaya
Tier 3 for 30 years and counting
[URL unfurl="true"]http://bshtele.com[/url]

 

[AvayaTier3]

There was a bug in load cm4.0.1

You can see the issue using "monitor traffic hunt-groups"

A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
Avaya. Too little or no help? Expensive?
For FAST switch support at bargain rates, give bsh a call.

bsh

40 years Bell, AT&T, Lucent, Avaya
Tier 3 for 30 years and counting
[URL unfurl="true"]http://bshtele.com[/url]

 

[loubear]

Sorry, the software load is R014x.00.2.732.1

 

[AvayaTier3]

That is a JITC load and there are no bug fixes for this issue for your load.
You should track down the source of the problem. It's usually a data call that
gets hung in the queue. A data call should probably not be directed at the hunt-group.

A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
Avaya. Too little or no help? Expensive?
For FAST switch support at bargain rates, give bsh a call.

bsh

40 years Bell, AT&T, Lucent, Avaya
Tier 3 for 30 years and counting
[URL unfurl="true"]http://bshtele.com[/url]

 

[loubear]

We'll see if we can track it through CDR if the supervisor can nail down the approximate time. Of course this only occurs at night when there are no technicians to monitor the split. Thanks for your responses.

 

[AvayaTier3]

CDR does not produce a record until the call is completed or dropped.

A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"
Avaya. Too little or no help? Expensive?
For FAST switch support at bargain rates, give bsh a call.

bsh

40 years Bell, AT&T, Lucent, Avaya
Tier 3 for 30 years and counting
[URL unfurl="true"]http://bshtele.com[/url]

 

[loubear]

True, but we're hoping that cdr will create a record once we know for a fact that the call has dropped from the trunk. We are able to confirm this in both the switch and the firewall. There should be nothing but voice calls going to the split.