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

Updates to the Original JSR

The following information has been updated from the original request.

2011年08月23日:
One of the Maintenance Leads was replaced:

Maintenance Leads: Yannis Cosmadopoulos, Amitha Pulijala

E-Mail Addresses: yannis.cosmadopoulos@oracle.com, amitha.pulijala@oracle.com

Telephone Numbers: -, +1 415 402 7245

Fax Number: +1 415 402 7210

2008年03月13日:
One of the Spec Leads was replaced:

Specification Lead: Mihir Kulkarni, Yannis Cosmadopoulos

E-Mail Address: mihirk@bea.com, ycosmado@bea.com

Telephone Number: -

Fax Number: +1 415 402 7210

2007年10月03日:
The Spec Lead was replaced:

Specification Lead: Jarek Wilkiewicz, Mihir Kulkarni

E-Mail Address: jwiliew@bea.com, mihirk@bea.com

Telephone Number: -

Fax Number: +1 415 402 7210

2007年08月03日:

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

Public Review (PR): Sepetember 2007.
Proposed Final Draft (PFD): November 2007.
Final Release (FR): January 2008

2007年05月25日:

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

Public Review (PR): July 2007.
Proposed Final Draft (PFD): September 2007.
Final Release (FR): November 2007.

2006年11月17日:

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

Early Draft Review (EDR): December 2006.
Public Review (PR): May 2007.
Proposed Final Draft (PFD): July 2007.
Final Release (FR): August 2007.

2006年08月28日:

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

Early Draft Review (EDR): October 2006.
Public Review (PR): February 2006.
Proposed Final Draft (PFD): April 2007.
Final Release (FR): March 2007.

2006年06月23日:

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

Early Draft Review (EDR): August 2006.
Public Review (PR): December 2006.
Proposed Final Draft (PFD): February 2007.
Final Release (FR): March 2007.

2006年03月20日:

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

Early Draft Review (EDR): June 2006.
Public Review (PR): October 2006.
Proposed Final Draft (PFD): December 2006.
Final Release (FR): February 2007.

---

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: BEA

Name of Contact Person: Phelim O'Doherty

E-Mail Address: phelim.odoherty@bea.com

Telephone Number: +44 289 036 9158

Fax Number: +44 289 036 9158

Specification Lead: Nasir Khan

E-Mail Address: nkhan@bea.com

Telephone Number: +1 415 402 7419

Fax Number: +1 415 402 7770

Initial Expert Group Membership:

Supporting this JSR:

AT&T
BEA Systems
Cisco Systems
Ericsson
IBM
Sun Microsystems

Section 2: Request

2.1 Please describe the proposed Specification:

The SIP Servlet Specification (JSR116) is a container based approach (modelled on the HTTP servlet paradigm) to developing communication applications utilizing the Session Initiation Protocol (SIP) protocol. SIP is used to establish and manage multimedia IP sessions. This JSR requests the evolution of the SIP Servlet specification to address capabilities discovered by the industry as a result of using the specification. Some of the core requirements requiring the evolution of this specification are:

- Application Composition: The ability to map certain communication features to SIP Servlets and in-turn invokes those features in an independent manner is desirable. It is clear that a SIP Servlet environment should be able to support the composition on a call of multiple SIP servlets application written by unrelated parties and to have that composition produce good, predictable results. It is necessary to define when, if or how one SIP Servlet application is invoked to service a request with respect to another SIP Servlet application.

- Application Invocation: When multiple applications are invoked the SIP servlet environment should define behaviour for the order in which applications or the triggering rules are considered. While SIP Servlet v1.0 does dictate an order for triggering rules within a servlet application it does not dictate anything about the order in which servlet applications themselves or their rules should be considered for invocation.

- Application Convergence: The ability to move seamlessly between HTTP and SIP servlets within a convergence application.

- Deployer support for Application Invocation and Composition: There is a need to define a mechanism that enables the deployer to have control, either real time or operational, over when and how SIP Servlet applications are invoked to handle communication requests. This needs to be a standard, non-proprietary mechanism whereby the deployer has a well understood role in determining the invocation of SIP Servlet applications.

- Enhanced SIP Servlet control of Application Invocation: SIP servlets should be able to convey their intentions about how they wish subsequent service invocation to take place. For example, a B2BUA SIP Servlet application can be invoked and receive an initial request as a UAS. When it issues another request as a UAC, it has no way to indicate to the container or any deployer logic that how it wishes the new INVITE to be considered. Should the INVITE be routed as if it were received anew by the container or, should this request continue to be "routed" to subsequent applications as if it were a 'continuation' of the service invocation process that had already been started and resulted in the invocation of the B2BUA application.

