UCCX place call step information

[j.recio]

Hi,

we need info about uccx place call step, about when unsuccessful branch is matched, specifically with 487 sip message, because we have detected an unwanted behaviour (when the place call step receives a 487, the step is unable to process it, the script/step doesnt process the next call and the script finish abruptly. For other message errors (for example sip 480) it matches unsuccessful branch correctly, and then script continues with nex call correctly.

Thank you very much.

[david.macias]

Who is sending the cancel?

david

[j.recio]

Telco SBC sends the 487 to our cucm.

Thank you.

[david.macias]

On which call leg? The inbound or outbound side?

david

[j.recio]

It´s an outgoing call from a uccx place call step, the call is answered by a customer system, it plays a prompt (in the customer side), and drop the call in the customer side after playing the prompt. The 487 error comes from the telco net, after dropping the call, to our uccx.

Thank you very much.

[Roger Kallberg]

The full response code for SIP-487 is “487 Request Terminated.” This indicates that the request has been terminated by the recipient and that the call cannot continue.

[j.recio]

Yes, that´s right. This is the right behavior for a call and 487 response.

But the problem is about the place call step in uccx.

When this step receives, for example a 480 or 486 response, the place call step puts the call in the busy, unsuccess, or rna branch (it depends on the received message), and the call is dropped and the script continues with next call (we have confgured a data base with a list of numbers to call). It works correctly.

But when the script/place call step receives a 487 message it drops the call and the script finish abruptly (it doesnt match any branch in the place call step and it doesnt go for the next call, the script ends). Why this behaviuor with this 487 message?

Thank you very much.

[david.macias]

I think you're misunderstanding how that step works. The call was completed thus the step stops. Had the call not answered or had an error then it would continue processing. The step can't do a conference and then continue moving on to more steps. Just doesn't do that.

david

[j.recio]

Not quite. I have configured the step so that after 40 seconds it drops the call and continues with the next step (the script makes a total of 200 calls).
 The call in question is processed like the others but receives an error/disconnection code that the step does not understand and causes the script to stop and not make the next call.
Thank you very much.

[Elliot Dierksen]

I haven't had to do much with CCX placing calls, but it sounds like whatever is happening is generation an exception. It sounds like you will need to set an 'on exception' check to trap this error and continue processing. You will probably want to clear the 'on exception' after you get out of that section of the code.

[david.macias]

@Elliot Dierksen but in this case it's not an exception the step is terminating correctly. What I understand from OP previous post he wants the step to continue down one of the branches but the telco has told it the call is done and thus there is nothing to branch on. Unless the logs show an exception, there's nothing he can do.

david

[j.recio]

But that's part of the problem too. I am not absolutely sure whether the step is completed successfully or not. What we are completely sure of is that the script ends and the next call is not launched. What type of trace in the uccx should I check to check at what step/point the script has ended?
Thank you very much.

[j.recio]

That could be an option. Forgive me for my ignorance, but how can I configure an on exception check in this step?

Thank you very much.

[j.recio]

Are you referring to introducing an exception like in the image I attached?

Thank you very much.

[Roger Kallberg]

Are you absolutely sure that the script ends abruptly, doesn’t the step go to call successful before the 487 is received? If the call is determined to be successful then the call step is doing exactly what is expected just as @david.macias has answered you. However if the script does end abruptly then you should be able to follow @Elliot Dierksen advice to handle the exception.