Upload recording issues

[Frank]

Hi, Plum support



I have codes below http://stage.ivr.mobilemessenger.com.au/vxml/e.vxml
<http://stage.ivr.mobilemessenger.com.au/vxml/e.vxml>


<?xml version="1.0"?>

<vxml version="2.0">



<property name="inputmodes" value="dtmf"/>

<form id="waitMessage">

<block>

<prompt timeout="6s">

<audio
expr="'http://stage.ivr.mobilemessenger.com.au ... us/US7.mp3'">
Please wait while we process your request.</audio>

</prompt>

<goto next="#process"/>

</block>

</form>



<form id="process">

<block>

<submit
expr="'http://stage.ivr.mobilemessenger.com.au/index_e.php'"
method="post"

fetchaudio="http://stage.ivr.mobilemessenger.com.au ... s_us/unsub
scribing.mp3" fetchtimeout="10s" maxage="0"/>

</block>

<error>

<goto next="#fetcherror"/>

</error>

</form>



<form id="fetcherror">

<block>

<goto
next="http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml"
fetchtimeout="120s" maxage="0"/>

</block>

</form>



</vxml>



It is all working fine if I paste these codes to scratchpad.

But it will be problem if I save it to a file and plum server accesses it by remote URL http://stage.ivr.mobilemessenger.com.au/vxml/e.vxml
<http://stage.ivr.mobilemessenger.com.au/vxml/e.vxml>



See error logs below



Mon 14 Jul 2008 02:48:11 AM EDT:

Error fetching document
http://stage.ivr.mobilemessenger.com.au/index_e.php due to Operation timed out with 0 out of -1 bytes received

DocumentParser::FetchBuffer - could not open URL:
http://stage.ivr.mobilemessenger.com.au/index_e.php

DocumentParser::FetchDocument - exiting with error result 2

errno: 203 uri http://stage.ivr.mobilemessenger.com.au/index_e.php

received event: error.badfetch:

DocumentParser::FetchDocument(http://stage.ivr.mobilemessenger.com.au/vx
ml/end.vxml)

Cache Miss: http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml

Attempting to fetch
http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml So far, all is OK



Mon 14 Jul 2008 02:50:12 AM EDT:

Error fetching document
http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml due to Operation timed out with 0 out of -1 bytes received (Problem, should be no time out error)

DocumentParser::FetchBuffer - could not open URL:
http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml

DocumentParser::FetchDocument - exiting with error result 2

errno: 203 uri http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml

received event: error.badfetch:

Can not queue audio -- line disconnected

received event: connection.disconnect.hangup:

VXI::exit_element()

Call End Event

Ending session

Ending Session On Channel 37



http://stage.ivr.mobilemessenger.com.au/index_e.php
<http://stage.ivr.mobilemessenger.com.au/index_e.php> file usually will take long time to process (sometime more then 180s, and will raise an
error)

I try to catch this error and forward the request to http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml
<http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml> (very fast
page)



It is working in scratchpad.



But when plum server accesses it by remote URL http://stage.ivr.mobilemessenger.com.au/vxml/e.vxml
<http://stage.ivr.mobilemessenger.com.au/vxml/e.vxml>

Once fetching http://stage.ivr.mobilemessenger.com.au/index_e.php raises a timeout error, plum server still raise a timeout error while forwarding the request to http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml
<http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml> (but it is very fast, no timeout)



For testing, the codes of
http://stage.ivr.mobilemessenger.com.au/index_e.php is very simple. Just like below.



<?php

sleep(300);

?>



When I hang up the phone, I can see the process is still running until index_e.php is finished by backend interface http://hosting.plumgroup.com/call_logs_current.php.

It looks like that the connection to index_e.php is still not closed once the time out error raised.





Regards,

[support]

Hi,

This is not a bug within the IVR platform, but rather, a case of where your IVR application server is timing out, as described in these earlier posts:

http://support.plumvoice.com/viewtopic.php?t=571
http://support.plumvoice.com/viewtopic.php?t=850

Try some of the suggestions from these previous posts and if this IVR issue is still occurring, I would suggest looking over your php scripts for any problems.

Regards,
Plum Support

[Frank]

Yes, I know it is timeout

but the problem is that I can catch the first page timeout exception, then I submit the request to other page(very simple page,

never timeout) in the catch block, I still get timeout error on the second page.

Please see my first post again. My question is very clear.

The logic is as below

1. entrance page http://stage.ivr.mobilemessenger.com.au/vxml/e.vxml

Page 1 is entrance page, and never problem

2. submit to page http://stage.ivr.mobilemessenger.com.au/index_e.php

Submit the request to page 2, and page 2 will be timeout as expected, than catch the error go to page 3

3. deal error page http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml

Page 3 is very simple page, never timeout. But plum system still raise timeout error


