Appendix A. Deploying JSR 180 on MIDP 2.0 Platform


This section provides implementation notes for platform developers deploying the JSR 180 interfaces on a MIDP 2.0 platform. This section addresses features available in a MIDP 2.0 device that can be used to enhance SIP applications.

In particular, this document describes how to:


To send and receive messages (requests/responses) using this API, applications MUST be granted a permission to perform the requested operation. The mechanisms for granting a permission are implementation dependent.

Permissions for Opening Connections

The MIDP 2.0 specification defines a mechanism for granting permissions to use privileged features. This mechanism is based on a policy mechanism enforced in the platform implementation. The following permissions are defined for the JSR 180 functionality, when deployed with a JSR 118 MIDP 2.0 implementation.

To open a connection, a MIDlet suite requires an appropriate permission to access the SIPConnection implementation. If the permission is not granted, then methods MUST throw a SecurityException . The following table indicates the permission that must be granted for each protocol.

Table A.1. Permissions mappings

Permission Protocol sip sips

Note that ideally the permission granted will probably allow all subsequent network connections to be made (open a UDP/TCP/RTP media stream for example). However, this behavior might vary on different platforms.

CDC Security

On top CDC platform the MIDlet suite requires an appropriate permission to access the SIPConnection implementation. The implementations of SIP API on configurations and profiles that use the fine grained security permissions based on security checks MUST include the class javax.microedition.sip.ConnectionProtocolPermission.

The permission check MUST be performed when Connector.Open method is called with protocol scheme sip or sips. If the permission is not granted, then methods MUST throw a SecurityException. If the permission is granted all the actions are allowed thereafter. Below is the program listing for SipProtocolPermission. The SipsProtocolPermission is equal to the SipProtocolPermission expect the name and scheme.

 * This class represents access rights to connections via the sip protocol.
 * SipProtocolPermission consists of a URI string but no actions list. The URI 
 * string specifies a connection target and used protocol 
 * e.g. sip:user@ 
 * The URI is specified in RFC3261 [1] and here it takes general form of:
 * {scheme}:[{target}][{params}]
 * where:
 *	- scheme is SIP scheme supported by the system sip or sips
 *	- target is user network address in form of 
 *    [{user_name}@]{target_host}[:{port}] or {telephone_number}
 * 	- params stands for additional SIP URI parameters like ;transport=udp
 * The SIP URI may contain quote characters. The application can use either 
 * the quote character or it's escaped version (%22), the API implementation 
 * must support both forms.
 * @see in 
 * MIDP 3.0 Specification
public final class SipProtocolPermission extends GCFPermission {

	private static final long serialVersionUID = 1L;
	 * Creates a new SipProtocolPermission instance with the specified URI 
	 * as its name.
	 * @param uri the URI string.
	 * @throws IllegalArgumentException if the uri is malformed
	 * @throws NullPointerException if uri is null
	 * @see Permission#getName()
	public SipProtocolPermission(String uri){}

