The NowSMS Tech Support Files

Introducing NowSMS Lite

2009-07-09T20:44:00.002+01:00

The Now SMS/MMS Gateway is one of the most widely used middleware software solutions for SMS, MMS and WAP Push messaging needs. When asked to explain it, we often refer to it as a Swiss Army Knife of mobile messaging protocols.

Since it's introduction in 2002, we've consistently updated NowSMS to support the widest variety of SMS and MMS protocols, following both the latest industry standards, and the real world variations that make you realise how incomplete the standards are.

We're proud to talk about how well the NowSMS product scales from entry level test-lab configurations to production mobile operator environments.

However, with all of the flexibility of the NowSMS product comes a lot of complexity. That complexity is great for the core technical audience of NowSMS, but it is overwhelming for those that are newer to SMS and MMS messaging technologies, or that have less demanding messaging needs.

The NowSMS Lite edition is designed to send and receive SMS and MMS messages using a single GSM (GRPS/EDGE/3G) modem.

The NowSMS Lite Edition allows clients to submit SMS messages to NowSMS for delivery via the GSM modem, using either the HTTP or SMPP protocols. NowSMS Lite also provides examples for submitting SMS messages from Java, PHP and a command line interface.

Received SMS messages can be routed to an application program using either HTTP, SMPP, or a command-line interface.

The NowSMS Lite Edition allows clients to submit MMS messages for delivery via the GSM modem, using either a proprietary HTTP interface that supports both HTTP GET and POST operations, or using the MM7 protocol. MM7 is a SOAP/XML based protocol that operates over HTTP POST. Additionally, NowSMS Lite provides examples for submitting MMS messages from Java, PHP and a command line interface.

Received MMS messages can be routed from NowSMS Lite to an application program using either MM7, an HTTP interface optimised for PHP, or via a file/directory based interface.

A free 30-day trial version of NowSMS Lite is available for download at http://www.nowsms.com/lite/download.

The product manual for NowSMS Lite is available on-line at:

http://www.nowsms.com/lite/documentation

Or to download a copy of the product manual, right click on http://www.nowsms.com/download/nowsmslite.pdf.

As a special introductory offer, NowSMS Lite will be available for £195 (GBP) through September 30, 2009.

SMSGW.INI and MMSC.INI Advanced Parameters

2009-06-30T21:51:00.002+01:00

Below is a link to a document that describes the latest advanced configuration parameters available for NowSMS in the SMSGW.INI and MMSC.INI files:

http://www.nowsms.com/download/NowSMS2009Ini.pdf

MM7 Schemas and MMS Version Number Confusion, revisited

2009-05-22T20:11:00.003Z

Receiving this e-mail about a recent post got me thinking that it might be worth sharing these thoughts here. It's got a little more opinion than other posts, but I think it is interesting for many people who are working with, or trying to work with, MM7.

quote:
Hi,

I read the article, MM7 Schemas and MMS Version Number Confusion, and it answered the difference between mm7 verion and mms version, but I wonder do they have the mapping relationship?
for example: REL-5-MM7-1-2 - 5.3.0 (version is actually 5.5.0, but schema requires 5.3.0) , which standard document define which mms version shall use which schema.

Thanks!

Br,
Tommy

Hi Tommy,

As I read back through it, that blog article is pretty good about defining that table ... defining which schema was introduced in which version of the specification.

The relevant specifications are 3GPP TS 23.140, which defines the MMS protocols. Similarly, 3GPP TS 23.040 defines SMS.

There is no table that is defined by the specifications themselves. You have to review the different versions of the specifications themselves and try to figure out what has changed.

An archive of different versions of MMS can be found here:

http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/

Note: MM1, the over-the-air MMS protocol is only defined in abstract in this specification. It's technical realisation is defined by the OMA (http://www.openmobilealliance.org).

23140-520.zip (3GPP TS 23.140 V5.2.0) is the first version that defines a technical realisation of MM7. However, it's not a true technical realisation, as it only defines MM7 in an abstract fashion ... defining transactions and elements ... but not defining an XML schema or even mandating that the HTTP protocol be used for MM7. (To quote from Section 7.1.13.1, "For example, if HTTP is used as an MM7 transport, many optional authentication mechanisms are available.")

Some MMSC vendors decided to implement MM7 based upon this v5.2.0 specification. This led to MM7 implementations from Ericsson and LogicaCMG that are completely incompatible with the MM7 schema and protocol defined in v5.3.0 of the specification.

23140-530.zip (3GPP TS 23.140 V5.3.0) is the first version that defines MM7 in a true technical realisation. It specifies that SOAP over HTTP POST is used as the transport protocol, and an XML schema is published at: http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0

In NowSMS, we refer to this as schema version REL-5-MM7-1-0.

23140-540.zip (3GPP TS 23.140 V5.4.0) introduces a new schema, http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-1

If you analyse this schema, the only allowed value for the element is 5.3.0, even though this specification is 5.4.0.

23140-550.zip (3GPP TS 23.140 V5.5.0) introduces yet another new schema, http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2

And is still restricted to 5.3.0.

Needless to say, it is maddening that there are so many different MM7 versions and schemas.

Version number frustration is only part of it!

There are significant changes to types and elements made between different versions of the schema.

Sender address formats are different between different versions of the schema!

"+" is not allowed in a phone number in some versions of the schema!

I realise that it is a lot of work to produce such a large specification ... and it's easy to pick faults (in this case, easier than most).

The reality is that different MMSC vendors have implemented support for different versions of the 3GPP MMS specification. A particular MMSC may only support 1 or 2 versions.

In some cases, most things may work when using a schema that is not supported by a particular in MMSC ... but you encounter weird problems.

