Plum IVR Support

We have opted to turn off callee detection because of its issues, not worth getting into them so let’s just leave it at that. The idea here is that as soon as the call connects we want to fetch the VoiceXML from our server to process the call. Actually I would like it to fetch the VoiceXML before the call but my understanding is that is not an option. We saw some issues the other day that lead to an investigation of our logs compared to the Plum logs trying to figure out why we had a period of dead silence between the time we answered the phone and the time the recording started to play. We have already figured on 2 to 4 seconds due to our own callee detection attempts but we started seeing longer time period, or at least noticing them recently.

Below is one of the log entries from Plum showing this issue. Again with callee detection turned off and no attempt to reach our server in the log why would we have an 8 second duration between log entries?

Thanks for any help or advice that can be offered.

Rich

Fri 10 Jun 2011 04:14:03 PM EDT:
Call Start Event: ANII 18067896117 DNIS outbound VURL http://us.popproxy.plumgroup.com/plumvp/startpage.php
DocumentParser::FetchDocument()
DocumentParser::FetchDocument(http://us.popproxy.plumgroup.com/plumvp/startpage.php)
Cache Miss: http://us.popproxy.plumgroup.com/plumvp/startpage.php
Attempting to fetch http://us.popproxy.plumgroup.com/plumvp/startpage.php
VXI::var_element(name="sessionID" expr = "session.id")
DocumentParser::FetchDocument(startpage.php)
Cache Miss: http://us.popproxy.plumgroup.com/plumvp ... 1307736101
Attempting to fetch http://us.popproxy.plumgroup.com/plumvp ... 1307736101

Fri 10 Jun 2011 04:14:11 PM EDT:
VXI::var_element(name="callee_type" expr = "'voice'")
VXI::var_element(name="phone_number" expr = "'tel:+18067896117;ani=18163312798'")
VXI::var_element(name="call_id" expr = "'4060222'")
VXI::var_element(name="message_reference" expr = "'ce1c9e87-ab0a-4a7f-ab7f-f708ad0b5206'")
VXI::var_element(name="call_parameters" expr = "'pre-render'")
VXI::var_element(name="campaign_parameters" expr = "''")
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
Ending Session On Channel 103

Hi Rich,

Our engineering team has been made aware of this issue and are looking into why this call has returned returned silence. However, have you seen any other call instances of this issue occurring?

Regards,
Plum Support

Yes, we experienced several calls while attempting to take customer live that had up to 30 seconds of dead silence before starting the message. Of course we knew it was the system calling us so we stayed on the line until it played. As I’m sure you would also expect most people receiving a phone call will hang up within 5 to 8 seconds of dead silence.

I picked this one example out of the log because it was a clear example that no outside variables could have caused the slow processing time. Most of the other examples include a call to our server before adding another log entry with date/time on it. So although it is my contention that it is not a slow response from our server there is no way to prove that with the current log data. However this one is a prime example that shows something else is going on.

I would be more than happy to try some test calls and see if we can reproduce it but it seems to be somewhat inconsistent.

Of course the biggest issue is there is no way to track this issue. If we charge our client for 700 calls, but 100 of these resulted in non delivery of message due to the dead silence at the start resulting in the recipient hanging up then effectively we have not done a successful job of delivering the message. Because we have no way of tracking when/why the recipient hangs up that is an issue. If we can say we play an introduction within 3 seconds of a pickup then we know that any call over 5 seconds at least notify the user of who was call. At that point if they choose to hang up that is beyond our control. With random delays from answer to playing the initial message of 3 to 30 seconds this becomes an impossible task.

Thanks again and if I can help to address this issue in any way please let me know.

Rich

Hi Rich,

Thanks for your concerns.

Our engineering team has looked into this issue and the cause is due to a recent usage spike that has adversely affected database performance. To remedy the issue, we will be upgrading a cluster of servers on Sunday during our late night maintenance window. We are also working on software improvements to prevent this from happening in the future.

Regards,
Plum Support

Thanks for the update. I'm glad to hear that this is an addressable issue. We look forward to the new updates in performance.

Rich