We've Moved! Please visit our new and improved forum over at our new portal: https://portal.plumvoice.com/hc/en-us/community/topics

Head's up: outbound problems

Questions and answers about IVR programming for Plum DEV

Moderators: admin, support

Post Reply
ej
Posts: 12
Joined: Fri Jun 18, 2004 7:54 pm

Head's up: outbound problems

Post by ej »

I now realize that the outbound platform has not been officially released and is still undergoing development. Understandable - I'm trying to development outbound app at the same time. I'm not sure what to expect of the system at this moment, and you may already be aware of this, but here is some feedback anyway:

Currently, no outbound calls which are queued and actually placed are appearing in the session logs. When my script generates an error there is nothing in the error logs. Calls that I actually received do not increment the "Total Completed Calls" counter on the "Outbound Tools" page. I haven't looked at the logs before, so maybe it has always been that way to date - not sure.

My real concern is that I now do not appear to be getting any call result posted back (either for VXML that seems to be OK, or for VXML that is generating an error) where previously I was. Are you aware of that recently getting broken :?:

-ej

ej
Posts: 12
Joined: Fri Jun 18, 2004 7:54 pm

Post by ej »

I didn't quite finish that thought... Assuming the POST of the call result is fixed, will I get a call result for both cases: both valid and invalid VXML at StartVXMLURL? Is there any indication of error passed through to PostCallResultURL or is the error only in the error log? The current spec (Outbound Programmers Guide) doesn't indicate anything about problems at StartVXMLURL being reported at PostCallResultURL.

If nothing is passed through to PostCallResultURL, shouldn't there be? That would be useful to customers - that way I can capture in my own DB the fact that my own script is not generating valid VXML, and I can have my own alerts to monitor the status I am getting back on the result of that call. Without that, I am left manually searching your error logs after the fact. For an alarm notification, I need to know ASAP that I've got a problem trying to make this notification. That's a pro-active approach and much more valuable than a post-mortem of "Why did we miss a critical alarm?"

-ej

Post Reply