For example, one of the issues we encountered recently was a missing/blank sender address when submitting messages via a Huawei MMSC (http://www.nowsms.com/discus/messages/485/24992.html).

The Huawei MMSC only truly understands the REL-5-MM7-1-0 schema from 5.3.0.

Other MMSCs use REL-5-MM7-1-2 as a baseline spec. And they'll reject messages because of invalid sender if you try to use REL-5-MM7-1-0 formatting.

In that case, you need to use the REL-5-MM7-1-2 schema, and specify 5.3.0 ... even though the schema was actually defined in version 5.5.0.

Bottom line ...

MM7 is more difficult than it should be.

In NowSMS, we implement the proprietary MM7 protocols, as defined by Ericsson and LogicaCMG, which preceded 3GPP TS 23.140 v5.3.0.

And we implement v5.3.0 through v6.13.0, and the relevant schemas.

However, we used to allow the MM7 Version number and MM7 Schema values to be configured separately. In newer releases, we only allow the configuration of MM7 Version Numbers that are allowed in the selected MM7 Schema.

That makes it a little less confusing when configuring an MM7 connection in NowSMS.

However, you still really need to know which MMS Schema version is supported by your provider in order to avoid confusion. Sometimes they only tell you the version number, and you need to correlate that to the schema. As you can see, this is really confusing if they are using the REL-5-MM7-1-2 schema (which is a good baseline schema, because it finally stablised some confusing aspects of earlier schemas) ... because the schema requires a version specifier of 5.3.0, even though this schema didn't actually exist until 5.5.0.

Sigh ...

At least we can deal with the schema differences in NowSMS. But there's no way to do version discovery when initiating an MM7 connection ... and that would have simplified a lot of these problems!

Protocol designers should always have a way of dealing with version discovery and/or specify ways of dealing with forward/backward compatibility.

The OMA MMS specifications that define the technical realisation of MM1 (over the air MMS) are actually quite good, and well thought out in this regard.

Needless to say, I've got some strong opinions on this subject ...

Got a comment or question, here's the thread on our discussion board: http://www.nowsms.com/discus/messages/485/25210.html

-bn

MMSC Accounting Callbacks for Billing and Charging

2009-05-07T14:54:00.004Z

MMSC accounting callbacks provide an interface between the NowSMS MMSC and external billing and charging systems.

These MMSC accounting callbacks are HTTP-based. When accounting callbacks are enabled, the MMSC will issue HTTP requests to a customer supplied URL in order to interface with the customer billing and charging systems.

To enable MMSC accounting callbacks, it is necessary to manually edit the MMSC.INI configuration file, and define the callback URL under the [MMSC] section header, using the following configuration parameter:

MMSAccountingURL=http://server/path

Whenever the MMSC processes an MMS message, it issues an accounting callback by issuing an HTTP transaction to the callback URL. Variables describing the MMS transaction are appended to the MMSAccoutingURL as HTTP GET CGI-style variables, with standard URL escaping applied for encoding reserved characters.

For example:

http://server/path?PreAuth=Yes&Type=MMSSend&From=%2B449999999999&To=%2B447777777777&MsgCount=1

(These variables and transaction types will be described later in this document.)

Most of the accounting callbacks are informational only, and exist to record charging information after the MMSC has processed a transaction.

However, there are also pre-authorisation callbacks which occur before the MMSC processes a transaction. These pre-authorisation callbacks exist to allow the customer billing system to decide whether or not the transaction should be allowed. In this scenario, the callback could check available credit and reject an MMS message transaction before it is accepted by the MMSC.

The following accounting callbacks are supported by the MMSC:

MMSSend PreAuth Callback

This callback is executed when an MMS subscriber, Value Added Service Provider (VASP) or MMSC interconnect partner, is requesting to send a message.

This is a “pre-authorisation” request, and does not mean that the message will actually be accepted by NowSMS for delivery. If NowSMS cannot successfully connect to the accounting URL, or the URL returns a response other than a standard “HTTP 200 OK” response, the user request to send a message will be blocked. A “PreAuth” request to send a message will also be blocked if the HTTP response content includes the text “PreAuth=Deny”.

The following parameter variables may be set for the MMSSend pre-authorisation request:

PreAuth=Yes

The presence of this parameter indicates that this callback is a pre-authorisation request.

Type=MMSSend

The transaction type is MMSSend, indicating that a request is being made to send an MMS message.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber that is sending the message. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber (may be a comma delimited list with multiple recipients)

This parameter contains one or more recipient phone numbers. If more than one phone number is present, this will be a comma delimited list of recipient phone numbers. (Note that URL escaping rules require the "," symbol to be encoded as "%2C".)

VASPIN=MmscVaspName

This parameter is present if the message is arriving from a Value Added Service Provider or MMSC interconnect partner. The value of this parameter refers to the account name as defined in the "MMSC VASP" list.

Note that some versions of NowSMS may preface the MmscVaspName with the text "VASP:".

VASP=MmscOutboundRoute (may be a comma delimited list if multiple recipients)

This parameter is present if the MMSC has determined that the message must be routed via an external route for delivery. The value of this parameter refers to the account name as defined in the "MMSC Routing" list.

If the message is being sent to multiple recipients, this field may contain a comma delimited list of routes with a route listed for each recipient. If there is a mix of local and remote recipients, local recipients will have a blank entry within the comma delimited list of routes.

MsgCount=####

This parameter specifies the number of recipients for this MMS message transaction.

(Note that the MMSSend PreAuth callback is issued only once if an MMS message is being sent to multiple recipients. The MMSSend Charging callback, which records billing and charging information after the MMSC has accepted the message, issues a separate callback for each recipient.)

Size=####

This parameter specifies the size of the MMS message in bytes.

Note that the MMS message size refers to the size of the data using the encoding of the protocol through which the message is being received (e.g., MM1, MM4, MM7). The actual size of the delivered MMS message may be different because of conversion between these protocols, and/or MMS header manipulation.

Also note that this parameter may not be present for all protocols. In particular, this parameter is not present for messages received via the MM4 (MMSC interconnect) protocol.

MMSSend Charging Callback

This callback is executed when an MMS subscriber, Value Added Service Provider (VASP) or MMSC interconnect partner, has submitted a message to the MMSC, and the MMSC has accepted the message for further processing.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSSend Charging Callback:

Type=MMSSend

The transaction type is MMSSend, indicating that an MMS message has been submitted.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber that is sending the message. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber

This parameter contains a single recipient phone number. If the original message was submitted to more than one recipient, a separate charging callback will occur for each recipient.

VASPIN=MmscVaspName

This parameter is present if the message arrived from a Value Added Service Provider or MMSC interconnect partner. The value of this parameter refers to the account name as defined in the "MMSC VASP" list.

Note that some versions of NowSMS may preface the MmscVaspName with the text "VASP:".

VASP=MmscOutboundRoute

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MessageID=assignedMessageID

This parameter records the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

Note that MMS message size may differ based upon the encoding protocol (e.g., MM1, MM4, MM7). The actual size of the delivered MMS message may be different because of conversion between these protocols, and/or MMS header manipulation.

MMSRetrieve Accounting Callback

This callback is executed when an MMS subscriber connects to the MMSC to retrieve the content of an MMS message.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSRetrieve Accounting Callback:

Type=MMSRetrieve

The transaction type is MMSRetrieve, indicating that an MMS subscriber has connected to the MMSC to retrieve the content of an MMS message.

From=SenderPhoneNumber (or EMailAddress)

This parameter contains the phone number or e-mail address of the message sender. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber

This parameter contains the recipient phone number that is retrieving this MMS message.

MessageID=assignedMessageID

This parameter contains the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

MMSOut Accounting Callback

This callback is executed when an MMS message is routed to an external route (VASP or MMSC interconnect) defined in the "MMSC Routing" list.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSOut Accounting Callback:

Type=MMSOut

The transaction type is MMSOut, indicating that an MMS message has been routed to an external route.

From=SenderPhoneNumber (or EMailAddress)

This parameter contains the phone number or e-mail address of the message sender. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber

This parameter contains the recipient phone number for the MMS message.

MessageID=assignedMessageID

This parameter contains the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

VASP=MmscOutboundRoute

This parameter specifies the MMSC outbound route via which the MMS message was routed.

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSOutFailed Accounting Callback

This callback is executed when an attempt is made to route an MMS message to an external route (VASP or MMSC interconnect) defined in the "MMSC Routing" list, but the attempt fails.

Information about the failure is not currently provided by this callback, but can be found in the MMSC-yyyymmdd.LOG file.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSOutFailed Accounting Callback:

Type=MMSOutFailed

The transaction type is MMSOutFailed, indicating that an attempt was made to route an MMS message to an external route, but the attempt failed.

From=SenderPhoneNumber (or EMailAddress)

This parameter contains the phone number or e-mail address of the message sender. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber

This parameter contains the recipient phone number for the MMS message.

MessageID=assignedMessageID

This parameter contains the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

VASP=MmscOutboundRoute

This parameter specifies the MMSC outbound route via which the MMS message was routed.

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSDeliveryReport PreAuth Callback

This callback is executed when a Value Added Service Provider (VASP) or MMSC interconnect partner is requesting to send a delivery report. This callback is also generated when the MMSC wants to generate a delivery a report on behalf of a local subscriber.

This is a “pre-authorisation” request, and does not mean that the delivery report will actually be accepted by NowSMS for delivery. If NowSMS cannot successfully connect to the accounting URL, or the URL returns a response other than a standard “HTTP 200 OK” response, the user request to send a message will be blocked. A “PreAuth” request to send a message will also be blocked if the HTTP response content includes the text “PreAuth=Deny”.

The following parameter variables may be set for the MMSDeliveryReport pre-authorisation request:

PreAuth=Yes

The presence of this parameter indicates that this callback is a pre-authorisation request.

Type=MMSDeliveryReport

The transaction type is MMSDeliveryReport, indicating that a request is being made to send an MMS delivery report.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber for which the delivery report is being generated (i.e., the original recipient of the message).

To=RecipientPhoneNumber

This parameter contains the phone number to which this delivery report is being sent (i.e., the original sender of the message).

VASP=MmscOutboundRoute

This parameter is present if the MMSC has determined that the delivery report must be routed via an external route for delivery. The value of this parameter refers to the account name as defined in the "MMSC Routing" list.

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSDeliveryReport Charging Callback

This callback is executed when a delivery report is being routed by the MMSC.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSDeliveryReport charging callback:

Type=MMSDeliveryReport

The transaction type is MMSDeliveryReport, indicating that an MMS Delivery Report has been generated.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber for which the delivery report has been generated (i.e., the original recipient of the message).

To=RecipientPhoneNumber

This parameter contains the phone number to which this delivery report is being sent (i.e., the original sender of the message).

VASP=MmscOutboundRoute

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSReadReport PreAuth Callback

This callback is executed when a MMS subscriber, Value Added Service Provider (VASP) or MMSC interconnect partner is requesting to send a read report (a.k.a., message read receipt).

This is a “pre-authorisation” request, and does not mean that the read report will actually be accepted by NowSMS for delivery. If NowSMS cannot successfully connect to the accounting URL, or the URL returns a response other than a standard “HTTP 200 OK” response, the user request to send a message will be blocked. A “PreAuth” request to send a message will also be blocked if the HTTP response content includes the text “PreAuth=Deny”.

The following parameter variables may be set for the MMSReadReport pre-authorisation request:

PreAuth=Yes

The presence of this parameter indicates that this callback is a pre-authorisation request.

Type=MMSReadReport

The transaction type is MMSReadReport, indicating that a request is being made to send an MMS read report.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber for which the read report is being generated (i.e., the original recipient of the message).

To=RecipientPhoneNumber

This parameter contains the phone number to which this read report is being sent (i.e., the original sender of the message).

VASP=MmscOutboundRoute

This parameter is present if the MMSC has determined that the read report must be routed via an external route for delivery. The value of this parameter refers to the account name as defined in the "MMSC Routing" list.

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSReadReport Charging Callback

This callback is executed when a read report is being routed by the MMSC.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSReadReport charging callback:

Type=MMSReadReport

The transaction type is MMSReadReport, indicating that an MMS Read Report has been generated.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber for which the read report has been generated (i.e., the original recipient of the message).

To=RecipientPhoneNumber

This parameter contains the phone number to which this read report is being sent (i.e., the original sender of the message).

VASP=MmscOutboundRoute

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSEMail PreAuth Callback

This callback is executed when an e-mail message has arrived via SMTP, specifying an MMS recipient.

The following parameter variables may be set for the MMSEMail pre-authorisation request:

PreAuth=Yes

The presence of this parameter indicates that this callback is a pre-authorisation request.

Type=MMSEMail

The transaction type is MMSEMail, indicating that an SMTP request is being made to deliver an MMS message to a subscriber.

From=EMailAddress

This parameter contains the e-mail address of the SMTP message sender.

To=RecipientPhoneNumber

This parameter contains a single recipient phone number.

MsgCount=1

This parameter is always 1 in current versions of NowSMS.

MMSEMail Charging Callback

This callback is executed when an SMTP message has been accepted for routing to an MMS recipient.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSEMail Charging Callback:

Type=MMSEMail

The transaction type is MMSEMail, indicating that an SMTP message has been accepted for routing to an MMS recipient.

From=EMailAddress

This parameter contains the e-mail address of the SMTP message sender.

To=RecipientPhoneNumber

This parameter contains a single recipient phone number. If the original message was submitted to more than one recipient, a separate charging callback will occur for each recipient.

MessageID=assignedMessageID

This parameter records the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

Missing Text Parts from MMS Messages

2009-04-07T08:26:00.000Z

A recent tech support incident where users were receiving MMS messages with missing text parts of the MMS content had us rather confused.

The customer was using NowSMS as an MMSC, and encountered two devices, the Motorola RAZR V8 and ROKR Z6, which were unable to receive any text content within an MMS message.

As a first step of troubleshooting, we recommended that the customer disable "content adaptation" by the MMSC to determine if the problem was related to content adaptation. (This setting is labeled "Enable Dynamic Image + Audio Conversion" in the MMSC configuration.)

The problem did go away with content adaptation disabled. However, disabling this support was not considered to be a permanent solution for the customer.

Upon further investigation, it was determined that the content adaptation problem was caused by errors in the User Agent Profiles (UAProf files) published by Motorola for these devices. The NowSMS MMSC consults these profiles to determine what content types are supported by the MMS client in the receiving handset. The profiles for these devices included a list of content types supported by the MMS client, but did not include plain text (text/plain) as one of the supported content types.

The NowSMS MMSC caches UAProf files in the UAPROF subdirectory of the NowSMS installation. The user was able to manually edit the motorazrv8.rdf and motorokrz6.rdf files in this directory to add support for the content typle "text/plain".

The supported MMS content types are listed in the "MmsCcppAccept" section of the UAProf file. Simply adding <rdf:li>text/plain</rdf:li> within this section of the file is all that is necessary to add support for the "text/plain" content type.

Future versions of the NowSMS MMSC will always assume that "text/plain" is a supported content type within MMS messages, even if there is an error in the UAProf file published by the handset manufacturer.

Sending Multimedia Content Push Messages with NowSMS

2009-04-02T07:15:00.000Z

One of the ways that NowSMS can be used for multimedia content delivery is a service that we refer to as Multimedia Content Push (also referred to as Multimedia WAP Push).

When you send a Multimedia WAP Push message with NowSMS, you post all of the message content (e.g., images, video, text, applet) to the NowSMS server. NowSMS packages the content and dynamically generates a URL on the NowSMS server. A WAP Push message is then sent which includes a link to the content.

To send a Multimedia WAP Push message via NowSMS, the same APIs are used as for sending an MMS message, with a special flag set to indicate that the message should be sent out as a Multimedia WAP Push instead of as an MMS message. The subject of the message is used as the text in the WAP Push, and the remainder of the content is packaged into the dynamically generated URL that accompanies the WAP Push message.

NowSMS 2009 also supports a concept of Multimedia Content Push where the push is sent via a text SMS instead of using WAP Push. The concept is similar to Multimedia WAP Push, except that the message that is sent to the recipient is a standard text message.

This alternative is useful in environments where WAP Push is not supported (such as environments where there is a mix of GSM and CDMA technologies), or where binary messaging required by WAP Push is more expensive than standard text messaging. It is also useful for delivering content to devices that do not support WAP Push, such as the Apple iPhone.

The article will explain how the Send MMS APIs for NowSMS are adapted to support Multimedia Content Push.

The APIs for sending MMS messages are described in the following link:

http://blog.nowsms.com/2009/02/sending-mms-messages-with-nowsms.html

PHP:

Follow the example described at http://blog.nowsms.com/2008/11/nowsms-php-example-send-mms-message.html

To send a Multimedia Content Message using WAP Push, add this line before calling MmsSend:

$mmsMessage = MmsAddField ($mmsMessage, "MMSWAPPush", "Yes");

To send a Multimedia Content Message using Text SMS, add this line before calling MmsSend:

$mmsMessage = MmsAddField ($mmsMessage, "SMSWAPPush", "Yes");

Java:

Follow the example described at http://blog.nowsms.com/2009/02/nowsms-java-example-send-mms-message.html, but include the following additional parameter setting when building the MMS message to send the message via WAP Push:

mms.addparameter ("MMSWAPPush", "Yes");

Or this parameter setting when building the MMS message to send the message via text SMS:

mms.addparameter ("SMSWAPPush", "Yes");

Command Line Interface:

Follow the example described at http://blog.nowsms.com/2007/07/sending-mms-from-command-line.html, but include the following additional parameter in your command line to send the message via WAP Push:

MMSWAPPush=Yes

Or include this additional parameter to send the message as a URL link via text SMS:

SMSWAPPush=Yes

NowSMS Proprietary URL Submission

Follow the example described at http://blog.nowsms.com/2009/02/sending-mms-messages-with-nowsms.html.

Include the following additional variable setting to send the message via WAP Push:

MMSWAPPush=Yes

Or include this additional variable setting to send the message as a URL link via text SMS:

SMSWAPPush=Yes

This additional variable setting can be included in the URL (e.g., &MMSWAPPush=Yes), or it can be included as a variable setting in part of the multipart/form-data.

MM7

Follow the MM7 example described at http://blog.nowsms.com/2009/02/sending-mms-messages-with-nowsms.html.

Append "/TYPE=WAPP" to the recipient phone number to send via WAP Push or "/TYPE=SMSP" to send as a URL link via text SMS.

MM4/SMTP

Follow the MM4 example described at http://blog.nowsms.com/2009/02/sending-mms-messages-with-nowsms.html.

Append "/TYPE=WAPP" to the recipient phone number to send via WAP Push or "/TYPE=SMSP" to send as a URL link via text SMS.

MM1

Multimedia Content Push is not supported via the MM1 Interface, unless the default outbound route for MMS messages is to use "Multimedia WAP Push" ("WAP Push with Web Link") or "SMS with Web Link (Direct)". In this case, MMS messages will be automatically converted to the format specified by the outbound route.

EAIF

Multimedia Content Push is not supported via the EAIF Interface, unless the default outbound route for MMS messages is to use "Multimedia WAP Push" ("WAP Push with Web Link") or "SMS with Web Link (Direct)". In this case, MMS messages will be automatically converted to the format specified by the outbound route.

Send OMA Client Provisioning (OTA XML) via PHP

2009-03-26T07:07:00.000Z

OMA Provisioing Content Messages are special SMS messages that contain information used to configure certain settings of a mobile phone, such as settings for the browser (APN, proxy, bookmarks), MMS client, IM client, or SyncML client.

These messages are sometimes referred to as OTA configuration messages, where OTA is an acronym for Over-The-Air.

These settings are specified in an XML format, and the encoded by NowSMS into a compact binary format for sending via SMS.

Some of the XML document formats supported by NowSMS include:

1.) OMA (Open Mobile Alliance) Provisioning Content (root XML element "wap-provisioningdoc")

