Topic Keywords: J2ME, Java, Java MIDlet, JSR-205, SMS port addressing

Application Directed MMS:  Send an MMS to a Java app/MIDlet

In the last post, I talked about sending SMS messages to a Java MIDlet running on a phone by using SMS port addressing. This time I want to explain how to send an MMS message to a Java MIDlet running on a phone, using MMS application ID addressing.

SMS port addressing has been part of SMS, as defined by the ETSI GSM 03.40 specifciation, since at least 1998. So when the Java Community defined their Wireless Messaging API in JSR-120, it made sense to use SMS port addressing as a basis for routing SMS messages to specific applications.

When the MMS protocol was originally defined, there were no considerations made for application or port addressing.

But the Java Community clearly saw a need to be able to have MMS messages delivered to MIDlets, as is possible with SMS messages.

JSR-205 defined extensions to the MMS headers that would support application ID addressing. Specifically they defined additional parameters for the “Content-Type:” header of the MMS message which could indication source (reply) and destination application identifiers.

For example:

Content-Type: application/vnd.wap.multipart.related; start=<smil>;

 type=application/smil; Application-ID=destinationApp;

 Reply-To-Application-ID=sourceApp

Meanwhile, the need for application ID addressing was also communicated back to the 3GPP and the Open Mobile Alliance, who are responsible for the actual MMS specifications. But the process of updating these MMS specifications can sometimes be slow. 3GPP introduced Applic-ID headers in TS 23.140 v6.7.0. The Open Mobile Alliance introduced Applic-ID headers in v1.3 of the MMS specification.

The application id (Applic-ID) headers introduced by the 3GPP and OMA are completely different from the application ID addressing extensions defined by JSR-205. This is unfortunate, as it will likely generate considerable confusion and interoperability concerns.

However, in fairness to all parties involved, there are advantages and disadvantages of both definitions. The JSR-205 application ID addressing extensions can be safely implemented on top of any version of MMS, including MMS v1.0, v1.1, v1.2 and v1.3. They do not require an implemenation of a completely new version of the MMS protocol specification.

But, the JSR-205 application ID addressing extensions, while effective, could only support sending and replying to messages. They could not support delivery reports and read reply reports. When the 3GPP and OMA got around to adding application ID addressing support to the MMS protocol, they could not simply adopt the JSR-205 approach, as they likely believed that the inability to support delivery reports and read reply reports was too severe a limitation.

With the full release of NowSMS 2007, we have added support for MMS application ID addressing, implementing support for both JSR-205 and MMS v1.3 (as well as the updated 3GPP TS 23.140 specification).

It is possible to submit an MMS message to NowSMS that includes application ID addressing using any of the following methods:

1.) When sending an MMS message from the NowSMS web form, it is possible to specify the reply (source) and recipient application IDs by making them part of the corresponding sender or recipient phone number. (For example: +44777777777:applicationID)

NowSMS will parse the phone numbers and generate the appropriate JSR-205 and MMS v1.3 headers.

The “phonenumber:applicationID” format is avaialble only for MMS messages being posted via the web interface, or the NowSMS proprietary URL submission format.

2.) When submitting via MM1, it is necessary to use the MMS v1.3 defined “X-Mms-Applic-ID” and “X-Mms-Reply-Applic-ID” binary headers, and/or the “Content-Type” parameters defined by JSR-205.

For example (the following are text examples representations of the binary headers, such as the text headers that would be passed to MMSCOMP):

Message-type: m-send-req

Transaction-id: 501B3E2C

MMS-version: 1.3

From: 5678/TYPE=PLMN

Date: Tue, 19 Jun 2007 18:12:16 GMT

Delivery-report: No

Message-class: Personal

Message-id: 20070619/19/501B3E2C@bigkahuna

Message-size: 634

Priority: normal

Read-reply: No

Subject: MM1 Application ID Test

To: +99999999999/TYPE=PLMN

X-Mms-Applic-ID: destinationApp

X-Mms-Reply-Applic-ID: sourceApp

Content-type: application/vnd.wap.multipart.related; 

 start=<4620d4c5.smil>; type=application/smil;

 Application-ID=destinationApp; Reply-To-Application-ID=sourceApp

Note: When submitting a message via MM1, it is important to note that the JSR-205 “Content-Type” parameters are applied as part fo the binary MMS message headers.

The example above shows a text representation of the MMS message headers. An actual over-the-air MMS message would have these headers encoded in a binary MMS Encapsulation format.

When this binary MMS message is posted to the MMSC, it is done so using HTTP POST, specifying a “Content-Type:” of “application/vnd.wap.mms-message” for the binary MMS message payload of the HTTP POST. The JSR-205 “Content-Type” parameters are encoded inside of the binary MMS message.

Note: If MMSCOMP sees either the JSR-205 “Content-Type” parameters or the “X-Mms-Applic-ID”/”X-Mms-Reply-Applic-ID” headers, it will automatically encode the binary MMS message with application ID values for both headers. However, if the MMSC receives an MM1 submission with just one type of application ID parameters set, the MMSC will forward the resulting message with only that type of application ID parameter set.

3.) When submitting via MM4, use the “X-Mms-Applic-ID” and “X-Mms-Reply-Applic-ID” text headers defined by 3GPP TS 23.140, and/or the “Content-Type” parameters defined by JSR-205. (If NowSMS detects the Application ID parameters being set by either approach, it will automatically apply the Application ID values using both formats in the resulting MMS message.)

For example:

X-Mms-3GPP-MMS-Version: 6.7.0

X-Mms-Message-Type: MM4_forward.REQ

X-Mms-Transaction-ID: "20070619.14.28C55CD2-p99999999999"

