Deploying a SIP Module

You deploy a SIP module as described in Tools for Deployment. A SIP module that includes web module features is converged and can be assembled in either a WAR or SAR file. For a converged web/SIP module, you can use all the features described in Deploying a WAR Module except session persistence. To deploy a SIP module in an application (EAR file), assemble it as a converged web/SIP module in a WAR file.

You can optionally use a sun-sip.xml file, or both a sun-web.xml and a sun-sip.xml file for a converged application, to specify extra deployment settings. If you use both, the sun-web.xml file configures the web container and the sun-sip.xml file configures the SIP container.

If a SIP module accesses a DataSource that is not specified in a resource-ref in sun-sip.xml, or there is no sun-sip.xml file, the resource-ref-name defined in sip.xml is used. A warning message is logged recording the JNDI name used to look up the resource.

SIP sessions in SIP modules can be saved in a persistent store in case a server instance fails. For more information, see Distributed Sessions and Persistence in Sun GlassFish Communications Server 2.0 Developer’s Guide and the Sun GlassFish Communications Server 2.0 High Availability Administration Guide.

After a SIP module is undeployed, its session information is not immediately removed if sessions are persistent. Session information is removed in the subsequent cycle, when timed out sessions are removed. Therefore, you should disable a SIP module before undeploying it if sessions are persistent.

See the Sun GlassFish Communications Server 2.0 High Availability Administration Guide for information about load balancing.