2.) OMA (Open Mobile Alliance) DRM Rights Objects (root XML element "o-ex:rights")

3.) WAP Push Service Indication, Service Load and Cache Operation (root XML element "si", "sl", or "co")

4.) OMA (Open Mobile Alliance) E-Mail Notification (EMN) (root XML element "emn")

5.) Nokia/Ericsson Over The Air Settings (OTA) Specification (root XML element "CHARACTERISTIC-LIST")

6.) Nokia/Ericssson SyncML OTA or Wireless Village Settings (root XML element "SyncSettings" or "WVSettings")

A couple of years ago, we posted an example of a simple command line script that can be used to submitting an XML document to NowSMS to send out as an OTA configuration message. That script is described in more detail in the following article:

http://blog.nowsms.com/2007/07/send-oma-client-provisioning-ota-xml.html

We frequently receive questions about how to submit an XML OTA document via PHP, so I've posted an example PHP script that can be downloaded from http://www.nowsms.com/download/sendota-php.txt.

This PHP script contains a function called SendOTA.

The function definition for SendOTA contains the following parameters:

function SendOTA ($host, $port, $username, $password, $phoneNoRecip, $otafilename, $otapin, $otapintype)

$host - IP address or host name of the NowSMS server

$port - "Port number for the web interface" of the NowSMS Server

$username - "SMS Users" account on the NowSMS server

$password - Password defined for the "SMS Users" account on the NowSMS Server

$phoneNoRecip - One or more phone numbers (comma delimited) to receive the text message

$otafilename - File name of a local file containing the XML document to be encoded and sent as an OTA message

$otapin - Optional PIN code for signing the OTA message

$otapintype - Type of PIN code (USERPIN or NETWPIN)

Assuming that you have created an XML document named f:/temp/bookmark.xml, the following function call could be used to submit this document for sending as an OTA message via NowSMS:

SendOTA("127.0.0.1", 8800, "username", "password", "+4499999999999", "f:/temp/bookmark.xml", "0000", "USERPIN");

PIN codes are always the most confusing part of sending an OTA message.

An OTA PIN can be associated with many of the XML settings types to provide a layer of authentication to the message. Many devices will allow you to send XML settings without a PIN, but some will require a PIN to be present before the settings will be accepted at all.

There are three different types of PINs, depending on the "OTA PIN Type" ($otapintype) setting.

The simplest "OTA PIN Type" is "USERPIN" (User PIN). This setting indicates that a short PIN code (often 4 digits) is supplied as the "OTA PIN". When the user receives the OTA settings message, they will need to supply this PIN code in order to be able to open the message and apply the settings. If a "PINValue" is specified, but a "PINType" is not, then USERPIN will be assumed.

"NETWPIN" (Network PIN) indicates the PIN is a network PIN code. In the GSM environment, this is the IMSI number associated with the SIM card in the device. (Hint, if you want to experiment with determining the PIN card associated with a SIM, you can put the SIM into a GSM modem and the AT+CIMI command to return the IMSI. However, not all GSM modems support the AT+CIMI command.) When the device receives the settings, if the NETWPIN does not match the IMSI, the settings will be discarded.

An additional type of PIN, known as "USERNETWPIN" also exists, which indicates a combination of the USERPIN and NETWPIN types. To use this OTA PIN type, specify the OTA PIN as the IMSI number associated with the SIM card in the device, followed by a ":" character, followed by a USERPIN (e.g., 1234567889012345:1234). When the device receives the settings, the user will be prompted for a PIN. This user supplied PIN, and the SIM card IMSI, must match in order for the settings to be accepted.

NowSMS Java Example: Send WAP Push

2009-03-23T09:51:00.000Z

The previously posted examples for sending SMS and MMS messages from a Java application with NowSMS can also be used for sending WAP Push messages.

Normally, when we talk about WAP Push messages, we are talking about "Service Indication" (SI) messages, which are a common type of WAP Push message. MMS Messages also use WAP Push for part of the delivery process, but they are handled by a separate client. "Service Indication" WAP Push messages are the push messages that include some informational text, and a URL link for retrieving additional content.

To send a WAP Push message where you have already created the URL containing your content, the SMS example can be used. This example is described in the article http://blog.nowsms.com/2009/02/nowsms-java-example-send-sms-message.html, and can be downloaded directly at http://www.nowsms.com/download/sendsms.java.txt.

Using that script, the following code can be used to send a WAP Push message:

sendsms.init();

sendsms.server = "http://localhost:8800/";

sendsms.user = "test";

sendsms.password = "test";

sendsms.phonenumber = "+9999999999";

sendsms.text = "This is a test WAP Push message";

sendsms.wapurl = "http://www.nowsms.com/";

sendsms.send();

Another type of WAP Push supported by NowSMS is something that we refer to as Multimedia WAP Push.

Multimedia WAP Push also uses the "Service Indication" WAP Push message. However, when you send a Multimedia WAP Push message, you post all of the message content (e.g., images, video, text, applet) to the NowSMS server. NowSMS packages the content and dynamically generates a URL on the NowSMS server. A WAP Push message is then sent which includes a link to the content.

To send a Multimedia WAP Push message from Java, use the MMS example script described at http://blog.nowsms.com/2009/02/nowsms-java-example-send-mms-message.html, and available for download at http://www.nowsms.com/download/sendmms.java.txt.

Follow the example for sending an MMS message, but include the following additional parameter setting when building the MMS message:

mms.addparameter ("MMSWAPPush", "Yes");

To send a Multimedia Content Push via SMS with NowSMS 2009, follow the example for sending an MMS message, but include the following additional parameter setting when building the MMS message:

mms.addparameter ("SMSWAPPush", "Yes");

Creating a Bookmark using OMA Client Provisioning

2009-03-20T12:12:00.000Z

A recent posting on the NowSMS discussion board raised an interesting question.

How do you use OMA Client Provisioning to add a bookmark to a mobile phone?

The NowSMS web interface has a simple function for doing this using the old Nokia/Ericsson OTA format (WAP OTA), however the web interface for OMA Client Provisioning only allows a browser home page URL to be defined.

While the NowSMS web interface does not have a field for adding bookmarks, it is quite easy to manually edit the XML document to define a bookmark.

Here's a simple XML document that only defines a bookmark, without modifying or adding any other configuration settings:

<wap-provisioningdoc>

</characteristic>

</wap-provisioningdoc>

The bold part of the document is the specific part that defines the bookmark. This section can be repeated to add additional bookmarks.

It is important that this bold section appear inside of a CHARACTERISTIC APPLICATION section with an APPID value of W2. (This is the application id of the mobile phone browser application.)

If you want to send a complete configuration message, including a browser home page, plus additional bookmarks, see the related discussion at http://www.nowsms.com/discus/messages/1/24907.html.

The XML document can be sent as an OTA message using the "Send XML Settings" page of the NowSMS web interface. Additional examples of submitting OTA messages programmatically can be found at the following links:

http://www.nowsms.com/documentation/ProductDocumentation/sending_wap_ota_messages/oma_provisioning_content.htm

http://blog.nowsms.com/search/label/OTA

Sierra Wireless 881 USB Modem (881U) and NowSMS

2009-03-17T07:23:00.000Z

The Sierra Wireless 881 USB Modem (881U) is a good modem to use with NowSMS.

However, it can be a frustrating modem to get properly configured. The reason for this is because the primary market for this modem (and other USB modems) is to provide internet connectivity.

If you're looking at using this modem (or a similar modem) with NowSMS, it's probably best not to purchase the modem from the mobile operator with a data plan. When you do this, they are assuming that the primary use of the modem is internet connectivity, and NowSMS will not use the modem for that purpose. Often these data plans don't even have SMS or MMS services enabled.

When you attempt to add the Sierra Wireless 881 USB Modem to NowSMS, you will most likely encounter the error message "Modem does not properly support command for sending SMS (AT+CMGS)".

Or, with older versions of NowSMS, the modem will add correctly, however any attempt at sending SMS messages will result in the error "ERROR -Modem Response (1): OK".

These errors happen because the driver software for the Sierra Wireless modems actually installs

several virtual COM ports for communicating with the modem.

One of these ports can be used for sending/receiving SMS messages, while the other port can only support data/internet connectivity.

Older Sierra Wireless modems would install two Windows modem drivers, one for each port.

The modem driver "Sierra Wireless AirCard HSDPA Modem" would work with NowSMS and provide support for sending/receiving SMS mesasges. However the modem driver "Sierra Wireless AirCard 3G Modem" did not work with NowSMS, and could only be used for data/internet connectivity.

With the 881U modem, multiple virtual COM ports are installed by the Sierra Wireless software. However, a Windows modem driver is installed for only one of these COM ports, so when you select "Sierra Wireless AirCard 881U HSDPA Modem", you are connecting to a COM port that only supports data/internet connectivity.

To be able to send/receive SMS messages, it is necessary to identify the other COM port.

To identify the COM port, go into the System applet in the Windows Control Panel, and access "Device Manager". In the "Ports (COM & LPT)" section, you will find a port labeled "Sierra Wireless AT Command Port (UMTS)", followed by a COM port number such as COM8.

Once you have identified the COM port number, it is possible to add the modem to NowSMS by referencing the COM port number directly.

However, if you use the COM port directly in NowSMS, you won't be allowed to configure the modem for sending and receiving MMS. It will support SMS only.

The simple way to enable support for sending/receiving MMS is to manually install a Windows Modem driver for this COM port. This can be done through the "Phone & Modem Options" applet in the Windows Control Panel. We recommend that you manually select the modem driver, rather than having Windows detect the modem. For best results, use the "Standard 33600 bps Modem" driver.

After installing this Windows modem driver, configure NowSMS to use the "Standard 33600 bps Modem" to connect with the Sierra Wireless 881U, instead of using the direct COM port reference.

MM7 Schemas and MMS Version Number Confusion

2009-03-10T08:23:00.001Z

In a recent posting, I posted a reference to the SMPP specification, which is the de facto standard for application generated SMS, as well as for interconnecting SMS systems. The most commonly used version of the SMPP specification was published 10 years ago.

There are a few ambiguities in SMPP with regard to message encoding for long text messages, and delivery receipt formats. But overall, it's a stable protocol, and there are just a few advanced configuration options in NowSMS to adjust for minor inconsistencies in different implementations of the protocol.