- Formal Distinction between Caller and Callee services: The SIP Servlet specification defines no formal distinction between callee and caller services, therefore SIP servlets cannot easily determine on whose behalf they are being invoked. Many telecommunications features involve application logic that acts on behalf of a particular subscriber where the functionality of the application needs to be present whether the subscriber places or receives calls.

This list of requirements is not necessarily complete and this will be explored further in the expert group - for example, additional support could be defined for initial and subsequent request, inter-servlet loop detection, additional protocol support, complex SIP dialog management, explicit header manipulation, JMX management, 3GPP IMS support and inter-servlet communication. It is intended that the priority of each of these enhancements be defined by the expert group with the goal of defining the API in an incremental manner satisfying a bulk set of requirements in each release. 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.

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

The Java Standard Edition or the Java Enterprise Edition.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This specification has no direct impact on the Java Enterprise Edition or the Java Standard Edition. Yet it is possible that this specification may be adopted by the Java Enterprise Edition as the SIP protocol becomes main stream in enterprise computing. An implementation of this specification may run on the Java Standard Edition or Java Enterprise Edition run-time.

2.4 Should this JSR be voted on by both Executive Committees?

No. This JSR only requires a vote from the SE/EE committee.

2.5 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. This specification takes the existing SIP Servlet specification which defines an actual API as well as XML based deployment descriptors and related file formats for developing SIP Servers in Java and evolves that specification to satisfy requirements from deployed products today. See Section 2.1 for the list of requirements.

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

SIP Servlet v1.0 specification left some of these areas undefined to get feedback from developers and product implementation in order to determine the best way to standardize these capabilities. No other specification addresses these requirements specific to the SIP Servlet specification. This specification relates to other specification in the Java platform namely 'JSR 180 - SIP for J2ME' and 'JSR32 - JSIP'. This specification can be viewed as the server-side container model to handle SIP requests coming from client devices, such as clients developed by JSR180 - SIP for J2ME or JSR32 - JSIP. This specification may also be developed as a server side container on top of JSR32, which exposes a direct interface to the SIP protocol for either client or server development.

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

SIP Servlet implementations are SIP Containers that can be implemented on the Java Standard Edition or Java Enterprise runtime, they can interact and share state with HTTP Servlets in order to develop converged communication services that need to plug-in to the web tier.

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

javax.servlet.sip

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

No

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

No

2.11 Are there any internationalization or localization issues?

No

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

This specification will evolve 'JSR 116 - SIP Servlet v1.0', this specification may also provide suggested feedback for the evolution of JSR32 - JSIP.

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

Initiation: January 2006.
Early Draft Review: May 2006.
Public Review: August 2006.
Proposed Final Draft: October 2006.
Final Release: December 2006.

NOTE that this information has been updated from this original request.

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

Continuous email communications, with regular telephone conferences and face-to-face meetings as required.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The specification lead will maintain an interest alias for JCP members outside of the Expert Group. The specification lead will publish periodic milestone drafts and status to this list. The Expert Group may also use the list to request feedback on key issues facing the group. The specification lead will on a quarterly basis provide a brief JSR status to the JCP PMO, for publication to the Java community. This will include the current schedule for the JSR and notes on any major events that have occurred in the previous quarter.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI and TCK will be delivered stand-alone, as was SIP Servlet v1.0. The RI and TCK will be built upon the SIP Servlet v1.0 RI and TCK.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

Not Applicable.

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

The specification will be licensed under a standard Community Source License. The TCK will be licensed under a standard Community Source License. The TCK binaries will be licensed at no charge, with no support. The RI will be licensed under a standard Community Source License. The RI binaries will be licensed at no charge, with no support.

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.

Session Initiation Protocol (SIP), June 2002 - http://www.ietf.org/rfc/rfc3261.txt.
SIP Servlet Specification v1.0 - http://www.jcp.org/en/jsr/detail?id=116.
SIP Servlet mailing list - http://archives.java.sun.com/sipservlet-interest.html.

3.2 Explanation of how these items might be used as a starting point for the work.

A combination of the enhanced functionality in RFC3261 and other RFC's, the initial version of the SIP Servlet specification and archived discussions over the SIP Servlet mailing list over the past two years all provide sufficient information and ideas as a starting point for this work.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

Not Applicable