The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 116

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: dynamicsoft, Inc.

Name of Contact Person: Anders Kristensen

E-Mail Address: akristensen@dynamicsoft.com

Telephone Number: +1 973 952 5065

Fax Number: +1 (973) 952-5050

Specification Lead: Anders Kristensen

E-Mail Address: akristensen@dynamicsoft.com

Telephone Number: +1 973 952 5065

Fax Number: +1 (973) 952-5050

Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)

Sean Olson, Ericsson
Gautam Talagery, Ericsson
Mikko Lonnfors, Nokia
Michael O'Doherty, Nortel Networks
Danny Coward, Sun Microsystems
Johannes Stadler, Technische Universitaet Wien
Igor Miladinovic, Technische Universitaet Wien

Section 2: Request

2.1 Please describe the proposed Specification:

The Session Initiation Protocol (SIP) is used to establish and manage multimedia IP sessions. This JSR requests the creation of a SIP Servlet API specification based on the model of the existing Servlet API. This will be version number 1.0.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java^TM 2 Standard Edition. We also expect the proposed specification to be a candidate for consideration to be part of the J2EE platform.

2.3 What need of the Java community will be addressed by the proposed specification?

The proposed API enables SIP servers to be augmented with Java extension code which can be deployed and managed as a unit. The expert group will define an actual API as well as XML based deployment descriptors and related file formats. The SIP Servlet API is similar in nature to the HTTP Servlet API, but there are some important differences. HTTP servlets run only on origin servers. In SIP, proxy servers play a much bigger role, as do application servers which initiate requests. As such, SIP servlets must be able to run on these other server types.

The SIP Servlet API specification must address the following requirements:

• allow network servers to handle SIP requests in the delivery of SIP related services. This requires the ability to respond to requests, proxy requests, and initiate new requests.
• lifecycle management of SIP servlets and related SIP abstractions
• provide session management support, allowing users to deposit and retrieve data from objects which potentially span multiple SIP requests, calls, and even multiple protocols
• provide high level access to SIP objects, such as requests and responses, with the ability to manipulate key headers and field values. Emphasis is on simplicitly and minimality rather than completeness.
• must hide the complexities of SIP wherever possible; developers should not need to be SIP experts
• definition of rule based mappings from SIP requests to servlets which will process them
• definition of a security model
• definition of an XML DTD for SIP Servlet deployment descriptors
• definition of a jar based file format for SIP Servlet applications (similar to the Web ARchive (war) format defined for the HTTP Servlet API)
• possibly access to location databases

This list of requirements is not necessarily complete and neither will all items be addressed by version 1.0. In particular we do not expect to define SIP servlet mappings, deployment descriptors, and file formats in version 1.0. We intend to define the API in a progression of specifications which address the requirements in an incremental fashion. This is done to ensure timely delivery of the API as well as in order to gain experience with some of the more advanced features prior to standardization.

Please note that while the ability to proxy is central to SIP services, we make no assumption about whether this functionality is provided for servlets generally or for SIP servlets specifically.

2.4 Why isn't this need met by existing specifications?

The JAIN SIP API (JSR 32) defines a general purpose API which is intended for low-level SIP processing in clients as well as servers. Servlets add another layer of API to handle the specific needs of high volume servers that process SIP services developed by third parties. This introduces the need for many of the higher level services listed above: lifecycle management, sessions, data storage and retrieval, security, mappings, context and configuration data.

Where the JAIN SIP API exposes the full complexity of the SIP protocol, the servlet API will present an abstracted view of SIP to application writers and will be designed to allow servlet engines to 1) handle those details of SIP protocol operation not needed for authoring services, and 2) prevent services from performing protocol violations or other restricted operations.

2.5 Please give a short description of the underlying technology or technologies:

SIP is an IETF protocol used for establishing, managing, and terminating sessions between two or more IP endpoints. It defines a number of network entities, notably user agents (UAs) which are the endpoints which initiate and respond to SIP requests, and proxies which makes routing decisions and forward SIP messages towards their destination UA. One of the main functions of SIP is routing session invitations from UA clients via a path of SIP proxies to UA servers. SIP servlets will typically reside on network servers where they will be responsible for making routing decisions.

The Servlet API was developed as an extension mechanism for Web servers similar to CGI scripts and native APIs. It allows Web servers to invoke Java based Web components in order to have them generate content dynamically. The Servlet API consists of a generic, protocol independent part, javax.servlet, as well as an HTTP specific part, javax.servlet.http. Apart from applying to SIP and not HTTP, the envisioned SIP Servlet API differs from the (HTTP) Servlet API primarily in its need to support proxying functionality and in having a more complicated state model.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.servlet.sip. The expert group will investigate whether changes to javax.servlet are desirable, and if so, will work with the servlet expert group to make this happen.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

Similar to the HTTP Servlet API, e.g. servlet authors will be allowed to specify locale for responses.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

This is the first protocol other than HTTP for which an API is defined based on the javax.servlet package. It is possible that it turns out to be desirable to modify parts of the (HTTP) Servlet API, e.g. to support a common definition of sessions. The working group will investigate if modifications are needed, and if so, how they can be made in a way that ensures backwards compatibility of existing HTTP servlet code.

2.11 Please describe the anticipated schedule for the development of this specification.

Initiation: May 2001
Community Review: July 2001
Public Review: August 2001
Final Draft Proposal: October 2001

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", Nov. 2000
http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-02.txt

A. Deo, A. Kristensen, P. Mataga, K. Porter, J. Rosenberg, and P. Sripathi, "Overview of the SIP Servlet API", dynamicsoft Inc, Mar. 2001.