Plum IVR Support

Hi,

I have an issue where a call was placed but the result_url specified in the initial URL was not invoked.

The call log shows:

Mon 18 Dec 2006 08:59:17 AM EST:
Call Start Event: ANII xxxxxxxxxxxxxx DNIS outbounduk VURL http://popproxy-uk.plumgroup.com/director/start.vxml
DocumentParser::FetchDocument()
DocumentParser::FetchDocument(http://popproxy-uk.plumgroup.com/director/start.vxml)
Cache Hit: http://popproxy-uk.plumgroup.com/director/start.vxml
DocumentParser::FetchDocument(director.vxml)
Cache Miss: http://popproxy-uk.plumgroup.com/director/director.vxml
Attempting to fetch http://popproxy-uk.plumgroup.com/director/director.vxml
Click here to view saved VoiceXML script
VXI::var_element(name="dnis" expr = "session.telephone.dnis")
DocumentParser::FetchDocument(http://outbound-uk.plumgroup.com/outbou ... rtpage.php)
Cache Miss: http://outbound-uk.plumgroup.com/outbou ... rtpage.php
Attempting to fetch http://outbound-uk.plumgroup.com/outbou ... rtpage.php
Click here to view saved VoiceXML script
VXI::var_element(name="session_id" expr = "session.id")
impl->dxi->waitForPlayEOD() detected a disconnect. Abandoning queued data.
Line disconnect detected. Abandoning queued audio data.
received event: connection.disconnect.hangup
Disconnect
Disconnecting On Channel 18

Mon 18 Dec 2006 09:00:19 AM EST:
VXI::exit_element()
Call End Event
Ending session
Ending Session On Channel 18

The recent calls list shows that this call took 1:02 minutes to get as far as it did.

From my own web server logs I can see a GET was issued against the result_url but no corresponding POST, where as in other situations where the reply worked both are present.

Any clues as to what is going on? If this is expected behaviour then how could I determine the result of the call?

Thanks,
Adrian

Did the result_url fail to be invoked for just that one IVR call, or has it not been working for you in general? Also, was there a start_url specified for that queued IVR call in the IVR system?

Hi,

The customer ran 4 tests. Two completed exactly as expected and two exhibited the symptoms described above. All four tests requested the same result_url. I haven't been aware of this issue when making outbound calls in the past.

The whole call to the Plum outbound system is set up using a template so the same start_url and result_url would have been used in all four tests.

Adrian

We currently do not have a means of tracking failed result_url attempts. However, we will modify our IVR outbound engine to begin logging result URL fetch errors.

Given the intermittent nature of this behavior, it's presumably either a web server problem or a network congestion issue.