Avoiding Call Throttling on Outbound Calls

ml_ — Thu, 23 Jul 2009 14:06:36 GMT

One of the most common ways of queuing outbound calls with Speech Server is by using the built in MSMQ support. For the most part, using a message queue is extremely straightforward and easy to implement. But there is one gotcha – call throttling.

When an outbound call fails to connect, Speech Server will start throttling down the number of messages it pulls from the queue. The assumption is that failures are the result of your system having insufficient capacity to handle the load. The more failures your have, the more it will throttle the load. This would be acceptable if it were not for two issues:

Almost any failure, even acceptable ones, can result in throttling
It will happy throttle you all the way down to 0, effectively shutting down your application

Disabling call throttling needs to be done on a per-call bases by binding to the TelephonySession.OpenCompleted event prior to the MakeCall Activity. Typically I do this in a Code Activity at the very top of my workflow.

Inside my initWorkflow Activity I bind to the OpenCompleted like so:

TelephonySession.OpenCompleted += new EventHandler<Microsoft.SpeechServer.AsyncCompletedEventArgs>(TelephonySession_OpenCompleted);

Then I use the following to disable throttling on any failure:

void TelephonySession_OpenCompleted(object sender, Microsoft.SpeechServer.AsyncCompletedEventArgs e)
{
    if (e.Error != null && e.Error is SipPeerException)
    {
        SipPeerException sipEx = e.Error as SipPeerException;
        sipEx.ShouldThrottleMsmqCalls = false;
    }
}

302 Redirect and Box-2-Box Testing

ml_ — Fri, 13 Mar 2009 03:11:00 GMT

When testing Speech Server applications in our lab we often use what we call a “Box-2-Box” test. This is where we point two Speech Server instances at each other such that “Box A” makes an outbound call to “Box B” over the local LAN. This can be useful when load testing an the application beyond the number of physical ports you have available.

One of the issues we ran into immediately however is that Speech Server issues a 302 Redirect upon answering a call to move the call to another TCP port. While most SIP endpoints will seamlessly handle the redirect, ironically the Speech Server MakeCall Activity isn’t one of them. Luckily there is a simple workaround to the issue.

Prior to initiating the outbound call you need to subscribe to the Redirecting event of the TelephonySession object.

TelephonySession.Redirecting += new EventHandler<Microsoft.SpeechServer.RedirectingEventArgs>(TelephonySession_Redirecting);

Then in the TelephonySession_Redirecting event handler you tell it to accept the redirect.

void TelephonySession_Redirecting(object sender, Microsoft.SpeechServer.RedirectingEventArgs e)
{
e.Action = Microsoft.SpeechServer.RedirectAction.TryAll;
}

Search results matching tags 'Speech Server', 'Troubleshooting', and 'Core API'

Avoiding Call Throttling on Outbound Calls

302 Redirect and Box-2-Box Testing