[cisco-voip] UCCX script question

[Erick Wellnitz]

Queuing the callers if all 'ports' are busy.  They aren't really ports
but extension numbers associatd with a 3rd party SIP device.  It's not
the most elegant 'integration'.

On 1/26/12, Bill Riley <bill at hitechconnection.net> wrote:
> How are you going to Queue ports?
>
>
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Erick Wellnitz
> Sent: Thursday, January 26, 2012 12:38 PM
> To: Anthony Holloway
> Cc: cisco-voip
> Subject: Re: [cisco-voip] UCCX script question
>
> I like the CSQ idea.  The Nuance product is a Phoenetic Operator.  We would
> like to implement some sort of queue mechanism when the ports are busy to
> eliminate the need for a human operator.
>
>
> What happens today is you call 1234 and if 1234 is busy it forwards to
> 1235 and so on.
>
> The problem with testing this is I don't have this Nuance product in the
> lab.
>
>
>
>
>
> On 1/26/12, Anthony Holloway <avholloway+cisco-voip at gmail.com> wrote:
>> Erick,
>>
>> I'm not sure I understand your question: "Would this still work with
>> the 'pilot' extension forwarding to another when busy or would I need
>> to write my script to handle the 'cascading' effect?"
>>
>> However, what you are trying to do seems correct.  Have you tried out
>> your solution yet?  Does it work?  If not, what's not working?
>>
>> You could place the call on hold prior to the redirect attempt, and
>> never take it off hold.  That works better, because then you are not
>> constantly placing the call on hold, then taking it off hold.  Less
>> work for UCCX and CUCM to do.
>>
>> And yeah, those Nuance ports are valuable.  However, it's important to
>> note that the TTS ports are only active for the duration of the
>> prompt, while the ASR ports are active for the duration of the call.
>> Are you in fact using ASR?
>>
>> One more thing to note about what you are doing:  if one person calls
>> in, and is placed in the holding pattern, then a port free's up during
>> the delay step, there is a chance that a new call can come in and take
>> that open port, thus jumping in front of that original caller.  This
>> leap frogging could go on forever and your poor caller will never see
>> the light of day.
>>
>> What I would suggest is to create a CSQ to queue these people in, and
>> check for position in queue.  If the caller is in first position, then
>> let them attempt the redirects, otherwise, keep holding and checking
>> PIQ.  This is a fair method.  Also, upon successful redirect the
>> caller will be dequeued automatically, and all other callers will move up
> in position.
>>
>> -Anthony
>>
>> On Thu, Jan 26, 2012 at 11:35 AM, Erick Wellnitz
>> <ewellnitzvoip at gmail.com>wrote:
>>
>>> I have a situation where I need to transfer a call to an extension
>>> but if it is busy, queue the call and try again after a certain
>>> length of time.
>>>
>>> It's a nuance thing and we only have a certain number of ports available.
>>>
>>> I'm thinking I could use UCCX in the following way.
>>>
>>> Accept
>>> :TRANSFER Label
>>> Redirect
>>>   -Busy
>>>       -Hold
>>>       - Delay
>>>       - Unhold
>>>       -goto TRANSFER
>>>
>>>
>>> Any suggestions?  Would this still work with the 'pilot' extension
>>> forwarding to another when busy or would I need to write my script to
>>> handle the 'cascading' effect?
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>