Plum IVR Support

Thanks for your prompt reply and also for that detailed information.

Dorsey

Hello, We have a situation where some of our members are making calls outside the U.S., and we'd like to selectively block calls to the countries they're calling, while allowing others. We suspect that the callee is traveling with a U.S. phone, as we only allow U.S. format numbers at this time, and ...

Fantastic! Based on your suggestion, I've also modified the expression that returns the total call length (document.timelen) so that we now uniformly return seconds as the unit for returned values.

Thank you very much for your VXML assistance and for your quick response on this,
Dorsey

I have some code snippets early in this post, but that might have been misleading. Here's the entire script: <?xml version="1.0"?> <!DOCTYPE vxml SYSTEM "http://vxml.plumgroup.com/vxml.dtd"> <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"> <!-- allow barge-in from dtmf --> <property name="ba...

We found a way to duplicate this problem. When we set a call duration greater than 1200 seconds and the call itself lasts longer than 60 seconds, the xferduration variable returns a very large number. If the call lasts less than 60 seconds, a reasonable number is returned. When the call duration is ...

That's what I suspected; thanks for confirming it.

Is the link in the previous reply valid? When I try to open it with Firefox, I'm asked to download a new ActiveX object, which I won't do unless there is a compelling reason. The larger issue is that rather than posting a link that purports to explain something, please include a synopsis of what the...

Thanks for taking a look at this. We've been trying to reliably duplicate the problem, but have not been able to yet. We appreciate having a second opinion that the code looks fine. We'll try various input combinations to see if we can reliably produce these odd results. Because the xferduration var...

Our script sometimes returns an unexpected number for the following calculated value (xferduration) : <var name="timestart" expr="new Date()" /> <var name="timeend" expr="new Date()" /> <assign name="document.timeend" expr="new Date()" /> <assign name="document.timelen" expr="document.timeend.getTim...

Removing the extra two characters solved the problem, but I thought that the HTTP specification required those as a separator. Also, we had not changed that code while moving from testing to production, so it will remain a mystery. You really went beyond the call of duty in actually running our code...

I'll give that a try, but I wanted to answer your other question first. We have two HTTP libraries, one that uses curl and another that doesn't. Depending on how PHP is built (options), the curl library will sometimes only work when executed in the context of browser response and aborts when run in ...

I've included some code snippets that demonstrate the problem. The first is the PHP code that initiates the POST: $retVal['login'] = PLUM_LOGIN; $retVal['pin'] = PLUM_PIN; $retVal['phone_number'] = '1'.$from; // phone number to be dialed -- be sure to include the 1 before the area code $retVal['star...

We've just moved to a production system, and it works very well other than the following inconsistency between development and production. After POSTing to http://outbound.plumgroup.com/webservice/queuecall.php, we don't read any response from your server. The script is executing correctly, however,...

As it turns out, we were both correct. Our script used the submit tag to deliver call results, but we also specified a return_url when starting the call. So, once we removed the return_url parameter, we get one and only one result set. I apologize for taking up your time on what turned out to be a m...

It has to be coming from your end. When I "open" the script directly from a browser, I only get one log message as shown below. We log the following set of messages 132 times when we try to execute our script (some variables differ, of course): <30-May-2007 12:37:41> [/svc_callresult.php] Called <30...