Signal call failure from script

[rstevehole]

Is there any way that I can tell the engine from an executing script that the call is to be deemed a failure, thereby engaging the redial support? I want to be able to leave a voice message, signal that the voice message was a failure, and have the call engine try to call again after the delay period. Thus, connection to a voice message system is deemed not to be a successful connection attempt.

[support]

Hi,

We're assuming you're talking about placing an outbound call, as you're looking to handle the case when you encounter an answering machine. Please feel free to clarify if we did not understand correctly.

When a queued outbound call is connected with the destination phone number, if it is either picked up by a person or an answering machine, the status of the outbound call is set to successful and the redial option set when you queued the call no longer applies. At this point in the call there is no way in your script to signal a failure to the outbound system.

What you can do, however, is to act on the 'callee_type' which is POST'd to both your start_url and result_url when you queue the outbound call. The callee_type is either 'voice' or 'answeringmachine', indicating which type of user has picked up the line. In your start_url script, you can handle this case where the callee_type is answering machine and choose to leave a voice mail message. Additionally, in your result_url script, you can process the callee_type to do post-processing to determine if you need to redo the call later, as you have specified.

Additional information about the start_url and result_url paramters, as well as callee_type can be found at: http://www.plumvoice.com/docs/dev/plumd ... nddevguide

Please feel free to let us know if you have any questions.

Best Regards,
Plum Support

[rstevehole]

I was assuming the answering machine scenario. Pity though. I was hoping that there was an error condition that I could signal from within the script that would tell the server to set it's retry state.

I am collecting and using the call status information on the result_url callback now for tracking, so your suggestion to act on that field is a good idea. And for mass calling apps this would work great. Unfortunately I have found the answering machine detection to be very inaccurate for our application's purposes. We are almost exclusively calling mobile phone numbers and the answering machine detection does not work for mobile voice mail -- less than 10% hit rate from our calculations.

So it looks like I'm going to have to deal with it explicitly in the application logic (script + application server). I have implemented voice mail detection within my scripts already, so it won't be that big a deal to signal the condition. The tricky part is handling the special case of initiating a "retry call" vs the "initial call" that I was doing. Not hard ... just more work that I'd rather not have done right now.