In Communication Manager, it is possible to have a "route-to number <phonenumber>" followed by one or more commands, and if the route to delivers a busy signal, CM will continue processing commands on the next line. Is there any way to accomplish this same logic within ED/Breeze so that I can transfer a call but be able to continue to process commands should that transfer fail due to busy condition or some other error?

Use case would be I have a remote number that has a limited number of ports available. If I transfer a call out of ED/Breeze, I would not want to deliver a busy to that customer (release call control). I would want to be able to continue processing commands should that transfer fail.

Yes, if you use the Set Call Policy task, you can set the call termination policy to "DROP_CALL_WHEN_NO_PARTICIPANT_REMAINS". This will keep the calling party leg alive even if there's an error on the called party leg. You can then do an addParticipant to add another party or play announcements, etc.

Joel,

I have the same issue but never got a reply:
https://www.devconnectprogram.com/forums/posts/list/22494.page


I'm trying to add some error handling for a ForwardCall to an invalid VDN on CM. This way I could try an alternate destination in case of a ForwardCall error.

In my workflow, the ForwardCall returns SUCCESS, but the Call is ended.

Next, I tried to use SetCallPolicy with Drop_Call_When_No_Participant_Remains, to keep the call active and try an alternate destination. But no events seem to be triggered.

Using AllowCall after the ForwardCall returns: java.lang.IllegalStateException: cannot invoke allow in current state

Do you know a way to check for the result of the ForwardCall, and try an alternate destination?



So, would I need to use SetCallPolicy with Drop_Call_When_No_Participant_Remains and use AddParticipant instead of ForwardCall?

Would adding an invalid Participant number (a CM VDN destination), return an error this way if unsuccessful?

Hi Jack, sorry that you never got a response on that other thread, and that the response here has been slow. I've engaged some experts to discuss the best way to do what you want. I think we may want to enhance the Forward Call task with more detailed information about the outcome, but there's likely a workaround that you can use for now. I'm just trying to get the details on that. I'll hopefully be back with more info today or tomorrow.

Jack,

Sorry that you didn't get a response. Somehow it got missed in our radar. Joel brought this to my attention yesterday and here is something that you can build upon:

Depending on which version of Engagement Designer you are running on, there were some changes to Forward Call. Regardless, to achieve what you need, you take a look at the attached workflow instance screenshots. In the Instance1 image, I have shown the use case where the Forward Call will fail and in Instance2 image, I have shown the same workflow with the use case where the Forward Call will succeed. I have also attached the workflow (ForwardTest.xml) for your reference. Note that this workflow will open only in 3.5 or later releases. If you want a version of this xml for earlier releases, please let me know. Please look into those and let me know if this would help with your requirement. Thanks!

Prakash,

I am still using 3.4, so I had to re-create your example workflow, but that was no problem.

Whenever I use ForwardCall to an invalid destination, the ReceiveTask for Add ParticipantFailed is never triggered.

So this example WF does not seem to work (in 3.4?).

From another response I learned ForwardCall is an synchronous task, so will never return an error. This is supposedly fixed in 3.6.

Any ideas?

I did some more tracing in Breeze.

After the ForwardCall I receive:
SIP/2.0 404 Not Found
which triggers this error: EngagementDesigner-3.4.0.1.00049 - errorResponseReceived caught exception.

See attachment Exception.txt for more details...

Hi Jack, thanks for that additional information. I'll get somebody on the Breeze team to check into that Exception, which definitely should not have happened. What exact Breeze load are you running?

Jack, the team tells me that this issue has been resolved in the Breeze 3.6 release. If possible, please upgrade to the latest and greatest. If that is not possible and if you would like to request a patch on 3.4, please open a Siebel Service Request with Avaya Client Services. You can reference this thread and my name, asking for an immedaite escalation.

I'll warn you, however, that the product team will likely push back on a patch 2 releases back. That may end up being a lot of effort with no payoff.

I am currently running 3.4.0.1.09340120, and we are not able to upgrade at the moment.

I think the sample workflow in this thread from Prakash, would be a good solution to receive the call events. In theory at least...

I guess due to the unhandled exception, the call event for add-party-failed is never triggered.

I had a previous SR/discussion with Karthik about this, but at that time, it seemed more an issue with ForwardCall being an synchronous task. Workaround would be to make a custom (async) ForwardCall dynamic task which handles the call events.
But I am not sure this would work for 3.4, considering the new insight on the exception.

I'll contact Karthik about this and see what we can do.

OK, keep us informed. Thanks Jack.