UCCX basic queue script takes up 2 calls worth of location bandwidth

Unanswered Question
Jul 15th, 2009
User Badges:
  • Bronze, 100 points or more

I currently have a UCCX script configured to accept a call, play a welcome prompt, and attempt a consult transfer to a huntgroup. The script then plays a periodic prompt while waiting for an answer.

The problem I am seeing is that because the UCCX server is located at the corp site and the gateway and huntgroup members are located at a remote location, while a call is on hold and while the consult transfer is alerting the huntgroup members it counts as 2 calls in progress and subtracts from the available bandwidth for the remote location for the duration the call is in the queue.

Is there a way to use a redirect to a huntgroup instead of a consult transfer so there would be only one call in progress during the duration the call is being queued?

I have also seen that there is a location setting on the script trigger. I attempted to set this for the same location as the remote huntgroup members and pstn gateway.

I have recreated the way the script currently functions with an IP phone located at the central location. When I call that phone through the remote gateway and attempt a transfer to a phone at the remote location, I get 2 calls in progress at the remote location. 1 for putting the call on hold (the BW is reserved to ensure the call can be retreaved if necessary) and 1 for the call alerting during the consult transfer (This is also reserving BW so the transferer can talk to the transferee).

If I put that same phone physically located at the central site but configured for the remote location, there is no bandwidth used or reserved during the whole process. I thought this would be the way to configure the application to have it in the remote location so it doesn't reserve BW, but I found two issues with this.

1. The priority queue at the remote location could become over subscribed during the playing of the script prompts.

2. When I changed the location of the application trigger to be the remote location, it made no difference; I still have 2 calls in progress during the queue process.

Wow, I wrote a lot of stuff here. I hope someone can read entirely through it before they get bored.

Any assistance or tips would be appreciated.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jonathan Schulenberg Thu, 07/16/2009 - 05:41
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

This sounds like it is working as designed to me. If there are two call legs (one from the gateway to CCX and a second from CCX to another a destination in another location) there are going to be two calls which both decrement the CAC bandwidth. To answer the points you ask:

-A Call Redirect should work. I haven't tested this to a Hunt Pilot before but I do not see a reason this would not work. This removes CCX from the call entirely so there is still only one call from the PSTN gateway. Of course once you do this there is no further IVR treatment you can provide from CCX as it is no longer involved in the call.

-You could enable the PSTN gateway at the remote site to use multicast MoH instead of unicast. Multicast MoH media resources do *not* count against locations- or RSVP-based CAC; however, there is still bandwidth crossing the WAN which you would need to manually account for in your priority queue. A second option here is to use local multicast from the SRST/CME router but this has several restrictions. This is explained in chapter five of the UCM SRND.

-You are still seeing two call legs when changing the script trigger (CTI Route Point) because the call is actually terminated on the CTI Port. You would also need to change the location of the Call Control Group (CTI Ports). Spoofing the location of a resource is a bad idea though. This totally destroys you CAC mechanism.

MARK BAKER Thu, 07/16/2009 - 06:13
User Badges:
  • Bronze, 100 points or more


Thanks for the reply. Your point on using multicast MoH from the SRST/CME you would think would not count against the BW for the location. I thought the same thing and couldn't figure out why it appeared to be counting against it since that is how I have it configured.

I originally thought the 1st call in progress was because of the multicast MoH that I do have configured and was confused by this since it should't use any BW.

What I realized is that it isn't the multicast MoH that is counting against the BW for the location. It is the fact that the call is on hold and the BW needs to be reserved so the holder will have enough BW to retrieve the call.

The second call in progress is from the consult transfer in the UCCX script. It too has to reserve BW so the tranferer can consult with the transfer receiver. I'm not sure why there is only consult transfer in the UCCX script options.

I understand the issue of CAC if I spoof the resource. However, the way I have it set up the transfer would take place between the remote gateway and remote IP Phone which doesn't require location BW so it would not cause a problem with CAC.

The way I see it is that if I could get rid of one of the calls in progress it would maintain CAC and allow more calls to be queued for the remote site. Taking up two calls worth of BW during queueing is not very efficient.

I would have thought that the location setting on the trigger would have removed at least the MoH call leg, but it didn't.

Thanks again for your reply.

Jonathan Schulenberg Thu, 07/16/2009 - 08:22
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

No problem; one thing: "However, the way I have it set up the transfer would take place between the remote gateway and remote IP Phone which doesn't require location BW so it would not cause a problem with CAC."

...Well yes but you need to remove CCX from the call path for this to be true. The Call Consult Transfer step doesn't do. The Call Redirect step on the other hand does.

MARK BAKER Thu, 07/16/2009 - 09:18
User Badges:
  • Bronze, 100 points or more

I guess what I am saying here is that even though the transfer is being performed from the UCCX server script, the two endpoints that would be connected are both local to the remote location.

My thinking is that no RTP streams actually exist between the UCCX script and the remote user that answered before the call transfer is completed and release by UCCX, QoS priority Queue would not see any of those packets and not be oversubscribed.

So if I could have UCCX appear to be at the remote location during the call transfer call leg my BW usage would be more accurate.

Your thought?




This Discussion