Categories
Mobile Networks RFCs & Standards

MMS Deep Dive – MM1 – Mobile Originated MMS

A deep dive into Mobile Originated MMS via the MM1 Interface

So you want to send a Multimedia Message (Aka MMS or MM)?

Let’s do it – We’ll use the MM1 interface from the UE towards the MMSc (MMS Service Center) to send our Mobile Originated MMS.

Transport & Creation

Out of the box, our UE doesn’t get told by the network anything about where to send MMS messages (Unless set via something like Android’s Carrier Settings).
Instead, this is typically configured by the user in the APN settings, by setting the MMSc address (Typically an FQDN), port (Typically 80) and often a Proxy (Which will actually handle the traffic).
Lastly under the bearer type, if we’re sending the MMS on the default bearer (the one used for general Internet) then the bearer type will need to change from “default” to “default,mms”. Alternately, if you’re using a dedicated APN for MMS, you’ll need to set the bearer type to “mms”.

With the connectivity side setup, we’ll need to actually generate an MMS to send, something that is encapsulated in an MMS – so a picture is a good start.

We compose a message with this photo, put an address in the message and hit send on the UE.

The UE encapsulates the photo and metadata, such as the To address, into an HTTP POST is sent to the IP & Port of your MMSc (Or proxy if you have that set). The body of this HTTP POST contains the MMS Message Body (In this case our picture).

Our MMSc receives this POST, extracts the headers of interest, and the multimedia message body itself (in our case the photo) ready to be forwarded onto their destination.

PCAP Extract showing MMS m-send-req from UE

Header Enrichment / Charging / Authentication

One thing to note is that the From header is empty.

Often times a UE doesn’t know it’s own MSISDN. While there is an MSISDN EF on the SIM file system, often this is not updated with the correct MSISDN, as a customer may have ported over their number from a different carrier, or had a replacement SIM reissued. There’s also some problems in just trusting the From address set by a UE, without verifying it as anyone could change this.

The MMS standards evolved in parallel to the 3GPP specifications, but were historically specified by the Open Mobile Alliance. Because it is at arms length with 3GPP, SIM based authentication was not used on the MM1 interface from a UE to the MMSc.

In fact, there is no authentication on an MMS specified in the standard, meaning in theory, anyone could send one. To counter this, the P-GW or GGSN handling the subscriber traffic often enables “Header Enrichment” which when it detects traffic on the MMS APN, will add a Header to the Mobile Originated request with the IMSI or MSISDN of the subscriber sending it, which the MMSc can use to bill the customer.

m-send-req Request

Let’s take a closer look into the HTTP POST sent by the UE containing the message.

Firstly we have what looks like a pretty bulk-standard HTTP POST header, albeit with some custom headers prefixed with “X-” and the Content-Type is application/vnd.wap.mms-message.

But immediately after the HTTP header in the HTTP message body, we have the “MMS Message Encapsulation” header:

MMS Message Encapsulation Header from MO MMS

This header contains the Destination we set in the MMS when sending it, the request type (m-send-req) as well as the actual content itself (inside the Data section).

So why the double header? Why not just encapsulate the whole thing in the HTTP Post? When MMS was introduced, most phones didn’t have a HTTP stack baked into them like everything does now. Instead traffic would be going through a WAP Gateway.

When usage of WAP fell away, the standard moved to transport the same payload that was transfered over WAP, to instead be transferred over HTTP.

Inside the Data section we can see the MIME Type of the attachments themselves, in this case, it’s a photo of my desk:

With all this information, the MMSc analyses the headers and stores the message body ready for forwarding onto the recipient(/s).

m-send-conf Response

To confirm successful receipt, the MMSc sends back a 200 OK with a matching Transaction ID, so the UE knows the message was accepted.

I’ve attached the PCAP here to view / analyse.

2 replies on “MMS Deep Dive – MM1 – Mobile Originated MMS”

Hi Nick,

I was reading another article on your site about CUPS when for a leap of seconds my eyes were surprised by this article here, which recalled my days when I worked closer to WAP, MMS, and also GPRS/EDGE/UMTS related technologies.

There are a lot of weird and funny facts about MMS, just mentioning a couple of them.

The lack of the read-reply messages support on MMS 1.0 standard led some old MMS clients to implement the read-reply submission using the ‘m-send-req’ PDU (a fact that usually caused an unintended charging, since MMSC servers were not capable to perform a message content inspection to try to identify this message workflow).

The SMIL presentation language which was capable to produce enjoyable and funny messages was supported by legacy mobile operating systems, unfortunately, it isn’t supported anymore by Android or Apple iOS MMS clients.

MMS service customers from distinct mobile operators still don’t have the same user experience due to many factors such as different quality levels of content adaptation policies. It was even worse when there were a dozen mobile operating systems.

In the early times, many MMSC servers and even MMS clients and their OS didn’t have strong security policies to avoid virus spread attacks. I remember seeing some PCAP trace files having samples of some Symbian OS virus.

Leave a Reply to Dave Cancel reply

Your email address will not be published.