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.

Note: At the time of this posting, NowSMS 2007 is not yet officially released. A pre-release version is available for download at http://www.nowsms.com/download/nowsms2007.zip.

-bn

Send an SMS to a Java app/MIDlet

It's a common task, but a confusing one. As Java becomes more widely supported on mobile phones, one of the most obvious application needs is the ability to send SMS messages to an application and have the application take some action based upon the content of the SMS message.

However, while J2ME will let an application receive messages, it will not let the MIDlet interact directly with the phone's SMS inbox. Instead, applications only receive messages that were addressed to their specific port number.

From within your MIDlet, it is relatively easy to send an SMS message to a particular port, because you just include the port number in the recipient address (sms://phonenumber:port).

However, it is not so easy (or in many cases even possible) to send an SMS message to a specific port from a conventional SMS client.

We've supported a relatively easy (if obscure) way of sending an SMS message to a specific port in NowSMS since early 2004.

With the full NowSMS 2007 release, it's going to be easier, as the "Send Text Message" web form will now include a "Destination Port" field. Alternatively, when submitting via a URL request, include "&DestPort=xxxx" or "&SourcePort=xxxx" in the URL request to specify a destination and/or source port. Or, the destination port can be specified in the recipient phone number using the format phonenumber:port. (Note: When using the phonenumber:port format, if multiple recipients are specified, the same destination port will be applied for all recipients, that being the first destination port encountered in the recipient list.)

But it is still relatively easy to send an SMS message to a specific port when using current versions of NowSMS.

From the web form, use the "Send Binary Message Other" form, specify a user data header (UDH) of: 060504xxxxyyyy Where xxxx is the destination port in hex, and yyyy is the source port in hex. (If the source port is not important, replace it with 0's.) In the "Binary Data" field, put in your text, and leave the DCS as 0. (If you want to send binary data, put the hex string for the binary data in the "Binary Data" field, and use a binary DCS value such as 4.)

If you are posting via direct URL submission, specify the user data header using the parameter "&UDH=060504xxxxxxxx", and submit the text as you normally would using the "&Text=" parameter.

For example:

http://serverip:port/?phone=phonenum&udh=06050433330000&text=this+is+a+test

The above example sends a message to port 3333 (hex value, decimal value = 13107). The source port in this example is 0.

The text of the message is "this is a test", it has just been URL escaped for encoding in a URL.