• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Specification Leads
	Jean-Yves Bitterlich	Oracle
	Brian Deuser	Motorola
Expert Group
	Andreani, Stefano	Cingular Wireless	Ericsson AB
	Esmertec AG	Gemalto	Intel Corp.
	Motorola	Nokia Corporation	Oracle
	Orange France SA	Philips Electronics UK Ltd	SavaJe Technologies
	Sharp Corporation	Siemens AG	Sony Ericsson Mobile Communications AB
	Sun Microsystems, Inc.	Symbian Ltd	Vodafone Group Services Limited

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2009.07.06: Sun Microsystems has become co-Maintenance Lead.

Specification Lead: Jean-Yves Bitterlich

E-Mail Address: jean-yves.bitterlich@sun.com

Telephone Number: +49 89 46008 1097

Fax Number: -

Maintenance Lead: Brian Deuser

E-Mail Address: brian.deuser@motorola.com

Telephone Number: -

Fax Number: -

2008.05.21: Specification Lead: Eric Overtoom - Motorola.

2007.04.11: Jim Lee is the current temporarily acting co-Spec Lead.

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

Expert Group formation: September 2004
Early Draft: January 2005
Public Draft: March 2005
Proposed Final Draft: End of September - beginning of October 2005
Final Approval Ballot: November 2005

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Siemens, Motorola

Name of Contact Person: Jan Eichholz, Dr. James E. Van Peursem

E-Mail Address: jan.eichholz@siemens.com, jim.van.peursem@motorola.com

Telephone Number: +49 89 722 21405, +1 847 523 8865

Fax Number: +49 89 722 53164, +1 847 523 4713

Specification Lead: Ekaterina Chtcherbina, Eric Overtoom

E-Mail Address: Ekaterina.Chtcherbina@siemens.com, Eric.Overtoom@motorola.com

Telephone Number: +49 89 722 21405, +1 847 523 8865

Fax Number: +49 89 722 53164, +1 847 523 4713

Initial Expert Group Membership:

TBD

Supporting this JSR:

Nokia
Vodafone
Sun Microsystems

Section 2: Request

2.1 Please describe the proposed Specification:

Mobile Telephony API (MTA) defines a set of functions for controlling calls and using network services suitable for Java applications written for J2ME devices. An example of Java application that uses MTA can be conference application, scheduled calls, or voice services. The MTA must be suited to small devices in terms of functionality and processing. Existing APIs such as JTAPI and JAIN JCC do not suit these requirements.

It is not intended to model the whole telephony network, nor is it necessarily intended to expose every telephony feature available in every wireless network. The goal is to define a portable API basis that exposes common telephony features available in most wireless handsets. The design targets extensibility such that unique features available in some networks can be made available as option packages. <>

The MTA supports call and supplementary services handling as well as access to the call-related parameters that are required for call management. The interface is an abstraction of the underlying protocols (GSM, CDMA, or UMTS), therefore call and call-related functions must be generalized in order to be applicable independent of the network protocol. The API does not deal with any service functionality and call control on the operator side. The API neither deals with user interfaces nor any presentation issues.
The Mobile Telephony API allows java applications to access call-related functionality such as:

- Initiate voice and emergency calls
- Receive/accept an incoming call
- Control and end an existing call
- Receive event notifications of call state changes
- Receive event notifications of network state changes (e.g. roaming to a different network)
- Access network information such as Network ID and "Network Selection Modes"
- Use supplementary services such as multiparty calls, and call forwarding
- Get status information about supplementary services
- Activate/deactivate supplementary services
- Send/receive Unstructured Supplementary Service Data
- Manage call-related phone and user parameters such as "Phone Identity Presentation Restriction" or "User Group"

The resulting APIs will be suitable on both the CLDC and CDC platforms.

This JSR does not define mapping of the Mobile Telephony API to underlying protocols and does not deal with any protocol details. The choice of the underlying protocol to use is a responsibility of the API implementation.

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

J2ME - both CLDC and CDC

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 targets are the CLDC and CDC platforms within J2ME. There is no direct relationship to other platform editions

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?

Call Control (for example dial, receive, transfer calls) as well as possibility to use supplementary and unstructured services for mobile wireless devices

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

There is currently no API for controlling calls and network services that would not be too large to be implemented on terminals with limited resources. That is why a new set of APIs must be designed.

JSR-118 (MIDP2) includes a simple API called platformRequest() through which a MIDlet can request that the platform originate a phone call. However, the model of this API is for the platform to present the call to the user through the resident "phone" application. There is no concept of the MIDlet interacting with the call other than the originating request. Likewise there is no way to receive calls, no access to network information, etc.

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 and other wireless networks).

This JSR is suitable for mobile devices that have wireless telephony support and have either a CLDC or CDC based J2ME platform.

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. The API must be generic and independent of transport level protocols or operating systems

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

No. The platform that this API is implemented on, needs to have a security framework that can be used to enforce the appropriate policy. Defining the security framework is out of the scope for this JSR. For example, the MIDP 2.0 security framework can be used.

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.

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

Expert Group formation: September 2004
Early Draft: January 2005
Public Draft: March 2005
Proposed Final Draft: May 2005
Final Approval Ballot: September 2005

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

This group will conduct its work similar to other expert groups, utilizing email lists, frequent telephone conferences, and face-to-face meetings approximately every 6-8 weeks. Decisions will be made by technical consensus of the EG members.

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.

- Provide an interim version of the specification to the community at least once a month
- Publish meeting minutes and open issues in the JSR observer alias
- Put news and opening a mailing list if necessary
- Maintain an Observer interest list for JCP members outside of the Expert Group (EG). Observers may follow the progress of the JSR by the periodic short briefs about the progress of the remaining open issues and specification drafts created by this JSR, as will be decided by the Expert Group. However, Observers will not be entitled to participate in the Expert Group meetings (face-to-face or telephone conferences). The Expert Group may also use the list to request feedback on key issues facing the group.
- Provide on a quarterly basis 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 licensed separately, as stand-alone optional packages for the J2ME platform.

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.

RI and TCK will be licensed to all interested parties, TCK and RI will be licensed separately.

For TCK we plan to introduce a single one time fee of max $50,000 and annual maintenance fee of max $20,000 for a term of four years. TCK will include both binary environment and source code of the test suite. Maintenance fee covers limited basic support. Major new releases (esp. from new follower JSR) might be subject to additional single one time fee.

For the RI source code we will charge one time access fee, and 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.

This JSR will expose telephony features specified by other standards including but not limited to 3GPP: http://www.3gpp.org/specs/specs.htm

Other standards: JSR 118: http://jcp.org/aboutJava/communityprocess/final/jsr118

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

The telephony standards will be used for general reference purposes and descriptions of telephony capabilities available in wireless devices. The API supports in a smart form call-related functionality that is available in GSM, UMTS, CDMA and other wireless network protocols

The security framework of JSR 118 will be used.