MM7 is the defined standard for application generated MMS. And in just a few short years, there were at least 24 versions of the specification released, and at least 10 different XML schemas, some of which have rather significant differences ... not just additional elements, but there have been some changes to elements defined in previous versions ... to the extent that applications cannot assume that elements are upward compatible to newer versions of the XML schema, which is a major headache.

It gets even a little more confusing, because first versions of the MMS specification to define MM7 defined it only in an abstract format, without a formal XML schema. As a result of this, two major MMSC vendors, Ericsson and LogicaCMG, implemented their own non-standard versions of MM7.

When configuring an MM7 connection in NowSMS, we have allowed the user to configure the MM7 XML Schema version and MMS Version (element) to be used, providing support for variations in different versions of the XML schema. We have also provided configuration options to support non-standard variations, such as the original implementations from Ericsson and LogicaCMG.

However, matching up the version and schema with that of the mobile operator to which you are connecting can be confusing.

In the next major release of NowSMS, we are automatically selecting the MMS version based upon the MM7 schema version selected. However, until this release is made available, we thought it would be helpful to associate the MMS MM7 version numbers with the associated MM7 XML Schema version.

REL-5-MM7-1-0 - 5.3.0

REL-5-MM7-1-1 - 5.3.0 (version is actually 5.4.0, but schema requires 5.3.0)

REL-5-MM7-1-2 - 5.3.0 (version is actually 5.5.0, but schema requires 5.3.0)

REL-5-MM7-1-3 - 5.6.0

REL-5-MM7-1-4 - 5.8.0

REL-5-MM7-1-5 - 5.10.0

REL-6-MM7-1-0 - 6.3.0

REL-6-MM7-1-1 - 6.4.0

REL-6-MM7-1-2 - 6.5.0

REL-6-MM7-1-3 - 6.6.0

REL-6-MM7-1-4 - 6.8.0

The full path to these schemas is relative to:

http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/

For example:

http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2

When connecting to an operator MMSC over MM7, it is important to know the schema and verison number supported by the mobile operator. If the operator only provides you with a version number or schema, then it is possible to correlate the correct value for the other setting based on the above table.

Unfortunately, there is a considerable amount of confusion over MM7 Version numbers and schemas, because of inconsistencies in the 3GPP TS 23.140 specification that defines MMS and MM7. For example:

3GPP TS 23.140 version 5.5.0 defines the REL-5-MM7-1-2 schema. However, section 8.7.8.1 of the specfication says that the schema URI should reference REL-5-MM7-1-1. Complicating matters further, a version number value of 5.5.0 is NOT valid in either the REL-5-MM7-1-2 or REL-5-MM7-1-1 schema. However, the version number 5.5.0 is valid for the REL-5-MM7-1-3 and later schemas!

3GPP TS 23.140 sersion 5.8.0 defines the REL-5-MM7-1-4 schema. However, section 8.7.8.1 still says that the schema URI should reference REL-5-MM7-1-1, and all of the examples reference the REL-5-MM7-1-3 schema and version 5.6.0. At least in this case, version number 5.8.0 is valid in the REL-5-MM7-1-4 schema.

Needless to say, the inconsistencies are maddening!

The most commonly supported version/schema combinations seem to be:

REL-5-MM7-1-2 - 5.3.0 (defined in version 5.5.0 of 3GPP TS 23.140)

REL-6-MM7-1-0 - 6.3.0

REL-5-MM7-1-0 - 5.3.0

All versions of the 3GPP TS 23.140 specification can be downloaded at the following link: http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/

Premium Rate SMS (OPPC) with Verisign and NowSMS

2009-03-05T12:29:00.000Z

Here at NowSMS, we make it a point not to endorse any particular SMS service provider. We like our customers to have flexibility to choose and change SMS service providers that best fit their needs.

That said, some SMS service providers have unique configuration attributes, and you need to apply special configuration parameters in NowSMS in order to take advantage of features and flexibility offered by the SMS service provider. This is especially the case with premium rate SMS services, including AT&T's OPPC (Off Portal Purchase Control).

In a previous article, we discussed how to configure NowSMS to support the additional parameters supported by the mBlox: http://blog.nowsms.com/2008/10/mblox-and-nowsms.html

In this article, we're going to explain how to configure NowSMS to support the additional parameters supported by the Verisign SMS service.

These special parameters are specific to the verisign SMS Service. So for customers who are looking to use NowSMS with Verisign, I want to highlight some of these settings and parameters.

This should not be construed as an endorsement of Verisign by NowSMS, or vice versa. This is just information that is provided to help simplify the process of integrating NowSMS with the Verisign service.

There are a series of special SMPP parameters that Verisign defines for their service. SMPP is flexible in that it allows service providers to define additional parameters in the optional TLV (tag, length, value) section of the SMPP message packet.

To enable the additional Verisign parameters in NowSMS, it is necessary to manually edit the SMSGW.INI file and and add the following section:

[SMPPOptions]
verisign_product_code=1520,String
verisign_output_code=1530,String
verisign_error_message=1531,String
verisign_auth_code=1532,String
verisign_auth_message=1533,String
verisign_carrier_id=1402,String
verisign_carrier_name=1404,String

The above text should be added to the SMSGW.INI file "as is". "String" and "Integer" are not place holders for you to replace when adding this information to the SMSGW.INI file, so please avoid that common mistake.

These parameters are provider specific, and you are telling NowSMS that there are additional parameters supported by your provider, and these settings tell NowSMS the parameter type (e.g., "String"), length restrictions, and the SMPP parameter value.

When these settings are present, additional parameters are supported when submitting a message to NowSMS via an HTTP URL request.

"&SMPPOption_verisign_product_code=" can specify a value for the premium rate product code of this message. This is a text string that you setup and register with Verisign before you can use it.

The other parameters could also be specified when submitting a message, however Verisign documentation suggests that they are only supported in messages that you receive.

When these SMSGW.INI file settings are present, NowSMS will also route these parameters to HTTP-based 2-way commands. If a message is received which contains values for any of these settings, NowSMS will automatically append the setting name and value (e.g., "&SMPPOption_verisign_carrier_id=value" or "&SMPPOption_verisign_carrier_name=" to the 2-way URL. It is not necessary to add any variables to the 2-way command template, as these values will be appended automatically if present in a received message.

In addition to supporting these options via HTTP URL request, it is possible to configure default settings for any of these options for each outbound SMPP connection.

In many cases, it may be desirable to define default values for these parameters, instead of having to specify them in each HTTP URL submission. To define default values for these parameters, manually edit the SMSGW.INI, and in the section header for an SMPP connection (e.g., [SMPP - ip.address:port]), add a "DefaultSMPPOptions=" setting, where the value of this setting can contain any of the "SMPPOptions" settings. For example, "DefaultSMPPOptions=verisign_product_code=ACMEX_12345_RINGHIP_999_S". To include multiple options, separate the entries with a ";", for example, "DefaultSMPPOptions=verisign_product_code=ACMEX_12345_RINGHIP_999_S;verisign_auth_code=test".

For additional information on any of these parameters, please refer to the Verisign SMS Gateway API Reference.

SMPP 3.4 Protocol Specification Archive

2009-03-02T09:02:00.000Z

For archive purposes, I'm posting a copy of the SMPP 3.4 Specification here.

The SMS standards organization that created the specification has disbanded, and there are plans for their web site to be shut down.

This doesn't mean that SMPP is not still important for SMS. It remains the de-facto standard for application based SMS messaging.

It's just that the SMPP v3.4 specification was published in 1999, and it really hasn't been updated since.

The group did produce a successor specification, SMPP v5.0 ... but it was too overwhelming, and never really caught on in the marketplace. This leaves SMPP v3.4 as the de-facto industry standard.

Download links:

SMPP v3.4 Protocol Specification

SMPP v3.3 Protocol Specification

Those specifications are a good reference for developers.

Those are good SMPP references for developers.

It's probably also a good idea to archive some reference information here for SMPP issues as they relate to NowSMS:

Garbage When Sending Text Messages longer than 160 Characters

SMPP TON and NPI Settings

Optional SMPP TLV Parameters for mBlox and other SMS Providers

SMPP Connection Types (Sender, Receiver, Transceiver)

Limiting the Speed of an SMPP Connection

SMPP Error Code Handling and Retries

Provisioning MMS Short Codes on the NowSMS MMSC

2009-02-23T08:08:00.000Z

When using the NowSMS MMSC as an operator MMSC, one frequently asked question is how to provision short codes for MMS content providers, or Value Added Service Providers (VASP).

The MMS specifications from the 3GPP define MM7 as the standard protocol for Value Added Service Providers to interface with operator MMSCs.

Since many MMS content providers are existing SMS content providers, it may help to point out some significant ways in which MM7 differs from the SMPP protocol which is most frequently used for SMS content delivery.

With SMPP, it is almost always the content provider that originates the SMPP connection. The SMPP connection is a persistent, always active connection. SMS messages can be sent and received over the same connection.

MM7 is an HTTP-based protocol. Connections are not persistent, but instead are initiated on demand, as required (HTTP keep-alive sockets are used to avoid re-connection overhead if many messages are being submitted in bulk). When a content provider has a message to send, it initiates a new connection (unless a keep-alive connection is available) to the mobile operator to submit the message. When the mobile operator has a message to deliver to the content provider, the mobile operator initiates a connection to the content provider.

The NowSMS product is available to content providers to simplify the process of interfacing with your MMSC over MM7. Content providers can find morre information about configuring NowSMS to interface with an operator MMSC over MM7 in the following article: http://blog.nowsms.com/2009/02/connecting-to-operator-mmsc-with-mm7.html.

These are the steps for provisioning a content provider on the NowSMS MMSC.

Step 1: Provision the "MMSC VASP" account which defines an account through which the content provider authenticates to the MMSC and submits MMS messages for delivery.

On the "MMSC VASP" page of the NowSMS configuration dialog, press the "Add" button to define a new VASP.

For the "Account Name", we recommend specifying the short code assigned to the provider. This not required, but is recommended for simplifying administrative tasks.

The "Password" field contains a password that the content provider will use when connecting to the MMSC. (We recommend also assigning "IP Address Restrictions" so that the content provider is only allowed to connect from a single IP address, or a limited number of IP addresses.)

"Account Description" is an informational field that is not required.

"IP Address Restrictions" can contain a comma delimited list of IP addresses from which this content provider is allowed to connect to the MMSC.

"Accept Connections Via" defines which protocols the VASP is allowed to use. We recommend enabling only MM7.

"VASP Sender Address" specfies the default sender address to be used for messages being sent by this content provider. In most instances, this would be the short code assigned to the provider.

"Allow Sender Address Override" specifies whether or not the content provider can use any sender address values other than the "VASP Sender Address". If this field is NOT checked, then all messages sent by this content provider will have the "VASP Sender Address" recorded as the sender address. If this field is checked, then any sender address specified by the content provider will be allowed.

"3GPP MMS Version" and "MM7 Schema" should be left at their default values, unless there is a special requirement.

"MMSC Routing for Received Messages" should be set to "Standard MMS Delivery".

Step 2: Inform the content provider of their MM7 connection settings, and ask questions about their configuration.

a.) The content provider will need to know the MM7 Server URL to which their MM7 transactions should be posted. This URL will be:

http://host.name:port/mm7/account=password

"host.name" is the IP address or host name of your NowSMS MMSC.

"port" is the "HTTP port" on the "MMSC" page of the configuration dialog".

"account" is the "MMSC VASP" account name, and "password" is the password associated with that account.

b.) Inform the content provider that no login name, password, VASPID, VASID or Service Code is required, and that they will be authenticated based upon the IP address of their server. Ask the provider for the IP address of their server, so that you can define this IP address in the "IP Address Restrictions" field of the "MMSC VASP" definition, and so that you can open any required access in your firewall.

c.) Ask for the MM7 URL on their system to which you should post any messages for their short code. You cannot complete the provisioning of their account until you have this information.

Step 3: Provision the "MMSC Routing" definition which defines how messages addressed to the content provider's short code will be routed to the content provider's system.

