Creating an Application Manifest

Microsoft Office Live Communications Server 2005 with SP1

Creating an Application Manifest

What Is an Application Manifest?

The application manifest is the document with which you communicate the nature of your SIP application to the Live Communications Server. It also contains the logic that dispatches specific SIP messages to your application, and potentially filters others. There is no relationship between the application manifest and an assembly manifest in a managed application.

The first step in creating a Live Communications Server application is to create an application manifest. At this point, you should consider the functionality of your potential application and decide whether the script-based message filter support that is present in the application manifest will suffice. Some questions to consider when making this decision include:

• Will my application simply proxy SIP messages of a certain type? If so, the Microsoft SIP Processing Language (MSPL) support present in the message filter portion of the application manifest will easily suffice.
• Will my application handle potentially complex branching proxy scenarios, or support multiple points-of-presence (MPOP)? If so, a message filter script may suffice, but may not be as extensible as you need. In this case, you should consider the scalability and growth needs of the application, and if you expect future complexity, a managed application would be more appropriate.
• Will my application work directly with SIP transaction objects, and support multiple work threads? Your application cannot be script only, and you will need to create a managed application along with the message filter and dispatch script in the application manifest.

To determine what functionality can and cannot be incorporated in the message filter, see Microsoft SIP Processing Language.

Creating the Application Manifest

Once you determine the subdivision of labor between the message filter and the application, you create the actual application manifest document. This document describes the basic rules for message delivery to your script (and application), as well as contains the logic for the message filter script itself.

An application manifest document is written in XML format, with the MSPL message filter script encapsulated in a CDATA block. Each element of the manifest is prefixed by the namespace alias, as defined by the xmlns attribute of the applicationManifest tag. In the example application manifest below, the namespace alias is set to "lc" and separated from the element name by a colon.

<?xml version="1.0" ?>
<lc:applicationManifest
   appUri="http://www.my_domain_here.com/myApplicationLocation"
   xmlns:lc="https://schemas.microsoft.com/lc/2003/05">
<lc:requestFilter methodNames="INVITE,MESSAGE" 
                        strictRoute="false" 
                        registrarGenerated="true"
                        domainSupported="true"/ >
<lc:responseFilter reasonCodes="NONE" />
<lc:proxyByDefault action="true" />
<lc:scriptOnly />
<lc:splScript><![CDATA[
	// ...
	// my MSPL message filter script here
	// ...
   ]]></lc:splScript>
</lc:applicationManifest>

The first element, applicationManifest, establishes the URI used to uniquely identify the application to Live Communications Server in the appUri attribute. Two applications with the same URI cannot coexist on the same running Live Communications Server instance. The second attribute, xmlns, specifies the alias used to identify XML elements in the manifest specific to this application.

The requestFilter and responseFilter tags set the basic filters for SIP request and response messages, respectively. This allows you to control what messages are seen by the application at the top level. In the preceding example, only requests with a SIP method type of "INVITE" or "MESSAGE" are passed to the application, and no responses are dispatched. Responses are filtered on status class, such as "1XX" or "2XX".

The scriptOnly tag indicates that the application has no managed code component; the message handling is performed solely within the MSPL script. If you have a managed code application component, this tag must not be present.

The script itself is defined in the CDATA block enclosed by the splScript tags, and written in MSPL.

The full set of possible application manifest tags are described in detail in Application Attributes.

When you have finished creating the document, save it as a text file, or embed it as a string in your managed code application. If it is script-only, you must save it as a text file.

For more detailed information on creating an application manifest and the associated message filter/dispatch script, see Application Manifests.

What did you think of this topic?

© 2008 Microsoft Corporation. All rights reserved.