| Author |
Message |
|
|
|
NicholasKwiatkowski
![[Avatar]](http://cabs.msu.edu/toolkit/images/helmet/gif/Spartan-helmet-Green-50-pxls.gif?_ga=2.212029398.33051)
Joined: Dec 13, 2013
Messages: 32
Location: East Lansing, MI
Offline
|
Wondering if the following use-case is possible :
We have an app that gets executed when a caller calls into a particular call center. We do some basic IVR type things, then do an "Allow Call" and the workflow sends the call to the next item in the sequenced app (in our case, Avaya Aura Contact Center). What we would like to happen is when the agent then hangs up, the call is returned to the workflow to do some additional processing. Think of the use-case of an agent does an order of some widgets, then they send the call to a workflow that reads the database entries back to the customer to verify that is what they ordered.
We are struggling getting the call back to the workflow. It seems when the agent hangs up on caller, the call seems to die there. We've also tried having the agent transfer the call back to the workflow, but the callid (Call UUID) doesn't seem to match (a new one is generated).
Any thoughts on how to do something like this?
Thanks!
-Nick Kwiatkowski
Michigan State University Telecom Systems
|
--------------------------- Nick Kwiatkowski Michigan State University, Telecom Systems Planning and Engineering Team Adj. Professor of Media and Information Studies |
|
|
 |
|
|
|
AnuragAggarwal
Joined: Jun 1, 2014
Messages: 154
Offline
|
Hi,
so that the call is not dropped when agent drops, you can use "set call policy" task and use "drop_call_if _no _paritcipant_remains" in drop down. Thaw would prevent the call from getting dropped
to get back to workflow - you can create a custom event (say confirm_widgets), in workflow you can have receive task with that event. Workflow would wait for that event. After agent is done - you can raise that event and workflow would resume from that receive task
Regards, Anurag
|
|
|
|
|
|
|
NicholasKwiatkowski
Joined: Dec 13, 2013
Messages: 32
Location: East Lansing, MI
Offline
|
AnuragAggarwal wrote:so that the call is not dropped when agent drops, you can use "set call policy" task and use "drop_call_if _no _paritcipant_remains" in drop down. Thaw would prevent the call from getting dropped
Makes sense. Do you know if that is a ASM/SIP policy or a Breeze-specific one? The call is going through an adjunct (AACC) and that is where the call is being dropped.
AnuragAggarwal wrote:to get back to workflow - you can create a custom event (say confirm_widgets), in workflow you can have receive task with that event. Workflow would wait for that event. After agent is done - you can raise that event and workflow would resume from that receive task
I guess I don't know how to actually raise the event from outside Breeze. I know I can do a REST call to the Eventing subsystem, but the call is going to 'live' within the adjunct that isn't really Breeze aware. |
--------------------------- Nick Kwiatkowski Michigan State University, Telecom Systems Planning and Engineering Team Adj. Professor of Media and Information Studies |
|
|
|
|
|
|
JoelEzell
Joined: Nov 15, 2013
Messages: 780
Offline
|
Hi Nick, it's good to hear from you again. Here's how things work.
When you invoke the Set Call Policy task with a call termination policy of "No participant remains", that tells Breeze to keep one-party calls alive. If it gets a BYE from either the customer or agent side, as long as the other side has not hung up, that call will remain active. In addition to the use case you mentioned, it can also be used to reconnect an agent to a customer if the call ended unexpectedly ("Was this drop expected? Press 1 to reconnect to the customer") or for post-call survey, among others.
The next question is how to wake up the workflow. I think the easiest way to do this is to put a "Receive" task that is looking for a "Participant Dropped" event. When you get this event, you can check to see whether the dropping party was the customer or the agent, then take appropriate action.
Hopefully this clarifies. Let us know if you have any follow-up questions.
|
|
|
|
|
|
|
NicholasKwiatkowski
Joined: Dec 13, 2013
Messages: 32
Location: East Lansing, MI
Offline
|
JoelEzell wrote:Hi Nick, it's good to hear from you again. Here's how things work.
When you invoke the Set Call Policy task with a call termination policy of "No participant remains", that tells Breeze to keep one-party calls alive. If it gets a BYE from either the customer or agent side, as long as the other side has not hung up, that call will remain active. In addition to the use case you mentioned, it can also be used to reconnect an agent to a customer if the call ended unexpectedly ("Was this drop expected? Press 1 to reconnect to the customer") or for post-call survey, among others.
The next question is how to wake up the workflow. I think the easiest way to do this is to put a "Receive" task that is looking for a "Participant Dropped" event. When you get this event, you can check to see whether the dropping party was the customer or the agent, then take appropriate action.
Hopefully this clarifies. Let us know if you have any follow-up questions.
Setting the call policy to DROP_CALL_WHEN_NO_PARTICIPANTS_REMAIN and waiting for the PARTICIPANT_DROPPED event did the trick. Setting the Criterion to Call and mapping the UCID we were searching for is something I found mentioned in one of the youtube videos, which was the last missing piece of the puzzle (I wasn't filtering on call before, and the event wasn't arriving).
The only thing remaining that I need to figure out is the Set Call Context. I'm trying to send some data to AACC, but I'm not sure if the format is correct. We see some data in AACC, but it looks like it might be in hex form, rather than dec, making it useless to the agent. Do you know if there are any parameters on the Breeze side for that (it is quite possible it is being mangled on the AACC side too). Thanks! |
--------------------------- Nick Kwiatkowski Michigan State University, Telecom Systems Planning and Engineering Team Adj. Professor of Media and Information Studies |
|
|
|
|
|
|
JoelEzell
Joined: Nov 15, 2013
Messages: 780
Offline
|
Nick, I'm happy to hear that you made progress. The User-to-User header is indeed hex encoded, and it includes much more data than just the Context ID. This is also the header that carries UCID, Collected Digits and more. I must admit, I fairly well loathe this header, but it's what we had to work with to interoperate with Experience Portal, CM and AES.
I'm somewhat surprised that AACC doesn't deal with this header format. One possibility available to you would be to introduce another snap-in that would read the Context ID from the Call object, populate it in a Call attribute, then use an OutgoingSipMessageListener to move that content to a separate header. A bit of a hack, I know, but it should work.
|
|
|
|
|
|
|
NicholasKwiatkowski
Joined: Dec 13, 2013
Messages: 32
Location: East Lansing, MI
Offline
|
JoelEzell wrote:Nick, I'm happy to hear that you made progress. The User-to-User header is indeed hex encoded, and it includes much more data than just the Context ID. This is also the header that carries UCID, Collected Digits and more. I must admit, I fairly well loathe this header, but it's what we had to work with to interoperate with Experience Portal, CM and AES.
Do you know if the format of this header is documented anywhere? Otherwise what might end up being easiest (albeit with a possible race condition) is for me to write this data into a DB, and pick it up in AACC via a database dip based on time/date, called party and calling party.
Thanks for the help! I've not used Engagement Designer a whole lot up to this point, but it's been fun watching my co-workers pick up on it and develop all these custom apps. I'm the only programmer in my group, but after doing a few tutorials on SQL, they are pretty much empowered enough to do some serious work with it :) |
--------------------------- Nick Kwiatkowski Michigan State University, Telecom Systems Planning and Engineering Team Adj. Professor of Media and Information Studies |
|
|
|
|
|
|
JoelEzell
Joined: Nov 15, 2013
Messages: 780
Offline
|
The only reference I have for the header format says it's proprietary, so I don't think I can share it. Try googling for "SIP User-to-User header Avaya" That turned up a number of references that may be useful.
I'm happy that your team has been enjoying Engagement Designer! Even though I'm a Java developer at heart, I find myself using ED for quick prototyping, and could definitely see myself using it to quickly create production workflows as well.
|
|
|
|
