[cisco-voip] HTTP Response for HTTP Triggered Script

Tue Jan 28 16:15:19 EST 2020

That sounds like way more fun than I’m willing to have!

Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com | e: MLoraditch at heliontechnologies.com
From: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Sent: Tuesday, January 28, 2020 3:59 PM
To: Matthew Loraditch <MLoraditch at heliontechnologies.com>
Cc: Johnson, Tim <johns10t at cmich.edu>; Cisco VoIP Group <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] HTTP Response for HTTP Triggered Script

[EXTERNAL]

I mean, you could probably contain it all in a single app script and by inspecting the triggering events/data, figure out which phase you're on.

E.g., If trigger is HTTP Trigger then Phase 1; If Trigger is JTAPI extension 1000, then Phase 3, else Phase 2

There's probably something to be concerned about when it comes to packing so much into such a small space, and troubleshooting issues might be harder, but I bet its achievable.

On Tue, Jan 28, 2020 at 9:40 AM Matthew Loraditch <MLoraditch at heliontechnologies.com<mailto:MLoraditch at heliontechnologies.com>> wrote:
So basically I need 3 separate applications. The HTTP Trigger to take the input then pass the input to another application that then places the call into the queue that’s in a third application.

Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518<tel:443.541.1518>
w: www.heliontechnologies.com<http://www.heliontechnologies.com/>
 |
e: MLoraditch at heliontechnologies.com<mailto:MLoraditch at heliontechnologies.com>
[Helion Technologies]<http://www.heliontechnologies.com/>
[Facebook]<https://facebook.com/heliontech>
[Twitter]<https://twitter.com/heliontech>
[LinkedIn]<https://www.linkedin.com/company/helion-technologies>
[cid:image006.jpg at 01D5D5F4.FE801100]
From: Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>>
Sent: Tuesday, January 28, 2020 10:24 AM
To: Johnson, Tim <johns10t at cmich.edu<mailto:johns10t at cmich.edu>>
Cc: Matthew Loraditch <MLoraditch at heliontechnologies.com<mailto:MLoraditch at heliontechnologies.com>>; Cisco VoIP Group <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: Re: [cisco-voip] HTTP Response for HTTP Triggered Script

[EXTERNAL]

Tim is correct: this is normal from my experience too.

I feel partly responsible for your woes, since I think you found that solution from me pointing out the script repository online.

Thinking about it some more, I think I would have the HTTP Triggered Application use the Trigger Application step in async mode, to start the initial callback feature, and then it can just End almost immediately.

I through together this quick and dirty MS Paint representation of it:

[cid:image007.png at 01D5D5F4.FE801100]

There's like a dozen ways to solve this, and this is just one of them.  Some details are left out of the drawing on purpose, so if you get stuck, let's keep this thread going.

On Tue, Jan 28, 2020, 7:14 AM Johnson, Tim <johns10t at cmich.edu<mailto:johns10t at cmich.edu>> wrote:
As far as my experience, this is “normal” for UCCX. Yes, I believe the request stays open until the script ends. I believe we opened up a TAC case about it a year or two ago but I don’t believe it went anywhere.

From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> On Behalf Of Matthew Loraditch
Sent: Tuesday, January 28, 2020 8:06 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] HTTP Response for HTTP Triggered Script

Got the following comment from the developer who is writing an app that will queue a call via http trigger:
It seems like the MobileApp integration is accepting my request, spits back some HTML, but the HTTP request remains open until the queued call is answered.

Ideally, that HTTP request would be closed with a successful HTTP status code (e.g. HTTP 200) when the call was queued, so that I can report back to the user that they can wait for a callback.

I understand his problem, but I see no way  of fixing it. The send http response command doesn’t seem to have any settings but the doc sent back. Is this normal behavior or can I do something with the doc being sent back to make it work?

Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518<tel:443.541.1518>
w: www.heliontechnologies.com<http://www.heliontechnologies.com/>
 |
e: MLoraditch at heliontechnologies.com<mailto:MLoraditch at heliontechnologies.com>
 <http://www.heliontechnologies.com/>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip<http://www.heliontechnologies.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 431 bytes
Desc: image003.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 561 bytes
Desc: image004.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 444 bytes
Desc: image005.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 19523 bytes
Desc: image006.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 19372 bytes
Desc: image007.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6884 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image034854.png
Type: image/png
Size: 9409 bytes
Desc: image034854.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image460416.png
Type: image/png
Size: 431 bytes
Desc: image460416.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image671084.png
Type: image/png
Size: 561 bytes
Desc: image671084.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image128737.png
Type: image/png
Size: 444 bytes
Desc: image128737.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image270337.jpg
Type: image/jpeg
Size: 19523 bytes
Desc: image270337.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/f52144f5/attachment-0001.jpg>