Application Error Handling

This section discusses what can go wrong with an application and what you can do to ensure that you let the customer down gracefully, rather than letting them crash and burn!

VoiceXML GW dies

I know it shouldn’t happen, but sometimes it does. Particularly in real life! What should happen here, is that the MSC notices that the lines to a given GW are dead and tries a different GW. In the ultimate worst case that you don’t have a redundant system or that all lines are blocked for some reason, then the MSC will play an error prompt saying that the number in question is unavailable at the moment.

Web server is down

Next up is the web server - or even the connection to it. Whichever it is, your GW makes a request for a page to the web server and nothing comes back - your request basically hangs there in mid-air until it times out. This results in a bad fetch. Your gateway should have a stock prompt for this kind of error. However, there is a more graceful way to deal with this. Basically put a small start page on your GW. This page tries to fetch the main page. If the page isn’t there then the resulting badfetch is caught. Now a prompt which has been recorded specifically for your application can be played. If appropriate you can also connect the caller to your call centre.

<vxml version = "2.0">
  <form id="GetApplication">
    <block name="GetApplication">
    <!-- Get the Application -->
      <submit 
        next="http://123.45.678.9:8080/vxml/start.vxml" 
        namelist="session.telephone.ani session.telephone.dnis" 
        fetchtimeout="5s"/>
    </block>
    <catch event="error.script error.application 
      error.pagetimeout error.badfetch">
      <log>ERROR! Bad fetch</log>
      <goto next="#TransferToOperator"/>
    </catch>
  </form>
  <form id="TransferToOperator">
    <transfer name="Transfer" destexpr="'phone://1234567890'" bridge="false">
    </transfer>		
    <catch event="error.telephone">
      <log>ERROR! Operator Transfer: <value expr="Transfer"/> </log>
      <prompt>
        <audio xsrc="file:///disaster.wav"> 
          I'm sorry, but this service is temporarily unavailable.  
          Please call back again later! 
        </audio>
      </prompt>
      <exit/>
    </catch>
  </form>
</vxml>

Actually this page handles two errors - the fetch failing and the transfer to the operator not working. Better safe than sorry ;-)

Back-End failure

In a back-end failure, the web server accepts the request and starts processing it. So both VoiceXML GW and web server have connected and the VoiceXML is waiting for the next page to be delivered. However, because some database is unavailable or something else has gone pear-shaped, there isn’t going to be a reply - at least not within the timeout that most VoiceXML applications use. So you get a badfetch in your VoiceXML page. Now how you deal with this depends on your application and how important the failed request was. If a badfetch is considered fatal, then you can write a generic catch for all badfetches in the rootdocument and deal with them that way:

<catch event="error error.internal error.script error.application 
  error.pagetimeout error.badfetch error.semantic error.noauthorization 
  error.unsupported.element error.unsupported.object">
    <prompt bargein="false">
      <audio src = "error_internal.wav"> 
        We're sorry, but the service is temporarily our of order. 
        Please call again later.  Goodbye!
      </audio>
    </prompt>
  <throw event="telephone.disconnect.hangup"/>
</catch>

This page actually handles more than just a badfetch. It also handles problems that may occur in the actual VoiceXML of the application, such as bad syntax, illegal objects, javascript errors, etc. Most of these errors are fatal for an application - so you will probably want to stop the application. Putting this catch into the rootdocument saves you the bother of trying to catch the error in every page that makes a request. It goes without saying, that javascript, object and semantic errors should have been rooted out in the test phase - -however, there’s no harm covering all the bases.

Error Monitoring & Notification

It’s all very well handling the various error types in a graceful manner, but you should also know that you have a problem. The most preferable way of doing this is to be notified by the GW that the application has a problem. Most GWs can send an email to an administrator if an application has an error - although this can get a little out of hand if you lose a server for anything more than a few minutes! If you have no means of being notified when something has gone wrong, then you’ll have to scan the logs on a regular basis and check for any major errors. Often it will turn out that the cause of the error is beyond your control - but you should at least know why the errors occur and who’s to blame ;-)

If you have any comments, ideas, issues, etc. about this topic why not try the voice-push forums