X-Mms-Message-ID: "20070619.14.28C55CD2@bigkahuna"

X-Mms-Ack-Request: No

X-Mms-Originator-System: system-user@bigkahuna

Message-ID: <20070619.14.28C55CD2@bigkahuna>

Date: Tue, 19 Jun 2007 14:12:16 -0400

Sender: 5678/TYPE=PLMN@bigkahuna

From: 5678/TYPE=PLMN

To: +99999999999/TYPE=PLMN

X-Mms-Priority: Normal

X-Mms-Delivery-Report: No

X-Mms-Read-Reply: No

X-Mms-Applic-ID: destinationApp

X-Mms-Reply-Applic-ID: sourceApp

Subject: MM4 Application ID Test

Content-Type: multipart/related; start="<4620D4C5.smil>";

 type="application/smil"; Application-ID=destinationApp;

 Reply-To-Application-ID=sourceApp;

 boundary="---mime-boundary-27CFCD10.35835F91---"

-----mime-boundary-27CFCD10.35835F91---

Content-Type: application/smil; name="4620D4C5.smil"; charset=utf-8

Content-ID: <4620D4C5.smil>

Content-location: 4620D4C5.smil

<smil>

<head>

<layout>

<region id="Image" height="100%" width="100%" fit="meet"/>

<region id="Text" height="100%" width="100%" fit="scroll"/>

</layout>

</head>

<body>

<par dur="3s">

<text src="textfile.txt" region="Text"/>

</par>

</body>

</smil>

-----mime-boundary-27CFCD10.35835F91---

Content-Type: text/plain

Content-ID: <textfile.txt>

Content-location: textfile.txt

this is a test

-----mime-boundary-27CFCD10.35835F91-----

4.) When submitting via MM7, use the <ApplicID> and <ReplyApplicID> elements defined by 3GPP TS 23.140, and/or the “Content-Type” parameters defined by JSR-205. (If NowSMS detects the Application ID parameters being set by either approach, it will automatically apply the Application ID values using both formats in the resulting MMS message.)

For example:

POST /mm7 HTTP/1.1

Host: mmsc:8002

SOAPAction: ""

Content-Length: 1973

Content-Type: multipart/related;

 boundary="---mime-boundary-3F95F09C.BE61A41D---";

 type="text/xml"; start="<mm7_msg>"

Connection: close

-----mime-boundary-3F95F09C.BE61A41D---

Content-Type: text/xml; charset=utf-8

Content-ID: <mm7_msg>

<?xml version="1.0" encoding="UTF-8"?>

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

<env:Header>

<TransactionID xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4" env:mustUnderstand="1">

20070619140731-DD9A3699@bigkahuna

</TransactionID>

</env:Header>

<env:Body>

<SubmitReq xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4">

<MM7Version>6.7.0</MM7Version>

<SenderIdentification>

<SenderAddress><ShortCode>1234</ShortCode></SenderAddress>

</SenderIdentification>

<Recipients>

<To><Number>+99999999999</Number></To>

</Recipients>

<DeliveryReport>false</DeliveryReport>

<ReadReply>false</ReadReply>

<Priority>Normal</Priority>

<Subject>MM7 Application ID Test</Subject>

<ApplicID>destinationApp</ApplicID>

<ReplyApplicID>sourceApp</ReplyApplicID>

<Content href="cid:mms_cid" />

</SubmitReq>

</env:Body>

</env:Envelope>

-----mime-boundary-3F95F09C.BE61A41D---

Content-Type: multipart/related; start="<4620D4BD.smil>"; type="application/smil";

 Application-ID=destinationApp;

 Reply-To-Application-ID=sourceApp;

 boundary="---mime-boundary-B61FC9DA.135BD7DB---"

Content-ID: <mms_cid>

-----mime-boundary-B61FC9DA.135BD7DB---

Content-Type: application/smil; name="4620D4BD.smil"; charset=utf-8

Content-ID: <4620D4BD.smil>

Content-location: 4620D4BD.smil

<smil>

<head>

<layout>

<region id="Image" height="100%" width="100%" fit="meet"/>

<region id="Text" height="100%" width="100%" fit="scroll"/>

</layout>

</head>

<body>

<par dur="3s">

<text src="textfile.txt" region="Text"/>

</par>

</body>

</smil>

-----mime-boundary-B61FC9DA.135BD7DB---

Content-Type: text/plain

Content-ID: <textfile.txt>

Content-location: textfile.txt

this is a test

-----mime-boundary-B61FC9DA.135BD7DB-----

-----mime-boundary-3F95F09C.BE61A41D-----

Note: The MMS v1.3 “Applic-ID” headers will only be delivered to an MMS v1.3 client. When deployed in an operator MMSC configuration (direct MMS delivery), NowSMS tracks the MMS version number implementation of each client account. The JSR-205 parameters will be delivered to all MMS clients.

Similarly, if posting to an operator MMSC, MMS v1.3 headers are only sent if the version number of the connection supports them. NowSMS 2007 allows an MMS version number to be associated with MM1 and MM7 connection types. (MM1 connections must be defined as “MMS Version: 1.3”. MM7 connections must use the “REL-6-MM7-1-4” or later schema.) MM4 connections will receive MMS v1.3 headers if they are present, as servers supporting earlier versions should ignore these headers as extra SMTP layer headers.

If you are routing MMS messages for delivery via an operator MMSC, you will need to test to see if the operator MMSC supports the application ID headers, as some operator MMSCs might not support the JSR-205 application ID headers. In particular, there may be interoperability issues when sending MMS messages across an interoperator connection.

-bn