MMS carries multimedia messages through an MMSC (relay/server), defined by 3GPP TS 23.140 and OMA MMS. Handsets submit and retrieve over MM1 (WAP/HTTP); MMSCs exchange between carriers over MM4 (SMTP-based); and value-added service providers submit over MM7 (SOAP/XML). Content is MIME multipart with an optional SMIL layout, subject to per-carrier size limits.
The MMSC and the MMS reference architecture
MMS (Multimedia Messaging Service) was specified to carry images, audio, video and rich text where SMS carries only short text. At its centre is the MMSC — the MMS Centre, or MMS Relay/Server — which stores messages, resolves recipients, converts media for the receiving device and bridges to other networks and to email. 3GPP TS 23.140 (with OMA MMS) defines the architecture as a set of numbered reference points, the MMx interfaces, around this MMSC. Each interface connects a different actor — the handset, another operator's MMSC, a value-added service provider, the subscriber database — and uses a protocol suited to that leg, which is why MMS looks like several protocols stitched together rather than one.
| Interface | Between | Transport |
|---|---|---|
| MM1 | Handset (MMS client) ↔ MMSC | WAP / HTTP (MMS encapsulation) |
| MM3 | MMSC ↔ external servers (e.g. email) | SMTP / internal |
| MM4 | MMSC ↔ MMSC (inter-carrier) | SMTP with MMS headers |
| MM7 | VASP / application ↔ MMSC | SOAP / XML over HTTP |
| MM5 / MM6 | MMSC ↔ HLR / user databases | Operator-internal |
MM1: the handset to the MMSC
MM1 is the interface between the MMS client on the handset and its home MMSC, and it is a store-and-notify design. To send, the handset submits the message to the MMSC (an M-Send.req) over WAP or HTTP using the MMS encapsulation encoding. To receive, the MMSC does not push the full message; it sends a WAP push notification (M-Notification.ind), typically triggered by a binary SMS, telling the handset a message is waiting, and the handset then retrieves it (M-Retrieve.conf) over HTTP. This notify-then-fetch pattern lets the network hold large media until the device is ready and is why MMS delivery involves both a signalling nudge and a data download.
Send: Handset --M-Send.req--> MMSC (WAP/HTTP, MMS encapsulation)
Handset <--M-Send.conf-- MMSC
Notify: MMSC --M-Notification.ind--> Handset (WAP push via binary SMS)
Retrieve: Handset --GET (M-Retrieve.conf)--> MMSC (HTTP download of MIME body)
Handset --M-Acknowledge.ind--> MMSCMM4: inter-carrier MMSC-to-MMSC over SMTP
When the sender and recipient are on different networks, the two MMSCs exchange the message over MM4 — and MM4 is built on SMTP. The originating MMSC forwards the message as an RFC 822 / MIME email (an MM4_forward.REQ) to the recipient MMSC, addressing the subscriber and carrying MMS-specific metadata in X-Mms-* headers (message type, transaction ID, message ID, sender address). The receiving MMSC acknowledges with an MM4_forward.RES, and delivery and read reports flow back the same way. Using SMTP as the inter-carrier transport is what lets MMS interwork with email gateways and made cross-operator MMS deployable on existing mail infrastructure, at the cost of SMTP's looser delivery guarantees.
MAIL FROM:<+15551234567/TYPE=PLMN@mms.operator-a.example>
RCPT TO:<+15559876543/TYPE=PLMN@mms.operator-b.example>
X-Mms-3GPP-MMS-Version: 6.10.0
X-Mms-Message-Type: MM4_forward.REQ
X-Mms-Transaction-ID: a1b2c3
X-Mms-Message-ID: <20260718-4021@operator-a>
Content-Type: multipart/related; type="application/smil"; boundary=NEXT
--NEXT application/smil (layout)
--NEXT text/plain (caption)
--NEXT image/jpeg (photo)MM7: the VASP-to-MMSC application interface
MM7 is the interface an application or value-added service provider (VASP) uses to submit and receive MMS through an operator's MMSC — the MMS equivalent of a bulk messaging feed, and the interface behind A2P MMS. Unlike MM1's binary encapsulation or MM4's SMTP, MM7 is a SOAP/XML web service over HTTP: the VASP sends an MM7 SubmitReq with a SOAP envelope carrying recipient addresses, sender identity and message metadata, plus a MIME multipart attachment for the media, and receives a SubmitRsp with a message ID. Delivery and read reports come back as MM7 DeliveryReportReq / ReadReplyReq. This structured, request/response shape is what makes MM7 suitable for high-volume application senders and for platform integration.
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body>
<SubmitReq xmlns="http://www.3gpp.org/ftp/Specs/.../REL-6-MM7-1-4">
<TransactionID>tx-4021</TransactionID>
<SenderIdentification><VASPID>brand</VASPID></SenderIdentification>
<Recipients><To><Number>+15559876543</Number></To></Recipients>
<Subject>Your receipt</Subject>
<Content href="cid:receipt.smil"/>
</SubmitReq>
</env:Body>
</env:Envelope>Content, SMIL and size limits — and MMS vs SMS
An MMS message body is a MIME multipart container: each media part (text, JPEG, audio, video) is a MIME entity, and an optional SMIL document describes the presentation — how the parts are laid out into slides and the timing between them — so a multi-slide message renders consistently. That richness is the whole point of MMS over SMS: SMS is 140 octets on the wire (160 GSM-7 characters) of text only, while MMS carries kilobytes of mixed media. But MMS size is capped by the network, not the spec — carriers commonly enforce a maximum message size (often around 300 KB, sometimes up to roughly 600 KB or 1 MB), and the MMSC transcodes or rejects oversized media to match the receiving device. A2P MMS senders therefore design to the lowest common carrier limit and let the MMSC adapt down.
| Property | SMS | MMS |
|---|---|---|
| Payload | 140 octets (160 GSM-7 chars) | MIME multipart, kilobytes of mixed media |
| Media | Text only | Image, audio, video, rich text + SMIL layout |
| Transport to handset | SS7/SMPP short message | MM1 WAP/HTTP notify + fetch |
| Inter-carrier | SS7 / SMPP | MM4 (SMTP with MMS headers) |
| Application feed | SMPP | MM7 (SOAP/XML) |
| Size limit | Fixed by segment | Carrier-set (commonly ~300 KB) |
Frequently asked
What is an MMSC?
The MMSC (MMS Centre, or MMS Relay/Server) is the core node of MMS. It stores multimedia messages, resolves recipients, converts media for the receiving device, and bridges between handsets, other operators' MMSCs and email. All the MMS reference interfaces (MM1, MM4, MM7 and others) are defined around it in 3GPP TS 23.140 and OMA MMS.
What is the difference between MM1, MM4 and MM7?
MM1 connects the handset to its MMSC over WAP/HTTP using MMS encapsulation. MM4 connects two MMSCs for inter-carrier delivery and is SMTP-based, carrying MMS metadata in X-Mms-* headers. MM7 connects a value-added service provider or application to the MMSC as a SOAP/XML web service, and is the interface behind A2P MMS.
Why does MMS use SMTP between carriers?
MM4, the inter-carrier interface, forwards each message as an RFC 822 / MIME email with MMS-specific X-Mms-* headers. Building on SMTP let MMS interwork with email gateways and deploy on existing mail infrastructure, so cross-operator MMS worked without a bespoke transport — at the cost of SMTP's looser delivery guarantees.
What is SMIL in an MMS message?
SMIL (Synchronized Multimedia Integration Language) is an optional XML document inside the MMS MIME container that describes presentation — how the media parts are arranged into slides and their timing. It lets a multi-slide message with text, image and audio render consistently across devices instead of as a loose bag of attachments.
How big can an MMS message be?
The size limit is set by the carrier, not the specification. Networks commonly enforce a maximum around 300 KB, sometimes up to roughly 600 KB or 1 MB, and the MMSC transcodes or rejects oversized media to fit the receiving device. A2P MMS senders design to the lowest common carrier limit and let the MMSC adapt down.
How is MMS submitted for A2P (application) traffic?
Through the MM7 interface: an application or VASP sends an MM7 SubmitReq as a SOAP envelope over HTTP, with recipient addresses and metadata in the XML and the media as a MIME multipart attachment, and receives a SubmitRsp with a message ID. Delivery and read reports return as MM7 DeliveryReportReq / ReadReplyReq.
Source specifications
The published standards this page is grounded in. Opens in a new tab.