Mailing List Archive

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@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@cmich.edu
>
> Fax: +19897795900
>
> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

Anthony,

/..
"...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?
../

I believe that is referenced here. I don’t recall the actual reasoning behind 2 separate call control groups though.

https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200764-UCCX-Call-Back-Feature-as-seen-on-CUCM-a.html

Kevin

From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Anthony Holloway
Sent: Tuesday, November 5, 2019 3:19 PM
To: Johnson, Tim <johns10t@cmich.edu>
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) <cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] UCCX Callback Script

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@cmich.edu<mailto:johns10t@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@cmich.edu<mailto:+19897744406@cmich.edu>
Fax: +19897795900
[webexemailsig]<https://cmich.webex.com/meet/johns10t>

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


Confidentiality Notice: This message (including any attachments) is only for the use of the person(s) for whom it is intended. It may contain confidential, proprietary and/or trade secret information. If you are not the intended recipient, you are forbidden to copy, distribute or use this information for any purpose, and you should inform the sender immediately and delete this e-mail.

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@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@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@cmich.edu
>>
>> Fax: +19897795900
>>
>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

Thanks for the link Kevin, I see the section now:

*There must be 2 different Call Control Groups used for these scripts under
Subsystems > CM Telephony > Call Control Group.*
*There must be 2 different Media Channels defined under Subsystems > Cisco
Media.*


Unfortunately, they didn't expand on the topic and explain why.

Anyone know these two Authors on the article?


Aravind Krishna Murthy
Cisco TAC Engineer

Arunabh Bhattacharjee
Cisco TAC Engineer


Can you ask them to jump in here? Or maybe someone just simply knows the
"why" behind this requirement?

I can tell you that I have deployed several callback solutions which do not
use a different CCG/Media Group and it works. So, to say that it "must be
2 different" is a bit of mystery to me.

On Tue, Nov 5, 2019 at 3:41 PM Damisch, Kevin <Kevin.Damisch@oneneck.com>
wrote:

> Anthony,
>
>
>
> /..
>
> *"...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?*
>
> ../
>
>
>
> I believe that is referenced here. I don’t recall the actual reasoning
> behind 2 separate call control groups though.
>
>
>
>
> https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200764-UCCX-Call-Back-Feature-as-seen-on-CUCM-a.html
>
>
>
> *Kevin*
>
>
>
> *From:* cisco-voip <cisco-voip-bounces@puck.nether.net> *On Behalf Of *Anthony
> Holloway
> *Sent:* Tuesday, November 5, 2019 3:19 PM
> *To:* Johnson, Tim <johns10t@cmich.edu>
> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] UCCX Callback Script
>
>
>
> 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@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@cmich.edu
>
> Fax: +19897795900
>
> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> *Confidentiality Notice:* This message (including any attachments) is
> only for the use of the person(s) for whom it is intended. It may contain
> confidential, proprietary and/or trade secret information. If you are not
> the intended recipient, you are forbidden to copy, distribute or use this
> information for any purpose, and you should inform the sender immediately
> and delete this e-mail.
>

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@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@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@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@cmich.edu
>>>
>>> Fax: +19897795900
>>>
>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

This sounds next level! I'm going to try this out as soon as possible.


On Tue, Nov 5, 2019, 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>
>>>> Fax: +19897795900
>>>>
>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>

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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Nov 5, 2019, at 5:31 PM, Tanner Ezell <tanner.ezell@gmail.com<mailto:tanner.ezell@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@vt.edu<mailto:bmeade90@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@gmail.com<mailto:avholloway%2Bcisco-voip@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@cmich.edu<mailto:johns10t@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@cmich.edu
Fax: +19897795900
[webexemailsig]<https://cmich.webex.com/meet/johns10t>

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

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@puck.nether.net> On Behalf Of Lelio Fulgenzi
Sent: Tuesday, November 5, 2019 10:24 PM
To: Tanner Ezell <tanner.ezell@gmail.com>
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) <cisco-voip@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<x-apple-data-detectors://1/0>
519-824-4120 Ext. 56354<tel:519-824-4120;56354> | lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Nov 5, 2019, at 5:31 PM, Tanner Ezell <tanner.ezell@gmail.com<mailto:tanner.ezell@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@vt.edu<mailto:bmeade90@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@gmail.com<mailto:avholloway%2Bcisco-voip@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@cmich.edu<mailto:johns10t@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@cmich.edu<mailto:+19897744406@cmich.edu>
Fax: +19897795900
[webexemailsig]<https://cmich.webex.com/meet/johns10t>

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

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@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@puck.nether.net> *On Behalf Of *Lelio
> Fulgenzi
> *Sent:* Tuesday, November 5, 2019 10:24 PM
> *To:* Tanner Ezell <tanner.ezell@gmail.com>
> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@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@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@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@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@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@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@cmich.edu
>
> Fax: +19897795900
>
> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

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@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@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@puck.nether.net> *On Behalf Of *Lelio
>> Fulgenzi
>> *Sent:* Tuesday, November 5, 2019 10:24 PM
>> *To:* Tanner Ezell <tanner.ezell@gmail.com>
>> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
>> cisco-voip@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@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@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@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@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@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@cmich.edu
>>
>> Fax: +19897795900
>>
>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

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@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@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@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@puck.nether.net> *On Behalf Of *Lelio
>>> Fulgenzi
>>> *Sent:* Tuesday, November 5, 2019 10:24 PM
>>> *To:* Tanner Ezell <tanner.ezell@gmail.com>
>>> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
>>> cisco-voip@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@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@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@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@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@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@cmich.edu
>>>
>>> Fax: +19897795900
>>>
>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>

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@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@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@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@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@puck.nether.net> *On Behalf Of *Lelio
>>>> Fulgenzi
>>>> *Sent:* Tuesday, November 5, 2019 10:24 PM
>>>> *To:* Tanner Ezell <tanner.ezell@gmail.com>
>>>> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
>>>> cisco-voip@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@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@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@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@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@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@cmich.edu
>>>>
>>>> Fax: +19897795900
>>>>
>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>

Tanner, Can you describe, or show what you're doing in script 1, which has
the Place Call step, inside the Successful branch?

On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>
>>>> Fax: +19897795900
>>>>
>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>

It's really not all that complicated. Think of it this way, the place call
is the contact the agent is exposed to when they answer the queued call,
which of course is just the IVR.

Pass the generated contact to the agent script (the one that has the select
resource), under the connected branch is when you know that your other IVR
application contact (from place call), connected to the agent. Use the
passed contact and play media just like you would any other contact. In
essence, you take the agent menu out of script 1 and put it in script 2 :)

With all that you can do some cool stuff, like ensuring the agent doesn't
just hang up (aka callback resiliency) and what to do if they do (like
re-queue, email a supervisor, re-call the agent, etc), can control if the
designated callback destination doesn't answer and some other fun stuff.

happy hacking!

On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> Tanner, Can you describe, or show what you're doing in script 1, which has
> the Place Call step, inside the Successful branch?
>
> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>>
>>>>> Fax: +19897795900
>>>>>
>>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>

I actually got that part to work. What I'm wondering about is what you are
doing in script 1 (place call script) after the successful branch. Like,
are you looping, are you delaying, are just ending?

On Wed, Nov 6, 2019 at 3:52 PM Tanner Ezell <tanner.ezell@gmail.com> wrote:

> It's really not all that complicated. Think of it this way, the place call
> is the contact the agent is exposed to when they answer the queued call,
> which of course is just the IVR.
>
> Pass the generated contact to the agent script (the one that has the
> select resource), under the connected branch is when you know that your
> other IVR application contact (from place call), connected to the agent.
> Use the passed contact and play media just like you would any other
> contact. In essence, you take the agent menu out of script 1 and put it in
> script 2 :)
>
> With all that you can do some cool stuff, like ensuring the agent doesn't
> just hang up (aka callback resiliency) and what to do if they do (like
> re-queue, email a supervisor, re-call the agent, etc), can control if the
> designated callback destination doesn't answer and some other fun stuff.
>
> happy hacking!
>
> On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
>> Tanner, Can you describe, or show what you're doing in script 1, which
>> has the Place Call step, inside the Successful branch?
>>
>> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>>>
>>>>>> Fax: +19897795900
>>>>>>
>>>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip@puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>

I see that the contact in both scripts is actually the same contact, but
each script views the contact from a different leg/sequence number (I.e.,
Outbound leg versus Inbound leg)

*Contact Created with Place Call Step (AKA CL1 for Call Leg 1)*

§com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=155,
implId=633001/1,state=STATE_ANSWERED_IDX,inbound=false,App
name=App1,task=26000000240,session=3000000115,seq num=0
,cn=2411,dn=null,cgn=2402,ani=null,dnis=null,clid=null,atype=OUTBOUND
,lrd=null,ocn=2411,route=RP[num=0000],OrigProtocolCallRef=null,DestProtocolCallRef=000000000009A8A902F728A200000000,TP=2402]§


*--Triggering Contact-- in the Queuing Script (AKA CL2 for Call Leg 2)*

