The Programs (which include both the software and documentation) contain proprietary information; they
are provided under a license agreement containing restrictions on use and disclosure and are also protected
by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly,
or decompilation of the Programs, except to the extent required to obtain interoperability with other
independently created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems in
the documentation, please report them to us in writing. This document is not warranted to be error-free.
Except as may be expressly permitted in your license agreement for these Programs, no part of these
Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs
on behalf of the United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data
delivered to U.S. Government customers are
data
" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental
regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including
documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable
Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19,
Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway,
Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup,
redundancy and other measures to ensure the safe use of such applications if the Programs are used for such
purposes, and we disclaim liability for any damages caused by such use of the Programs.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.
The Programs may provide links to Web sites and access to content, products, and services from third
parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites.
You bear all risks associated with the use of such content. If you choose to purchase any products or services
from a third party, the relationship is directly between you and the third party. Oracle is not responsible for:
(a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the
third party, including delivery of products or services and warranty obligations related to purchased
products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from
dealing with any third party.
"commercial computer software" or "commercial technical
Contents
Preface ................................................................................................................................................................. ix
Audience....................................................................................................................................................... ix
Documentation Accessibility..................................................................................................................... ix
Related Documents ..................................................................................................................................... x
Conventions ................................................................................................................................................. x
1 Overview
Introduction to Oracle Communication and Mobility Server......................................................... 1-1
New in this Release............................................................................................................................ 1-1
Application Development in OCMS.................................................................................................... 1-2
Parlay X Web Service Interface ................................................................................................. 1-2
Presence Web Services ............................................................................................................... 1-2
Oracle Communication and Mobility Server Development Tools ............................................. 1-2
2 SIP Servlets
Introduction to SIP Servlets ................................................................................................................... 2-1
The SIP Container .................................................................................................................................... 2-2
SIP Application Development Process ................................................................................................ 5-2
Creating a New Dynamic Web Project with SIP Support ................................................................ 5-3
Importing an Existing Project ................................................................................................................ 5-3
Importing Example Projects ................................................................................................................... 5-4
Importing the Basic Response SIP Application Example Project................................................ 5-5
Importing the Call Forward SIP Application Example Project................................................... 5-5
Importing the Message Sender SIP/Web Converged Application Example Project............... 5-6
Importing the Proxy/Registrar Example Project .......................................................................... 5-6
iv
Importing the Third Party Call Control Example Project............................................................ 5-6
Deploying a SIP Application to OCMS............................................................................................... 5-7
Testing an Application ............................................................................................................................ 5-8
Changing the Logging Level ............................................................................................................ 5-8
Viewing the System Log File............................................................................................................ 5-8
Starting the OCMS Server in Eclipse............................................................................................... 5-8
Testing a Third Party Call Control Servlet..................................................................................... 5-9
Sh Events .......................................................................................................................................... A-16
Sh Application Options.................................................................................................................. A-17
Diameter Application Example .......................................................................................................... A-17
Event Processing in Log4j...................................................................................................................... C-4
Index
vii
viii
This preface contains the following topics:
■Audience
■Documentation Accessibility
■Related Documents
■Conventions
Audience
This guide is intended for developers and programmers who want to use Oracle
Communication and Mobility Server to create custom applications.
Documentation Accessibility
Our goal is to make Oracle products, services, and supporting documentation
accessible, with good usability, to the disabled community. To that end, our
documentation includes features that make information available to users of assistive
technology. This documentation is available in HTML format, and contains markup to
facilitate access by the disabled community. Accessibility standards will continue to
evolve over time, and Oracle is actively engaged with other market-leading
technology vendors to address technical obstacles so that our documentation can be
accessible to all of our customers. For more information, visit the Oracle Accessibility
Program Web site at
Preface
http://www.oracle.com/accessibility/
Accessibility of Code Examples in Documentation
Screen readers may not always correctly read the code examples in this document. The
conventions for writing code require that closing braces should appear on an
otherwise empty line; however, some screen readers may not always read a line of text
that consists solely of a bracket or brace.
Accessibility of Links to External Web Sites in Documentation
This documentation may contain links to Web sites of other companies or
organizations that Oracle does not own or control. Oracle neither evaluates nor makes
any representations regarding the accessibility of these Web sites.
ix
TTY Access to Oracle Support Services
Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services
within the United States of America 24 hours a day, seven days a week. For TTY
support, call 800.446.2398.
Related Documents
For more information, see the following documents:
■Oracle Communication and Mobility Server Installation Guide
■Oracle Communication and Mobility Server Administrator’s Guide
■Oracle Communication and Mobility Server sample documentation (available at
Oracle Technology Network at http://www.oracle.com/technology/index.html)
■A. Kristensen, "SIP Servlet API Version 1.0", February 4, 2003. Available in the
OCMS SCE installation at C:\Program Files\Oracle\OCMS SCE\doc
■G. Murray, et al., "Java Servlet Specification, Version 2.5", May 11, 2006
Conventions
The following text conventions are used in this document:
ConventionMeaning
boldfaceBoldface type indicates graphical user interface elements associated
italicItalic type indicates book titles, emphasis, or placeholder variables for
monospaceMonospace type indicates commands within a paragraph, URLs, code
with an action, or terms defined in text or the glossary.
which you supply particular values.
in examples, text that appears on the screen, or text that you enter.
x
This chapter describes application development for the Oracle Communication and
Mobility Server (OCMS) in the following sections:
■"Introduction to Oracle Communication and Mobility Server"
■"Application Development in OCMS"
Introduction to Oracle Communication and Mobility Server
Oracle Communication and Mobile Server (OCMS) is a carrier-grade SIP application
environment for the development, deployment, and management of SIP applications.
Built on a standard Java2 Enterprise Edition (J2EE) platform, OCMS is a flexible,
scalable environment enabling easy integration of SIP applications and services.
Among the applications that may be developed and deployed on SIP platforms:
■Voice and video telephony, including call management services such as call
forwarding and call barring
1
Overview
■Publication of and subscription to user presence information, such as online or
■Instant messaging
■Push-to-Talk applications, including Push-to-Talk over Cellular (PoC)
OCMS provides standard SIP applications out-of-the-box, including Presence, a
combination Proxy and Registrar (Proxy/Registrar), and a SIP message routing
application, the Application Router. An integral part of any SIP platform, these
applications are automatically installed to the OCMS platform, reducing development
resources and deployment time.
OCMS is distinguished by its standards-based, high performance Presence application
which is built according to the OMA/Simple Presence Enabler 1.0. The OCMS
Presence application is robust enough to support a significant amount of users, while
still being a viable solution for ISVs, system integrators, and enterprises requiring an
integration platform and an enterprise Presence Server.
New in this Release
This release of Oracle Communication and Mobility Server includes enhancements
and new features. To read about new and improved features, see
http://www.oracle.com/technology/products/ocms/otn_front.htm.
offline status, notifications, permission to access a user’s status
Overview 1-1
Application Development in OCMS
Application Development in OCMS
The OCMS environment enables you to develop JSR-116-compliant applications
through its support of the following:
■SIP Servlet API
■Parlay X Web Service Interface
SIP Servlet API
OCMS supports development of SIP servlets using the JSR-116 SIP Servlet API. Using
these interfaces, you can build a SIP Servlet to create customized SIP-based
components that terminate SIP messages, send SIP responses, and proxy SIP messages.
For an overview of SIP servlets and the OCMS extensions to the SIP Servlet API, see
Chapter 2, "SIP Servlets". For an overall view of developing applications in OCMS, see
Chapter 5, "Building a SIP Servlet Application".
Parlay X Web Service Interface
OCMS supports application development using the Parlay X Presence Web Service
interface as defined in Open Service Access, Parlay X Web Services, Part 14, Presence ETSI ES 202 391-14. Using Parlay X interface, you can build a Web Service that acts as a
client for many users by providing them functions for publishing, subscribing and
listening to notifies. For more information on OCMS support of the Parlay X Web
Service interfaces and developing a Web Service using OCMS SCE as the IDE, see
Chapter 6, "OCMS Parlay X Web Services". For examples of building a Parlay X Web
Service for the Oracle WebCenter 10.1.3.3 platform, see the Oracle Communication and
Mobility Server documents on Oracle Technology Network
(http://www.oracle.com/technology/index.html).
Presence Web Services
You can use the Oracle JDeveloper 10g to test Presence Web Services. Oracle
JDeveloper Release 10.1.3.3 or higher is the preferred development tool for customers
creating applications for the WebCenter 10.1.3.3 platform. For more information on
using Oracle JDeveloper 10g within OCMS, refer to Oracle Communication and
Mobility Server documents on Oracle Technology Network
(http://www.oracle.com/technology/index.html).
Oracle Communication and Mobility Server Development Tools
OCMS provides OCMS Service Creation Environment (OCMS SCE) as the primary
development tool. Oracle JDeveloper is a secondary tool which is used to test Presence
Web Se rvices.
OCMS SCE
OCMS provides the OCMS Service Creation Environment (OCMS SCE), a
development tool for SIP servlets and server-side applications. OCMS SCE (SCE),
intended for developers on the Windows operating systems, provides tools and APIs
for creating services using the OCMS platform. OCMS SCE, which runs on Eclipse,
supports your development effort through the Code, Build, Deploy and Debug phases of
the development cycle (
For information on building applications with OCMS SCE, see Chapter 5, "Building a
SIP Servlet Application".
Figure 1–1).
1-2 Oracle Communication and Mobility Server Developer’s Guide
Figure 1–1 OCMS SCE Application Development Support
Application Development in OCMS
Overview 1-3
Application Development in OCMS
1-4 Oracle Communication and Mobility Server Developer’s Guide
This chapter provides an overview of SIP Servlets and the SIP Servlet API (as
described in JSR-116) in the following sections:
■"Introduction to SIP Servlets"
■"The SIP Container"
■"SIP Servlets and SIP Applications"
■"SIP Servlet Environment"
■"Classes and Methods"
■"Configuring SIP Applications in sip.xml"
■"SIP Servlets in OCMS"
Introduction to SIP Servlets
This chapter provides an overview the SIP Servlet API, the SIP container, the SIP
servlet environment, SIP classes and methods, and SIP application configuration.
2
SIP Servlets
The SIP Servlet API is defined in JSR 116, and describes a standard interface for
programming SIP services and applications. A SIP servlet can be compared with a Java
HTTP servlet but with SIP protocol-related methods. In fact, the SIP Servlet API builds
on the general Servlet API in the same way as the HTTP Servlet API
SIP Servlets are grouped into four categories:
■User Agent Server: A servlet that acts as a User Agent Server (UAS) receives
incoming requests and sends responses.
■User Agent Client: A servlet that acts as a User Agent Client (UAC) initiates
outgoing requests and receives responses to these requests.
■Proxy: A servlet that acts as a proxy receives incoming requests and proxies them
to other end-points (other proxies or a UAS). A proxy servlet will manipulate the
request URI and proxy the request to that destination.
■Back to Back User Agent: A servlet that acts as a Back to Back User Agent (B2BUA)
acts as both a UAS and UAC on a request. It receives and answers back to one
request (first session) and initiates and receives responses on another request
(second session).
SIP Servlets 2-1
The SIP Container
The SIP Container
This section describes the SIP Container (Figure 2–1) by discussing the following
components:
■Servlet Context
■SIP Application Sessions
■Protocol Sessions
■Tra ns ac ti on s
■Servlets
■Listeners
Figure 2–1 The SIP Container Object Model
Servlet Context
The Servlet Context is a servlet view of the SIP application to which it belongs. Using
the Servlet Context, the servlet can access such global application services as listeners
and context init parameters.
The application global init parameters are set in the deployment descriptor, the
sip.xml file, and are marked with the <context-param> marker. Examples of
global application parameters are common resource addresses, like addresses to a
database and backend applications.
The Servlet Context also holds all references to any implemented and configured
listeners. Session and proxy timeouts are held by the Servlet Context. These are
configured in the sip.xml file and the session timeout is found within the
<session-config> and marked in the <session-timeout> section. The proxy
timeout is found within the <proxy-config> and marked in the
<sequential-search-timeout> section.
The Servlet Context is retrieved by calling the getServletContext method from the
servlet. For example:
2-2 Oracle Communication and Mobility Server Developer’s Guide
SIP Application Sessions
While an application may involve several types of servlet sessions (for example, SIP
and HTTP), these sessions must be related to the same application. This is done
through a SIP Application Session. The SIP Application Session can hold multiple
protocol sessions; the protocol sessions can be of the same type or different types (SIP,
HTTP).
A SIP Application Session can hold attributes available to all protocol sessions related
to that application session. A SIP Application Session can hold multiple protocol
sessions. For example, B2BUA creates two sessions that are located in the same SIP
Application Session.
A SIP Application Session exists until it times out or when the application explicitly
calls the invalidate method. A well-behaved application should always invalidate a
session when it does not need it anymore. If the SIP Application Session is invalidated,
all Protocol Session objects are invalidated together with it. The timeout value of a
session is set with the <session-timeout> parameter in the sip.xml file. If no
timeout value is defined within this element, then the default value for the container is
used (the default is 15 minutes).
If a subsequent request arrives after a session has been invalidated, then the server will
respond with a 481 "Call transaction does not exist" message. Requests and responses
that correspond to a SIP application session can be retrieved with the
getApplicationSession() method on the request (SipServletRequest) or the
response (SipServletResponse) object.
The SIP Container
Protocol Sessions
A Protocol Session is a session for a certain protocol. If an application involves several
protocols, the SIP application session would then hold several protocol sessions.
A SipSession object can represent a point-to-point SIP relationship, an established
SIP dialog, or an initial state SIP dialog. The initial state is described as a request that
has been received or created with the createRequest method in the sipFactory
class. The SIP session object is created by the container when an initial request has
invoked one servlet.
A request or a response corresponding a SIP session can be retrieved with the
getSession() method on the request (SipServletRequest) or the response
(SipServletResponse) object. All of the protocol sessions in an application session
can be retrieved with the getSessions() method on the
SipApplicationSession object.
Transactions
A SIP transaction consists of a single SIP request and all responses to that request,
including the provisional responses and a final response.
A SipServletRequest and a SipServletResponse always belong to a SIP
transaction. If a servlet tries to send a message that violates the SIP transaction state
model, the container throws an IllegalStateException. The SIP Servlet API is
designed in such a way that a developer does not need to consider transactions, only
requests and responses.
SIP Servlets 2-3
The SIP Container
Servlets
Each servlet defined in the deployment descriptor has one instantiation. Because
servlets are run in a multi-threaded environment, only data that is common to all
requests and responses, such as init parameters, are stored as member variables.
Increased Servlet Modularity
Each servlet, which includes a <servlet> and a <servlet-mapping> section in
the deployment descriptor file (sip.xml) also has a <security-constraint>
section. OCMS makes these servlets reusable through the Servlet Creation wizard in
OCMS SCE, because these sections are created together with the servlet.
Renaming SAR Files for the JBoss Application Server
In OCMS, the Servlet archive format (SAR) file is renamed to a Sip Servlet aRchive
(SSR). The format of the two files are the same, the difference in naming is because of
the requirement for a third-party application server for OCMS. Because the application
server cannot process SAR files, the SIP AS checks for SSR files instead. This name
change enables portability between different SIP application servers.
Note: When you deploy a SIP application through Oracle 10g
Application Server Control or through the admin_client.jar
command-line tool you must rename the Servlet archive file (SAR file)
to WAR and list the WAR file in the application.xml just like a WAR
archive. Also the WAR must contain a web.xml file, so that you can
deploy it on OC4J.
Listeners
For more information on packaging SAR files and deploying EAR
files, see Oracle Communication and Mobility Server Administrator’s Guide.
Listeners can be registered to listen on events and invoke a method. Each deployment
descriptor can only have one defined listener of each type. Each of these listeners must
be implemented by the developer. The different types of listeners are as follows:
■SipApplicationSessionListener: The listener for
SipApplicationSession creation and invalidation. It can be used to ask for a
session extension. The SipApplicationSessionListener interface must be
implemented and the sip.xml updated.
■SipSessionListener: The listener for changes in active SipSessions in the SIP
servlet application. The SipSessionListener interface must be implemented
and configured in the sip.xml file.
■SipSessionAttributeListener: The listener for SipSession attribute
changes. The SipSessionAttributeListener interface must be implemented.
■TimerListener: The timer service enables delayed actions for a servlet if the
TimerListener interface has been implemented. Only one timer listener exists
per application (sip.xml).
■SipSessionActivationListener: Objects that depend on a session can listen
on their status about being active or passive if the
SipSessionActivationListener interface is implemented.
2-4 Oracle Communication and Mobility Server Developer’s Guide
SIP Servlets and SIP Applications
A SIP application is a J2EE-compliant application accessed over the SIP protocol.
Applications are triggered by an inbound SIP protocol request, just as Web
applications are triggered by an inbound HTTP protocol request.
An application has a protocol interface such as SIP or HTTP (presentation tier) that
reaches servlets and other business objects (logic tier) which in turn are managed and
have resource connections to the database (data tier). User and application data are
accessed through the data tier which is represented by applicable parts from the J2EE
specification. Applications are delimited by the scope of the deployment descriptor,
the sip.xml file.
SIP Servlet Environment
This section describes the environment of a SIP servlet and what occurs during both
the startup of the application server (AS) and when a request enters the SIP Container.
Figure 2–2 The SIP Container at Startup
SIP Servlet Environment
1.The following occurs at startup:
a.The container reads the deployment descriptor (sip.xml).
b.A Servlet Context is created.
–The global init parameters are set. These are marked with
<context-param> in the sip.xml file.
–Session Configuration values are set. These are marked with
<session-config> in the sip.xml file.
–Proxy Configuration values are set. These are marked with
<proxy-config> in the sip.xml file.
–The container instantiates the TimerListener,
SipApplicationSessionListener,
SipSessionActivationListener,
SipSessionAttributeListener, and the SipSessionListener.
Each listener has one instantiation (if defined).
c.A Servlet Config object is created. The Servlet Config holds all init parameters
per servlet. These are marked with <init-param> and are set per servlet in
the sip.xml file. It also includes the global init parameters
(context-param).
SIP Servlets 2-5
SIP Servlet Environment
Figure 2–3 Initial Requests Processed by the SIP Container
d.The servlets are created and initiated with the init parameters prepared by the
Servlet Config. Each servlet is run as one instance. The init method in the
servlets is executed.
e.A SIP Application Manager, which contains a reference to
SipApplicationSessions and the SipFactory, is created.
2.The container distinguishes between initial requests and subsequent requests,
where initial requests invoke a servlet depending on the invoke conditions (or
rules) of the servlet and subsequent requests get forwarded directly to the same
servlet as invoked for the initial request. At an Initial Request, the following steps
occur:
a.The container chooses a specific application based on the handling described
in "Handling Initial Requests".
b.Which servlet to invoke is decided by evaluating the rules of each servlet in
the servlet invocation order (
Figure 2–3). The rule execution order is decided
by the order of the <servlet-mapping> order for each servlet in the
sip.xml file. The servlet with the top-most servlet mapping is the one that
get the rules checked first. For more information, see the following section,
"Servlet Mapping".
c.A SIP Application Session is created together with a SIP Session.
d.A transaction and a request are created and associated with the SIP session
object just created.
3.For a subsequent request, one for which the container already holds a dialog (a
dialog is defined by the Local-tag + Remote-tag + CallId), the request is forwarded
to the same servlet executed at the initial request. The request works with the
same Message Context (SIP-Application Session + SIP-Session) as it had in the
initial request.
2-6 Oracle Communication and Mobility Server Developer’s Guide
Servlet Mapping
Classes and Methods
A SIP application can contain one or more SIP Servlets. When the SIP container
receives SIP requests, the container selects a SIP application to serve the request. The
SIP application then evaluates its rules (that is, the servlet-mapping defined in the
sip.xml file) to find the appropriate SIP servlet that responds to the request. The SIP
application then uses the first SIP servlet that matches the request.
Note: SIP servlets can forward the request to another SIP servlet by
using javax.servlet.ServletRequest.getRequestDispatcher()
Additionally, you can chain applications using the Application
Router. Refer to the Oracle Communication and Mobility Server Administrator’s Guide.
For example, if the SIP container receives an INVITE request, the container selects a
SIP application containing the following SIP Servlets to match the request:
■Servlet 1 - Invoked for INVITE requests.
■Servlet 2 - Invoke for MESSAGE requests.
■Servlet 3 - Invoked for all requests.
The SIP application then attempts to find a match by evaluating its rules from the top
to the bottom. In this case, Servlet 1 and Servlet 3 both match the INVITE request.
Since only one of these servlets can serve the request and since the application reviews
the rules sequentially, the application selects Servlet 1. Servlet 1 starves out Servlet 3. If
the SIP container receives a MESSAGE request, then the application invokes Servlet 2.
For REGISTER requests, the application invokes Servlet 3, the only servlet able to
serve this type of request. If the application does not include Servlet 3, the
application’s match method will return null for the REGISTER request and the SIP
container will issue a 403 response, Application choose not to service the request, which
will be written to the log file.
Note: While a SIP application can invoke only one SIP Servlet for a
request, the SIP container can invoke more than one SIP application
for an incoming request using the Application Router.
Classes and Methods
This section introduces the classes and methods in the SIP servlet API.
A SIP Servlet is a class that extends the javax.servlet.sip.SipServlet class
and thereby interacts with a SIP application server to send and receive SIP messages.
Request and Response Handling Methods
The servlet overrides the methods needed for the particular service. The two main
methods that the SIP Servlet uses to perform overrides are:
The doRequest() method handles all of the requests and the doResponse()method
handles all of the responses.
SIP Servlets 2-7
Classes and Methods
Outside of the service method, the doRequest() and doResponse() are the
broadest methods provided by the SipServlet class. These methods enable tasks
that are independent of the received method or response. You can extend methods to
perform specific request and response handling tasks.
Extend the following methods for request handling:
■doInvite – for SIP INVITE requests
■doAck – for SIP ACK requests
■doCancel – for SIP CANCEL requests
■doBye – for SIP BYE requests
■doOptions – for SIP OPTIONS requests
■doRegister – for SIP REGISTER requests
■doSubscribe – for SIP SUBSCRIBE requests
■doNotify – for SIP NOTIFY requests
■doMessage – for SIP MESSAGE requests
■doInfo – for SIP INFO requests
■doPrack – for SIP PRACK requests
For response handling, extend the following:
■doProvisionalResponse – for SIP 1xx informational responses
■doSuccessResponse – for SIP 2xx responses
■doRedirectResponses – for SIP 3xx responses
■doErrorResponse – for SIP 4xx, 5xx, and 6xx responses
Note: All of these response handling methods, as well as the doAck
and doCancel request handling methods, are empty. The remaining
request handling methods respond to a request with a 500 Response
(Internal Server Error).
Messages
SIP Messages follow the RFC 822 standard. Headers, values and content can be
accessed through the methods in the javax.servlet.sip.SipServletMessage
interface.
Both the SipServletRequest and SipServletResponse classes extend the
SipServletMessage interfaces:
■public interface SipServletRequest extends
javax.servlet.ServletRequest,SipServletMessage
■public interface SipServletResponse extends
javax.servlet.ServletResponse, SipServletMessage
Requests
SipServletRequest and SipServletResponse objects in the SIP servlet methods
doRequest and doResponse are implementations of the SipServletRequest
interface and the SipServletResponse interface which both extend the
SipServletMessage interface from the javax.servlet.sip package.
2-8 Oracle Communication and Mobility Server Developer’s Guide
Classes and Methods
A SIP request consists of the following:
■Request line
■Headers
■Empty line
■Message body
All parts of the SIP request for instance request URI, headers and parameters are
accessible through these interfaces. The SIP container handles many of these system
headers. Applications must not add, delete, or modify the following system headers:
■From
■To
■Call ID
■CSeq
■Via
■Route (except through pushRoute)
■Record Route
■Contact (Contact is a system header field in messages other than REGISTER
requests and responses, as well as 3xx and 485 responses)
Responses
Responses to incoming requests are created using the createResponse method on
the request object. It will automatically create a response with all SIP headers set
according to the request. A SIP response has the same structure as a SIP request,
except for a Status line instead of a request line. When receiving responses through, for
instance the doResponse method, methods like getStatus() can be used on the
response object to decide what action to take.
Content
The content in a request or a response can be set with the setContent() method as
illustrated in
Example 2–1 Setting the Content of a Request with the setConent Method
// Copy of the content from request A to request B
requestB.setContent(requestA.getContent(),
requestA.getContentType());
// Create new content
{
try
req.setContent("Hello!", "text/plain");
}
catch (UnsupportedEncodingException e)
{
// Handle the exception
}
Example 2–1.
Manipulating SIP headers
The javax.servlet.sip.SipServletMessage includes methods for
manipulating SIP headers. The getHeaderNames() method is the most general
SIP Servlets 2-9
Classes and Methods
method that returns an iterator of the SIP headers of the message. The setHeader
method sets or adds an address for a header. Specifying the name of the header in
getHeaders(name) method returns another iterator of String objects containing all
of the values for that header.
For those headers that conform to AddressHeader, the getAddressHeader(name)
method will return the header parsed as an Address object.
Addresses can be added or set for a header by using setAddressHeader(name, address), addAddressHeader(name, address, first), where name is the
name of the header, the address to add, and first is a Boolean. If first is set to true, then
the address will be added first, otherwise it will be added last.
Example 2–2 shows how to manipulate SIP headers:
Example 2–2 Manipulating SIP Headers
javax.servlet.sip.SipServletRequest req;
// Set a header with the given name and value.
// Overwrites any previous header values.
req.setHeader("Accept", "application/sdp");
// Add a header value to the end of a header
req.addHeader("Accept", "text/html");
// Clear all header values
req.removeHeader("Accept");
// Add a Route header value ahead of the existing Route header
// values.
req.pushRoute(sipURI);
// Get the first route as an Address object
Address first route = req.getAddressHeader("Route");
// Get all address header fields for a header
Iterator addrIter = req.getAddressHeaders("Route");
while (addrIter.hasNext())
{
Address addr = (Address) addrIter.next();
// ...
}
SipURI
A base class javax.servlet.sip.URI exists with two sub classes,
javax.servlet.sip.SipURI and javax.servlet.sip.TelURL which
represents SIP URIs and TEL URLs according to RFC 3261, and URLs defined by
RFC 2806. The Address class stores a SipURI or a TelURL as the address of the user.
URIs can be described as user@host, where the user part is either a user name or a
telephone number, and the host is a domain name or an IP address.
Parameters can be accessed with getters and setters. The getParameterNames
method will return an iterator with the names of the parameters. A parameter can be
accessed either with the general getParameter method or with specific parameter
methods like getUser, getHost and getLrParam, which returns the user, the host,
and true if the loose route, lr is set. Parameters can be set with its corresponding
setMethod() as shown in
2-10 Oracle Communication and Mobility Server Developer’s Guide
Example 2–3.
Classes and Methods
Example 2–3 Accessing Parameters in SipURI
// Create a SipURI, set the port, the lr, and the transport
// protocol parameter
SipURI myURI;
myURI = sipFactory.createSipURI("bob", "10.0.0.10");
myURI.setPort(5072);
myURI.setLrParam(true);
myURI.setTransportParam("udp");
Address
SIP addresses found in headers, such as the From, To , and Contact headers, are stored
as javax.servlet.sipAddress objects. As shown in
holds, beside the URI, an optional display name and a set of name-value parameters.
Example 2–4 SIP Addresses Stored in java.servlet.sip Address Objects
Address contactAddress;
String displayName;
try
{
// Get the contact address
contactAdress = req.getAddressHeader("Contact");
displayName = contactAdress.getDisplayName();
}
catch (ServletParseException spe)
{
// Handle exception
}
// Create a new address
Address myNewAddress;
myNewAddress = sipFactory.createAddress(URI, "Bob's display name");
myNewAddress.setParameter("myparameter","42");
Example 2–4, the object
The content of myNewAddress in the preceding example is as follows:
DisplayName: "Bob’s display name"
URI: <sip:bob@example.com;lr>;
parameter myparameter: 42
The Address class offers the following methods:
■getDisplayName()
■setDisplayName()
■getURI()
■setURI()
■clone()
■toString()
SIP Details
When working with the SIP Servlet API, many SIP details are hidden and performed
automatically by the OCMS SIP Application Server.
■When the transport protocol is UDP, retransmissions are handled automatically.
SIP Servlets 2-11
Classes and Methods
■Dialog-related information such as tags, contacts, and CSeq in the SIP messages
are handled automatically.
■On outgoing requests, OCMS performs DNS lookups and supports NAPTR-,
SRV-, and A-records (according to RFC 3263).
Storing Data as Session Attributes
The SIP Servlet API enables data to be stored as session attributes. Session attributes
can be used to store session specific data to be used in responses and subsequent
requests or from a listener class. The attributes are stored and accessed through setters
and getters directly on the session object. The session can be either a SipSession or a
SipApplicationSession. An attribute can only be retrieved from the same session
it was set. For example:
session.setAttribute("key", "value");
session.getAttribute("key"); // Will return "value"
session.removeAttribute("key");
Although the session attributes can store any object, the attributes and their keys must
be serializable for applications that are distributable (for High Availability). Use the
getAttributeNames method to retrieve all of the set attributes. For example:
A servlet can be configured by adding parameters to the <servlet> section in the SIP
Servlet application descriptor (sip.xml). The servlet can then access these parameters
through the getInitParameter method.
the response code.
2-12 Oracle Communication and Mobility Server Developer’s Guide
Configuring SIP Applications in sip.xml
SIP servlets must be declared in the application’s deployment descriptor, the sip.xml
file. The sip.xml file enables you to configure the init parameters and the rules that
match initial requests with SIP servlets.
The deployment descriptor is divided into the following sections:
–Application life cycle listener classes
–Error handler
■Security
Setting and Accessing Global Init Parameters
The <context-param> and the <env-entry> elements provide the means to set
and access the application’s global parameters, such as the database used with an
application or other resources that are common to the entire application. These
elements differ in how the global parameters are accessed.
The <context-param> element declares the servlet’s init parameters that are global to
the entire
Servlet Context. Example 2–6 illustrates setting the database for an
application within the <context-param> element.
Example 2–6 Setting a Database Name within the <context-param>
<context-param>
<param-name>Database</param-name>
<param-value>10.0.0.100</param-value>
<description>The database to be used with this application.</description>
</context-param>
Configuring Application Sessions
SIP Application Sessions are configured within the <session-config> clause. The
session configuration can configure a session timeout value, which is done within the
<session-timeout> clause as shown in the following example. The timeout is set in
minutes; if it set to 0 or below, an application session will never timeout and must be
invalidated explicitly. If no value is set within <session-timeout>, the default
timeout session set for the SIP Servlet Container is used instead (15 minutes).
The <servlet> element defines the SIP container’s servlets. A servlet requires a
servlet name <servlet-name>, and a servlet class, <servlet-class>. The name
must be unique within the application and the class must be the fully qualified name
of the servlet class, as illustrated in
A servlet can also have its own init parameters, <init-param> and a description
<description>. When the container starts, it only instantiates and calls the init()
method for the servlets which have set the <load-on-startup> element, as shown
in
Example 2–8.
Example 2–8 Defining a Servlet
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>com.mydomain.test.MySipServlet</servlet-class>
<init-param>
<param-name>logging</param-name>
<param-value>true</param-value>
<description>
Set if logging should be switched on (true) or not (false).
</description>
</init-param>
<init-param>
<param-name>infotainment</param-name>
<param-value>http://www.infotainmentsite.com</param-value>
<description>
The site to use as the infotainment content provider.
</description>
</init-param>
<load-on-startup/>
</servlet>
Example 2–7.
Defining the Servlet Mapping
The <servletmapping> element of the SIP servlet application deployment
descriptor defines the conditions for invoking a servlet.
servlet named MySipServlet can only be invoked for incoming MESSAGE requests. For
more information, see
2-14 Oracle Communication and Mobility Server Developer’s Guide
"Servlet Mapping".
Example 2–9 illustrates how a
Configuring SIP Applications in sip.xml
Creating Rules Using the Request Object Structure
The request object model enables you to define rules for processing SIP requests. This
section describes the object model and the predicates for building the rules.
The Request object contains many sub objects, for example SipURI which extends the
URI object.
The request object contains the following elements:
■method: The method of the request is represented as String.
■uri: The URI object of the request object, such as SipURI or a TelURI.
■from: The From header address represented as Address.
■to: The To header address represented as Address.
The URI object consists of the URI scheme.
The SipURI object consists of the following elements:
■scheme: The string sip or sips (where sips indicates that TLS should be used).
■user: The user part of the SIP or SIPS URI. If the SIP address is
sip:alice@example.com, then request.uri.user will return alice.
■host: The host part of the SIP or SIPS URI. If the SIP address is
sip:alice@example.com, then request.uri.host will return
example.com.
■port: The SIP URI port. If it is not present, then the default value for UDP and TCP
is 5060 and TLS is 5061.
■tel: Returns the user part of the SIP or SIPS URI if the parameter user is set to
phone for the URI. The initial visual separators as + and - are stripped away. For
example, if the SIP URI is sip:+12345@example.com;user=phone, then the request.uri.tel would return 12345.
■param.name: The value of the SipURI parameter with the name name. For example,
given the following request URI: INVITE
sip:23479234@oracle.com;user=phone SIP/2.0, the
request.uri.param.user will return phone.
The TelURL consists of the following elements:
■scheme: The string, tel.
■tel: The tel URL subscriber name.
■param.name: the value of the SipURI parameter with the name name.
Address consists of the following elements:
■uri: The URI object
■display-name: The To or From display name of the header.
SIP Servlets 2-15
Configuring SIP Applications in sip.xml
Conditions
Tab le 2–1 lists the operators.
Table 2–1 Operators
Condition NameDescription
equalCompares the value of a variable with a literal value and
evaluates to true if the variable is defined and its value equals
that of the literal. Otherwise, the result is false.
existsTakes a variable name and evaluates to true if the variable is
containsReturns true if the first argument, a variable, contains the literal
subdomain ofIf given a variable denoting a domain name (SIP/SIPS URI host)
defined, or to false if the variable has not been defined.
string specified as the second argument.
or telephone subscriber (tel property of SIP or Tel URLs), and a
literal value, this operator returns true if the variable denotes a
sub domain of the domain given by the literal value.
Tab le 2–2 lists the logical connectors.
Table 2–2 Logical Connectors
LogicDescription
andContains a number of conditions and evaluates to true if all of
orContains a number of conditions and evaluates to true if and
notNegates the value of the contained condition.
the contained conditions evaluate to true.
only if at least one contained condition evaluates to true.
Examples
Example 2–10 describes the parts of a request which are referenced with the different