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.
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 Connector.open methods MUST throw a SecurityException. The following table indicates the permission that must be granted for each protocol.
|
Permission |
Protocol |
|---|---|
javax.microedition.io.Connector.sip |
sip |
javax.microedition.io.Connector.sips |
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.
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.
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 = "com.company.sip.SIPExample2";
String serverURI = "sip:5080";
SipConnectionNotifier scn = (SipConnectionNotifier) Connector.open(sURI);
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.
| 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.
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.