UCCX 5.0 Queued call being dropped after approximately 3 minutes

Unanswered Question
Feb 7th, 2009
User Badges:

Hello. Very interesting problem here. Curious to hear what you think and if you can provide direction.

I setup a test queue with no agents logged in.

1. Calls placed to a DID that triggers a CRS script. Caller is queued. After approx 3 minutes call is Dropped. (Local PRIs being used - DMS100 switch type)

2. Calls placed to company Main Line and transferred by Receptionist to the my test Queue. After approx 3 minutes call is Dropped (same Local PRIs being used).

3. Calls placed to a Test 800 number stayed queued indefinitely (LD PRIs being used - 4ESS swith type).

4. Internal calls to the script trigger remain queued indefinitely.

5. I next tested with an agent logged in. Call connects to agent and remains connected without dropping at any point.

6. Normal DID calls on Local PRIs DO NOT DROP. Nor do outgoing LD calls. No reports from users.

Attached are JTAPI and IVR logs with 2 dropped calls. Call details are as follows:

start 11:45, dropped at 11:48, duration 2:58

start 11:49 dropped at 11:52, duration 2:54

Look for Trigger of 1899. Queue name is TEST_QUEUE. UCXX 5.0.




  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
edguidry Sat, 02/07/2009 - 15:50
User Badges:


I have done more testing and this is very interesting.

For the IVR script, I had the Select Resource step Queued branch placing the call on hold for 20 seconds, then taking it off of hold and going back to execute the Select Resource step again and so on. A regular queue loop.

I found it strange that the call was dropping for the Local PRIs just under 3 minutes.

So, I changed the hold time to 240 seconds. The call did not drop until approx 32 minutes. I changed the script back to 20 second hold time and calls would drop after 3 minutes. In fact it is right 2 minutes and 40 seconds when it drops.

These PRIs use an ISDN switch type of DMS100. The other set of PRIs use 4ESS. So I am wondering if this has something to do with the call being taking off of hold and then back on hold and if something is being signalled to the DSM100 causing the call to drop. This is a wild guess.

Anthony Holloway Sat, 02/07/2009 - 22:27
User Badges:
  • Purple, 4500 points or more

I'm curious...

If you placed a call in to an IP Phone instead of the RP, then replicated the MOH pattern of the Queue branch (20 seconds on/off), would the call still disconnect?

Also, have you checked 'debug isdn q931' on the gateway?

Additionally, I don't believe a normal queue loop includes looping back to the Select Resource step.

The accepted practice I believe is:

Select Resource

-- Selected/Connected

-- Queued

---- :Label0

---- Music, Prompts, Hold, etc.

---- Goto Label0

Technically could loop it anywhere you wanted to:


Music, Prompts, Hold, etc.

Goto Label0

Select Resource

-- Selected/Connected

-- Queued

---- Goto Label0

The point being, you don't have to, and probably shouldn't-- though not confirmed--execute the Select Resource step another time, once the contact has been queued.

edguidry Sun, 02/08/2009 - 07:47
User Badges:

Good suggestions especially with the test with the regular call being placed on hold. Will test tomorrow. I agree with the queue loop label being within the Queued branch. Never understood why all the examples I have seen included it outside of the Select Resource step. Will test this as well.



edguidry Mon, 02/09/2009 - 08:30
User Badges:

i call a random DID (not involved in CRS) and place it on hold. Stays on hold for 10+ minutes without dropping. Then I begin to go offhold/onhold for 5 or 6 times and the call drops.

in my scripts i have moved the queue label inside of the select resource step and increased delay timer. this is keeping the calls from dropping.

Anthony Holloway Mon, 02/09/2009 - 08:49
User Badges:
  • Purple, 4500 points or more

So it's not a CRS problem then, correct?

Can you please update this thread once you figure out why your circuit is dropping calls that are placed on hold?

It would be a shame if another person stumbled on this thread for the same reason you created it, only to find that there is no solution, or explanation.

edguidry Mon, 02/09/2009 - 09:25
User Badges:

not a CRS problem. will update once resolved. thanks!

edguidry Sun, 02/15/2009 - 20:11
User Badges:

Cisco found a similar case involving a DMS100 switch type.

Changed was for the Systemwide Service Parameter: "Enable DMS PRI Notify Message from User to Network". I set value to FALSE and made a few calls and could not re-create the dropped call issue by toggling on hold/off hold.

I made inbound and outbound calls to ensure that there were no glaring adverse effects by making this change.

Description of parameter:

Enable DMS PRI Notify Message from User to Network: This parameter determines whether Cisco CallManager sends an ISDN PRI Notify message from the User Side to the Network Side when Cisco CallManager is connected to a DMS-100/250 switch. Valid values specify True (Cisco CallManager sends the message) or False (Cisco CallManager does not send the message). Set this parameter to False for DMS implementations that do not support the PRI Notify message.

This is a required field.

Default: True


This Discussion