Common Outbound Issues
More developers are starting to work with Office Communication Server 2007 these days. As the community has grown I’ve noticed a number of developers running into a few “gotchas” when working with the OCS outbound calling mechanism.
MSMQ Path Configuration
OCS makes use of MSMQ for managing the queue of outbound calls to be placed. This allows you to place many more calls into the queue than there are available ports (aka phone lines).
When pointing OCS at your MSMQ you need to provide the full path to the queue. This isn’t made very clear in the application configuration dialog. This coupled with the lack of validation within the dialog makes it difficult to determine why your calls are in the queue but OCS isn’t placing the calls.
For example:
Let’s say we created a private queue on our OCS machine named “MyOutboundQueue”. Inside our application configuration we’ll need to supply the full path of “.\private$\MyOutboundQueue”.
MSMQ Permissions
Speech applications run under IIS and as with ASP.NET are run under an Application Pool. The pool, among other things, runs as a given user. By default this is the NETWORK SERVICE user. Your queue therefore must grant read, write and delete permissions for the NETWORK SERVICE user (or whatever user you’ve configured for the Pool).
Running on Windows XP and Vista
Speech Server only supports XP and Vista for development purposes. In production it requires Windows Server 2003. As such it imposes some limitations. One of these is that you’re applications will only run when a debugger is attached.
The easiest way to attach a debugger is to run it from within Visual Studio 2005. Once the application is running in debug mode just close the “Voice Response Debugging Window” and your application will behave similarly to how it runs in production.
Another XP/Vista limitation is that it only supports two concurrent calls. This isn’t an issue most of the time but it can be difficult to understand why you have 96 ports configured, 100 calls in your queue and only 2 calls going out at a time.
Troubleshooting Other Issues
When you launch the application from within Visual Studio you can see any error messages in the debugger's output window. This is often the best way to determine what is going on as MSS is a bit terse with what it tosses into the Windows event log.