Outbound API changed?

[ej]

The Application Programmer's Guide for Outbound Notification ( available at: http://outbound.plumgroup.com/outbound/ ... pi_pg.html), in section 4.3 describes the parameters that are returned to the script specified as 'postCallResultUrl' when you first queue a call. Specifically, the 'result' parameter is advertised to be "success" or "failure", and when it is "success", 'calleeType' is advertised to be one of {"voice" | "answeringmachine"}, and when 'result' is "failure", 'calleeType' is advertised to be one of {"fax" | "busy" | "noanswer" | "operator"}.

Unfortunately, in practice, that's not actually what happens. Are there recent changes going on that aren't yet covered in the API Guide? If so, can you give us the skinny in some temporary document so we can develop to what the system is currently doing? What sort of values (if any) can we expect in 'calleeType'?

Some debug dumps of the parameters I am actually receiving follow to demonstrate (with actual phone numbers changed). The code to capture such things might be useful to other readers in their developments efforts and so that's here:

# capture var_dump() to buffer
ob_start(); # start buffering
var_dump($_POST); # dump to buffer
$dump = ob_get_contents(); # grab contents
ob_end_clean(); # stop buffering



var_dump($_POST) = "array(7) {
["phone"]=>
string(11) "15055551234"
["callID"]=>
string(3) "994"
["msgReference"]=>
string(1) "3"
["result"]=>
string(9) "completed"
["calleeType"]=>
string(0) ""
["nTries"]=>
string(1) "1"
["time"]=>
string(19) "2004-06-29 19:25:08"
}
"


var_dump($_POST) = "array(7) {
["phone"]=>
string(11) "15551112222"
["callID"]=>
string(3) "995"
["msgReference"]=>
string(1) "3"
["result"]=>
string(6) "failed"
["calleeType"]=>
string(0) ""
["nTries"]=>
string(1) "1"
["time"]=>
string(19) "2004-06-29 19:28:01"
}
"


Thanks in advance for any help,
-ej

[support]

Thank you for your post, this IVR issue should now be resolved.

The Plum Support team

[ej]

Well, a couple of things here...

First of all, it would be useful to me, at the time you verify that there is a discrepancy and intend to do something about it that you acknowledge it by posting something to the effect of "Yeah, we got a problem - we're working on it. Will update you as we know more." rather than waiting over a week before saying anything. That way, I know my problem has been read, someone doing something and I can expect something to change.

Secondly, I hesitate to mention this because it is not that difficult for me to change my application to deal with a "completed" string, and I have actually done so, but for the record, you might want to note that this issue is NOT resolved.

Here's another dump of a recent POST back to my PostCallResult script:

Code: Select all

var_dump($_POST) = "array(7) {
  ["phone"]=>
  string(11) "15052326908"
  ["callID"]=>
  string(2) "19"
  ["msgReference"]=>
  string(2) "31"
  ["result"]=>
  string(9) "completed"
  ["calleeType"]=>
  string(5) "voice"
  ["nTries"]=>
  string(1) "1"
  ["time"]=>
  string(19) "2004-07-08 16:44:47"
}
"

So, I am now getting a value for the 'calleeType' parameter, which is a useful improvement. Sorry if this seems nit-picky, but as I said in my original post, 'result' is advertised to be either "success" or "failure". Obviously, "completed" is neither of those, so your application still does not conform to your published spec. So I am left wondering, Well, might it be "success" sometimes? If so, what's the semantic difference between "completed" and "success"? Do you guys just need to update your documentation, or is there something going on that's causing it to print "completed" when you really do expect it to be "failure" or "succeess"?

I'm wondering why other people are not bringing this up - are they not actually looking for the results of their outbound calls, or are they not seeing this behavior?

Thanks,
-ej

[support]

ej:

Sorry for the latency in our reply. Currently things are in somewhat of a weird state because the outbound IVR system is undergoing a variety of changes and fixes with respect to the invocation interface and the logging functionality. Hopefully these changes will be made available, and the IVR outbound documentation will be synched up with the actual API definition by Wednesday, July 21st.

Keep in mind that the IVR outbound interface is still in testing and not a production system yet. This should have been relayed to you from the start, and I apologize if you were not informed of this initially.

We are hoping to have the production IVR system in place in the coming weeks; a news item will be placed on the index page when this is ready.

Sincerely,

Plum Support

[support]

**OUTBOUND SYSTEM STATUS UPDATE**

The IVR Outbound system has been revised and improved to fix several problems mentioned in the forums over the last few weeks upon the beta release of our IVR outbound platform. Its accessible from your hosted IVR account by logging in at http://hosting.plumgroup.com and visiting the outbound tools section located in the navigation menu on the left.

Also, be sure to view the newest documention in the IVR Outbound Dev guide, located at:

http://www.plumvoice.com/docs/dev/plumd ... nddevguide

kindly,

Plum Support Team