Le MMS achemine les messages multimédias via un MMSC (relais/serveur), défini par la 3GPP TS 23.140 et OMA MMS. Les combinés soumettent et récupèrent via MM1 (WAP/HTTP) ; les MMSC s'échangent entre opérateurs via MM4 (fondé sur SMTP) ; et les fournisseurs de services à valeur ajoutée soumettent via MM7 (SOAP/XML). Le contenu est du MIME multipart avec une couche SMIL optionnelle, soumis aux limites de taille propres à chaque opérateur.
Le MMSC et l'architecture de référence MMS
Le MMS (Multimedia Messaging Service) a été spécifié pour transporter images, audio, vidéo et texte enrichi là où le SMS ne porte que du texte court. En son centre se trouve le MMSC — le MMS Centre, ou MMS Relay/Server — qui stocke les messages, résout les destinataires, convertit les médias pour le terminal récepteur et fait le pont vers d'autres réseaux et vers la messagerie électronique. La 3GPP TS 23.140 (avec OMA MMS) définit l'architecture comme un ensemble de points de référence numérotés, les interfaces MMx, autour de ce MMSC. Chaque interface relie un acteur différent — le combiné, le MMSC d'un autre opérateur, un fournisseur de services à valeur ajoutée, la base de données d'abonnés — et utilise un protocole adapté à ce segment, ce qui explique pourquoi le MMS ressemble à plusieurs protocoles assemblés plutôt qu'à un seul.
| Interface | Entre | Transport |
|---|---|---|
| MM1 | Téléphone (client MMS) ↔ MMSC | WAP / HTTP (encapsulation MMS) |
| MM3 | MMSC ↔ serveurs externes (ex. e-mail) | SMTP / interne |
| MM4 | MMSC ↔ MMSC (inter-opérateur) | SMTP avec en-têtes MMS |
| MM7 | VASP / application ↔ MMSC | SOAP / XML sur HTTP |
| MM5 / MM6 | MMSC ↔ HLR / bases de données utilisateurs | Interne à l'opérateur |
MM1 : du combiné vers le MMSC
MM1 est l'interface entre le client MMS du combiné et son MMSC domestique, et c'est une conception de type stocker-puis-notifier. Pour envoyer, le combiné soumet le message au MMSC (un M-Send.req) via WAP ou HTTP en utilisant l'encodage d'encapsulation MMS. Pour recevoir, le MMSC ne pousse pas le message complet ; il envoie une notification WAP push (M-Notification.ind), généralement déclenchée par un SMS binaire, indiquant au combiné qu'un message l'attend, et le combiné le récupère ensuite (M-Retrieve.conf) via HTTP. Ce schéma notifier-puis-récupérer permet au réseau de retenir les médias volumineux jusqu'à ce que le terminal soit prêt, et explique pourquoi la remise MMS implique à la fois un signal de signalisation et un téléchargement de données.
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-opérateur MMSC vers MMSC via SMTP
Lorsque l'expéditeur et le destinataire sont sur des réseaux différents, les deux MMSC s'échangent le message via MM4 — et MM4 repose sur SMTP. Le MMSC d'origine transfère le message sous forme d'e-mail RFC 822 / MIME (un MM4_forward.REQ) vers le MMSC destinataire, en adressant l'abonné et en portant des métadonnées propres au MMS dans des en-têtes X-Mms-* (type de message, identifiant de transaction, identifiant de message, adresse de l'expéditeur). Le MMSC récepteur accuse réception avec un MM4_forward.RES, et les rapports de remise et de lecture reviennent par la même voie. Utiliser SMTP comme transport inter-opérateur est ce qui permet au MMS d'interfonctionner avec les passerelles e-mail et a rendu le MMS inter-opérateur déployable sur l'infrastructure de messagerie existante, au prix des garanties de remise plus lâches du SMTP.
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 : l'interface applicative VASP vers MMSC
MM7 est l'interface qu'une application ou un fournisseur de services à valeur ajoutée (VASP) utilise pour soumettre et recevoir des MMS via le MMSC d'un opérateur — l'équivalent MMS d'un flux de messagerie en masse, et l'interface derrière le MMS A2P. Contrairement à l'encapsulation binaire de MM1 ou au SMTP de MM4, MM7 est un service web SOAP/XML sur HTTP : le VASP envoie un MM7 SubmitReq avec une enveloppe SOAP portant les adresses des destinataires, l'identité de l'expéditeur et les métadonnées du message, plus une pièce jointe MIME multipart pour le média, et reçoit un SubmitRsp avec un identifiant de message. Les rapports de remise et de lecture reviennent sous forme de MM7 DeliveryReportReq / ReadReplyReq. Cette structure requête/réponse est ce qui rend MM7 adapté aux émetteurs applicatifs à fort volume et à l'intégration de plateforme.
<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>Contenu, SMIL et limites de taille — et MMS vs SMS
Le corps d'un message MMS est un conteneur MIME multipart : chaque partie média (texte, JPEG, audio, vidéo) est une entité MIME, et un document SMIL optionnel décrit la présentation — comment les parties sont agencées en diapositives et le rythme entre elles — afin qu'un message multi-diapositives s'affiche de façon cohérente. Cette richesse est tout l'intérêt du MMS face au SMS : le SMS représente 140 octets sur le fil (160 caractères GSM-7) de texte seul, tandis que le MMS porte des kilo-octets de médias mixtes. Mais la taille du MMS est plafonnée par le réseau, non par la spécification — les opérateurs imposent couramment une taille maximale de message (souvent autour de 300 Ko, parfois jusqu'à environ 600 Ko ou 1 Mo), et le MMSC transcode ou rejette les médias trop volumineux pour s'adapter au terminal récepteur. Les émetteurs de MMS A2P conçoivent donc pour la limite d'opérateur la plus basse et laissent le MMSC réduire en conséquence.
| Propriété | SMS | MMS |
|---|---|---|
| Payload | 140 octets (160 caractères GSM-7) | MIME multipart, kilooctets de médias mixtes |
| Média | Texte uniquement | Image, audio, vidéo, texte enrichi + mise en page SMIL |
| Acheminement vers le terminal | Message court SS7 / SMPP | Notification + récupération MM1 WAP/HTTP |
| Inter-opérateur | SS7 / SMPP | MM4 (SMTP avec en-têtes MMS) |
| Interface applicative | SMPP | MM7 (SOAP/XML) |
| Limite de taille | Fixé par segment | Défini par l'opérateur (généralement ~300 Ko) |
Questions fréquemment posées
Qu'est-ce qu'un MMSC ?
Le MMSC (MMS Centre, ou MMS Relay/Server) est le nœud central du MMS. Il stocke les messages multimédias, résout les destinataires, convertit les médias pour le terminal récepteur, et fait le pont entre les combinés, les MMSC d'autres opérateurs et la messagerie électronique. Toutes les interfaces de référence MMS (MM1, MM4, MM7 et autres) sont définies autour de lui dans la 3GPP TS 23.140 et OMA MMS.
Quelle est la différence entre MM1, MM4 et MM7 ?
MM1 relie le combiné à son MMSC via WAP/HTTP en utilisant l'encapsulation MMS. MM4 relie deux MMSC pour la remise inter-opérateur et repose sur SMTP, portant les métadonnées MMS dans des en-têtes X-Mms-*. MM7 relie un fournisseur de services à valeur ajoutée ou une application au MMSC sous forme de service web SOAP/XML, et c'est l'interface derrière le MMS A2P.
Pourquoi le MMS utilise-t-il SMTP entre opérateurs ?
MM4, l'interface inter-opérateur, transfère chaque message sous forme d'e-mail RFC 822 / MIME avec des en-têtes X-Mms-* propres au MMS. S'appuyer sur SMTP a permis au MMS d'interfonctionner avec les passerelles e-mail et de se déployer sur l'infrastructure de messagerie existante, de sorte que le MMS inter-opérateur fonctionnait sans transport dédié — au prix des garanties de remise plus lâches du SMTP.
Qu'est-ce que le SMIL dans un message MMS ?
SMIL (Synchronized Multimedia Integration Language) est un document XML optionnel à l'intérieur du conteneur MIME du MMS qui décrit la présentation — comment les parties média sont agencées en diapositives et leur rythme. Il permet à un message multi-diapositives avec texte, image et audio de s'afficher de façon cohérente sur les terminaux au lieu d'un simple assemblage de pièces jointes.
Quelle est la taille maximale d'un message MMS ?
La limite de taille est fixée par l'opérateur, non par la spécification. Les réseaux imposent couramment un maximum autour de 300 Ko, parfois jusqu'à environ 600 Ko ou 1 Mo, et le MMSC transcode ou rejette les médias trop volumineux pour les adapter au terminal récepteur. Les émetteurs de MMS A2P conçoivent pour la limite d'opérateur la plus basse et laissent le MMSC réduire en conséquence.
Comment le MMS est-il soumis pour le trafic A2P (applicatif) ?
Via l'interface MM7 : une application ou un VASP envoie un MM7 SubmitReq sous forme d'enveloppe SOAP sur HTTP, avec les adresses des destinataires et les métadonnées dans le XML et le média en pièce jointe MIME multipart, et reçoit un SubmitRsp avec un identifiant de message. Les rapports de remise et de lecture reviennent sous forme de MM7 DeliveryReportReq / ReadReplyReq.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.