§com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=156,
implId=633001/1,state=STATE_ANSWERED_IDX,inbound=true,App
name=App2,task=26000000241,session=3000000115,seq num=1
,cn=2411,dn=2411,cgn=2402,ani=null,dnis=null,clid=null,atype=DIRECT
,lrd=null,ocn=2411,route=RP[num=2411],OrigProtocolCallRef=000000000009A8A902F728A400000000,DestProtocolCallRef=null,TP=2401]§


So, things like Set/Get Enterprise Call Info work on the same contact,
because they are leg independent, whereas things requiring media, like Play
Prompt, are call leg dependent, and need to reference the correct call leg
of the contact. Hence, you have to pass the CL1 object into Script 2, in
order to interact with the Agent from CL1.

Unfortunately, if script 1 ends, there seems to be some clean up tasks
which run at the end of script 1 to unload CL1 from memory, and I am
getting an abort event in script 2, when trying to reference CL1. As is
the case when I try to play media to the Agent or Call Redirect them to the
callback number. If prevent script 1 from ending, and thus cleaning up
after itself, CL1 stays alive and script 2 works great. The question for
me now is, how do I release script 1, without also releasing CL1?

One thought I had was to setup a Contact Inactive listener in script 1, and
use the Delay step in script 1 for an absurd amount of time, like 12 hours,
and then rely on the fact that once CL1 transfers the Agent to the callback
number, CL1 goes inactive, and thus the 12 hour delay is interrupted and
script 1 can now end. In theory that is. In practice, script 1 never
receives a CIE event, and the delay continues for the 12 hours. No Beuno.

Second thought was to signal something from script 2 to script 1, but that
requires looping in script 1 (polling). No beuno.

Which by the way, I should mention, I am looking at your solution as a way
to avoid looping, though you didn't specifically say that you have figured
out a way to avoid looping. I was just being hopeful that somehow your
method did avoid looping.

Like Brian Meade already mentioned, we have solved the "only once an Agent
answers" dilemma by using polling in script 1, and setting a flag in script
2 once the agent answers, using Enterprise variables. Polling solves the
Agent only hearing the message from the top, versus in the middle, but it
doesn't solve the finite script steps issue.

Therefore, I am wondering how you are handling script 1, post successful
place call.

Don't get me wrong, I'm still #TeamTanner, and will be converting my
callback method to yours, since there are some advantages. I just have to
solve the script 1 clean up problem first.

On Wed, Nov 6, 2019 at 4:09 PM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> I actually got that part to work. What I'm wondering about is what you
> are doing in script 1 (place call script) after the successful branch.
> Like, are you looping, are you delaying, are just ending?
>
> On Wed, Nov 6, 2019 at 3:52 PM Tanner Ezell <tanner.ezell@gmail.com>
> wrote:
>
>> It's really not all that complicated. Think of it this way, the place
>> call is the contact the agent is exposed to when they answer the queued
>> call, which of course is just the IVR.
>>
>> Pass the generated contact to the agent script (the one that has the
>> select resource), under the connected branch is when you know that your
>> other IVR application contact (from place call), connected to the agent.
>> Use the passed contact and play media just like you would any other
>> contact. In essence, you take the agent menu out of script 1 and put it in
>> script 2 :)
>>
>> With all that you can do some cool stuff, like ensuring the agent doesn't
>> just hang up (aka callback resiliency) and what to do if they do (like
>> re-queue, email a supervisor, re-call the agent, etc), can control if the
>> designated callback destination doesn't answer and some other fun stuff.
>>
>> happy hacking!
>>
>> On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>>> Tanner, Can you describe, or show what you're doing in script 1, which
>>> has the Place Call step, inside the Successful branch?
>>>
>>> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>>>>
>>>>>>> Fax: +19897795900
>>>>>>>
>>>>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip@puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip@puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>

Ok, so I solved the looping thing by...well...looping. :/

So, loops themselves are not the problem, rather it's the finite script
steps we can execute which are the problem...err...challenge.

Since the CIE doesn't get thrown in script 1 properly (bug?), I used a Do
step in the success branch of the Place Call step to wait for the active
state of CL1 to change. Like so:

Do {
do {
java.lang.Thread.sleep(1000);
} while (contact_leg_1.isActive());
}

CL1 only becomes inactive once the Agent acknowledges the callback and the
call redirect is successful. Therefore, I get all the benefits of Tanner's
solution, plus I can keep the max steps at 1,000, and technically queue for
12 hours (the CallManager default max call timer).

I think this should work just fine, though, more rigorous testing will be
needed. What do you think?

On Wed, Nov 6, 2019 at 5:10 PM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> I see that the contact in both scripts is actually the same contact, but
> each script views the contact from a different leg/sequence number (I.e.,
> Outbound leg versus Inbound leg)
>
> *Contact Created with Place Call Step (AKA CL1 for Call Leg 1)*
>
> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=155,
> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=false,App
> name=App1,task=26000000240,session=3000000115,seq num=0
> ,cn=2411,dn=null,cgn=2402,ani=null,dnis=null,clid=null,atype=OUTBOUND
> ,lrd=null,ocn=2411,route=RP[num=0000],OrigProtocolCallRef=null,DestProtocolCallRef=000000000009A8A902F728A200000000,TP=2402]§
>
>
> *--Triggering Contact-- in the Queuing Script (AKA CL2 for Call Leg 2)*
>
> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=156,
> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=true,App
> name=App2,task=26000000241,session=3000000115,seq num=1
> ,cn=2411,dn=2411,cgn=2402,ani=null,dnis=null,clid=null,atype=DIRECT
> ,lrd=null,ocn=2411,route=RP[num=2411],OrigProtocolCallRef=000000000009A8A902F728A400000000,DestProtocolCallRef=null,TP=2401]§
>
>
> So, things like Set/Get Enterprise Call Info work on the same contact,
> because they are leg independent, whereas things requiring media, like Play
> Prompt, are call leg dependent, and need to reference the correct call leg
> of the contact. Hence, you have to pass the CL1 object into Script 2, in
> order to interact with the Agent from CL1.
>
> Unfortunately, if script 1 ends, there seems to be some clean up tasks
> which run at the end of script 1 to unload CL1 from memory, and I am
> getting an abort event in script 2, when trying to reference CL1. As is
> the case when I try to play media to the Agent or Call Redirect them to the
> callback number. If prevent script 1 from ending, and thus cleaning up
> after itself, CL1 stays alive and script 2 works great. The question for
> me now is, how do I release script 1, without also releasing CL1?
>
> One thought I had was to setup a Contact Inactive listener in script 1,
> and use the Delay step in script 1 for an absurd amount of time, like 12
> hours, and then rely on the fact that once CL1 transfers the Agent to the
> callback number, CL1 goes inactive, and thus the 12 hour delay is
> interrupted and script 1 can now end. In theory that is. In practice,
> script 1 never receives a CIE event, and the delay continues for the 12
> hours. No Beuno.
>
> Second thought was to signal something from script 2 to script 1, but that
> requires looping in script 1 (polling). No beuno.
>
> Which by the way, I should mention, I am looking at your solution as a way
> to avoid looping, though you didn't specifically say that you have figured
> out a way to avoid looping. I was just being hopeful that somehow your
> method did avoid looping.
>
> Like Brian Meade already mentioned, we have solved the "only once an Agent
> answers" dilemma by using polling in script 1, and setting a flag in script
> 2 once the agent answers, using Enterprise variables. Polling solves the
> Agent only hearing the message from the top, versus in the middle, but it
> doesn't solve the finite script steps issue.
>
> Therefore, I am wondering how you are handling script 1, post successful
> place call.
>
> Don't get me wrong, I'm still #TeamTanner, and will be converting my
> callback method to yours, since there are some advantages. I just have to
> solve the script 1 clean up problem first.
>
> On Wed, Nov 6, 2019 at 4:09 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
>> I actually got that part to work. What I'm wondering about is what you
>> are doing in script 1 (place call script) after the successful branch.
>> Like, are you looping, are you delaying, are just ending?
>>
>> On Wed, Nov 6, 2019 at 3:52 PM Tanner Ezell <tanner.ezell@gmail.com>
>> wrote:
>>
>>> It's really not all that complicated. Think of it this way, the place
>>> call is the contact the agent is exposed to when they answer the queued
>>> call, which of course is just the IVR.
>>>
>>> Pass the generated contact to the agent script (the one that has the
>>> select resource), under the connected branch is when you know that your
>>> other IVR application contact (from place call), connected to the agent.
>>> Use the passed contact and play media just like you would any other
>>> contact. In essence, you take the agent menu out of script 1 and put it in
>>> script 2 :)
>>>
>>> With all that you can do some cool stuff, like ensuring the agent
>>> doesn't just hang up (aka callback resiliency) and what to do if they do
>>> (like re-queue, email a supervisor, re-call the agent, etc), can control if
>>> the designated callback destination doesn't answer and some other fun stuff.
>>>
>>> happy hacking!
>>>
>>> On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
>>> avholloway+cisco-voip@gmail.com> wrote:
>>>
>>>> Tanner, Can you describe, or show what you're doing in script 1, which
>>>> has the Place Call step, inside the Successful branch?
>>>>
>>>> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>>>>>
>>>>>>>> Fax: +19897795900
>>>>>>>>
>>>>>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cisco-voip mailing list
>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip@puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip@puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>

