[cisco-voip] UCCX Callback Script

Wed Nov 6 14:48:33 EST 2019

The why is simple: I feel like I'm above the law, and want an explicit way
to work around it.  ;)

On Wed, Nov 6, 2019 at 9:43 AM Tanner Ezell <tanner.ezell at gmail.com> wrote:

> It tracks because it executes each step individually, there's probably a
> way to reset the counter but it begs the question, why? How often are you
> exceeding step limits, and why? If you really keep hitting the limit, just
> up it. There can't be a measurable performance impact in doing so.
>
> On Wed, Nov 6, 2019 at 8:37 AM Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
>> Tanner, thanks for the backing on that.  I have a strange
>> question/request for you: can you tell us how the system is even tracking
>> the total steps executed, and what possible ways in which we can defeat
>> it?  I.e., Using Do steps instead of multiple Set steps, or Using Trigger
>> Application instead of Call Subflow.
>>
>> On Wed, Nov 6, 2019 at 8:05 AM Tanner Ezell <tanner.ezell at gmail.com>
>> wrote:
>>
>>> I'll echo Anthony, never used separate CCG's for CCB. There's no
>>> technical reason to do so either outside of perhaps some strange setup
>>> going on in the CUCM.
>>>
>>> On Wed, Nov 6, 2019 at 6:17 AM Johnson, Tim <johns10t at cmich.edu> wrote:
>>>
>>>> Thanks for all of the feedback here. Maybe I’ll try using the same CCG
>>>> & DG to see how it goes. Here’s also where it was mentioned about using
>>>> separate CCG:
>>>> https://community.cisco.com/t5/contact-center/contact-inactive-when-getting-channel-call-back-from-q/m-p/2091873/highlight/true#M63875
>>>>
>>>>
>>>>
>>>> As for this new secret, I’m not quite sure I understand how that would
>>>> be done, but I am intrigued.
>>>>
>>>>
>>>>
>>>> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> *On Behalf Of *Lelio
>>>> Fulgenzi
>>>> *Sent:* Tuesday, November 5, 2019 10:24 PM
>>>> *To:* Tanner Ezell <tanner.ezell at gmail.com>
>>>> *Cc:* voyp list, cisco-voip (cisco-voip at puck.nether.net) <
>>>> cisco-voip at puck.nether.net>
>>>> *Subject:* Re: [cisco-voip] UCCX Callback Script
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Your abbreviation of easy peasy has won me over. *
>>>>
>>>> *-sent from mobile device-*
>>>>
>>>>
>>>>
>>>> *Lelio Fulgenzi, B.A.* | Senior Analyst
>>>>
>>>> Computing and Communications Services | University of Guelph
>>>>
>>>> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON
>>>> | N1G 2W1
>>>>
>>>> 519-824-4120 Ext. 56354 <519-824-4120;56354> | lelio at uoguelph.ca
>>>>
>>>>
>>>>
>>>> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>>>>
>>>>
>>>>
>>>> [image: University of Guelph Cornerstone with Improve Life tagline]
>>>>
>>>>
>>>> On Nov 5, 2019, at 5:31 PM, Tanner Ezell <tanner.ezell at gmail.com>
>>>> wrote:
>>>>
>>>> Pssshhht....I'll share a "secret" for playing the agent menu only when
>>>> the agent answers..
>>>>
>>>>
>>>>
>>>> Pass the contact to the agent script, then play your agent menu after
>>>> they connect.
>>>>
>>>>
>>>>
>>>> Ez pz.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Tanner Ezell
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 5, 2019 at 2:54 PM Brian Meade <bmeade90 at vt.edu> wrote:
>>>>
>>>> Anthony,
>>>>
>>>>
>>>>
>>>> I'm curious how you handle catching when the agent answers the callback
>>>> request.
>>>>
>>>>
>>>>
>>>> I've got my scripts checking to see if the CallBack contact was
>>>> answered by setting some Enterprise Info in my callback queue script but I
>>>> still have to check every few seconds to see if that Enterprise Info is set.
>>>>
>>>>
>>>>
>>>> I just max out the max steps to account for that.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Brian Meade
>>>>
>>>>
>>>>
>>>> On Tue, Nov 5, 2019 at 4:19 PM Anthony Holloway <
>>>> avholloway+cisco-voip at gmail.com> wrote:
>>>>
>>>> Hi Tim,
>>>>
>>>>
>>>>
>>>> I think the idea of a flawless script is in the eyes of the beholder.
>>>>
>>>>
>>>>
>>>> I don't personally use the example script from the repo; are you
>>>> talking about the one here:
>>>>
>>>>
>>>>
>>>>
>>>> script_respository_902\script_respository\release3\BaseLineAdvQueuing\BaseLineAdvQueuing.aef
>>>>
>>>>
>>>>
>>>> If so, there a few things wrong with that script.
>>>>
>>>>
>>>>
>>>> For example, you said "...despite having Contact Inactive exception
>>>> error handling..."
>>>>
>>>>
>>>>
>>>> Yeah, they setup an exception handler at the top for
>>>> ContactInactiveException, but then they never clear it, or reset it, and so
>>>> if and when the caller disconnects while recording their message or
>>>> listening to the "success" prompt, the whole thing falls a part and fails,
>>>> sending script execution down to the ExceptionCIE label.
>>>>
>>>>
>>>>
>>>> Another thing wrong with it is that the waiting mechanism for the Agent
>>>> is such that it plays a relatively short prompt, waits 3 seconds for input
>>>> from the Agent, then repeats.
>>>>
>>>>
>>>>
>>>> If you consider every application has a max 1,000 steps it can execute,
>>>> and you subtract off the overhead of just getting the call to this point
>>>> (say 21 steps in the most streamlined of scenarios), that leaves you with
>>>> 32 minutes to queue a call, otherwise the call will be aborted.  Since most
>>>> people are only interested in callback when they have queue hold time
>>>> problems, this is likely to cause more issues than it solves.
>>>>
>>>>
>>>>
>>>> "...I’ve read that the Call Control Group and Dialog Group should be
>>>> different from the trigger on the originating application..."
>>>>
>>>>
>>>>
>>>> Can you link the source?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 5, 2019 at 10:59 AM Johnson, Tim <johns10t at cmich.edu>
>>>> wrote:
>>>>
>>>> Anyone have a callback script that is working flawlessly? We have
>>>> implemented the solution in Cisco’s Advanced Queueing script and it’s seems
>>>> to be working, but I’m seeing Contact Inactive Exceptions and Contact
>>>> Creation errors in syslog each time the callback is used, despite having
>>>> Contact Inactive exception error handling.
>>>>
>>>>
>>>>
>>>> It seems that the issue may be related to the Place Call step which
>>>> calls the trigger of the callback application. I’ve read that the Call
>>>> Control Group and Dialog Group should be different from the trigger on the
>>>> originating application (which is what we have setup), but I’m curious if
>>>> those should also be different from what’s used on the callback
>>>> application. If so, can I use the same CCG and DG from the original
>>>> trigger, on the callback trigger?
>>>>
>>>>
>>>>
>>>> For example, I have the following setup:
>>>>
>>>> App_A application has a trigger that uses CCG #8 and Dialog Group #0.
>>>> In its script, it uses the Place Call step with CCG #25 and Dialog Group
>>>> #3. This places the call to App_Callback application which has a trigger
>>>> that uses CCG #25 and Dialog Group #3.
>>>>
>>>>
>>>>
>>>> Tim Johnson
>>>>
>>>> Voice & Video Engineer
>>>>
>>>> Central Michigan University
>>>>
>>>> Phone: +19897744406 at cmich.edu
>>>>
>>>> Fax: +19897795900
>>>>
>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191106/7a152200/attachment.htm>