On the "MMSC Routing" page of the NowSMS configuration dialog, press the "Add" button to define a new routing definition.

For the "Account Name", we recommend specifying the short code assigned to the provider. This not required, but is recommended for simplifying administrative tasks.

"Account Description" is an informational field that is not required.

"Default Sender Address" should be left blank. (Warning: Do not put the content provider short code here!)

"Allow Sender Address Override" should be checked.

"Route messages to this account for recipient phone number(s)" should contain the content provider short code.

"Route messages to VASP via" should be set to "MM7".

"Server Address" is the MM7 URL provided to you by the content provider. This is the URL on the content provider's system to which you will connect for delivering MMS messages that were addressed to their short code.

"Login Name", "Password", "VASP ID", "VAS ID" and "Service Code" can all be left blank unless the content provider has special requirements.

"Connection Type" should be set "To VASP".

The remaining fields can be left at their default settings.

Note about MMS Accounting Callbacks

The MMS Accounting Callbacks can be used for recording billing and charging information for MMS messages sent and received by content providers. These callbacks can also be used to block certain messages from being sent or received by content providers.

The MMS Accounting Callbacks are defined in the following document: http://www.nowsms.com/support/bulletins/tb-nowsms-001.htm.

There are additional parameters in these accounting callbacks for indicating that a message has originated with or is destined to a content provider.

If the message is being received from a content provider, a "&VASPIN=xxxxx" parameter will be included in the callback URL where "xxxxx" is the "Account Name" of the "MMSC VASP" definition associated with the content provider.

If the message is being routed to a content provider, a "&VASP=xxxxx" parameter will be included in the callback URL where "xxxxx" is the "Account Name" of the "MMSC Routing" definition associated with the content provider.

Sending MMS Messages with NowSMS

2009-02-17T08:55:00.000Z

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://blog.nowsms.com/2008/11/nowsms-php-example-send-mms-message.html.

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

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://blog.nowsms.com/2007/07/sending-mms-from-command-line.html

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/.

XML Status Query for SMSC Connection Status and Statistics

2009-02-16T15:15:00.000Z

NowSMS 2008 added an XML-based status query interface that reports information similar to what is reported on the "Status" page of the NowSMS configuration dialog. The query results include information about SMSC connection status, the number of messages processed via the different connections, and the number of messages pending in the queues, among other information.

The XML-based status interface can be accessed on the web port of the SMS gateway using a URL of "/ADMIN/XMLSTATUS" (not case sensitive). To enable access to this interface, "Enable Web Account Administration" must be enabled on the "Web" tab of the NowSMS administrative interface. The Admin User Name and Password can either be sent in an HTTP "Authorization:" header, or using "&User=username&Password=password" in the URL request.

An example will help better illustrate the information that is available.

Connect to the NowSMS server with the following URL: http://127.0.0.1:8800/admin/xmlstatus?user=adminuser&password=adminpass Substitute in your appropriate IP address and port ... and the appropriate "adminuser" and "adminpass" values. The XML formatted information is quite readable, so a good way to get started is to make the request to your own NowSMS server via a web browser to see what information is returned.

Here's an example of the XML response from one of our testing servers (I've added some line breaks for readability):

<NowSMSStatus>

<SMSCStatus>
<Name>SMPP - xps5:9000</Name>
<Status>OK</Status>
<MessagesToday>44640</MessagesToday>
<MessagesLast7Days>44640</MessagesLast7Days>
<MessagesLast30Days>44640</MessagesLast30Days>
</SMSCStatus>

<SMSCStatus>
<Name>SMPP - xps5:9001</Name>
<Status>OK</Status>
<MessagesToday>43369</MessagesToday>
<MessagesLast7Days>43369</MessagesLast7Days>
<MessagesLast30Days>43369</MessagesLast30Days>
</SMSCStatus>

<SMSCStatus>
<Name>SMPP - xps5#2:9000</Name>
<Status>OK</Status>
<MessagesToday>45308</MessagesToday>
<MessagesLast7Days>45308</MessagesLast7Days>
<MessagesLast30Days>45308</MessagesLast30Days>
</SMSCStatus>

<SMSCStatus>
<Name>SMPP - xps5#2:9001</Name>
<Status>OK</Status>
<MessagesToday>48856</MessagesToday>
<MessagesLast7Days>48856</MessagesLast7Days>
<MessagesLast30Days>48856</MessagesLast30Days>
</SMSCStatus>

<SMSOUTQ>92833</SMSOUTQ>
<SMSINQ>0</SMSINQ>
<SMSRCPTQ>0</SMSRCPTQ>

<SMSSubmitted>
<MessagesToday>275006</MessagesToday>
<MessagesLast7Days>275006</MessagesLast7Days>
<MessagesLast30Days>275006</MessagesLast30Days>
</SMSSubmitted>

<SMSSent>
<MessagesToday>182173</MessagesToday>
<MessagesLast7Days>182173</MessagesLast7Days>
<MessagesLast30Days>182173</MessagesLast30Days>
</SMSSent>

<SMSReceived>
<MessagesToday>73786</MessagesToday>
<MessagesLast7Days>73786</MessagesLast7Days>
<MessagesLast30Days>73786</MessagesLast30Days>
</SMSReceived>

<SMSFailed>
<MessagesToday>0</MessagesToday>
<MessagesLast7Days>0</MessagesLast7Days>
<MessagesLast30Days>0</MessagesLast30Days>
</SMSFailed>

<SMSRetried>
<MessagesToday>0</MessagesToday>
<MessagesLast7Days>0</MessagesLast7Days>
<MessagesLast30Days>0</MessagesLast30Days>
</SMSRetried>

<MMSProcessedUser>
<MessagesToday>0</MessagesToday>
<MessagesLast7Days>0</MessagesLast7Days>
<MessagesLast30Days>0</MessagesLast30Days>
</MMSProcessedUser>

<MMSProcessedVASP>
<MessagesToday>0</MessagesToday>
<MessagesLast7Days>0</MessagesLast7Days>
<MessagesLast30Days>0</MessagesLast30Days>
</MMSProcessedVASP>

<MMSSentMMSC>
<MessagesToday>0</MessagesToday>
<MessagesLast7Days>0</MessagesLast7Days>
<MessagesLast30Days>0</MessagesLast30Days>
</MMSSentMMSC>

<MMSSentVASP>
<MessagesToday>0</MessagesToday>
<MessagesLast7Days>0</MessagesLast7Days> <MessagesLast30Days>0</MessagesLast30Days>
</MMSSentVASP>

<MMSRetrieved>
<MessagesToday>0</MessagesToday>
<MessagesLast7Days>0</MessagesLast7Days>
<MessagesLast30Days>0</MessagesLast30Days>
</MMSRetrieved>

<SMPPClientList>

<ActiveConnectionCount>2</ActiveConnectionCount>
<ActiveConnection>
<Name>micro</Name>
<ConnectionType>S</ConnectionType>
<IPAddress >192.168.1.114</IPAddress>
</ActiveConnection>

<ActiveConnection>
<Name>micro</Name>
<ConnectionType>R</ConnectionType>
<IPAddress >192.168.1.114</IPAddress>
</ActiveConnection>

</SMPPClientList>

</NowSMSStatus>

Most of this information directly correlates to statistics that are displayed on the NowSMS configuration dialog.

NowSMS Java Example: Send MMS Message

2009-02-09T09:09:00.000Z

A Java example for sending MMS messages via NowSMS has been posted at the following link:

http://www.nowsms.com/download/sendmms.java.txt

This class supports all of the MMS related parameters available in NowSMS, most of which are described later in this posting.

For a related PHP script, please see:

http://blog.nowsms.com/2008/11/nowsms-php-example-send-mms-message.html

To use this Java class, begin by creating a new sendmms object, specifying the address of the NowSMS server, and a valid username and password for a user account ("SMS Users") on the NowSMS Server.

sendmms mms = new sendmms ("http://127.0.0.1:8800/", "test", "test");

The addparameter method is used to build the MMS message object.

Start by specifying a recipient using the "PhoneNumber" parameter (this can be a comma delimited list of recipients):

mms.addparameter ("PhoneNumber", "+9999999999");

Next, add any desired MMS header parameters, such as the message subject using the "MMSSubject" parameter, or an optional text part of the message using the "MMSText" parameter:

mms.addparameter ("MMSSubject", "This a a test message");
mms.addparameter ("MMSText", "test message"); // Optional

Next, add the file objects for the MMS content using the "MMSFile" parameter.

mms.addparameter ("MMSFile", new File("f:\\temp\\test.jpg"));
mms.addparameter ("MMSFile", new File("f:\\temp\\test2.jpg"));