I place an exception handler for contact inactive, checking for the
callback contact via get Contact Info step to make sure the caller hanging
up didn't catch the exception.

From there I have programmed in resiliency for the callback to be hung up
by the agent, but beyond that there is a Delay 999s loop. You'll never hit
the limit as you've discovered.

Would not recommend Thread.sleep inside your code as it will thread lock
the task and may interfere; for example, it may prevent the CIE to be
caught properly in that script. Use Delay step, it's thread safe and is
built in a way that allows exceptions to be handled.

On Wed, Nov 6, 2019 at 4:46 PM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> Ok, so I solved the looping thing by...well...looping. :/
>
> So, loops themselves are not the problem, rather it's the finite script
> steps we can execute which are the problem...err...challenge.
>
> Since the CIE doesn't get thrown in script 1 properly (bug?), I used a Do
> step in the success branch of the Place Call step to wait for the active
> state of CL1 to change. Like so:
>
> Do {
> do {
> java.lang.Thread.sleep(1000);
> } while (contact_leg_1.isActive());
> }
>
> CL1 only becomes inactive once the Agent acknowledges the callback and the
> call redirect is successful. Therefore, I get all the benefits of Tanner's
> solution, plus I can keep the max steps at 1,000, and technically queue for
> 12 hours (the CallManager default max call timer).
>
> I think this should work just fine, though, more rigorous testing will be
> needed. What do you think?
>
> On Wed, Nov 6, 2019 at 5:10 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
>> I see that the contact in both scripts is actually the same contact, but
>> each script views the contact from a different leg/sequence number (I.e.,
>> Outbound leg versus Inbound leg)
>>
>> *Contact Created with Place Call Step (AKA CL1 for Call Leg 1)*
>>
>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=155,
>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=false,App
>> name=App1,task=26000000240,session=3000000115,seq num=0
>> ,cn=2411,dn=null,cgn=2402,ani=null,dnis=null,clid=null,atype=OUTBOUND
>> ,lrd=null,ocn=2411,route=RP[num=0000],OrigProtocolCallRef=null,DestProtocolCallRef=000000000009A8A902F728A200000000,TP=2402]§
>>
>>
>> *--Triggering Contact-- in the Queuing Script (AKA CL2 for Call Leg 2)*
>>
>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=156,
>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=true,App
>> name=App2,task=26000000241,session=3000000115,seq num=1
>> ,cn=2411,dn=2411,cgn=2402,ani=null,dnis=null,clid=null,atype=DIRECT
>> ,lrd=null,ocn=2411,route=RP[num=2411],OrigProtocolCallRef=000000000009A8A902F728A400000000,DestProtocolCallRef=null,TP=2401]§
>>
>>
>> So, things like Set/Get Enterprise Call Info work on the same contact,
>> because they are leg independent, whereas things requiring media, like Play
>> Prompt, are call leg dependent, and need to reference the correct call leg
>> of the contact. Hence, you have to pass the CL1 object into Script 2, in
>> order to interact with the Agent from CL1.
>>
>> Unfortunately, if script 1 ends, there seems to be some clean up tasks
>> which run at the end of script 1 to unload CL1 from memory, and I am
>> getting an abort event in script 2, when trying to reference CL1. As is
>> the case when I try to play media to the Agent or Call Redirect them to the
>> callback number. If prevent script 1 from ending, and thus cleaning up
>> after itself, CL1 stays alive and script 2 works great. The question for
>> me now is, how do I release script 1, without also releasing CL1?
>>
>> One thought I had was to setup a Contact Inactive listener in script 1,
>> and use the Delay step in script 1 for an absurd amount of time, like 12
>> hours, and then rely on the fact that once CL1 transfers the Agent to the
>> callback number, CL1 goes inactive, and thus the 12 hour delay is
>> interrupted and script 1 can now end. In theory that is. In practice,
>> script 1 never receives a CIE event, and the delay continues for the 12
>> hours. No Beuno.
>>
>> Second thought was to signal something from script 2 to script 1, but
>> that requires looping in script 1 (polling). No beuno.
>>
>> Which by the way, I should mention, I am looking at your solution as a
>> way to avoid looping, though you didn't specifically say that you have
>> figured out a way to avoid looping. I was just being hopeful that somehow
>> your method did avoid looping.
>>
>> Like Brian Meade already mentioned, we have solved the "only once an
>> Agent answers" dilemma by using polling in script 1, and setting a flag in
>> script 2 once the agent answers, using Enterprise variables. Polling
>> solves the Agent only hearing the message from the top, versus in the
>> middle, but it doesn't solve the finite script steps issue.
>>
>> Therefore, I am wondering how you are handling script 1, post successful
>> place call.
>>
>> Don't get me wrong, I'm still #TeamTanner, and will be converting my
>> callback method to yours, since there are some advantages. I just have to
>> solve the script 1 clean up problem first.
>>
>> On Wed, Nov 6, 2019 at 4:09 PM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>>> I actually got that part to work. What I'm wondering about is what you
>>> are doing in script 1 (place call script) after the successful branch.
>>> Like, are you looping, are you delaying, are just ending?
>>>
>>> On Wed, Nov 6, 2019 at 3:52 PM Tanner Ezell <tanner.ezell@gmail.com>
>>> wrote:
>>>
>>>> It's really not all that complicated. Think of it this way, the place
>>>> call is the contact the agent is exposed to when they answer the queued
>>>> call, which of course is just the IVR.
>>>>
>>>> Pass the generated contact to the agent script (the one that has the
>>>> select resource), under the connected branch is when you know that your
>>>> other IVR application contact (from place call), connected to the agent.
>>>> Use the passed contact and play media just like you would any other
>>>> contact. In essence, you take the agent menu out of script 1 and put it in
>>>> script 2 :)
>>>>
>>>> With all that you can do some cool stuff, like ensuring the agent
>>>> doesn't just hang up (aka callback resiliency) and what to do if they do
>>>> (like re-queue, email a supervisor, re-call the agent, etc), can control if
>>>> the designated callback destination doesn't answer and some other fun stuff.
>>>>
>>>> happy hacking!
>>>>
>>>> On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>
>>>>> Tanner, Can you describe, or show what you're doing in script 1, which
>>>>> has the Place Call step, inside the Successful branch?
>>>>>
>>>>> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>>>>>>
>>>>>>>>> Fax: +19897795900
>>>>>>>>>
>>>>>>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> cisco-voip mailing list
>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cisco-voip mailing list
>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip@puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>>

To your last point about CIE: it doesn't work for me anyway, and I'm not
trying to have the script do anything else, so threadlocking doesn't sound
all that bad. Unless of course you're trying to tell me that it's not just
the thread my script is running within, but the entire CCX Engine as a
thread, then yeah, that's pretty terrible. Though, I just did a test,
where I thread slept for 100 seconds in script A, and during that time,
called into script B, and made sure everything worked fine while the
threadlocking should have been taking place. So, I would say it's not the
CCX Engine as a whole, and likely each script is executed in its own
thread. This should be acceptable in this one use case.

It's still a mystery to me how you're handling script 1.

It kind of sounds like you are doing a 999s delay loop, but are you
checking for the contact to be active still with the Get Contact Info
step? So, essentially the same thing I was doing, but with script steps
instead (and less frequently)? If so, then your script 1 stays active for
~15 minutes, worst case scenario, after the callback has been completed,
correct?

E.g.,

CL1 = Place Call ()
Successful
LABEL0:
Delay 999s
is_active = Get Contact Info (CL1)
If (is_active)
True
Goto LABEL0
End

On Wed, Nov 6, 2019 at 5:55 PM Tanner Ezell <tanner.ezell@gmail.com> wrote:

