 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 309: Media Server Control API
Updates to the Java Specification Request (JSR) The following information has been updated from the original JSR:
2013.10.21: Maintenance Leads: Tomas Ericson, Sanjeeva Manvi E-Mail Address: tomas.ericson Telephone Number: -, +91 8025166528 Fax Number: - 2012.10.30: The following Maintenance Lead's contact information has been updated.Maintenance Lead: Tomas Ericson E-Mail Address: tomas.ericson Telephone Number: - Fax Number: - 2008.09.26: 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 to all interested parties by Oracle and Hewlett-Packard, in accordance with JCP JSPA rules. RI It is specification lead's intention to provide a license to use and distribute the RI according to the JSPA2 terms in binary format and for no charge. The RI will implement JSR 309 based on a media control protocol, such as MSCML (RFC 4722) or a protocol specified by the IETF mediactrl group. The RI will use and will require a SIP Servlet container implementation (JSR 116/289). TCK It is specification lead's intention to provide a license to use the TCK, according to the JSPA2 terms, in binary format and for a fair and reasonable charge for the purpose of developing and distributing a compatible implementation of a JSR 309 specification. Final terms may still be refined during the JSR process. RI and TCK Final Terms will be provided along the next phases of the JSR process.
2008.07.09:
2007.11.12: If you would like to be added to the observer alias for this JSR and receive e-mail updates on the progress of the JSR, please send e-mail to the Spec Lead with "Add to observer alias" in the subject line. 2007.09.18: Specification Lead: Tomas Ericson, Marc Brandt E-Mail Address: tomas.ericson Telephone Number: +46 8 506 309 00, +33 4 76 14 10 88 Fax Number: +46 8 506 309 11, +33 4 76 14 30 47 2007.06.19: Initiation: January 2007. Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Hewlett-Packard, BEA Systems Name of Contact Person: Marc Brandt, Phelim O'Doherty E-Mail Address: marc.brandt Telephone Number: +33 4 76 14 10 88, +1 415 402 7340 Fax Number: +33 4 76 14 30 47, +1 415 402 7718 Specification Lead: Mikhail Nekorystnov, Marc Brandt E-Mail Address: mnekorys Telephone Number: +1 415 402 7554, +33 4 76 14 10 88 Fax Number: +1 415 402 7718, +33 4 76 14 30 47 NOTE that this information has been updated from this original proposal. Initial Expert Group Membership: BEA Supporting this JSR: Italtel Section 2: Request
2.1 Please describe the proposed Specification:This JSR defines an API for the generic Media Server Control. Modern IP and SIP based Media Servers are designed to perform various smart functions with media streams. Most of the Media Servers are also designed to act as an MRF (Media Resource Function) in 3G and IMS environments. Typical non-exhaustive functions provided by the Media Server would include IVR, Conferencing, Speech Recognition Services, TTS (text to speech) Services, etc. There are several industry accepted specifications defining Media Server control protocols designed to support interactions between application servers and media servers. Those protocols provide access to Media Server functions. In most cases protocol functions can be abstracted at the business application level to provide common functionality for application developers. This JSR will define an interface that is intended to be the standard API to write multimedia applications and services for both IP and converging networks. This specification work does not intend to specify any aspect of the media server control protocols. For developers, Media Server Control API is intended to provide a standard API for developing and deploying new media rich applications for the Java platform without a prior knowledge of the underlying Media Server Control protocols. Moreover, a Java application that invokes Media Server Control API can use any compliant implementation with any compatible Media Server. Furthermore, developers will be able to implement interoperable applications and services that can run over a variety of protocols with various Media Servers. The central focus of this JSR is to provide an abstracted API for external Media Servers that may be controlled via different protocols from the application server. The proposed API is not protocol specific. Media servers are usually controlled by an Application Server that will have the implementation of the proposed API. API will allow extensions for protocol optional functions or Media Server optional capabilities. Requirements: The initial version of Media Server Control API is targeted to support capabilities such as IVR and Conferencing, both individually and combined within the same session. The API will be designed to handle the fact that different media servers may differ in capabilities. This will require defining packages, profiles or API capability for the application to query the level of support of a media server. This list of requirements is not complete and this will be explored further in the expert group ? for example, additional support could be defined for ASR, TTS, or RTSP-based streaming, etc. 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. It is intended that these requirements be handled and evolve in a consistent manner with media server capabilities, protocol and application related standardization efforts from such standard bodies as IETF, 3GPP or W3C. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The target platforms for Media Server Control API are both the Java Standard Edition and 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. 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 main objective of the proposed specification is to provide the community of developers with an API that allows them to develop a multitude of compliant multimedia applications and services on top of Application Servers for the Java platform that use external Media Server resources. The Media Server Control API will allow the developers to rapidly write and deploy media applications and services without an in depth knowledge of media control protocols. 2.6 Why isn't this need met by existing specifications?The JSR43 JTAPI specification solves call control and media manipulation for embedded telephony systems. There is a need today for an explicit media control API for Application Servers that will take advantage of the newer Media Server capabilities available in the industry today and provide a better abstraction for commonly used application functions. The JSR 21 JCC specification and the JSR 122 JCAT specification were designed as an abstracted call control API that may be implemented on multiple network signaling protocols. Applications that are developed for SIP based Application Servers often take advantage of explicit Media Server functions such as IVR and Conferencing. Existing specifications do not address the necessary interfaces for building applications with Media Server support. For example SIP assumes that applications are developed in a separate layer that is above the SIP dialog layer. Existing specifications rely on telephony call model where the application and signaling are vertically integrated. 2.7 Please give a short description of the underlying technology or technologies:Media Server Control API implementations are primarily a Server based technology that can be implemented on the Java Standard Edition or Java Enterprise Edition runtime. The APIs are used by applications that require an external Media Server control. The proposed API is not protocol specific. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.media.mscontrol 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, there are no new security issues. 2.11 Are there any internationalization or localization issues?No, there are no new localization issues. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.Initiation: January 2007. 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 leads will maintain an interest alias for JCP members outside of the Expert Group. The specification leads 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 leads 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 will be delivered as a standalone API implementation that can be used by an application running on top of SIP Servlet v1.1 RI. The RI will work with an external SIP-based media server emulation which supports required API functionality (mandatory capabilities defined by the JSR versus optional). The TCK will be implemented as a test suite of application use cases that exercise the Media Server Control APIs mandatory capabilities. 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.NOTE that this section has been updated from this original proposal. The specification will be licensed to all interested parties by BEA Systems and Hewlett-Packard, in accordance with JCP JSPA rules. Hewlett-Packard intends to make a binary version of the Reference Implementation, together with the emulated media server, and TCK test cases available on fair and reasonable terms, likely at no cost, but with no right to redistribute them. Terms may be refined during JSR process and will stay fair and reasonable. 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 3.2 Explanation of how these items might be used as a starting point for the work.The proposed API is not protocol specific but it is mostly structured around the features provided through draft IETF protocols, that form the basis for requirements of the Media Server Control API specification. Existing drafts and RFCs from IETF SIP and SIPPING, XCON provide guidance for relationship between SIP call control and Media control. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.
|