If I copy the codes of page 1 to scratchpad, than page 2 is timeout and page 3 is no problem

I am very sure that is plum server problem

[support]

Hi Frank,

We are currently looking in this IVR issue and we'll let you know once we have fully diagnosed it.

Regards,
Plum Support

[support]

Hi Frank,

After further testing, it appears we've isolated a strange behavior that occurs when our IVR platform interacts with your IVR application server: the IVR platform chains an HTTP/1.1 request on the same socket that's in a timeout state so end.vxml is requested on the same socket that's still waiting for a response from your php script. While chaining requests on an existing TCP socket is standard behavior for HTTP/1.1, strictly speaking a new socket should be created if an existing socket is still waiting for response. That said, what's particularly strange is we can't replicate this behavior between our IVR platform and other web servers. It only happens between our platform and your app server.

We're currently looking into a way to patch our IVR platform to specifically address this IVR issue with your app server but until then, there are a couple workarounds that we'd suggest. First, set up another subdomain like stage2.mobilemessenger.com.au that will refer to your current virtual server. Then make all references to the PHP script that times out use this new subdomain. This will effectively prevent the IVR platform from attempting to reuse an already open HTTP/1.1 socket. Second, you can reduce the PHP max execution time variable to a value that's less than the current fetch timeout. This will ensure an error is kicked back to the platform so it can do proper clean-up of the socket that's currently held open waiting for a response before it's reused.

Regards,
Plum Support

[Frank]

Hi,

I have found what the problem is in your server.
Your server use the same socket for same domain, that is the problem.

It is difficult for us to set up a subdomain, becase the domain has been hard coded to the static vxml script.

Also our server can not reduce the timeout time, because some code need long time to finish.

Could you please increase your server's maximum timeout time for our company untill this bug fixed? 6 mins is best.

Please see my test code below (one trick)

<form id="process">
<block>
<submit expr="'http://stage.ivr.mobilemessenger.com.au/index_e.php'" method="post" fetchaudio="http://stage.ivr.mobilemessenger.com.au ... ribing.mp3" fetchtimeout="10s" maxage="0"/>
</block>
<catch event="error.badfetch">
<goto next="#fetcherror"/>
</catch>
</form>

<form id="fetcherror">
<block>
<goto next="http://www.mobilemessenger.com.au/vxml/noexist.vxml"/>
</block>
<catch event="error.badfetch">
<goto next="http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml" fetchtimeout="120s" maxage="0"/>
</catch>
</form>


error logs

Thu 17 Jul 2008 08:01:24 PM EDT:
Error fetching document http://stage.ivr.mobilemessenger.com.au/index_e.php due to Operation timed out with 0 out of -1 bytes received
DocumentParser::FetchBuffer - could not open URL: http://stage.ivr.mobilemessenger.com.au/index_e.php
DocumentParser::FetchDocument - exiting with error result 2
errno: 203 uri http://stage.ivr.mobilemessenger.com.au/index_e.php
received event: error.badfetch:
DocumentParser::FetchDocument(http://www.mobilemessenger.com.au/vxml/noexist.vxml)
Cache Miss: http://www.mobilemessenger.com.au/vxml/noexist.vxml
Attempting to fetch http://www.mobilemessenger.com.au/vxml/noexist.vxml

Thu 17 Jul 2008 08:01:25 PM EDT:
HTTP/1.1 404 Not Found - http://www.mobilemessenger.com.au/vxml/noexist.vxml
DocumentParser::FetchBuffer - could not open URL: http://www.mobilemessenger.com.au/vxml/noexist.vxml
DocumentParser::FetchDocument - exiting with error result 2
errno: 203 uri http://www.mobilemessenger.com.au/vxml/noexist.vxml
received event: error.badfetch.http.404:
DocumentParser::FetchDocument(http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml)
Cache Miss: http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml
Attempting to fetch http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml

Thu 17 Jul 2008 08:03:26 PM EDT:
Error fetching document http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml due to Operation timed out with 0 out of -1 bytes received
DocumentParser::FetchBuffer - could not open URL: http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml
DocumentParser::FetchDocument - exiting with error result 2
errno: 203 uri http://stage.ivr.mobilemessenger.com.au/vxml/end.vxml
received event: error.badfetch:
impl->dxi->waitForPlayEOD() detected a disconnect. Abandoning queued data.
Line disconnect detected. Abandoning queued audio data.
received event: connection.disconnect.hangup:
VXI::exit_element()
Call End Event
Ending session

[support]

I'm sorry but we can not increase the system-wide maximum timeout as it is a shared environment and would impact all of our other IVR customers.

However, we do have a permanent fix for this IVR issue in testing and will have it deployed during our next maintenance window at 4AM EDT July 20th. The problem should be resolved at that point.

[Frank]

Ok, tested and good