Thursday, 9 July 2009

Introducing NowSMS Lite

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:


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.


Tuesday, 30 June 2009

SMSGW.INI and MMSC.INI Advanced Parameters

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

Friday, 22 May 2009

MM7 Schemas and MMS Version Number Confusion, revisited

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

Thursday, 7 May 2009

MMSC Accounting Callbacks for Billing and Charging

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

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.

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.

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.



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.

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.

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.

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.

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

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



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

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




MMSEMail PreAuth Callback

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

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

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.



Tuesday, 7 April 2009

Missing Text Parts from MMS Messages

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.