MM7 Schemas and MMS Version Number Confusion, revisited

Topic Keywords: MM7

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 (https://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 …