Microsoft Speech Server Support for Outbound-Calling Applications
.jpg) |
Support for outbound call notification in Microsoft Speech Server (MSS) is built in to Telephony Application Services (TAS), and makes use of Microsoft Message Queue 3.0 (MSMQ). In this architecture, a server-side application is responsible for receiving event notifications from the data tier (for example, Microsoft SQL Server Notification Services) and placing a request onto the outbound message queue. The content of the request must be the URL of the first page of the outbound application that the service should execute. The first page of the outbound speech application should contain a MakeCall control to initiate an outbound call.
When TAS has an available idle outbound SALT interpreter, it will remove the next request from the message queue and make an HTTP request for the page defined by the URL in the message queue request. The full message flow can be seen in Figure 1 below.
Note TAS fetches the requested URL only if the URL is in the Trusted Sites list for TAS. TAS can be configured to receive messages from only a single queue. See the section on configuring MSS in the MSS documentation.
The URL should contain a query string defining information relevant to the outbound call notification dialog. In a simple application, this may contain just the telephone number of the recipient of the notification and a message to play to the recipient. Alternatively, the query string could contain a cookie or index to information in the data tier. The presentation logic should insert the relevant information into the response that will be executed by the SALT interpreter requesting the page.
.jpg)
Figure 1: Message flow for outbound notifications
In this architecture, the speech application is responsible for posting back state information about the progress of the outbound call, once the call is initiated. The Business Logic tier is then responsible for re-queuing any failed call notification requests. Failures should be determined by the speech application and these typically fall into the following categories:
- Called party does not answer.
- Called party is busy.
- Call is answered by voicemail.
- Dialog interaction with the called party did not reach a critical point, for which success is defined in the application.
- System errors that prematurely end the call or even stop the call from being made.