(Note: Remember to escape the "\" character as "\\" in your Java code.)

The send method submits the MMS message to NowSMS.

mms.send ();

The send method returns a string containing the MMS Message ID assigned for the submitted messages, in the following format:

MMSMessageID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Note that a try/catch exception handler must be added around the object. Here's a complete example:

try {
sendmms mms = new sendmms ("http://127.0.0.1:8800/", "test", "test");
mms.addparameter ("PhoneNumber", "+9999999999");
mms.addparameter ("MMSSubject", "This a a test message");
mms.addparameter ("MMSText", "test message"); // Optional
mms.addparameter ("MMSFile", new File("f:\\temp\\test.jpg"));
mms.addparameter ("MMSFile", new File("f:\\temp\\test2.jpg"));
mms.send ();
}
catch(IOException e) {
System.out.println("unable to create new url: "+e.getMessage());
}

The mms.addparameter method can be used to specify any NowSMS URL parameter that is valid for sending an MMS message. For example ... here is an incomplete list of additional parameter fields that can be specfied using the mms.addparameter.

"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.

NowSMS Java Example: Send SMS Message

2009-02-04T19:03:00.004Z

A Java example for sending SMS messages via NowSMS has been posted at the following link:

http://www.nowsms.com/download/sendsms.java.txt

The sendsms class defined in this example can be used to send simple SMS text messages, as well as many types of binary SMS messages, including WAP Push.

The class supports most of the URL paremeters that are defined for NowSMS at the following link:

http://www.nowsms.com/documentation/ProductDocumentation/sending_messages/url_parameters_for_sending_messages.htm

Additionally, the class supports many additional parameters that have been added in newer releases of NowSMS.

NowSMS URL parameters are supported as methods for the sendsms class, with method names matching the URL parameter names, except that all methods are in lower case.

In addition the URL parameter methods, the following additional methods are defined:

sendsms.init();

The init method initialise the SMS message object.

sendsms.server = "http://localhost:8800/";

The server method sets the URL address for the NowSMS server.

sendsms.send();

The send method submits the SMS message to NowSMS. (The send method returns a list of message ids assigned for the submitted message, with one message id per line, in the following format: MessageID=xxxxxxxxxxxxxx.req, Recipient=xxxxxxxxxxxx)

Additional supported methods:

sendsms.user = "username";
sendsms.password = "password";

These methods specify the authorisation credentials of the "SMS Users" account that is submitting the message.

sendsms.phonenumber = "recipient";

This method specifies the recipient phone number to which this message should be addressed. This can be a comma delimited list of recipient phone numbers or a distribution list name.

sendsms.text = "text of message";

This method specifies the text of the message. (Or for WAP Push messages, the text associated with the WAP Push URL.)

sendsms.data = "hexstring";

This method specifies a hex string of binary data for sending a binary SMS message.

sendsms.udh = "hexstring";

This method specifies a hex string of binary data for the User Data Header (UDH) of the SMS message.

sendsms.pid = "PID Value";

This method specifies a hex value representing the SMS Protocol ID (PID) of this SMS message.

sendsms.dcs = "DCS Value";

This method specifies a hex value representing the value of the SMS Data Coding Scheme (DCS) for this message.

sendsms.sender = "Sender";

This method specifies the sender (source) address to be specified for this message. (Note: It is not possible to override the sender address when sending messages via a GSM modem.)

sendsms.smscroute = "route name";

This method specifies an outbound SMSC route to be used for the message. (For more information on SMS message routing, see http://blog.nowsms.com/2008/07/routing-sms-messages-to-specifc-smsc.html.)

sendsms.receiptrequested = "Yes"';

This method can be used to request a delivery receipt.

sendsms.sourceport = "3333";
sendsms.destport = "3333";

These methods can be used to specify source and destination ports for routing the SMS message to a specific application on the recipient mobile phone. (For more information, see http://blog.nowsms.com/2007/06/send-sms-to-java-appmidlet.html.)

sendsms.delayuntil = "YYYYMMDDHHMM";

This method allows messages to be submitted to NowSMS and queued for later processing. The value of this parameter should be of the format "YYYYMMDDHHMM", indicating the date and time until which the message should be delayed, where YYYY is the year, MM is the month, DD is the day, HH is the hour (in 24 hour format), and MM is the minutes.

sendsms.wapurl = "http://x/path";

Specifies that the a WAP Push message should be sent, and this is the URL to be sent in the WAP Push message.

Examples

Example - Sending a simple text message:

sendsms.init();
sendsms.server = "http://127.0.0.1:8800/";
sendsms.user = "test";
sendsms.password = "test";
sendsms.phonenumber = "+9999999999";
sendsms.text = "This is a test message";
sendsms.send();

Example - Sending a text message to a specific application port for a Java applet running on the phone:

sendsms.init();
sendsms.server = "http://127.0.0.1:8800/";
sendsms.user = "test";
sendsms.password = "test";
sendsms.phonenumber = "+9999999999";
sendsms.text = "This is a test message";
sendsms.destport = "3333";
sendsms.send();

Example - Sending a WAP Push Message:

sendsms.init();
sendsms.server = "http://127.0.0.1:8800/";
sendsms.user = "test";
sendsms.password = "test";
sendsms.phonenumber = "+9999999999";
sendsms.text = "This is a test message";
sendsms.wapurl = "http://www.nowsms.com/";
sendsms.send();

Connecting to an Operator MMSC with MM7

2009-02-02T11:11:00.001Z

While NowSMS can function as an MMSC for direct MMS message delivery, this is not an option for most content providers, as most mobile operators block MMS message delivery from any MMSCs other than the mobile operator. In these situations, it is necessary to submit all MMS messages via an operator MMSC, or a service provider with operator MMSC connectivity. (For more information on how MMS works, and how external MMSC message delivery is blocked by a mobile operator, please see http://www.nowsms.com/howmmsworks.htm.)

The following protocols are frequently used for submiting messages via an operator MMSC:

MM1 - This is the protocol that mobile phones use for sending and receiving MMS messages. NowSMS has the ability to send and receive MMS messages using MM1 over a GPRS/EDGE/3G modem connected to an operator network, using the same protocols as the MMS client in a mobile phone. This capability is dicussed in more detail at http://www.nowsms.com/documentation/ProductDocumentation/mms_notifications_and_content/Connecting_to_operator_MMSC.htm.

EAIF - This is a variation of the MM1 protocol defined by Nokia. It does not require a GPRS modem, as connections to the mobile operator MMSC occur directly over TCP/IP with an HTTP-based protocol. A few mobile operators with existing Nokia MMSC installations prefer to use the EAIF, but it is expected that they will be migrating to the more standard MM7 protocol.

MM4 - This is an SMTP based protocol that is normally used by mobile operator for interconnecting their MMSCs. It is unusual for a content provider to interface with a mobile operator using MM4, but it is possible. More information on configuring NowSMS for interoperator MM4 connections can be found in the following article: http://blog.nowsms.com/2008/06/mmsc-mm4-interconnection-basics.html

MM7 - This is the MMS protocol that has been designed explicitly for the purpose of content providers interfacing with a mobile operator MMSC. The MM7 protocol uses SOAP-based XML transactions over HTTP.

A simple example of an MM7 message submission can be found at the following link: http://www.nowsms.com/documentation/ProductDocumentation/mms_notifications_and_content/Submitting_MMS_Messages_MM7.htm

For detailed information on the MM7 protocol, refer to the 3GPP TS 23.140 specification, which defines the overall MMS architcture, and the detailed technical realisation of the MM7 protocol. Different versions of the 3GPP TS 23.140 specification 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. (Note: There are a few operator MMSCs that use earlier MM7 implementations, and there are some subtle differences in the XML schemas for different MM7 releases.)

Configuring NowSMS for an MM7 Connection to a Mobile Operator

With that brief introduction out of the way, let's look at the specifics of configuring NowSMS to connect to a mobile operator with MM7.

In the SMS world, the SMPP protocol is most frequently used for high volume SMS content delivery. Since many MMS content providers are existing SMS content providers, it may help to point out some significant ways in which MM7 differs from SMPP.

With SMPP, it is almost always the content provider that originates the SMPP connection. The SMPP connection is a persistent, always active connection. SMS messages can be sent and received over the same connection.

MM7 is an HTTP-based protocol. Connections are not persistent, but instead are initiated on demand, as required (HTTP keep-alive sockets are used to avoid re-connection overhead if many messages are being submitted in bulk). When a content provider has a message to send, it initiates a new connection (unless a keep-alive connection is available) to the mobile operator to submit the message. When the mobile operator has a message to deliver to the content provider, the mobile operator initiates a connection to the content provider.

To establish an MM7 connection to a mobile operator or service provider for sending MMS messages, the following information is required at a minimum:

MM7 Server URL: This will be a complete URL string, such as http://host.name:port/servlets/mm7receiver. (In some cases, only http://host.name:port/ will be required, but often there is additional path information required in the URL in order to activate the correct application at the provider.)

Any required account information: Frequently your provider will specify VASPID, VASID and/or Service Code values that you will need to use. You may also be assigned a short code.

Other helpful information: If they can tell you the vendor of their MMSC, this can be helpful in determining the correct protocol versions to be used. It also helps if they can tell you the MM7 version number and schema that they support. Unfortunately, frequently this information is not available to you, and a successful configuration will require some trial and error.

Additionally, the mobile operator will most likely need to know your IP address so that they can open their firewall to allow you to connect to their system. In most instances, you will be identified/authorised based upon your IP address.

You define an MM7 connection under the "MMSC Routing" section of NowSMS. On that screen, press the "Add" button to add a new MM7 connection.

"Account Name" and "Account Description" are internal account names used only within NowSMS, so you can use any values here.

"Default Sender Address" refers to the sender address that will be applied to messages that you send out. You can set a default value for this sender address here, which would normally be your short code.

If "Allow Sender Address Override" is UNchecked, this means that all messages you send out will have the "Default Sender Address" applied as the sender address. If it is checked, then this means that you can specify different sender addresses when you send out messages.

"Route Messages to VASP via" should be "MM7", since that is the protocol being used.

"Server Address" refers to the path on their server to which you should submit messages using MM7. This is the MM7 Server URL that we referred to earlier.

"Login Name" and "Password" refer to a username and password that can be sent to the server when you submit messages. If these parameters are set, NowSMS will send these parameters with "HTTP Basic Authentication" (e.g., "Authorization: Basic" header). Note that in our experience, very few providers actually use this for user identification, instead authenticating based upon your IP address and "VASP ID", "VAS ID" and/or "Service Code" values. It is not unusual for several of these fields to be left blank. If your provider has given you "VASP ID", "VAS ID" and/or "Service Code" values to use, then normally the "Login Name" and "Password" fields are left blank.

Set "Connection Type" to be "To MMSC (submit format)", as you will be submitting MMS messages to the provider for outbound delivery. (The "Default" would also work, but it is safer to be explicit with this setting.)

The remaining settings can probably be left at their defaults, unless the provider has given you information about their preferred MM7 version or schema.

If the operator is using an Ericsson or LogicaCMG MMSC, it may be necessary to specify one of the "Non-Standard MM7 Variations" defined for these manufacturers. (Hopefully these vendors have adapted their products to use the standard MM7 protocol, but past releases have used MM7-like protocols that do not match the schemas defined by the 3GPP.)

Press "Ok" to save the settings, and then when you get back to the "MMSC Routing" screen, select this route as the "Default Route" and press "Apply" to save.

Now ... any messages that you submit via NowSMS will be routed via this MM7 connection.

At this point, it's a good idea to go to the NowSMS web interface and try sending an MMS message. Before you do that, enable the "MMSCDEBUG.LOG" on the "Serial #" page of the NowSMS configuration dialog. Because there are so many different MM7 protocol versions and options, and confusion over MM7 Server URLs, there is a good chance that your first message sending attempt will not be successful.

After you submit a message, the "MMSCDEBUG.LOG" will contain details about any message sending attempts. We can further analyse this information to make suggestions regarding configuration options. For assistance, please post a message on the NowSMS Discussion Board.

Note that the above only covers sending MMS messages through your provider. It does not cover how you receive MMS messages from your provider.

To receive MMS messages from the service provider, you will need to take the following steps:

Recall from the discussion above, that the service provider actually initiates a connection to your NowSMS system to deliver MMS messages (or even delivery receipts).

To enable such a connection to occur, it is necessary to define an account on the "MMSC VASP" page of the NowSMS configuration dialog. This defines an account on your system that your service provider will use when connecting to your system.

The "Account Name" and "Password" fields can be set to any values that you desire, as they will be used to build the URL that the mobile operator uses to connect to your system to deliver MMS messages.

The "Account Description" field is informational only, and is not used.

"IP Address Restrictions" can contain a comma delimited list of IP addresses from which the mobile operator is allowed to connect. (You will need to ask the mobile operator for a list of IP addresses used by their server.)

"Accept Connections via" should be set to MM7.

"VASP Sender Address" should be left blank.

"Allow Sender Address Override" should be checked.

The remaining settings can be left at their default values.

The mobile operator will connect to you (delivering received messages via MM7) using the following URL format:

http://host.name:port/mm7/account=password

"host.name" is the IP address or host name of your NowSMS server.

"port" is the "HTTP port" on the "MMSC" page of the configuration dialog".

"account" is the "MMSC VASP" account name, and "password" is the password associated with that account.

For more information on how to process any received MMS messages, please see http://www.nowsms.com/documentation/ProductDocumentation/2_way_mms_support.htm.

Also, there is an ability to route received messages to a PHP script, which is described at the following link: http://www.nowsms.com/support/bulletins/tb-nowsms-016.htm

Dynamic SMS Message Routing with HTTP Callbacks

2009-01-28T16:10:00.004Z

If you need control over routing to particular SMSC connections, the logic that NowSMS uses for SMS message routing is described in detail in the following article: http://blog.nowsms.com/2008/07/routing-sms-messages-to-specifc-smsc.html

For some installations, the routing control offered by NowSMS does not provide enough control.

For these installations, an HTTP based callback exists which allows an external application to specify the desired SMS message routing. This callback exists only in NowSMS 2009 and later releases. NowSMS 2009 is currently available as a release candidate via the download link http://www.nowsms.com/download/nowsms2009.zip.

The SMS message routing callback is an extension of the existing SMS accounting callbacks, which are described in the following article: http://www.nowsms.com/support/bulletins/tb-nowsms-001.htm

In NowSMS 2009 and later releases, the "SMS Send Accounting Callback" has been extended so that the response to the callback can include routing information for the SMS message.

The SMS Accouting callback URL is defined in the SMSGW.INI file, under the [SMSGW] section header:

SMSAccountingURL=http://server.name/path

The variables listed in the sections below will be added to the SMSAccountingURL when the URL is executed by the gateway as HTTP GET (CGI-style) parameters.

SMSSend PreAuth Callback

This callback is executed when an SMS (web, SMPP, SMTP) user is requesting to send a message.

This is a “pre-authorisation” request, and does not mean that the message will actually be accepted by NowSMS for delivery. If NowSMS cannot successfully connect to the accounting URL, or the URL returns a response other than a standard “HTTP 200 OK” response, the user request to send a message will be blocked. A “PreAuth” request to send a message will also be blocked if the response includes the text “PreAuth=Deny”.

The following variables will be set for a pre-authorisation request:

PreAuth=Yes (indicates that the message is a Pre-Authorisation Request)
Type=SMSSend
From=Defined "SMS Users" Account
To=Comma delimited list of message recipients (will not be present if message is addressed to more than 100 recipients)
MsgCount=#### (number of recipients user is requesting to send the message to)
SubmitIP=a.b.c.d
SMSCRoute=xxxxxx (optional, will be present only if an explicit route was requested in message submission)
Sender=xxxxxx (optional, will be present only if a sender address was specified in message submission)
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
ReceiptRequested=Yes (optional, will be present only if message is requesting a delivery receipt ... only available in v2009.01.26 and later)

(Note: For SMTP message submissions, only PreAuth, Type, From, To and MsgCount variables will be present.)

Example:

http://server.name/path?PreAuth=Yes&Type=SMSSend&From=UserAccount&To=%2B447777777777&MsgCount=1&SubmitIP=127.0.0.1&Text=This%20is%20a%20test.

Note that URL escaping is performed when building the URL string. Most HTTP scripting languages will automatically unescape these parameters for you (e.g., %2B is translated back to "+" and %20 is translated back to a space character).

SMSSend Accounting Callback

This callback is executed after an SMS message that has been sent by an SMS user has been accepted by the gateway for delivery.

In NowSMS 2009 and later, NowSMS will check the response to the HTTP request. If this response includes the text "SMSCRoute=xxxxx", then NowSMS will apply this SMSC route for the message. The specified route "xxxxx" can either be the name of a particular SMSC connection (e.g., "SMPP - host:port"), or it can be the value of the "RouteName=" attribute defined for one or more connections. (For more information on the "RouteName=" attribute, see http://blog.nowsms.com/2008/07/routing-sms-messages-to-specifc-smsc.html.)

The following variables will be set for the accounting callback:

Type=SMSSend
From=Defined "SMS Users" Account
To=Message Recipient Phone Number (if the message is sent to multiple recipients, this callback is repeated for each recipient)
MessageID=Message ID assigned to the message by NowSMS
SubmitIP=a.b.c.d
SMSCRoute=xxxxxx (optional, will be present only if an explicit route was requested in message submission)
Sender=xxxxxx (optional, will be present only if a sender address was specified in message submission)
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
ReceiptRequested=Yes (optional, will be present only if message is requesting a delivery receipt ... only available in v2009.01.26 and later)

(Note: For SMTP message submissions, only Type, From, and To variables will be present.)

Example:

http://server.name/path?Type=SMSSend&From=UserAccount&To=%2B447777777777&SubmitIP=127.0.0.1&Text=This%20is%20a%20test.

Note that URL escaping is performed when building the URL string. Most HTTP scripting languages will automatically unescape these parameters for you (e.g., %2B is translated back to "+" and %20 is translated back to a space character).

TON and NPI Settings for SMPP and UCP/EMI

2009-01-22T16:35:00.003Z

One of the most confusing issues involved in setting up an SMSC connection is when your SMS service provider requires specific TON (type of number) and NPI (numbering plan identification) values.

In the majority of cases, you can ignore any requirements that your provider has for these settings, because NowSMS uses intelligent default values.

For SMPP environments, these are the rules that NowSMS follows for setting the source_addr_ton and source_addr_npi values (e.g., TON and NPI for the sender address):

If the sender address is alphanumeric (contains both letters and numbers), TON is set to 5 and NPI to 0.

If the sender address is a short code, TON is set to 3, and NPI is set to 0. (By default, a number is considered to be a short code if the length of the number is 5 digts or less. You can change this length setting by editing SMSGW.INI, and under the [SMSGW] header specifying MaxSMPPShortCodeLen=#, where # is the max length of a short code.)

If the sender starts with a "+", TON is set to 1, and NPI is set to 1.

If none of the above conditions is met, TON is set to 0 and NPI is set to 1 (unless the sender is blank, in which case both are set to 0).

For setting the destination TON and NPI (dest_addr_ton and dest_addr_npi), only the condition of whether or not the recipient phone number starts with the international prefix of "+" is considered.

If the recipient starts with a "+", TON is set to 1, and NPI is set to 1.

Otherwise, TON is set to 0 and NPI is set to 1.

What do these values mean anyway, and why are they important?

Basically, they tell the SMSC how to interpret the address. The SMPP specification defines the following TON values:

Unknown = 0
International = 1
National = 2
Network Specific = 3
Subscriber Number = 4
Alphanumeric = 5
Abbreviated = 6

These definitions are derived from the ETSI GSM 03.40 specification, which defines the SMS protocol.

The only unusual observation that might be made regarding NowSMS defaults is that if a number is expressed without a "+" sign, NowSMS defaults to using a TON value of 0, or unknown. While this may seem unusual, it actually makes sense because NowSMS is telling the SMSC that the SMSC should use its own internal rules for making a determination of the number type.

Possible NPI values are defines as follows:

Unknown = 0
ISDN/telephone numbering plan (E163/E164) = 1
Data numbering plan (X.121) = 3
Telex numbering plan (F.69) = 4
Land Mobile (E.212) =6
National numbering plan = 8
Private numbering plan = 9
ERMES numbering plan (ETSI DE/PS 3 01-3) = 10
Internet (IP) = 13
WAP Client Id (to be defined by WAP Forum) = 18

So, generally speaking, 1 is the correct value. If the sender address is alphanumeric or shortcode, NowSMS uses 0 (it might also be argued that a short code could be considered part of a private numbering plan, but convention seems to expect a value of 0).

If the default TON and NPI settings for NowSMS are not appropriate for your environment, it is is possible to configure these settings under the "Advanced Settings" option in the "Properties" for an SMPP connection.

NowSMS allows the Source and Destination TON and NPI values to be hardcoded via these settings.

Additionally, SMPP has a concept of a Bind TON and NPI, which is addr_ton and addr_npi values that are sent as part of the bind operation during which NowSMS initially binds/connects to the SMS service provider. These values would normally only be used if the provider requires an address_range parameter for specifying the numbers for which you are receiving messages. If your provider requires specific bind addr_ton, addr_npi and/or address_range parameters, then they should be configured in the "Properties" of the SMPP connection definition within NowSMS.

What about UCP/EMI environments?

Well, the UCP/EMI protocol also defines TON and NPI parameters.

However, while SMPP uses the same TON and NPI parameter values as used in the actual SMS specifications, UCP/EMI uses different values.

In the UCP bind (e.g., connect or login), there are OTON and ONPI (originator TON and NPI) values that are specified. NowSMS is hard coded to use values of OTON=6 and ONPI=5. (We've yet to see a situation that required these values to be configurable.)

TON and NPI values are not specified for sender (source/originator) and recipient (destination) addresses, like they are in SMPP environments. Instead, UCP/EMI has a concept of a OTOA (orignator type of address) parameter which has a similar purpose. When setting the OTOA value, NowSMS sets the value appropriately to indicate whether the sender address is alphanumeric, international (starts with "+"), or numeric.

Sending WAP Push and Binary SMS from the Command Line

2009-01-12T18:05:00.003Z

In past postings, we've provided a variety of command line script examples that make it easy to interface with NowSMS from a command line interface.

The original command line interface, designed to send standard text messages can be found at the following link: http://www.nowsms.com/support/bulletins/tb-nowsms-008.htm

A script to enable sending MMS messages from a command line interface was published at the following link: http://blog.nowsms.com/2007/07/sending-mms-from-command-line.html

And a script to enable sending OMA Client Provisioning Content (XML Settings) was published at the following link: http://blog.nowsms.com/2007/07/send-oma-client-provisioning-ota-xml.html

All of these scripts can be executed from a standard command line interface, making it easy to interface with NowSMS from a variety of different environments.

However, suppose you want to send WAP push messages or other types of binary SMS messages from a command line interface? It is relatively easy to adapt the other examples for this purpose, but we decided to provide an example to make it even easier.

Download the Windows script file sms2.js from http://www.nowsms.com/download/sms2.js.txt. (Right click and save this file as sms2.js.)

Assuming that the script file is saved as a file named sms2.js, you would issue the following command:

cscript sms2.js PhoneNumber1[,PhoneNumber2,...] NowSMSURLParameter1=Value1 [NowSMSURLParameter2=Value2] [NowSMSURLParameterN=ValueN]

(cscript.exe is the Windows Script Host, which is a component of Windows which should be located in the \Windows\System32 directory.)

NowSMSURLParameter1=Value1 can be any of the URL parameters documented for NowSMS at http://www.nowsms.com/documentation/ProductDocumentation/sending_messages/url_parameters_for_sending_messages.htm.

However, one difference from the URL parameter interface is that this script will perform any necessary URL escaping to simplify the user interface to the script.

Multiple URL parameters can be specified via this command line interface.

For example, to send a WAP push message, the following command could be used:

cscript sms2.js +44777777777 WAPURL=http://www.nowsms.com "Text=This is a test push"

In this example, because the "Text=" parameter includes spaces, we put quotes around the paramter and value, so that it is recognised as a single parameter value combination.

A simpler example would be sending a message to turn on the voice message waiting indicator (MWI):

cscript sms2.js +44777777777 VoiceMail=On

Or, if you have a pre-constructed binary message, you can directly specify the UDH and Data parameters, such as in the following example:

cscript sms2.js +44777777777 Binary=1 UDH=080D0200040B020007 Data=20 DCS=8

A more complex example would be sending an EMS message. NowSMS defines simple mark-up tags for inserting attributes into an EMS text message. For example, "This is a <b>test</b>!" encodes the text with "test" highlighted as bold on supported EMS compatible phones.

Unfortunately, the "<" and ">" characters are used for input/output redirection from the Windows command line. Therefore to include those characters in a command line string, it is necessary to preface the character with the escape character "^".

To send this EMS message, the following command line would be used:

cscript sms2.js +44777777777 "EMSText=This is a ^<b^>test^</b^>!"

NowSMS PHP Example: Send MMS Message

2008-11-13T10:00:00.001Z

Continuing our series of PHP examples, today we'll revisit sendmms.php, which we originally published on our discussion board 5 years ago at http://www.nowsms.com/discus/messages/1/1113.html.

The sendmms.php script is considerably more complex than the sendsms.php script. The reason for this increased complexity is because an MMS message is more complex than an SMS message.

However, I have to admit that our 5 year old example can be a little difficult to follow. Over the years, I've answered quite a few questions about the script, as the way that you specify the files to include in the MMS message is a little confusing.

So in this posting, we'll update sendmms.php, and make it a little easier to follow.

The updated sendmms.php can be downloaded at http://www.nowsms.com/download/sendmms-php.txt.

The first part of sendmms.php consists of PHP functions that you will call in your PHP script ... namely MmsInit, MmsAddField, MmsAddFile and MmsSend. Include these functions in your script without editing them.

After these functions are defined, sendmms.php contains a simple example showing how to use these functions to send an MMS message through a NowSMS server.

1.) First, you need to initialise the parameters to point to your NowSMS server:

/* Set parameters for connecting to the NowSMS server */
$nowsmsHostName = "127.0.0.1"; /* IP Address or host name of NowSMS Server */
$nowsmsHostPort = "8800"; /* NowSMS Port number for the web interface */
$nowsmsUsername = "test"; /* "SMS Users" account name */
$nowsmsPassword = "test"; /* "SMS Users" account password */

2.) Second, you need to call MmsInit to initialise the MMS message structure.

$mmsMessage = MmsInit();

3.) Third, you need to add the necessary MMS header fields and attributes desired for your MMS message, calling the MmsAddField fuction.

$mmsMessage = MmsAddField ($mmsMessage, "PhoneNumber", "+447777777777");
$mmsMessage = MmsAddField ($mmsMessage, "MMSFrom", "sender@domain.com");
$mmsMessage = MmsAddField ($mmsMessage, "MMSSubject", "Subject of Message");

The "PhoneNumber" field specifies the recipient(s) for the MMS message. This can be a comma delimited list of phone numbers, or it can be the name of a NowSMS distribution list.

The "MMSFrom" field specfies the sender of the MMS message. Normally, this would be a phone number, short code or e-mail address. (And your MMS service provider may either require a specific value here, or they may overwrite the value you supply with the address associated with your service.)

The "MMSSubject" field specifies the subject of the MMS message.

Those are the most common MMS header fields. Optionally, you might also want to include an "MMSText" field to specify some text to be included in the MMS message. Text can also be included in an MMS message as a text file reference.

4.) Fourth, you specify the files to include in the MMS message using the MmsAddFile function. These files might be images, video, text, or other file types supported by the receiving device.

$mmsMessage = MmsAddFile ($mmsMessage, "f:\\temp\\filename.gif", "image/gif");

An MMS message can contain one or more of these included files. If you do not include a SMIL file component, NowSMS will build one automatically, so for full control of the MMS message presentation, you will want to include your own SMIL file, where you reference your file components by their short filename (without the full path, e.g., filename.gif ... NOT f:\temp\filename.gif).

The files referenced in the PHP script must be local files, residing on the same server as the PHP script. Remember to escape backslashes in the path so as not to confuse the PHP interpreter(c:\temp\file becomes c:\\temp\\file).

The last parameter of MmsAddFile is the MIME content type, e.g., "image/gif", "image/jpeg", "image/png", "text/plain" or "application/smil" ... however, note that current versions of NowSMS ignore the MIME content type when messages are submitted via the interface used by this PHP script. Instead, NowSMS uses the file extension to determine the content type (e.g., ".gif", ".jpg", ".png", ".txt", ".smil").

5.) Fifth and finally, you call MmsSend to submit the MMS message.

MmsSend ($nowsmsHostName, $nowsmsHostPort, $nowsmsUsername, $nowsmsPassword, $mmsMessage);

Those are the basics.

For the curious, the MmsAddField function can be used to specify any NowSMS URL parameter that is valid for sending an MMS message.

For example ... here is an incomplete list of additional parameter fields that can be specfied using the MmsAddField function.

"MMSFile" - As I've noted above, this script attaches local files to the MMS message. However, what if you want to include files that reside on a separate web server instead? In that case, do not use the MmsAddFile function. Instead, use $mmsMessage = MmsAddField ($mmsMessage, "MMSFile", "http://www.nowsms.com/media/logo.png" ); and specify the file components as URL references via the "MMSFile" parameter field.

"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.

NowSMS Update Available for Test Release

2008-11-05T18:51:00.002Z

Over the past several months, we have been working on some optimisations and performance enhancements to the core SMS message routing logic of the NowSMS product.

These enhancements have been geared primarily toward supporting higher volume messaging environments with speed requirements of 400 messages per second and higher.

These core performance enhancements are also of interest to other high speed, but not-quite-as-high-speed environments for a variety of reasons.

1.) Requesting delivery receipts for all (or most) messages can put an increased strain on the system, with previous versions of NowSMS peaking at speeds of 150 to 200 messages per second when delivery receipts are requested, and sometimes with a queued backlog of receipt processing. Performance is easily doubled in this update, and the queue backlog has been eliminated.

2.) 2-way SMS command performance has been optimised, particularly for HTTP based commands, allowing an HTTP based command to easily keep up with burst rates of hundreds of messages per second. (For more preliminary information, see http://www.nowsms.com/discus/messages/1/24486.html.)

3.) CPU load with large numbers of outbound messaging routes. Historically, the more outbound routes defined to NowSMS, the higher the CPU load, especially if there is a large volume of queued messages waiting for a small number of routes. The routing logic has been dramatically improved to reduce CPU load.

