Writing a Message Filter Script

Always ensure that you are handling a request when you call a function like Fork by enclosing it in an if (!sipResponse) { ... } section. For response-specific functions like ProxyResponse, an if (!sipRequest) { ... } section is likewise appropriate. Remember, every time a function attempts to process a message type it cannot handle, a critical MSPL error is raised against your application, and recorded in the server event log. If 10 of these errors occur, your application is disabled by Microsoft Lync Server 2010. Divide your filter into discrete sections for handling each class of message—response and request—and implement their processing separately.

Log is the only effective mechanism you have to debug your code logic. While the ApplicationManifest.Compile method will catch syntactical errors, code logic errors must be debugged using SPLLogger.exe (which ships with Lync Server 2010). Call Log anytime a message with a specific SIP method is identified, or when any meaningful action is taken when processing a message.

When forking a message, BeginFork, Fork, and EndFork must be called in the implied order. Calling one out of order generates an error. Fork can be called as many times for as many messages as appropriate as long as BeginFork has not been closed with a subsequent call to EndFork. When EndFork is called, all of the messages previously specified with calls to Fork after the initial BeginFork are forked. If you do not call EndFork, the forked messages are not sent, and an error is generated.

If your application is declared as script-only using the scriptOnly Element, compilation will fail if you attempt to call the Dispatch function.