Chapter 9. Developing SIP applications 221®. If a request is received where both of these conditions are true, then
the CallController servlet will be invoked, subject to the ordering rules
described in “Application composition” on page 221.
Example 9-9 Mapping Example
Application composition
Application composition depends on the order of deployed applications and on
the order of mapping rules within the deployment descriptor of each application.
To ensure consistent behavior, the order in which servlets are invoked is
determined as follows:
For an initial incoming request, the SIP container tries each potential rule in
the deployed application order, then in the order the rules are listed in an
application’s deployment descriptor. Upon finding the nth match, the container
then invokes the corresponding servlet.
If the servlet needs to proxy the request, the container re-scans the rules
searching for additional matches. Upon finding the (n+1)th match, the
container invokes the corresponding servlet.
Matching the request excludes any servlet in the same application as the
previously invoked servlet. No servlet will be invoked twice for the same SIP
9.3.8 Sessions
SIP Servlets are stateless and contain no per SIP dialog or per SIP transaction
data. In order to allow a SIP Servlet to process multiple messages that are
222 Developing SIP and IP Multimedia Subsystem (IMS) Applications
related, SIP Servlet provides the SipSession interface which represents a
point-to-point relationship between two user agents.
The SipApplicationSession links multiple of these point-to-point relationships to
allow them to be managed as a single application. For example, a SIP Servlet
may provide a service such as a third party call control application which involves
multiple user agents and an HTTP user interface. In this case, it is important to
have the ability to link these individual point-to-point relationships together to
comprise an application.
A SipSession represents a SIP dialog to a SIP Servlet. There are some
differences between the life cycle of a SIP dialog and a SipSession. Principally,
the differences are:
All messages within the SIP Servlet API belong to a SipSession, while some
SIP requests (such as OPTIONS and REGISTER) may exist outside a dialog
A SipSession is created immediately and does not require a 1xx or 2xx
response to be received in order to establish the SipSession
When a SIP dialog is terminated, the corresponding SipSession is not
destroyed, it must be explicitly invalidated or timed out
Adding attributes
An application may store information in the SipSession or the
SipApplicationSession using the setAttribute(String name, Object
attribute) method on either of these objects.
Removing attributes
Information store in the SipSession or SipApplicationSession can be retrieved
using the getAttribute(String name) method. If changes are made to the
retrieved information, then setAttribute method must be invoked after the
Iterating over the Sessions
To iterate over the Sessions contained by the SipApplicationSession, two
methods are available:
This method returns an Iterator over all sessions contained in
getSessions(String protocol)

Get Developing SIP and IP Multimedia Subsystem (IMS) Applications now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.