> I place an exception handler for contact inactive, checking for the
> callback contact via get Contact Info step to make sure the caller hanging
> up didn't catch the exception.
>
> From there I have programmed in resiliency for the callback to be hung up
> by the agent, but beyond that there is a Delay 999s loop. You'll never hit
> the limit as you've discovered.
>
> Would not recommend Thread.sleep inside your code as it will thread lock
> the task and may interfere; for example, it may prevent the CIE to be
> caught properly in that script. Use Delay step, it's thread safe and is
> built in a way that allows exceptions to be handled.
>
> On Wed, Nov 6, 2019 at 4:46 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
>> Ok, so I solved the looping thing by...well...looping. :/
>>
>> So, loops themselves are not the problem, rather it's the finite script
>> steps we can execute which are the problem...err...challenge.
>>
>> Since the CIE doesn't get thrown in script 1 properly (bug?), I used a Do
>> step in the success branch of the Place Call step to wait for the active
>> state of CL1 to change. Like so:
>>
>> Do {
>> do {
>> java.lang.Thread.sleep(1000);
>> } while (contact_leg_1.isActive());
>> }
>>
>> CL1 only becomes inactive once the Agent acknowledges the callback and
>> the call redirect is successful. Therefore, I get all the benefits of
>> Tanner's solution, plus I can keep the max steps at 1,000, and technically
>> queue for 12 hours (the CallManager default max call timer).
>>
>> I think this should work just fine, though, more rigorous testing will be
>> needed. What do you think?
>>
>> On Wed, Nov 6, 2019 at 5:10 PM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>>> I see that the contact in both scripts is actually the same contact, but
>>> each script views the contact from a different leg/sequence number (I.e.,
>>> Outbound leg versus Inbound leg)
>>>
>>> *Contact Created with Place Call Step (AKA CL1 for Call Leg 1)*
>>>
>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=155,
>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=false,App
>>> name=App1,task=26000000240,session=3000000115,seq num=0
>>> ,cn=2411,dn=null,cgn=2402,ani=null,dnis=null,clid=null,atype=OUTBOUND
>>> ,lrd=null,ocn=2411,route=RP[num=0000],OrigProtocolCallRef=null,DestProtocolCallRef=000000000009A8A902F728A200000000,TP=2402]§
>>>
>>>
>>> *--Triggering Contact-- in the Queuing Script (AKA CL2 for Call Leg 2)*
>>>
>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=156,
>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=true,App
>>> name=App2,task=26000000241,session=3000000115,seq num=1
>>> ,cn=2411,dn=2411,cgn=2402,ani=null,dnis=null,clid=null,atype=DIRECT
>>> ,lrd=null,ocn=2411,route=RP[num=2411],OrigProtocolCallRef=000000000009A8A902F728A400000000,DestProtocolCallRef=null,TP=2401]§
>>>
>>>
>>> So, things like Set/Get Enterprise Call Info work on the same contact,
>>> because they are leg independent, whereas things requiring media, like Play
>>> Prompt, are call leg dependent, and need to reference the correct call leg
>>> of the contact. Hence, you have to pass the CL1 object into Script 2, in
>>> order to interact with the Agent from CL1.
>>>
>>> Unfortunately, if script 1 ends, there seems to be some clean up tasks
>>> which run at the end of script 1 to unload CL1 from memory, and I am
>>> getting an abort event in script 2, when trying to reference CL1. As is
>>> the case when I try to play media to the Agent or Call Redirect them to the
>>> callback number. If prevent script 1 from ending, and thus cleaning up
>>> after itself, CL1 stays alive and script 2 works great. The question for
>>> me now is, how do I release script 1, without also releasing CL1?
>>>
>>> One thought I had was to setup a Contact Inactive listener in script 1,
>>> and use the Delay step in script 1 for an absurd amount of time, like 12
>>> hours, and then rely on the fact that once CL1 transfers the Agent to the
>>> callback number, CL1 goes inactive, and thus the 12 hour delay is
>>> interrupted and script 1 can now end. In theory that is. In practice,
>>> script 1 never receives a CIE event, and the delay continues for the 12
>>> hours. No Beuno.
>>>
>>> Second thought was to signal something from script 2 to script 1, but
>>> that requires looping in script 1 (polling). No beuno.
>>>
>>> Which by the way, I should mention, I am looking at your solution as a
>>> way to avoid looping, though you didn't specifically say that you have
>>> figured out a way to avoid looping. I was just being hopeful that somehow
>>> your method did avoid looping.
>>>
>>> Like Brian Meade already mentioned, we have solved the "only once an
>>> Agent answers" dilemma by using polling in script 1, and setting a flag in
>>> script 2 once the agent answers, using Enterprise variables. Polling
>>> solves the Agent only hearing the message from the top, versus in the
>>> middle, but it doesn't solve the finite script steps issue.
>>>
>>> Therefore, I am wondering how you are handling script 1, post successful
>>> place call.
>>>
>>> Don't get me wrong, I'm still #TeamTanner, and will be converting my
>>> callback method to yours, since there are some advantages. I just have to
>>> solve the script 1 clean up problem first.
>>>
>>> On Wed, Nov 6, 2019 at 4:09 PM Anthony Holloway <
>>> avholloway+cisco-voip@gmail.com> wrote:
>>>
>>>> I actually got that part to work. What I'm wondering about is what you
>>>> are doing in script 1 (place call script) after the successful branch.
>>>> Like, are you looping, are you delaying, are just ending?
>>>>
>>>> On Wed, Nov 6, 2019 at 3:52 PM Tanner Ezell <tanner.ezell@gmail.com>
>>>> wrote:
>>>>
>>>>> It's really not all that complicated. Think of it this way, the place
>>>>> call is the contact the agent is exposed to when they answer the queued
>>>>> call, which of course is just the IVR.
>>>>>
>>>>> Pass the generated contact to the agent script (the one that has the
>>>>> select resource), under the connected branch is when you know that your
>>>>> other IVR application contact (from place call), connected to the agent.
>>>>> Use the passed contact and play media just like you would any other
>>>>> contact. In essence, you take the agent menu out of script 1 and put it in
>>>>> script 2 :)
>>>>>
>>>>> With all that you can do some cool stuff, like ensuring the agent
>>>>> doesn't just hang up (aka callback resiliency) and what to do if they do
>>>>> (like re-queue, email a supervisor, re-call the agent, etc), can control if
>>>>> the designated callback destination doesn't answer and some other fun stuff.
>>>>>
>>>>> happy hacking!
>>>>>
>>>>> On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>
>>>>>> Tanner, Can you describe, or show what you're doing in script 1,
>>>>>> which has the Place Call step, inside the Successful branch?
>>>>>>
>>>>>> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>>>>>>>
>>>>>>>>>> Fax: +19897795900
>>>>>>>>>>
>>>>>>>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> cisco-voip mailing list
>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cisco-voip mailing list
>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>
>>>>>>>

[image: image.png]

