Sending MMS Messages with NowSMS

Posted by on Feb 17, 2009 in Support Blog

Topic Keywords: , , , , ,

Once you have succesfully configured NowSMS so that it is possible to send MMS messages via the web interface, you may want to explore APIs for sending MMS messages programmatically.

The NowSMS APIs for sending MMS messages are based upon either the HTTP or SMTP protocols. However, before we go into details about these protocols, there may be an easy way to interface with NowSMS without learning the details of these protocols.

If you work with PHP, there is an example PHP script for sending MMS messages that is described at the following link: http://www.nowsms.com/nowsms-php-example-send-mms-message.

If you work with Java or JSP, there is a Java class for sending MMS messages that is described at the following link: http://www.nowsms.com/nowsms-java-example-send-mms-message

There is also a command-line interface for Windows environments which allows you to send MMS messages by spawning a command line script from your application. Details of this script can be found at the following link: http://www.nowsms.com/sending-mms-from-the-command-line

.NET examples are available for VB.NET in the article Send MMS from VB .NET and C# in Send MMS from C# .NET.

Applications can submit MMS messages to the Now SMS & MMS Gateway via any of the following protocols, which we will describe in more detail below:

Now SMS & MMS Proprietary URL Submission via HTTP GET or POST.

MM7 – The MMS standard for applications to submit MMS messages to an MMSC. MM7 is an XML/SOAP based API where the MMS message is formatted in a MIME encoded XML document and posted to the server using an HTTP POST.

MM4 – The MMS standard for connectivity between multiple MMSCs. MM4 is an SMTP based interface where the MMS message is posted to the server as a standard MIME encoded e-mail message. While the interface exists primarily for connectivity between multiple MMSCs, the Now SMS & MMS Gateway also makes this interface available to application developers that are more comfortable with the SMTP protocol.

MM1 – The MMS standard for phones to send and receive MMS messages from an MMSC. This is an HTTP based protocol where applications can submit binary encoded MMS messages encoding according to the MMS Encapsulation Specification (application/vnd.wap.mms-message MIME type) to the gateway using HTTP POST.

EAIF – This is a Nokia proprietary variation on the MM1 protocol which was defined as an interface for submitting messages to a Nokia MMSC. The interface is functionally similar to MM1, with additional HTTP headers defined.

Now SMS & MMS Proprietary URL Submission

The Now SMS & MMS Proprietary format for submission of an MMS message is the interface that is used by the “Send MMS Message” form in the web menu interface of the gateway. It is also the interface that is used by the PHP and command line scripts that we referenced at the beginning of this article.

To submit a message via this interface, a user account must be specified on the “SMS Users” configuration dialog.

To submit it the same way that the “Send MMS Message” form does in the gateway’s web menu interface, you need to do an HTTP POST in the “multipart/form-data” MIME type.

Basically, when you POST, it would look something like this:

POST / HTTP/1.0
Accept: */*
Content-type: multipart/form-data; boundary=”–boundary-border–”
Content-length: xxxxx (size of content part of post)
Authorization: username:password (base64 encoded)

—-boundary-border–
Content-Disposition: form-data; name=“PhoneNumber”

+44777777777
—-boundary-border–
Content-Disposition: form-data; name=”MMSFrom”

sender@domain (or +44777777777)
—-boundary-border–
Content-Disposition: form-data; name=”MMSSubject”

Message Subject
—-boundary-border–
Content-Disposition: form-data; name=”MMSText”

An optional text part of the message.
—-boundary-border–
Content-Disposition: form-data; name=”MMSFile”; filename=”original-filename.ext”
Content-type: Mime/Type

File data goes here
—-boundary-border—-

The content-type for the overall message is “multipart/form-data”. As with other multipart MIME encoding, you must include a boundary that separates the multiple parts of the message.

It is very important to set the Content-length: field to specify the length of the multipart content that follows (this is how the server knows your HTTP post is complete).

The Authorization header specifies the username and password used to login to the gateway. It is in the format “username:password” and is Base64 encoded.

Next, the content has a part for each form variable.

The “PhoneNumber” variable is required, it is the phone number of the message recipient.

The “MMSFrom” variable is optional. It is the “From:” address to be used in the MMS message.

The “MMSSubject” variable is optional. It is the “Subject” line used in the MMS message.

The “MMSText” variable is optional. It contains a text part of the message.

The “MMSFile” variable is optional, and can be repeated multiple times. It contains binary file content for an uploaded file.

As an alternative to using the HTTP POST, if the content of the MMS message already exists on a web server, the “MMSFile” variable can be specified as a URL instead of the actual file content. In this case, the message can be submitted to the gateway with an HTTP GET request, instead of requiring HTTP POST. For example:

http://127.0.0.1:8800/?PhoneNumber=xxxxxx&MMSFrom=sender@domain&MMSSubject=Message+Subject&MMSText=An+optional+text+part+of+the+message&MMSFile=http://www.nowsms.com/media/logo.gif

The variables are the same as described above, except that in a GET request, the “MMSFile” variable must point to a URL. As with the POST request, the “MMSFile” variable can be repeated to specify multiple content files.

Note: If authentication is enabled for the web interface, any application submitting a message must supply a user name and password for access. This user name and password refers to an account defined on the “SMS Users” configuration dialog. The application can either include the user name and password in an “Authorization:” header using “HTTP Basic Authentication”, or it can include “&User=xxxx&Password=xxxx” parameters within the URL request.

There are additional parameters that are avaialble when submitting an MMS message. The following is an incomplete list of additional parameters available via this interface:

“MMSDeliveryReport” – “Delivery Report” specifies whether or not a delivery report is requested for the message. Set to “Yes” to request a delivery report. Note that any delivery report would be directed back to the phone number or e-mail address specified in the “MMSFrom” address.

“MMSReadReport” – “Read Report” specifies whether or not a read receipt is requested for the message. Note that the receiving client may choose not to send a read receipt. Any read receipt report would be directed back to the phone number or e-mail address specified in the “MMSFrom” address.

“MMSPriority” – “Priority” is a user defined priority to be associated with the message. Generally, any priority definition associated with the message is ignored by the underlying transport, but the receiving client may decide to display messages differently based upon this priority setting.

“MMSMessageClass” – “Message Class” is an attribute defined in the MMS specifications. “Personal” is the message type that is used for standard user-to-user communications. Other defined message classes that are supported by this parameter include: “Informational” and “Advertisement”.

“MMSWAPPush” – Set to “Yes” to indicate that the message being sent should be sent as an “Multimedia WAP Push” message instead of as an MMS message.

It is also possible to specify forward locking and DRM constraints to be applied against the content of the MMS message. Forward locking and DRM constraints apply to non-text parts of the MMS message (i.e., in a forward locked message, text could still be forwarded, but images or video could not). Please note that not all devices support forward locking and DRM constraints, therefore use these parameter settings only after testing thoroughly with mobile phones used by your message recipients.

“MMSForwardLock” – Forward locking is the most basic level of DRM (Digital Rights Management). When “Forward Lock” is set to “Yes”, this indicates that the receiving device should not allow any non-text objects in the message to be forwarded off of the device. The device may allow the user to extract pictures, videos or sounds from the message and save them on the phone. However, any such objects remain forward locked, such that they cannot be forwarded to another user or transferred to another device. (IMPORTANT NOTE: NOT ALL DEVICES SUPPORT FORWARD LOCK, WHEN NOT SUPPORTED THE CONTENT WILL APPEAR AS GARBAGE OR MAY BE REJECTED BY THE OPERATOR MMSC.)

“DRMRestrict” – Beyond forward locking, More advanced DRM (Digital Rights Management) restrictions can be applied to limit the number of times that the user can access an object, or start and end dates can be specified to limit how long the user can access an object.These advanced DRM restrictions can be applied by setting “DRMRestrict” to “Yes”. When this setting is enabled, forward lock is also implied, and the value of the “MMSForwardLock” setting is ignored. (IMPORTANT NOTE: NOT ALL DEVICES SUPPORT DRM RESTRICTIONS, WHEN NOT SUPPORTED THE CONTENT WILL APPEAR AS GARBAGE OR MAY BE REJECTED BY THE OPERATOR MMSC.)

“DRMRestrictTextXML”“Yes” specifies that the rights object should be encoded in text XML format. “No” specfies that the rights object should be encoded in binary XML format. The default is “No”.

When DRM Restrictions are specfied, it is generally necessary to specify one or more DRM Permissions and one or more DRM Constraints regarding the MMS message content.

DRM Permissions specify what types of access are allowed against the objects in a message that is protected with DRM.

For example, an audio or video object requires “Play” permission before the user can access it. An image requires “Display” permission before the user can access it, and it requires “Print” permission if the user is to be allowed to print the image to a printer , perhaps over Bluetooth. An application requires “Execute” permission before the user can make use of the application. In all cases, the forward locking is assumed, so that the user is not allowed to forward or transfer the object from the device.If you are sending multiple types of objects in the MMS message, specify all permissions that are required for the different types of objects that are being sent.

“DRMPermissionPlay” – Set to “Yes” to enable DRM “Play” Permission.

“DRMPermissionDisplay” – Set to “Yes” to enable DRM “Display” Permission.

“DRMPermissionExecute” – Set to “Yes” to enable DRM “Execute” Permission.

“DRMPermissionPrint” – Set to “Yes” to enable DRM “Print” Permission.

DRM Constraints specify constraints with regard to how long a DRM protected object object should remain accessible to the user.

“DRMConstraintCount” – “# of Accesses (count)” specifies the the user can only access the DRM protected object this number of times before access is no longer allowed.

“DRMConstraintStart” – “Start Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the DRM protected object until on or after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2008-12-24.)

“DRMConstraintEnd” – “End Date (yyyy-mm-dd)” specifies that the user will not be allowed to access the DRM protected object after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2008-02-24.)

“DRMConstraintInterval” – “# of Days (interval)” specifies that the user will be allowed to access the DRM protected object for this number of days after initial receipt of the object. The user can either enter a number of days here, or they can enter any valid value defined for the “” element in the OMA DRM Rights Expression Language specification. For example, P2Y10M15DT10H30M20S represents a duration of 2 years, 10 months, 15 days, 10 hours, 30 minutes and 20 seconds.

MM7

Before submitting a message via MM7, a VASP (Value Added Service Provider) account must be defined to the Now SMS & MMS Gateway. This account is defined on the “MMSC VASP” configuration dialog.

To post to the Now SMS & MMS Gateway via MM7, you must connect to the HTTP port configured for the MMSC on the “MMSC” configuration dialog. And you must perform an HTTP POST of the MM7 content to a URI of “/mm7”, which is how the gateway knows that the VASP intends to submit in the MM7 format.

Optionally the URI can include the account name and password of the “MMSC VASP” using the format “/mm7/account=password”.

The HTTP headers of your POST must include a “Content-length:” header.

If the VASP account name is not included in the URI, the request must either include an “Authorization:” header for Basic authentication using the account name and password configured for the account, or it must originate from an IP address that matches the name configured for the VASP account. (If your software cannot generate an “Authorization:” header, it is possible to configure the account name for the VASP as an IP address, and in this case, the MMSC will recognise any connections from that IP address as being for this VASP account.)

The “Content-type:” header in the POST should be one of the “multipart” types (usually “multipart/related”), and should include a “boundary=” parameter that delimits the different parts of the message.

The first part of the multipart message is expected to be the XML for the MM7 request, and we’re going to expect to see a section with at least one , or recipient specified.

The second part of the multipart message is expected to be the content for the MMS message, and this in turn will usually be another MIME multipart structure.

The following example is adapted from the official MM7 specification that is included in the 3GPP TS 23.140 specification:

Note that this example does not include a SMIL file, and as part of the MMS content, you would probably want to include a SMIL file (application/smil), which this example does not include.

Also note that the MM7 XML portion of the document (the first part of the main multipart content) should not use any Content-Transfer-Encoding, it should always be expressed without any encoding. For the portion of the document that includes the MMS content itself, you can use Content-Transfer-Encoding of either quoted-printable or base64, or no encoding can be specified in which case it is assumed that the binary data is to be included as is.


POST /mm7 HTTP/1.1
Host: mms.omms.com
Content-Type: multipart/related; boundary=”NextPart_000_0028_01C19839.84698430″; type=text/xml; start=”</tnn-200102/mm7-submit>”
Content-Length: nnnn
SOAPAction: “”

–NextPart_000_0028_01C19839.84698430
Content-Type:text/xml; charset=”utf-8″
Content-ID: </tnn-200102/mm7-submit>

<?xml version=”1.0″ ?>
<env:Envelope xmlns:env=”http://schemas.xmlsoap.org/soap/envelope/”>
<env:Header>
<mm7:TransactionID xmlns:mm7=”http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-M M7-1-3″ env:mustUnderstand=”1″>
vas00001-sub
</mm7:TransactionID>
</env:Header>
<env:Body>
<SubmitReq xmlns=”http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-3″>
<MM7Version>5.6.0</MM7Version>
<SenderIdentification>
<VASPID>TNN</VASPID>
<VASID>News</VASID>
</SenderIdentification>
<Recipients>
<To>
<Number>7255441234</Number>
</To>
<Cc>
<Number>7255443333</Number>
</Cc>
<Bcc>
<RFC2822Address>7255444444@OMMS.com</RFC2822Address>
</Bcc>
</Recipients>
<ServiceCode>gold-sp33-im42</ServiceCode>
<LinkedID>mms00016666</LinkedID>
<MessageClass>Informational</MessageClass>
<TimeStamp>2002-01-02T09:30:47-05:00</TimeStamp>
<EarliestDeliveryTime>2002-01-02T09:30:47-05:00</EarliestDeliveryTime>
<ExpiryDate>P90D</ExpiryDate>
<DeliveryReport>true</DeliveryReport>
<Priority>Normal</Priority>
<Subject>News for today</Subject>
<ChargedParty>Sender</ChargedParty>
<DistributionIndicator>true</DistributionIndicator>
<Content href=”cid:SaturnPics-01020930@news.tnn.com” allowAdaptations=”true”/>
</SubmitReq>
</env:Body>
</env:Envelope>
–NextPart_000_0028_01C19839.84698430
Content-Type: multipart/mixed; boundary=”StoryParts-74526-8432-2002-77645″
Content-ID:SaturnPics-01020930@news.tnn.com

–StoryParts-74526-8432-2002-77645
Content-Type: text/plain; charset=”us-ascii”

Science news, new Saturn pictures…
–StoryParts-74526-8432-2002-77645
Content-Type: image/gif
Content-ID:<saturn.gif>
Content-Transfer-Encoding: base64

R0lGODlhSAAcAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/
/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm
AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/
MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm
ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/
mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm
zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/
/5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ
AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA
M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ
ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A
mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z
zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAABIABwA
AAj/AP8JHEiwoMGDCBMqXMiwocOF1A5GNDjxoUWJ/1Bo3LhxSkeODCtedFiRmsZ/JQ1yXBmxJcqR
MAlOcXiSoEaPM2PqzIhCoMiDNV0K7Lnxpc+dDHs+rKlyaFGkDZUW/OnzZMqhRjdShWrzIsimNp8q
vKpypdmzGluebYpWKtmBFT+azUiX6M2zONty9Ig2JM++egMLFvw3YUS7Hf+uzDsYBd+Pj/fO5UuQ
WlynRecqbsy5McKekdcO7Py4tFzHgyuPTr26s2vCBQPnbW26cWizHjFrfnla7+bXgw/7vnwXN2rJ
RXHyrH28bc7MiD8jBh69d2C6JkFKfSkSde6BOQs+X/9efHHv5ccxFzb827pm6NpPuseqm6lCsV2p
1a7Ls3/b+60pRRVZPU1kFWD/bXeUUHDRVdVRSxWXkFSUfQWThSNlh8JW9GUUWoMxMchVWfThN+JD
KXHIm3z2IaWiQAEBADs=
–StoryParts 74526-8432-2002-77645–
–NextPart_000_0028_01C19839.84698430–

This is just a quick example of an MM7 connection to help you get started.

Note that in the above example, the binary data for the image has been base64 encoded. This is not necessary when submitting MMS messages to NowSMS using MM7. The standard 8-bit binary data can be included in the MIME object without encoding.

For full details of the MM7 protocol, please refer to the 3GPP TS 23.140 specification, which can be found at http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/. 23140-530.zip is a good version to start with, as it is what we consider to be the first “stable” definition of MM7, which is Release 5, Version 1.2.

MM4/SMTP

Before submitting a message via MM4, a VASP (Value Added Service Provider) account must be defined to the Now SMS & MMS Gateway. This account is defined on the “MMSC VASP” configuration dialog.

To post to the NowSMS MMSC via MM4, your application is making an SMTP connection to the MMSC, and you would connect to the “SMTP Port Number” that is configured on the “MMSC” configuration dialog.

To submit a message via MM4, the VASP must authenticate via SMTP using the “AUTH LOGIN” approach, or similar to the way it works for MM7, the VASP account can be created with an IP address as the “Account Name”, and in that case any connection from that IP will be accepted as being a connection from that VASP account.

“AUTH LOGIN” is rather simple. Basically, as part of the SMTP dialog, after the initial HELO or EHLO command, the SMTP client needs to issue the command AUTH LOGIN. The SMTP server responds with a “300” series code and prompts for the account name (the prompt after the code is a BASE64 encoded string). The client sends the account name as a BASE64 encoded string. The SMTP server responds with another “300” series code prompting for the password, and the client responds with the password as a BASE64 encoded string. A “200” series response indicates that the authentication was accepted, a “500” series response indicates that it was not.

The SMTP dialog then continues as normal, generally with a “MAIL FROM:” command from the client indicating the sending address of the message, followed by one or more “RCPT TO:” commands to indicate the recipients for the message. Note that NowSMS expects the “RCPT TO:” addresses to be in a format of phonenumber@domain.name or phonenumber/TYPE=PLMN@domain.name, where “domain.name” is the “Domain Name for MMS E-Mail” configured on the “MMSC” configuration dialog. (The “Local Host Name or IP Address” value is also acceptable here.) If the domain name is not present, the MMSC will reject the recipient. As special support for Multimedia WAP Push, the following address formats are also supported to specify Multimedia WAP Push to be used for sending to the phone number: phonenumber.wappush@domain.name or phonenumber/TYPE=WAPP@domain.name.

The actual MMS message is then transmitted via the “DATA” command. Normally an MMS message would be a multipart MIME message with multiple content parts, although NowSMS will also accept a message that includes only a single part.

The MM4/SMTP dialog looks something like this (IN means from NowSMS server, OUT means from client):

IN: 220 SMTP Ready
OUT: HELO client.name (or EHLO client.name)
IN: 250 OK (or a multiline response if EHLO was used)
OUT: AUTH LOGIN
IN: 334 VXNlcm5hbWU6
(“Username:” BASE64 encoded)
OUT: dGVzdA==
(“test” BASE64 encoded)
IN: 334 UGFzc3dvcmQ6
(“Password:” BASE64 encoded)
OUT: dGVzdA==
(“test” BASE64 encoded)
IN: 235 Ok
OUT: MAIL FROM: <username@domain.com>
IN: 250 Ok
OUT: RCPT TO: <+447778889999/TYPE=PLMN@mms.domain.com>
IN: 250 Ok
OUT: DATA
IN: 354 Ok, end with “.” on a new line…
OUT: (Transmit MIME encoded message, then end with a line with only the . character)
IN: 250 Message Accepted
OUT: QUIT

Using the example data from the MM7 message above, the MIME encoded message would look something like this:


To: +447778889999/TYPE=PLMN@mms.domain.com
From: username@domain.com
Subject: News for today
Content-Type: multipart/mixed; boundary=”StoryParts-74526-8432-2002-77645″

–StoryParts-74526-8432-2002-77645
Content-Type: text/plain; charset=”us-ascii”

Science news, new Saturn pictures…
–StoryParts-74526-8432-2002-77645
Content-Type: image/gif
Content-ID:<saturn.gif>
Content-Transfer-Encoding: base64

R0lGODlhSAAcAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/
/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm
AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/
MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm
ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/
mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm
zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/
/5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ
AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA
M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ
ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A
mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z
zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAABIABwA
AAj/AP8JHEiwoMGDCBMqXMiwocOF1A5GNDjxoUWJ/1Bo3LhxSkeODCtedFiRmsZ/JQ1yXBmxJcqR
MAlOcXiSoEaPM2PqzIhCoMiDNV0K7Lnxpc+dDHs+rKlyaFGkDZUW/OnzZMqhRjdShWrzIsimNp8q
vKpypdmzGluebYpWKtmBFT+azUiX6M2zONty9Ig2JM++egMLFvw3YUS7Hf+uzDsYBd+Pj/fO5UuQ
WlynRecqbsy5McKekdcO7Py4tFzHgyuPTr26s2vCBQPnbW26cWizHjFrfnla7+bXgw/7vnwXN2rJ
RXHyrH28bc7MiD8jBh69d2C6JkFKfSkSde6BOQs+X/9efHHv5ccxFzb827pm6NpPuseqm6lCsV2p
1a7Ls3/b+60pRRVZPU1kFWD/bXeUUHDRVdVRSxWXkFSUfQWThSNlh8JW9GUUWoMxMchVWfThN+JD
KXHIm3z2IaWiQAEBADs=
–StoryParts-74526-8432-2002-77645–

Note: In this example, we don’t use any actual MM4 headers, just standard SMTP headers.

For full details of the MM4 protocol, please refer to the 3GPP TS 23.140 specification, which can be found at http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/.

MM1

Before submitting a message via MM1, a VASP (Value Added Service Provider) account must be defined to the Now SMS & MMS Gateway. This account is defined on the “MMSC VASP” configuration dialog.

To post to the Now SMS & MMS Gateway via MM1, you must connect to the HTTP port configured for the MMSC on the “MMSC” configuration dialog. And you must perform an HTTP POST of the MM1 content to a URI of “/mm1”, which is how the gateway knows that the VASP intends to submit in the MM1 format.

The HTTP headers of your POST must include a “Content-length:” header. To specify the account name and password of the VASP account, you must either include an “Authorization:” header for Basic authentication using the account name and password configured for the VASP account, or the account name and password can be specified on the request URI (e.g., /mm1/account=password). Alternatively, the request must originate from an IP address that matches the name configured for the VASP account. (If your software cannot generate an “Authorization:” header, it is possible to configure the account name for the VASP as an IP address, and in this case, the MMSC will recognise any connections from that IP address as being for this VASP account.)

The “Content-type:” header in the POST should be “application/vnd.wap.mms.message”, and the message should be a binary MMS message of the m-send-req format, formatted according to the MMS Encapsulation Specification, published by the Open Mobile Alliance.

Consistent with HTTP specifications, a “400” or “500” series HTTP response would be considered an error condition. The MMSC might return a “200” series response even if an error did occur, in which case information would be included in the “X-Mms-response-status” field of the MM1 response (MIME type “application/vnd.wap.mms-message”, X-Mms-Message-Type of “m-send-conf”) indicating a response-status value other than Ok.

The MMS Encapsulation Specification can be downloaded from the Open Mobile Alliance web site at http://www.openmobilealliance.org/.

EAIF

Before submitting a message via EAIF, a VASP (Value Added Service Provider) account must be defined to the Now SMS & MMS Gateway. This account is defined on the “MMSC VASP” configuration dialog.

To post to the Now SMS & MMS Gateway via EAIF, you must connect to the HTTP port configured for the MMSC on the “MMSC” configuration dialog. And you must perform an HTTP POST of the EAIF content to a URI of “/eaif”, which is how the gateway knows that the VASP intends to submit in the EAIF format.

The HTTP headers of your POST must include a “Content-length:” header. To specify the account name and password of the VASP account, you must either include an “Authorization:” header for Basic authentication using the account name and password configured for the VASP account, or the account name and password can be specified on the request URI (e.g., /eaif/account=password). Alternatively, the request must originate from an IP address that matches the name configured for the VASP account. (If your software cannot generate an “Authorization:” header, it is possible to configure the account name for the VASP as an IP address, and in this case, the MMSC will recognise any connections from that IP address as being for this VASP account.)

The “Content-type:” header in the POST should be “application/vnd.wap.mms.message”, and the message should be a binary MMS message of the m-send-req format, formatted according to the MMS Encapsulation Specification, published by the Open Mobile Alliance.
MMS message recipients can be specified either in the MMS message content itself, or in the “X-Nokia-MMSC-To:” header.

Consistent with HTTP and EAIF specifications, a “400” or “500” series HTTP response would be considered an error condition. The expected response for a valid message submission would be an HTTP “204” response that includes an “X-Nokia-MMSC-Message-Id:” header.

The MMS Encapsulation Specification can be downloaded from the Open Mobile Alliance web site at http://www.openmobilealliance.org/. The EAIF specification is available from the Forum Nokia web site at http://www.forum.nokia.com/.

For comments and further discussion, please click here to visit the NowSMS Technical Forums (Discussion Board)...