4.) If you use HTTP-based accounting callbacks for billing or accounting, they may be significantly limiting your overall message throughput. The new release uses HTTP keep-alive sockets and optimised logic to improve throughput when accounting callbacks are enabled.

There are also a number of new features in this release. A list of features and enhancements from the readme file can be found at the end of this message. However, the primary focus of this NowSMS update is performance.

We've completed our internal testing of this update. However, because there were a large number of internal changes, optimisations and fixes, we are going to make this version available as a test release before general release.

We're quite confident that this release is actually more stable and robust than previous versions. We know the performance and CPU overhead is much improved. We know that overall disk I/O has been reduced. And we know several rather significant bugs that have been fixed in this release. But, the problem with bugs is they are very much configuration dependent, and with such a large number of configuration options, we may have missed something that affects articular configurations, so we want to get some more feedback.

For this reason, we're going to go ahead and make this update available in a testing release prior to a more general release.

This update can be downloaded at http://www.nowsms.com/download/nowsms200811.zip.

A full list of changes can be found in the readme file included with this release, or is also avaialble at the following link: http://www.nowsms.com/discus/messages/53/24488.html

We will be detailing some of the other enhancements in future postings here, but here is a brief overview of some of the more significant features:

1.) Enhanced SMS Message Routing Logic - Recipient address masks can now specify addresses to exclude from the selected route, in addition to the existing inclusive logic. Additionally, the SMPP service_type value can be used as a basis for SMS message routing. Some additional preliminary information can be found in the following message thread: http://www.nowsms.com/discus/messages/1/24460.html