On Wed, Nov 6, 2019 at 6:18 PM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> To your last point about CIE: it doesn't work for me anyway, and I'm not
> trying to have the script do anything else, so threadlocking doesn't sound
> all that bad. Unless of course you're trying to tell me that it's not just
> the thread my script is running within, but the entire CCX Engine as a
> thread, then yeah, that's pretty terrible. Though, I just did a test,
> where I thread slept for 100 seconds in script A, and during that time,
> called into script B, and made sure everything worked fine while the
> threadlocking should have been taking place. So, I would say it's not the
> CCX Engine as a whole, and likely each script is executed in its own
> thread. This should be acceptable in this one use case.
>
> It's still a mystery to me how you're handling script 1.
>
> It kind of sounds like you are doing a 999s delay loop, but are you
> checking for the contact to be active still with the Get Contact Info
> step? So, essentially the same thing I was doing, but with script steps
> instead (and less frequently)? If so, then your script 1 stays active for
> ~15 minutes, worst case scenario, after the callback has been completed,
> correct?
>
> E.g.,
>
> CL1 = Place Call ()
> Successful
> LABEL0:
> Delay 999s
> is_active = Get Contact Info (CL1)
> If (is_active)
> True
> Goto LABEL0
> End
>
> On Wed, Nov 6, 2019 at 5:55 PM Tanner Ezell <tanner.ezell@gmail.com>
> wrote:
>
>> I place an exception handler for contact inactive, checking for the
>> callback contact via get Contact Info step to make sure the caller hanging
>> up didn't catch the exception.
>>
>> From there I have programmed in resiliency for the callback to be hung up
>> by the agent, but beyond that there is a Delay 999s loop. You'll never hit
>> the limit as you've discovered.
>>
>> Would not recommend Thread.sleep inside your code as it will thread lock
>> the task and may interfere; for example, it may prevent the CIE to be
>> caught properly in that script. Use Delay step, it's thread safe and is
>> built in a way that allows exceptions to be handled.
>>
>> On Wed, Nov 6, 2019 at 4:46 PM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>>> Ok, so I solved the looping thing by...well...looping. :/
>>>
>>> So, loops themselves are not the problem, rather it's the finite script
>>> steps we can execute which are the problem...err...challenge.
>>>
>>> Since the CIE doesn't get thrown in script 1 properly (bug?), I used a
>>> Do step in the success branch of the Place Call step to wait for the active
>>> state of CL1 to change. Like so:
>>>
>>> Do {
>>> do {
>>> java.lang.Thread.sleep(1000);
>>> } while (contact_leg_1.isActive());
>>> }
>>>
>>> CL1 only becomes inactive once the Agent acknowledges the callback and
>>> the call redirect is successful. Therefore, I get all the benefits of
>>> Tanner's solution, plus I can keep the max steps at 1,000, and technically
>>> queue for 12 hours (the CallManager default max call timer).
>>>
>>> I think this should work just fine, though, more rigorous testing will
>>> be needed. What do you think?
>>>
>>> On Wed, Nov 6, 2019 at 5:10 PM Anthony Holloway <
>>> avholloway+cisco-voip@gmail.com> wrote:
>>>
>>>> I see that the contact in both scripts is actually the same contact,
>>>> but each script views the contact from a different leg/sequence number
>>>> (I.e., Outbound leg versus Inbound leg)
>>>>
>>>> *Contact Created with Place Call Step (AKA CL1 for Call Leg 1)*
>>>>
>>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=155,
>>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=false,App
>>>> name=App1,task=26000000240,session=3000000115,seq num=0
>>>> ,cn=2411,dn=null,cgn=2402,ani=null,dnis=null,clid=null,atype=OUTBOUND
>>>> ,lrd=null,ocn=2411,route=RP[num=0000],OrigProtocolCallRef=null,DestProtocolCallRef=000000000009A8A902F728A200000000,TP=2402]§
>>>>
>>>>
>>>> *--Triggering Contact-- in the Queuing Script (AKA CL2 for Call Leg 2)*
>>>>
>>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=156,
>>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=true,App
>>>> name=App2,task=26000000241,session=3000000115,seq num=1
>>>> ,cn=2411,dn=2411,cgn=2402,ani=null,dnis=null,clid=null,atype=DIRECT
>>>> ,lrd=null,ocn=2411,route=RP[num=2411],OrigProtocolCallRef=000000000009A8A902F728A400000000,DestProtocolCallRef=null,TP=2401]§
>>>>
>>>>
>>>> So, things like Set/Get Enterprise Call Info work on the same contact,
>>>> because they are leg independent, whereas things requiring media, like Play
>>>> Prompt, are call leg dependent, and need to reference the correct call leg
>>>> of the contact. Hence, you have to pass the CL1 object into Script 2, in
>>>> order to interact with the Agent from CL1.
>>>>
>>>> Unfortunately, if script 1 ends, there seems to be some clean up tasks
>>>> which run at the end of script 1 to unload CL1 from memory, and I am
>>>> getting an abort event in script 2, when trying to reference CL1. As is
>>>> the case when I try to play media to the Agent or Call Redirect them to the
>>>> callback number. If prevent script 1 from ending, and thus cleaning up
>>>> after itself, CL1 stays alive and script 2 works great. The question for
>>>> me now is, how do I release script 1, without also releasing CL1?
>>>>
>>>> One thought I had was to setup a Contact Inactive listener in script 1,
>>>> and use the Delay step in script 1 for an absurd amount of time, like 12
>>>> hours, and then rely on the fact that once CL1 transfers the Agent to the
>>>> callback number, CL1 goes inactive, and thus the 12 hour delay is
>>>> interrupted and script 1 can now end. In theory that is. In practice,
>>>> script 1 never receives a CIE event, and the delay continues for the 12
>>>> hours. No Beuno.
>>>>
>>>> Second thought was to signal something from script 2 to script 1, but
>>>> that requires looping in script 1 (polling). No beuno.
>>>>
>>>> Which by the way, I should mention, I am looking at your solution as a
>>>> way to avoid looping, though you didn't specifically say that you have
>>>> figured out a way to avoid looping. I was just being hopeful that somehow
>>>> your method did avoid looping.
>>>>
>>>> Like Brian Meade already mentioned, we have solved the "only once an
>>>> Agent answers" dilemma by using polling in script 1, and setting a flag in
>>>> script 2 once the agent answers, using Enterprise variables. Polling
>>>> solves the Agent only hearing the message from the top, versus in the
>>>> middle, but it doesn't solve the finite script steps issue.
>>>>
>>>> Therefore, I am wondering how you are handling script 1, post
>>>> successful place call.
>>>>
>>>> Don't get me wrong, I'm still #TeamTanner, and will be converting my
>>>> callback method to yours, since there are some advantages. I just have to
>>>> solve the script 1 clean up problem first.
>>>>
>>>> On Wed, Nov 6, 2019 at 4:09 PM Anthony Holloway <
>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>
>>>>> I actually got that part to work. What I'm wondering about is what
>>>>> you are doing in script 1 (place call script) after the successful branch.
>>>>> Like, are you looping, are you delaying, are just ending?
>>>>>
>>>>> On Wed, Nov 6, 2019 at 3:52 PM Tanner Ezell <tanner.ezell@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> It's really not all that complicated. Think of it this way, the place
>>>>>> call is the contact the agent is exposed to when they answer the queued
>>>>>> call, which of course is just the IVR.
>>>>>>
>>>>>> Pass the generated contact to the agent script (the one that has the
>>>>>> select resource), under the connected branch is when you know that your
>>>>>> other IVR application contact (from place call), connected to the agent.
>>>>>> Use the passed contact and play media just like you would any other
>>>>>> contact. In essence, you take the agent menu out of script 1 and put it in
>>>>>> script 2 :)
>>>>>>
>>>>>> With all that you can do some cool stuff, like ensuring the agent
>>>>>> doesn't just hang up (aka callback resiliency) and what to do if they do
>>>>>> (like re-queue, email a supervisor, re-call the agent, etc), can control if
>>>>>> the designated callback destination doesn't answer and some other fun stuff.
>>>>>>
>>>>>> happy hacking!
>>>>>>
>>>>>> On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
>>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>>
>>>>>>> Tanner, Can you describe, or show what you're doing in script 1,
>>>>>>> which has the Place Call step, inside the Successful branch?
>>>>>>>
>>>>>>> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>>>>>>>>
>>>>>>>>>>> Fax: +19897795900
>>>>>>>>>>>
>>>>>>>>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> cisco-voip mailing list
>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>
>>>>>>>>

Tanner, That was tongue in cheek my man. I was really looking forward to
having more of a conversation with you about the thread locking solution,
and balancing the pros and the cons with it.

Also, I'm still confused how you are doing your solution, pertaining
specifically to keeping script 1 alive, as I have found that it needs to
remain alive, else you lose Leg 1's Contact (likely due to it being Garbage
Collected).



