Welcome to GotSpeech.NET Sign in | Join | Help
Handling SIP Errors on Outbound Calls

 

imageWhen placing outbound calls there are a number of scenarios that you will want to apply business logic too. When your application reaches a BUSY number for example, you will need to make an appropriate decision as to how to process this result (should you redial, wait some amount of time and then redial, stop calling, etc).

In order to handle these events you will first need to catch them using the Fault Handler page. From here you define the workflows for processing each fault type.

The default project template for speech workflows includes two fault handlers. The first handles call disconnections (normally this happens when a caller hangs up) and a general fault handler for catching everything else.

We’re going to add another one for trapping SIP results. This will fire off a code block where we will make decisions on how to handle the results we care about. 

  1. From the toolbox, drag a new FaultHandler object into the fault handler’s list.
  2. On the Properties tab for the FaultHandler, open the details dialog for the FaultType property.
  3. In the Type Name text box enter “Microsoft.SpeechServer.SipPeerException” and click ok.
  4. Drop a Code activity into the workflow area of the new FaultHandler instance
  5. Double-click the new Code activity to open the code view for the ExectuteCode event.

Now you can process the SipPeerException based on the ResponseCode you’ve received. For example:

if (sipPeerFaultHandler.Fault is Microsoft.SpeechServer.SipPeerException)
 {
     Microsoft.SpeechServer.SipPeerException ex = (Microsoft.SpeechServer.SipPeerException)sipPeerFaultHandler.Fault;
     switch (sipException.ResponseCode)
     {
         case 486: // Decline with Busy Here
         case 600: // Decline with Busy everywhere
             /*
              * 
              *  Handle your busy case here
              * 
              */
             break;
 
         case 480: // Temporarily unavailable
         case 503: // Service Unavailable
         case 603: // Decline
         case 408: // Request Timeout
         case 504: // Gateway Timeout
         case 404: // Not Found
         case 484: // Address Incomplete                 
         case 604: // Does Not Exist Anywhere
         case 485: // Ambiguous
         case 410: // Gone
         default:
             break;
     }
 }
Posted: Friday, May 15, 2009 1:31 PM by ml_

Comments

marshallharrison said:

Great post!

# May 15, 2009 11:10 PM

cmccarrick said:

Good post.  One point to make is that we have found that different SIP providers do not always send back the same response code for the same telephony event.  I have had to find out exactly the responses that get returned and then map to them depending on the provider.  So much for a standard....

# May 18, 2009 3:18 PM

ml_ said:

I've seen that as well. Although for the most part we've not seen them using conflicting codes. Using 486 or 600 for BUSY is one of the common examples we see.

# May 18, 2009 3:46 PM
Anonymous comments are disabled