	 * Returns the protocol scheme of this SipProtocolPermission
	 * @see
	public String getProtocol(){
		return null;

	 * Returns the URI of this SipProtocolPermission
	 * @see
	public String getURI(){
		return null;

	 * Checks if this SipProtocolPermission object implies
	 * the specified permission. 
	 * Method returns true if:
	 *	 - p is an instance of SipProtocolPermission and
	 *	 - p's URI equals this object's URI (Refer to the RFC3261 [1] 
	 *     section 25 how the URIs are constructed.)
	 *  are true and if one or more of following condition is met:
	 * 	  - If this object has a IP address and p's IP address is equal to 
	 * 		this object's IP address.
	 *    - If this object has a wildcard domain (such as *, and 
	 *		p's absolute name (the name with any preceding * removed) ends with 
	 *   	this object's absolute name. For example, * implies 
	 *		*  
	 * 	  - If this object's name equals p's name.  
	 * @param p the permission to check against.
	 * @return true if the specified permission is implied by this object,
	 * false if not.
	public boolean implies(Permission p) {
		return true;

	 * Checks two Permission objects for equality
	 * @return true if obj is a HttpsProtocolPermission and 
	 *  has the same URI string as this SipProtocolPermission object.
	 * @see
	public boolean equals(Object object) {
		return false;

	 * Returns the actions as a String. Since the SipProtocolPermission does 
	 * 	  not have actions, method will always return empty string. 
	 * @return the empty string 
	 * @see
	public String getActions(){
		return "";

	 * Returns the hash code value for this Permission object
	 * @return a hash code value for this object
	 * @see
	public int hashCode() {
		return -1;

JSR180 Push Capabilities and SIP Identity Sharing in MIDP 2.0

MIDP 2.0 defines a mechanism to register a MIDlet when a connection notification event is detected. Once the MIDlet has been launched it performs the same I/O operations it would normally use to open a connection and read and write data. For JSR 180 applications this capability allows the application to be launched if a message arrives either while the MIDlet is not running or while another MIDlet is running.

JSR 180 Push Registration Entry

Push registrations are either defined in the application descriptor or made dynamically at runtime via PushRegistry. The entry for a SIP protocol will include the connection URI string which identifies the scheme and port number of the inbound message connection. The entry also contains a filter field that designates which senders are permitted to send messages that launch the registered MIDlet. An asterisk ("*") and question mark ("?") can be used in the filter field as a wild cards as specified in the MIDP 2.0 specification.

For the SIP protocol, the filter field is matched against the URI of the From field in the received message.

The URI may also have a media feature tag (MIME type of the application) that associates the MIDlet with the SipConnectionNotifier. See definitions here: "Opening new server connection" and "Routing the incoming request". This media feature tag is compared with the tag included in the received request. This funcionality is based on the SIP Working Group specifications RFC3840 [4] and RFC3841 [5].

As a summary SIP PushRegistry may have following kind of entries:

Furthermore, the MIDlet can register dynamically to the Push Registry when opening the connection by passing the same augmented SIP URI to the Connector. Example:

				String midletName = "";
				String serverURI = "sip:5080"; SipConnectionNotifier scn
				= (SipConnectionNotifier);
				PushRegistry.registerConnection(serverURI, midletName,

Following table defines how the system is routing messages to MIDlets when registered in PushRegistry. It should be noticed that the system requires either port number or at least MIME type for the routing decision.

Table A.2. Push registry routing

  Connector SIP URI Request routing and PushRegistry functionality
1 sip:*;type="<MIME_TYPE>"
  • example: sip:;type="application/x-game"

  • share system SIP port (MIDlet does not have to know it)

  • route incoming SIP request with MIME type feature tag to this MIDlet and wake it up.

2 sip:nnnn[;type="<MIME_TYPE>"]
  • example: sip:5080;type="application/x-game"

  • use dedicated port number nnnn

  • route incoming SIP request on port nnnn to this MIDlet and wake it up. If the optional MIME type feature tag is present, route only the requests with the matching tag.

3 sip:
  • URI "sip:" can not be registered in PushRegistry since both the port number and MIME type are unknown.

Unlike the initial push connections defined in MIDP 2.0, the SIP protocol includes an explicit buffering mechanism where messages are held until processed by some application that reads and deletes messages. If a message is delivered to the device and does not pass the specified filter, the message will be deleted by the Application Management Software.

When the application is started in response to a Push request, the application SHOULD read and process all messages that are buffered for it. If an application fails to read and process the messages when started or if starting of the application is denied (for example, by the end user), the platform implementation MAY delete unread messages from the buffer, if it becomes necessary to do so. For example, the platform implementation may delete messages when the buffer becomes full.

Another difference between the JSR180 interface and other protocol handlers in MIDP 2.0, is that JSR180 includes a SipConnectionNotifier which provides asynchronous callbacks when messages become available while the application is running.

Portable JSR180 applications between MIDP1.0 and MIDP2.0

If permitted by the device security policy, a JSR180 application written for a MIDP 1.0 platform will work without any modification on a MIDP 2.0 system. This behavior is defined by the MIDP 2.0 specification of untrusted applications. MIDP 2.0 also supports the concept of trusted applications. For these applications, the device can automatically handle trust decisions based on signed JAR files and a platform-specific policy mechanism that associates specific permissions with the signed application.

The security model also allows for the definition of user-granted permissions on a one-shot, session or blanket authorization. In many cases, the platform-dependent policy for permissions on MIDP 1.0 will be able to be mapped onto the MIDP 2.0 defined permissions. An application designed to work only on a MIDP 2.0 device can use the methods in the PushRegistry class to check if there are active connections (listConnections) or to add or remove registered connections at runtime (registerConnection or unregisterConnection).

An application designed to run portably on MIDP 1.0 or MIDP 2.0 platforms will only use the application descriptor and attributes in the manifest to describe requested permissions and push registration entries. See the MIDP 2.0 specification for details about the MIDlet-Permissions and MIDlet-Push-<n> attributes. On a MIDP 1.0 platforms these properties will be ignored. On a MIDP 2.0 platform, these properties will direct the application management software to perform the necessary checks and registrations when the application is installed and removed from the system.