On Fri, Nov 8, 2019 at 11:43 AM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> [image: image.png]
>
> On Wed, Nov 6, 2019 at 6:18 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
>> To your last point about CIE: it doesn't work for me anyway, and I'm not
>> trying to have the script do anything else, so threadlocking doesn't sound
>> all that bad. Unless of course you're trying to tell me that it's not just
>> the thread my script is running within, but the entire CCX Engine as a
>> thread, then yeah, that's pretty terrible. Though, I just did a test,
>> where I thread slept for 100 seconds in script A, and during that time,
>> called into script B, and made sure everything worked fine while the
>> threadlocking should have been taking place. So, I would say it's not the
>> CCX Engine as a whole, and likely each script is executed in its own
>> thread. This should be acceptable in this one use case.
>>
>> It's still a mystery to me how you're handling script 1.
>>
>> It kind of sounds like you are doing a 999s delay loop, but are you
>> checking for the contact to be active still with the Get Contact Info
>> step? So, essentially the same thing I was doing, but with script steps
>> instead (and less frequently)? If so, then your script 1 stays active for
>> ~15 minutes, worst case scenario, after the callback has been completed,
>> correct?
>>
>> E.g.,
>>
>> CL1 = Place Call ()
>> Successful
>> LABEL0:
>> Delay 999s
>> is_active = Get Contact Info (CL1)
>> If (is_active)
>> True
>> Goto LABEL0
>> End
>>
>> On Wed, Nov 6, 2019 at 5:55 PM Tanner Ezell <tanner.ezell@gmail.com>
>> wrote:
>>
>>> I place an exception handler for contact inactive, checking for the
>>> callback contact via get Contact Info step to make sure the caller hanging
>>> up didn't catch the exception.
>>>
>>> From there I have programmed in resiliency for the callback to be hung
>>> up by the agent, but beyond that there is a Delay 999s loop. You'll never
>>> hit the limit as you've discovered.
>>>
>>> Would not recommend Thread.sleep inside your code as it will thread lock
>>> the task and may interfere; for example, it may prevent the CIE to be
>>> caught properly in that script. Use Delay step, it's thread safe and is
>>> built in a way that allows exceptions to be handled.
>>>
>>> On Wed, Nov 6, 2019 at 4:46 PM Anthony Holloway <
>>> avholloway+cisco-voip@gmail.com> wrote:
>>>
>>>> Ok, so I solved the looping thing by...well...looping. :/
>>>>
>>>> So, loops themselves are not the problem, rather it's the finite script
>>>> steps we can execute which are the problem...err...challenge.
>>>>
>>>> Since the CIE doesn't get thrown in script 1 properly (bug?), I used a
>>>> Do step in the success branch of the Place Call step to wait for the active
>>>> state of CL1 to change. Like so:
>>>>
>>>> Do {
>>>> do {
>>>> java.lang.Thread.sleep(1000);
>>>> } while (contact_leg_1.isActive());
>>>> }
>>>>
>>>> CL1 only becomes inactive once the Agent acknowledges the callback and
>>>> the call redirect is successful. Therefore, I get all the benefits of
>>>> Tanner's solution, plus I can keep the max steps at 1,000, and technically
>>>> queue for 12 hours (the CallManager default max call timer).
>>>>
>>>> I think this should work just fine, though, more rigorous testing will
>>>> be needed. What do you think?
>>>>
>>>> On Wed, Nov 6, 2019 at 5:10 PM Anthony Holloway <
>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>
>>>>> I see that the contact in both scripts is actually the same contact,
>>>>> but each script views the contact from a different leg/sequence number
>>>>> (I.e., Outbound leg versus Inbound leg)
>>>>>
>>>>> *Contact Created with Place Call Step (AKA CL1 for Call Leg 1)*
>>>>>
>>>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=155,
>>>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=false,App
>>>>> name=App1,task=26000000240,session=3000000115,seq num=0
>>>>> ,cn=2411,dn=null,cgn=2402,ani=null,dnis=null,clid=null,atype=OUTBOUND
>>>>> ,lrd=null,ocn=2411,route=RP[num=0000],OrigProtocolCallRef=null,DestProtocolCallRef=000000000009A8A902F728A200000000,TP=2402]§
>>>>>
>>>>>
>>>>> *--Triggering Contact-- in the Queuing Script (AKA CL2 for Call Leg 2)*
>>>>>
>>>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=156,
>>>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=true,App
>>>>> name=App2,task=26000000241,session=3000000115,seq num=1
>>>>> ,cn=2411,dn=2411,cgn=2402,ani=null,dnis=null,clid=null,atype=DIRECT
>>>>> ,lrd=null,ocn=2411,route=RP[num=2411],OrigProtocolCallRef=000000000009A8A902F728A400000000,DestProtocolCallRef=null,TP=2401]§
>>>>>
>>>>>
>>>>> So, things like Set/Get Enterprise Call Info work on the same contact,
>>>>> because they are leg independent, whereas things requiring media, like Play
>>>>> Prompt, are call leg dependent, and need to reference the correct call leg
>>>>> of the contact. Hence, you have to pass the CL1 object into Script 2, in
>>>>> order to interact with the Agent from CL1.
>>>>>
>>>>> Unfortunately, if script 1 ends, there seems to be some clean up tasks
>>>>> which run at the end of script 1 to unload CL1 from memory, and I am
>>>>> getting an abort event in script 2, when trying to reference CL1. As is
>>>>> the case when I try to play media to the Agent or Call Redirect them to the
>>>>> callback number. If prevent script 1 from ending, and thus cleaning up
>>>>> after itself, CL1 stays alive and script 2 works great. The question for
>>>>> me now is, how do I release script 1, without also releasing CL1?
>>>>>
>>>>> One thought I had was to setup a Contact Inactive listener in script
>>>>> 1, and use the Delay step in script 1 for an absurd amount of time, like 12
>>>>> hours, and then rely on the fact that once CL1 transfers the Agent to the
>>>>> callback number, CL1 goes inactive, and thus the 12 hour delay is
>>>>> interrupted and script 1 can now end. In theory that is. In practice,
>>>>> script 1 never receives a CIE event, and the delay continues for the 12
>>>>> hours. No Beuno.
>>>>>
>>>>> Second thought was to signal something from script 2 to script 1, but
>>>>> that requires looping in script 1 (polling). No beuno.
>>>>>
>>>>> Which by the way, I should mention, I am looking at your solution as a
>>>>> way to avoid looping, though you didn't specifically say that you have
>>>>> figured out a way to avoid looping. I was just being hopeful that somehow
>>>>> your method did avoid looping.
>>>>>
>>>>> Like Brian Meade already mentioned, we have solved the "only once an
>>>>> Agent answers" dilemma by using polling in script 1, and setting a flag in
>>>>> script 2 once the agent answers, using Enterprise variables. Polling
>>>>> solves the Agent only hearing the message from the top, versus in the
>>>>> middle, but it doesn't solve the finite script steps issue.
>>>>>
>>>>> Therefore, I am wondering how you are handling script 1, post
>>>>> successful place call.
>>>>>
>>>>> Don't get me wrong, I'm still #TeamTanner, and will be converting my
>>>>> callback method to yours, since there are some advantages. I just have to
>>>>> solve the script 1 clean up problem first.
>>>>>
>>>>> On Wed, Nov 6, 2019 at 4:09 PM Anthony Holloway <
>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>
>>>>>> I actually got that part to work. What I'm wondering about is what
>>>>>> you are doing in script 1 (place call script) after the successful branch.
>>>>>> Like, are you looping, are you delaying, are just ending?
>>>>>>
>>>>>> On Wed, Nov 6, 2019 at 3:52 PM Tanner Ezell <tanner.ezell@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> It's really not all that complicated. Think of it this way, the
>>>>>>> place call is the contact the agent is exposed to when they answer the
>>>>>>> queued call, which of course is just the IVR.
>>>>>>>
>>>>>>> Pass the generated contact to the agent script (the one that has the
>>>>>>> select resource), under the connected branch is when you know that your
>>>>>>> other IVR application contact (from place call), connected to the agent.
>>>>>>> Use the passed contact and play media just like you would any other
>>>>>>> contact. In essence, you take the agent menu out of script 1 and put it in
>>>>>>> script 2 :)
>>>>>>>
>>>>>>> With all that you can do some cool stuff, like ensuring the agent
>>>>>>> doesn't just hang up (aka callback resiliency) and what to do if they do
>>>>>>> (like re-queue, email a supervisor, re-call the agent, etc), can control if
>>>>>>> the designated callback destination doesn't answer and some other fun stuff.
>>>>>>>
>>>>>>> happy hacking!
>>>>>>>
>>>>>>> On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
>>>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>>>
>>>>>>>> Tanner, Can you describe, or show what you're doing in script 1,
>>>>>>>> which has the Place Call step, inside the Successful branch?
>>>>>>>>
>>>>>>>> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <tanner.ezell@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@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@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@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@cmich.edu
>>>>>>>>>>>>
>>>>>>>>>>>> Fax: +19897795900
>>>>>>>>>>>>
>>>>>>>>>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>
>>>>>>>>>

Tanner, I ran a test and actually, anything inside the Do step will block
events.

As a test, I used this Do step:

Do {
int i = 0;
do {
i++;
} while (i <= 100000000);
}

And then hang up the a call during the do step, and see that nothing
happens; no interrupt. However, the label we ask the script to goto on CIE
is then the label which is executed next. This seems obvious when you
consider that there isn't a toggle-able option for interrupt handling on
the Do step.

But back to your method of handling callbacks, because I find it so
interesting.

I found that if in script 2, if the Agent just hangs up, you cannot
re-queue the call, because CL2 is now dead. And in order to generate a new
active Contact Leg, you'd need to re-do the place call step, which means
you would need to signal something back to script 1.

Signaling between two running scripts is non-trivial and requires polling,
since Cisco hasn't implemented promises yet. ;)

