 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 304: Mobile Telephony API version 2
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: This JSR extends the interfaces defined in JSR253 (Mobile Telephony API) to cover additional use cases and features not covered in that JSR. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Dormant The following information has been updated from the original JSR: 2009.05.15: Maintenance Lead: Brian Deuser E-Mail Address: brian.deuser Telephone Number: - Fax Number: - 2009.02.03: Specification Lead: Mike Milikich, Motorola E-Mail Address: mike.milikich Telephone Number: +1 512 996 4216 Fax Number: +1 512 895 3798 2007.10.04:- Expert Group formation: Q3 2006 - Early Draft Review: Q2 2007 --> Q2 2008 - Public Review: Q4 2007 --> Q3 2008 - Proposed Final Draft: Q1 2008 --> Q1 2009 - Final Approval Ballot: Q2 2008 --> Q2 2009 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. Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: BenQ Corporation Name of Contact Person: Jens Paetzold E-Mail Address: jens.paetzold Telephone Number: +49 89 4111 4177 Fax Number: +49 89 4111 3782 Specification Lead: Jens Paetzold, BenQ Corporation E-Mail Address: jens.paetzold Telephone Number: +49 89 4111 4177, +1 847 523 8865 Fax Number: +49 89 4111 3782, +1 847 523 4713 Initial Expert Group Membership: - BenQ Corporation Supporting this JSR: - BenQ Corporation Section 2: Request
2.1 Please describe the proposed Specification:This JSR will describe telephony connection enhancements to extend the API?s defined in JSR253 (MTA) to cover additional functionality which were not included in that initial version. Examples of these capabilities include a mapping for use in Voice/Video over IP based protocols, methods to obtain telephony related device settings (device management specific), and control of the media stream associated with a session. Additional interfaces, as well as mappings to new protocols will be defined. Specific functionality which is being considered for inclusion in this version of the interface includes:
- Control over parameter negotiation related to a call, such as selecting a voice codec to be used for the session. Some use cases include getting the capabilities for media sessions in the terminal (support for voice, video, VoIP, etc.), setting audio/video parameters (codec, resolution, etc) for a call session, etc. - Supplemental services not covered by MTA1, such as the user-user supplemental service and multicall; - Interfaces to modify how the platform handles incoming calls, such as suppressing platform generated ringtones for compliance or overwriting of the platform profile settings; - API mapping annex for Voice/Video over IP based services, for example in establishing a call session using these services. This annex would indicate how JSR-253 interfaces should be implemented over JSR-281. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)JME. The MTA2 interfaces will be based on the JME Connected Limited Device Configuration (CLDC 1.1), or the JME Connected Device Configuration (CDC 1.1). In terms of profiles, MIDP 2.0 will be required by MTA2 for the MID profile, a similar environment will be expected in non-MID configurations. It is expected that MTA2 will often be used in conjunction with MIDP 2.0. This specification will include recommended practices for the implementation of specific features as they relate to mobility, such as the security framework under the profile above. This specification will also include recommended practices for the implementation of the interfaces on CDC 1.1, including the security framework model. 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.The target platform is the MID Profile on JME. 2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?This JSR provides some useful, but lower priority controls over telephony communication, such as call management (call types, call states, services, etc). As more types of calls are supported in mobile devices, such as video calls, or calls with multiple possible media formats, applications will desire to take advantage of these new features, including generic support for different underlying network technologies (CS, PS, etc.). These were not included in the first version of Mobile Telephony API (JSR 253). The key focus of MTA remains to provide a single interface for call control independent of the underlying telephony protocols. Applications built to use MTA can be reused on platforms with GSM, CDMA, UMTS and (with the work in this version) SIP based protocols. While interfaces may be defined for voice telephony control that are specific to SIP based telephony (such as JSR-281), the use of MTA as a common interface enables greater reuse across device implementations. 2.6 Why isn't this need met by existing specifications?JSR 253 did not include some technologies such as VoIP, as the requirements were not well understood at the time. Media controls could not be adequately developed in the time of the JSR253 schedule, and were chosen to be delayed. 2.7 Please give a short description of the underlying technology or technologies:The Mobile Telephony API makes use of underlying network protocols (GSM, CDMA, UMTS). These extensions to the MTA will include other Internet Protocol based protocols such as IMS and other proprietary IP based protocols. In cases where there is an existing JSR (such as JSR-281 for IMS) the specification describes how to maintain compatibility with the MTA interfaces, while using the capabilities of that other JSR. This JSR has a strong relationship to the Network Mobility and Mobile Data JSR. The view of the relationship of the two is that the Mobility/Data API provides methods to identify what networks/protocols are available, to set preferences for how the device selects networks and transports for servicing features(Mobility) and provides session control for data services(Data). MTA2 provides session control for voice and video telephony services. In situations where devices contain both MTA 2.0 and Mobility/Data API, telephony call sessions may be performed over a selection of preferred networks (operators), transports (physical medium such as CDMA/GSM, Bluetooth, WiFi, WiMax, USB, etc.) and services (SIP-based, cellular voice, etc.). Preferred selection of networks and transports can be requested by the application managing the call. One example of such preference can be the choice to use VoIP in precedence over the cellular voice service, assuming that both of these are available and are supported in the device platform. Some areas of this proposed API overlap with work being planned within the JSR-281 expert group for follow-on activity ? particularly definition of interfaces for voice call control when the IMS or SIP protocols are used. There will need to be a meeting between the spec leads for this proposed JSR and the JSR-281 spec leads to continue discussions on how to best coordinate the overlap in this area. The outcome of this will drive some work items in this proposed JSR. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.microedition.telephony.* 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?No 2.13 Please describe the anticipated schedule for the development of this specification.The targeted schedule for the JSR is as follows: 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The Expert Group will conduct its work via weekly conference calls, email lists, and web sites. In addition, periodic face-to-face meetings will be held approximately every 6-8 weeks, and phone conferences as needed for special issues that need to be resolved between meetings. Decisions will be made by technical consensus. The working model of the Expert Group for the development of this JSR will be based on tight cooperation with other expert groups (e.g. Network Mobility and Mobile Data) as far as necessary. 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.Transparency plan: 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.An independent RI and TCK will be produced as a part of this JSR with each being licensed separately. 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).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.These are initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof. The RI and TCK will be licensed separately. The RI and or TCK will be licensed to all interested parties. For the TCK we will charge a one time fee of not more than $50,000 and an annual maintenance fee of approximately $20,000 for a term of not less than three years. The TCK will include both binary environment and source code of the test suite. The maintenance fee will cover limited basic support. For the RI source code we will charge a one time access fee, and an annual maintenance fee. 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.JSR253 will be used as a base for this JSR. 3.2 Explanation of how these items might be used as a starting point for the work.Additional interface classes will be added, incorporating all of the existing JSR253 interface classes. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.
|
||||||||||||||||||||||||||||||||||||