2.) Dynamic SMS Message Routing Callbacks - This capability is long overdue! It has been availalble for MMS message routing for some time. Essentially, the existing HTTP accounting callbacks have been extended to allow the callbacks to dynamically specify which outbound route should be used for SMS message routing. Some additional preliminary information can be found in the following mesasge thread: http://www.nowsms.com/discus/messages/1/23919.html

3.) Explicit SMSC Routing available to SMPP Clients - Perhaps not as signicant as the other enhancements, but it is now possible to give SMPP clients connecting to NowSMS as their SMPP server more control over outbound SMSC routing if desired. Some additional preliminary information can be found in the following message thread: http://www.nowsms.com/discus/messages/1/24485.html

4.) Bug fix that could cause an SMPP client connection to "hang" - See http://www.nowsms.com/discus/messages/1/24483.html

5.) Throttling support for outbound MMS routing speed for external MM7, MM4 or EAIF connections.

6.) Enhanced support for the "mailto:" command as used in 2-way commands for routing received SMS messages to e-mail. Additional preliminary information can be found in the following message thread: http://www.nowsms.com/discus/messages/1/24428.html.

7.) More flexibility in controlling message retry behaviour in UCP/EMI and CIMD environments, as described in the following post: http://blog.nowsms.com/2008/10/sms-retry-error-handling-with-ucpemi.html

8.) Delivery receipts are now supported for UCP/EMI and CIMD environments, with NowSMS automatically translating message receipts for those environments into SMPP format to simplify processing.

9.) MMSC/MM4 Enhancements for improved real-world compatibility with more MMS interconnect services.

MMS Conversion to SMS With Web Link

2008-10-23T09:00:00.000Z

When using the NowSMS MMSC, one of the MMS routing options is to convert an MMS message to an SMS message with a web link.

This setting is most often used in operator MMSC configurations for one or more of the following configurations:

1.) Delivering an MMS message to a mobile phone that does not support MMS. (This is most frequently used in conjunction with auto-provisioning, where MMS compatible phones are automatically provisioned on the NowSMS MMSC. For more information on auto-provisioning, please see http://www.nowsms.com/support/bulletins/tb-nowsms-002.htm.)

2.) Delivering an MMS message to an international recipient for which there is no available MMS interconnection.

3.) It is also possible to configure a delay period where any pending MMS messages are converted to SMS messages with a web link if it is not retrieved within a configurable timeout.

This article will describe configuration settings relevant to one or more of these scenarios.

Sending MMS Message – Convert to SMS with Web Link

The "MMSC Routing" page of the NowSMS configuration defines all external routes for MMS message delivery.

The NowSMS MMSC will always perform direct MMS delivery as an MMSC for any subscribers that are registered with the MMSC. These subscribers could be manually or automatically provisioned, and they will be listed on the "MMSC Users" page of the NowSMS configuration.

Routing for MMS message recipients that are not subscribers of the MMSC is defined on the "MMSC Routing" page of the NowSMS configuration.

The routing type "Convert to SMS with Web Link" defines that any MMS messages sent via this route should be converted to an SMS message that includes a link to a web page where the recipient can go to retrieve the content of the MMS message.

For example, when sending an MMS message to a recipient that does not have an MMS compatible phone, or to an international recipient to which there is no available MMS interconnection, the recipient can instead receive an SMS message similar to the following:

Multimedia message from +4477777777. To view, go to http://mms.operator.com, and enter code number 1234.

The recipient can then navigate to the web link using a WAP browser on a mobile phone, or a web browser on a PC. They will be prompted for their phone number and the code number that was supplied in the SMS message. After entering that information, the message content will be displayed in the browser.

Frequently, this type of route is configured as a default route, which means that this route is used if a recipient was not in the "MMSC Users" list, and not covered by a recipient address mask in another "MMSC Routing" definition.

The following configuration settings are required for this type of routing:

"Local Server Port" specifies an available port number on the PC running NowSMS which will be used to accept connections from recipients who are attempting to connect in to retrieve MMS messages over the web interface. This port number must be different from other port numbers configured for use by NowSMS. This port must be unique, because the only functionality provided through this interface is MMS message retrieval over the web interface. Other NowSMS ports will likely have restricted access via a firewall, however this port needs to be open to the outside world to allow these types of messages to be retrieved.

"Local Server URL" specifies the externally accessible URL that recipients will access to connect to the "Local Server Port" on the MMSC. This setting will default to the "Local Host Name or IP Address" configured for the MMSC, and the "Local Server Port". However, if you are remapping the address and port via a firewall, you should specify the external host name (and port if required) in this field. Keep in mind that some users may be restricted from retrieving content from non-standard web server ports.

"SMS Message Text" is a template for the SMS text message that will be sent out to recipients. This text should consist only of characters that are part of the default GSM character set. And it should include the following replaceable text parameters:

@@PhoneNumber@@ will be replaced with the phone number of the message sender.
@@Server@@ will be replaced with the value configured for "Local Server URL".
@@Code@@ will be replaced with a code number that the recipient must enter in order to retrieve the MMS message content.

The default text for this message is:

"Multimedia message from @@PhoneNumber@@. To view, go to @@Server@@ and enter code number @@Code@@."

"Use MMS Sender as SMS Sender" - This option specifies that the SMS message that is sent out should use the sender address from the original MMS sender, if the original MMS sender was a phone number.

Web Link Template Files

HTML (XHTML Basic) and WML template files are used to construct the login page and message files generated by this facility.

These template files must be located in a subdirectory of NowSMS named "MMSSMS".

The templates for the login page are LOGIN.WML and LOGIN.HTM.

The templates for message file creation are MSGTEMPLATE.WML and MSGTEMPLATE.HTM.

These templates can also reference GIF or JPEG files that are located in the same "MMSSMS" directory. The default templates make use of two GIF files, CLOSE.GIF and OK.GIF.
NowSMS will automatically load either the WML or HTML (XHTML Basic) template, based upon the capabilities of the device.

Converting to SMS with Web Link After a Delay

It is also possible to configure the MMSC such that it if an MMS message is not retrieved from the MMSC within a configurable timeout period, the MMSC will then convert the message to SMS, sending a text SMS message to the recipient, with a URL like that can be used from either a phone or PC browser, to retrieve the content of the message.

To enable this SMS conversion, it is necessary to define an "MMSC Routing" of the type "Convert to SMS web Web Link", as described above.

Once that routing is defined, edit MMSC.INI, and add the following settings under the [MMSC] header:

UndeliverableRouteToSMS=VASPOutboundRouteName

Specifies the name of an MMSC Outbound Route that is defined in the "MMSC Routing" list, which must be of the type "Convert to SMS with Web Link". By default, if an MMS message has not been retrieved within 120 minutes, the message will be rerouted to be sent as an SMS with a web link for accessing the MMS content.

UndeliverableRouteToSMSTimeout=####

#### is a value in minutes that changes the time period after which the UnderliverableRouteToSMS setting is applied.