On Mon, Nov 11, 2019 at 2:13 PM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> Tanner, That was tongue in cheek my man. I was really looking forward to
> having more of a conversation with you about the thread locking solution,
> and balancing the pros and the cons with it.
>
> Also, I'm still confused how you are doing your solution, pertaining
> specifically to keeping script 1 alive, as I have found that it needs to
> remain alive, else you lose Leg 1's Contact (likely due to it being Garbage
> Collected).
>
>
>
> On Fri, Nov 8, 2019 at 11:43 AM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
>> [image: image.png]
>>
>> On Wed, Nov 6, 2019 at 6:18 PM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>>> To your last point about CIE: it doesn't work for me anyway, and I'm not
>>> trying to have the script do anything else, so threadlocking doesn't sound
>>> all that bad. Unless of course you're trying to tell me that it's not just
>>> the thread my script is running within, but the entire CCX Engine as a
>>> thread, then yeah, that's pretty terrible. Though, I just did a test,
>>> where I thread slept for 100 seconds in script A, and during that time,
>>> called into script B, and made sure everything worked fine while the
>>> threadlocking should have been taking place. So, I would say it's not the
>>> CCX Engine as a whole, and likely each script is executed in its own
>>> thread. This should be acceptable in this one use case.
>>>
>>> It's still a mystery to me how you're handling script 1.
>>>
>>> It kind of sounds like you are doing a 999s delay loop, but are you
>>> checking for the contact to be active still with the Get Contact Info
>>> step? So, essentially the same thing I was doing, but with script steps
>>> instead (and less frequently)? If so, then your script 1 stays active for
>>> ~15 minutes, worst case scenario, after the callback has been completed,
>>> correct?
>>>
>>> E.g.,
>>>
>>> CL1 = Place Call ()
>>> Successful
>>> LABEL0:
>>> Delay 999s
>>> is_active = Get Contact Info (CL1)
>>> If (is_active)
>>> True
>>> Goto LABEL0
>>> End
>>>
>>> On Wed, Nov 6, 2019 at 5:55 PM Tanner Ezell <tanner.ezell@gmail.com>
>>> wrote:
>>>
>>>> I place an exception handler for contact inactive, checking for the
>>>> callback contact via get Contact Info step to make sure the caller hanging
>>>> up didn't catch the exception.
>>>>
>>>> From there I have programmed in resiliency for the callback to be hung
>>>> up by the agent, but beyond that there is a Delay 999s loop. You'll never
>>>> hit the limit as you've discovered.
>>>>
>>>> Would not recommend Thread.sleep inside your code as it will thread
>>>> lock the task and may interfere; for example, it may prevent the CIE to be
>>>> caught properly in that script. Use Delay step, it's thread safe and is
>>>> built in a way that allows exceptions to be handled.
>>>>
>>>> On Wed, Nov 6, 2019 at 4:46 PM Anthony Holloway <
>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>
>>>>> Ok, so I solved the looping thing by...well...looping. :/
>>>>>
>>>>> So, loops themselves are not the problem, rather it's the finite
>>>>> script steps we can execute which are the problem...err...challenge.
>>>>>
>>>>> Since the CIE doesn't get thrown in script 1 properly (bug?), I used a
>>>>> Do step in the success branch of the Place Call step to wait for the active
>>>>> state of CL1 to change. Like so:
>>>>>
>>>>> Do {
>>>>> do {
>>>>> java.lang.Thread.sleep(1000);
>>>>> } while (contact_leg_1.isActive());
>>>>> }
>>>>>
>>>>> CL1 only becomes inactive once the Agent acknowledges the callback and
>>>>> the call redirect is successful. Therefore, I get all the benefits of
>>>>> Tanner's solution, plus I can keep the max steps at 1,000, and technically
>>>>> queue for 12 hours (the CallManager default max call timer).
>>>>>
>>>>> I think this should work just fine, though, more rigorous testing will
>>>>> be needed. What do you think?
>>>>>
>>>>> On Wed, Nov 6, 2019 at 5:10 PM Anthony Holloway <
>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>
>>>>>> I see that the contact in both scripts is actually the same contact,
>>>>>> but each script views the contact from a different leg/sequence number
>>>>>> (I.e., Outbound leg versus Inbound leg)
>>>>>>
>>>>>> *Contact Created with Place Call Step (AKA CL1 for Call Leg 1)*
>>>>>>
>>>>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=155,
>>>>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=false,App
>>>>>> name=App1,task=26000000240,session=3000000115,seq num=0
>>>>>> ,cn=2411,dn=null,cgn=2402,ani=null,dnis=null,clid=null,atype=OUTBOUND
>>>>>> ,lrd=null,ocn=2411,route=RP[num=0000],OrigProtocolCallRef=null,DestProtocolCallRef=000000000009A8A902F728A200000000,TP=2402]§
>>>>>>
>>>>>>
>>>>>> *--Triggering Contact-- in the Queuing Script (AKA CL2 for Call Leg
>>>>>> 2)*
>>>>>>
>>>>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=156,
>>>>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=true,App
>>>>>> name=App2,task=26000000241,session=3000000115,seq num=1
>>>>>> ,cn=2411,dn=2411,cgn=2402,ani=null,dnis=null,clid=null,atype=DIRECT
>>>>>> ,lrd=null,ocn=2411,route=RP[num=2411],OrigProtocolCallRef=000000000009A8A902F728A400000000,DestProtocolCallRef=null,TP=2401]§
>>>>>>
>>>>>>
>>>>>> So, things like Set/Get Enterprise Call Info work on the same
>>>>>> contact, because they are leg independent, whereas things requiring media,
>>>>>> like Play Prompt, are call leg dependent, and need to reference the correct
>>>>>> call leg of the contact. Hence, you have to pass the CL1 object into
>>>>>> Script 2, in order to interact with the Agent from CL1.
>>>>>>
>>>>>> Unfortunately, if script 1 ends, there seems to be some clean up
>>>>>> tasks which run at the end of script 1 to unload CL1 from memory, and I am
>>>>>> getting an abort event in script 2, when trying to reference CL1. As is
>>>>>> the case when I try to play media to the Agent or Call Redirect them to the
>>>>>> callback number. If prevent script 1 from ending, and thus cleaning up
>>>>>> after itself, CL1 stays alive and script 2 works great. The question for
>>>>>> me now is, how do I release script 1, without also releasing CL1?
>>>>>>
>>>>>> One thought I had was to setup a Contact Inactive listener in script
>>>>>> 1, and use the Delay step in script 1 for an absurd amount of time, like 12
>>>>>> hours, and then rely on the fact that once CL1 transfers the Agent to the
>>>>>> callback number, CL1 goes inactive, and thus the 12 hour delay is
>>>>>> interrupted and script 1 can now end. In theory that is. In practice,
>>>>>> script 1 never receives a CIE event, and the delay continues for the 12
>>>>>> hours. No Beuno.
>>>>>>
>>>>>> Second thought was to signal something from script 2 to script 1, but
>>>>>> that requires looping in script 1 (polling). No beuno.
>>>>>>
>>>>>> Which by the way, I should mention, I am looking at your solution as
>>>>>> a way to avoid looping, though you didn't specifically say that you have
>>>>>> figured out a way to avoid looping. I was just being hopeful that somehow
>>>>>> your method did avoid looping.
>>>>>>
>>>>>> Like Brian Meade already mentioned, we have solved the "only once an
>>>>>> Agent answers" dilemma by using polling in script 1, and setting a flag in
>>>>>> script 2 once the agent answers, using Enterprise variables. Polling
>>>>>> solves the Agent only hearing the message from the top, versus in the
>>>>>> middle, but it doesn't solve the finite script steps issue.
>>>>>>
>>>>>> Therefore, I am wondering how you are handling script 1, post
>>>>>> successful place call.
>>>>>>
>>>>>> Don't get me wrong, I'm still #TeamTanner, and will be converting my
>>>>>> callback method to yours, since there are some advantages. I just have to
>>>>>> solve the script 1 clean up problem first.
>>>>>>
>>>>>> On Wed, Nov 6, 2019 at 4:09 PM Anthony Holloway <
>>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>>
>>>>>>> I actually got that part to work. What I'm wondering about is what
>>>>>>> you are doing in script 1 (place call script) after the successful branch.
>>>>>>> Like, are you looping, are you delaying, are just ending?
>>>>>>>
>>>>>>> On Wed, Nov 6, 2019 at 3:52 PM Tanner Ezell <tanner.ezell@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> It's really not all that complicated. Think of it this way, the
>>>>>>>> place call is the contact the agent is exposed to when they answer the
>>>>>>>> queued call, which of course is just the IVR.
>>>>>>>>
>>>>>>>> Pass the generated contact to the agent script (the one that has
>>>>>>>> the select resource), under the connected branch is when you know that your
>>>>>>>> other IVR application contact (from place call), connected to the agent.
>>>>>>>> Use the passed contact and play media just like you would any other
>>>>>>>> contact. In essence, you take the agent menu out of script 1 and put it in
>>>>>>>> script 2 :)
>>>>>>>>
>>>>>>>> With all that you can do some cool stuff, like ensuring the agent
>>>>>>>> doesn't just hang up (aka callback resiliency) and what to do if they do
>>>>>>>> (like re-queue, email a supervisor, re-call the agent, etc), can control if
>>>>>>>> the designated callback destination doesn't answer and some other fun stuff.
>>>>>>>>
>>>>>>>> happy hacking!
>>>>>>>>
>>>>>>>> On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
>>>>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Tanner, Can you describe, or show what you're doing in script 1,
>>>>>>>>> which has the Place Call step, inside the Successful branch?
>>>>>>>>>
>>>>>>>>> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <
>>>>>>>>> tanner.ezell@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@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@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@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@cmich.edu
>>>>>>>>>>>>>
>>>>>>>>>>>>> Fax: +19897795900
>>>>>>>>>>>>>
>>>>>>>>>>>>> [image: webexemailsig] <https://cmich.webex.com/meet/johns10t>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>
>>>>>>>>>>

Bump.

