[cisco-voip] UCCX Callback Script

Wed Nov 6 10:42:52 EST 2019

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/2c938dea/attachment.htm>