 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 116: SIP Servlet API
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: The SIP Servlet API defines a high-level extension API for SIP servers. It enables SIP applications to be deployed and managed based on the servlet model. Please direct comments on this JSR to the Spec Lead(s) Team
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: Sean Olson, Ericsson 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.)JavaTM 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:
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 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 A. Deo, A. Kristensen, P. Mataga, K. Porter, J. Rosenberg, and P. Sripathi, "Overview of the SIP Servlet API", dynamicsoft Inc, Mar. 2001. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