On Thu, Nov 14, 2019 at 10:12 AM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> Tanner, I ran a test and actually, anything inside the Do step will block
> events.
>
> As a test, I used this Do step:
>
> Do {
> int i = 0;
> do {
> i++;
> } while (i <= 100000000);
> }
>
> And then hang up the a call during the do step, and see that nothing
> happens; no interrupt. However, the label we ask the script to goto on CIE
> is then the label which is executed next. This seems obvious when you
> consider that there isn't a toggle-able option for interrupt handling on
> the Do step.
>
> But back to your method of handling callbacks, because I find it so
> interesting.
>
> I found that if in script 2, if the Agent just hangs up, you cannot
> re-queue the call, because CL2 is now dead. And in order to generate a new
> active Contact Leg, you'd need to re-do the place call step, which means
> you would need to signal something back to script 1.
>
> Signaling between two running scripts is non-trivial and requires polling,
> since Cisco hasn't implemented promises yet. ;)
>
> On Mon, Nov 11, 2019 at 2:13 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
>> Tanner, That was tongue in cheek my man. I was really looking forward to
>> having more of a conversation with you about the thread locking solution,
>> and balancing the pros and the cons with it.
>>
>> Also, I'm still confused how you are doing your solution, pertaining
>> specifically to keeping script 1 alive, as I have found that it needs to
>> remain alive, else you lose Leg 1's Contact (likely due to it being Garbage
>> Collected).
>>
>>
>>
>> On Fri, Nov 8, 2019 at 11:43 AM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>>> [image: image.png]
>>>
>>> On Wed, Nov 6, 2019 at 6:18 PM Anthony Holloway <
>>> avholloway+cisco-voip@gmail.com> wrote:
>>>
>>>> To your last point about CIE: it doesn't work for me anyway, and I'm
>>>> not trying to have the script do anything else, so threadlocking doesn't
>>>> sound all that bad. Unless of course you're trying to tell me that it's
>>>> not just the thread my script is running within, but the entire CCX Engine
>>>> as a thread, then yeah, that's pretty terrible. Though, I just did a test,
>>>> where I thread slept for 100 seconds in script A, and during that time,
>>>> called into script B, and made sure everything worked fine while the
>>>> threadlocking should have been taking place. So, I would say it's not the
>>>> CCX Engine as a whole, and likely each script is executed in its own
>>>> thread. This should be acceptable in this one use case.
>>>>
>>>> It's still a mystery to me how you're handling script 1.
>>>>
>>>> It kind of sounds like you are doing a 999s delay loop, but are you
>>>> checking for the contact to be active still with the Get Contact Info
>>>> step? So, essentially the same thing I was doing, but with script steps
>>>> instead (and less frequently)? If so, then your script 1 stays active for
>>>> ~15 minutes, worst case scenario, after the callback has been completed,
>>>> correct?
>>>>
>>>> E.g.,
>>>>
>>>> CL1 = Place Call ()
>>>> Successful
>>>> LABEL0:
>>>> Delay 999s
>>>> is_active = Get Contact Info (CL1)
>>>> If (is_active)
>>>> True
>>>> Goto LABEL0
>>>> End
>>>>
>>>> On Wed, Nov 6, 2019 at 5:55 PM Tanner Ezell <tanner.ezell@gmail.com>
>>>> wrote:
>>>>
>>>>> I place an exception handler for contact inactive, checking for the
>>>>> callback contact via get Contact Info step to make sure the caller hanging
>>>>> up didn't catch the exception.
>>>>>
>>>>> From there I have programmed in resiliency for the callback to be hung
>>>>> up by the agent, but beyond that there is a Delay 999s loop. You'll never
>>>>> hit the limit as you've discovered.
>>>>>
>>>>> Would not recommend Thread.sleep inside your code as it will thread
>>>>> lock the task and may interfere; for example, it may prevent the CIE to be
>>>>> caught properly in that script. Use Delay step, it's thread safe and is
>>>>> built in a way that allows exceptions to be handled.
>>>>>
>>>>> On Wed, Nov 6, 2019 at 4:46 PM Anthony Holloway <
>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>
>>>>>> Ok, so I solved the looping thing by...well...looping. :/
>>>>>>
>>>>>> So, loops themselves are not the problem, rather it's the finite
>>>>>> script steps we can execute which are the problem...err...challenge.
>>>>>>
>>>>>> Since the CIE doesn't get thrown in script 1 properly (bug?), I used
>>>>>> a Do step in the success branch of the Place Call step to wait for the
>>>>>> active state of CL1 to change. Like so:
>>>>>>
>>>>>> Do {
>>>>>> do {
>>>>>> java.lang.Thread.sleep(1000);
>>>>>> } while (contact_leg_1.isActive());
>>>>>> }
>>>>>>
>>>>>> CL1 only becomes inactive once the Agent acknowledges the callback
>>>>>> and the call redirect is successful. Therefore, I get all the benefits of
>>>>>> Tanner's solution, plus I can keep the max steps at 1,000, and technically
>>>>>> queue for 12 hours (the CallManager default max call timer).
>>>>>>
>>>>>> I think this should work just fine, though, more rigorous testing
>>>>>> will be needed. What do you think?
>>>>>>
>>>>>> On Wed, Nov 6, 2019 at 5:10 PM Anthony Holloway <
>>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>>
>>>>>>> I see that the contact in both scripts is actually the same contact,
>>>>>>> but each script views the contact from a different leg/sequence number
>>>>>>> (I.e., Outbound leg versus Inbound leg)
>>>>>>>
>>>>>>> *Contact Created with Place Call Step (AKA CL1 for Call Leg 1)*
>>>>>>>
>>>>>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[.id=155,
>>>>>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=false,App
>>>>>>> name=App1,task=26000000240,session=3000000115,seq num=0
>>>>>>> ,cn=2411,dn=null,cgn=2402,ani=null,dnis=null,clid=null,
>>>>>>> atype=OUTBOUND
>>>>>>> ,lrd=null,ocn=2411,route=RP[num=0000],OrigProtocolCallRef=null,DestProtocolCallRef=000000000009A8A902F728A200000000,TP=2402]§
>>>>>>>
>>>>>>>
>>>>>>> *--Triggering Contact-- in the Queuing Script (AKA CL2 for Call Leg
>>>>>>> 2)*
>>>>>>>
>>>>>>> §com.cisco.wf.subsystems.jtapi.CallImpl§JTAPICallContact[id=156,
>>>>>>> implId=633001/1,state=STATE_ANSWERED_IDX,inbound=true,App
>>>>>>> name=App2,task=26000000241,session=3000000115,seq num=1
>>>>>>> ,cn=2411,dn=2411,cgn=2402,ani=null,dnis=null,clid=null,atype=DIRECT
>>>>>>> ,lrd=null,ocn=2411,route=RP[num=2411],OrigProtocolCallRef=000000000009A8A902F728A400000000,DestProtocolCallRef=null,TP=2401]§
>>>>>>>
>>>>>>>
>>>>>>> So, things like Set/Get Enterprise Call Info work on the same
>>>>>>> contact, because they are leg independent, whereas things requiring media,
>>>>>>> like Play Prompt, are call leg dependent, and need to reference the correct
>>>>>>> call leg of the contact. Hence, you have to pass the CL1 object into
>>>>>>> Script 2, in order to interact with the Agent from CL1.
>>>>>>>
>>>>>>> Unfortunately, if script 1 ends, there seems to be some clean up
>>>>>>> tasks which run at the end of script 1 to unload CL1 from memory, and I am
>>>>>>> getting an abort event in script 2, when trying to reference CL1. As is
>>>>>>> the case when I try to play media to the Agent or Call Redirect them to the
>>>>>>> callback number. If prevent script 1 from ending, and thus cleaning up
>>>>>>> after itself, CL1 stays alive and script 2 works great. The question for
>>>>>>> me now is, how do I release script 1, without also releasing CL1?
>>>>>>>
>>>>>>> One thought I had was to setup a Contact Inactive listener in script
>>>>>>> 1, and use the Delay step in script 1 for an absurd amount of time, like 12
>>>>>>> hours, and then rely on the fact that once CL1 transfers the Agent to the
>>>>>>> callback number, CL1 goes inactive, and thus the 12 hour delay is
>>>>>>> interrupted and script 1 can now end. In theory that is. In practice,
>>>>>>> script 1 never receives a CIE event, and the delay continues for the 12
>>>>>>> hours. No Beuno.
>>>>>>>
>>>>>>> Second thought was to signal something from script 2 to script 1,
>>>>>>> but that requires looping in script 1 (polling). No beuno.
>>>>>>>
>>>>>>> Which by the way, I should mention, I am looking at your solution as
>>>>>>> a way to avoid looping, though you didn't specifically say that you have
>>>>>>> figured out a way to avoid looping. I was just being hopeful that somehow
>>>>>>> your method did avoid looping.
>>>>>>>
>>>>>>> Like Brian Meade already mentioned, we have solved the "only once an
>>>>>>> Agent answers" dilemma by using polling in script 1, and setting a flag in
>>>>>>> script 2 once the agent answers, using Enterprise variables. Polling
>>>>>>> solves the Agent only hearing the message from the top, versus in the
>>>>>>> middle, but it doesn't solve the finite script steps issue.
>>>>>>>
>>>>>>> Therefore, I am wondering how you are handling script 1, post
>>>>>>> successful place call.
>>>>>>>
>>>>>>> Don't get me wrong, I'm still #TeamTanner, and will be converting my
>>>>>>> callback method to yours, since there are some advantages. I just have to
>>>>>>> solve the script 1 clean up problem first.
>>>>>>>
>>>>>>> On Wed, Nov 6, 2019 at 4:09 PM Anthony Holloway <
>>>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>>>
>>>>>>>> I actually got that part to work. What I'm wondering about is what
>>>>>>>> you are doing in script 1 (place call script) after the successful branch.
>>>>>>>> Like, are you looping, are you delaying, are just ending?
>>>>>>>>
>>>>>>>> On Wed, Nov 6, 2019 at 3:52 PM Tanner Ezell <tanner.ezell@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> It's really not all that complicated. Think of it this way, the
>>>>>>>>> place call is the contact the agent is exposed to when they answer the
>>>>>>>>> queued call, which of course is just the IVR.
>>>>>>>>>
>>>>>>>>> Pass the generated contact to the agent script (the one that has
>>>>>>>>> the select resource), under the connected branch is when you know that your
>>>>>>>>> other IVR application contact (from place call), connected to the agent.
>>>>>>>>> Use the passed contact and play media just like you would any other
>>>>>>>>> contact. In essence, you take the agent menu out of script 1 and put it in
>>>>>>>>> script 2 :)
>>>>>>>>>
>>>>>>>>> With all that you can do some cool stuff, like ensuring the agent
>>>>>>>>> doesn't just hang up (aka callback resiliency) and what to do if they do
>>>>>>>>> (like re-queue, email a supervisor, re-call the agent, etc), can control if
>>>>>>>>> the designated callback destination doesn't answer and some other fun stuff.
>>>>>>>>>
>>>>>>>>> happy hacking!
>>>>>>>>>
>>>>>>>>> On Wed, Nov 6, 2019 at 2:20 PM Anthony Holloway <
>>>>>>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Tanner, Can you describe, or show what you're doing in script 1,
>>>>>>>>>> which has the Place Call step, inside the Successful branch?
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 5, 2019 at 4:30 PM Tanner Ezell <
>>>>>>>>>> tanner.ezell@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@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@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@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@cmich.edu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Fax: +19897795900
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [image: webexemailsig]
>>>>>>>>>>>>>> <https://cmich.webex.com/meet/johns10t>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> cisco-voip mailing list
>>>>>>>>>>>> cisco-voip@puck.nether.net
>>>>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>>>>>>
>>>>>>>>>>>