Too much time for doing the call...

[ocbermudez]

Hello, I am testing the system and I saw that It take too much time for doing the call. I don't know if I am sending something wrong as information or no, but I saw the call in the plum system, but it does not do the call.

Could you explain me how it works.

Here is the info that I send to Plum:
---------------------------------------------------------------------
POST /webservice/queuecall.php HTTP/1.0
Host: outbound.plumgroup.com
User-Agent: ioncms.com Api
Content-Type: application/x-www-form-urlencoded
Content-Length: 366

login=xxxx
pin=xxxxxx
phone_number=tel:+1xxxxxxxxxx;ani=1xxxxxxxxxx
start_url=http://www.mysitecom/call_start.php
result_url=http://www.mysite.com/call_result.php
message_reference=238
call_parameters=try_confirm=0
max_retries=10
retry_interval=900
scheduled_time=0
expiration_time=
callee_earliest_time=0000
callee_latest_time=2300
-------------------------------------------------------------------------

An here is the Plum's answer :

-----------------------------------------------------------------------------
HTTP/1.1 200 OK
Date: Sun, 04 Mar 2007 13:29:55 GMT
Server: Apache/1.3.29 (Unix) PHP/4.2.3
X-Powered-By: PHP/4.2.3
Connection: close
Content-Type: text/xml

<?xml version="1.0"?>
<queuecall status="queued" call_id="493767">
<login>xxxxx</login>
<pin>xxxxxxxx</pin>
<phone_number>tel:+1xxxxxxxxxx;ani=1xxxxxxxxxx</phone_number>
<start_url>http://www.mysite.com/call_start.php</start_url>
<result_url>http://www.mysite.com/call_result.php</result_url>
<message_reference>238</message_reference>
<call_parameters>try_confirm=0</call_parameters>
<max_retries>10</max_retries>
<retry_interval>900</retry_interval>
<scheduled_timestamp>1172984400</scheduled_timestamp>
<scheduled_time>Sun, 4 Mar 2007 00:00:00 -0500</scheduled_time>
<callee_earliest_time>0000</callee_earliest_time>
<callee_latest_time>2300</callee_latest_time>
</queuecall>
-----------------------------------------------------------------------------

Thanks.
Omar.

[support]

Thanks for posting this IVR problem. It appears to be related to the way we're using callee_earliest_time and callee_latest_time in the outbound IVR system. Engineering is looking at it right now. In the meantime, our recommendation is to leave those two fields blank when queueing an IVR call. If you want control over when the IVR call goes out, use the "scheduled_time" field instead.

[ocbermudez]

Ok, yes, when I saw that, I didn't send any more the two field for my test. And all work well.
I will work for the moment with these values.

scheduled_timestamp/scheduled_time
expiration_timestamp/expiration_time


Thanks.
Omar

[support]

Correct. Using IVR applications, please note that the *_timestamp parameters take an integer representing UNIX time (the number of seconds since midnight Dec 31, 1969). The *_time parameters can take a natural language time like: "3AM EST tomorrow".

[ocbermudez]

Hello folk,

Do you have some news about that?
I tried to use the alternative parameters, but it not the same.
For example if I post one call now and the expired time will be tomorrow, PLUM could do it in any time, for example at 06:00 or 22:00
and my system always want to limit this time for example from 09:00 to 18:00.
Please let me know the state of this issue, this functionality was development in my system and it is very important use it.
Thanks.
Omar

[support]

Hi,

I'm sorry; we don't have any updates concerning your IVR issue at this time.

Regards,
Plum Support