MM4 messaging (MMS) integration guide


Ashley Brodzinski


Multimedia Messaging Service (MMS) is a standard way to send messages that include multimedia content to and from a mobile phone over a cellular network. MMS allows the sender to send messages with media files (such as pictures, videos, and audio files) all in one message, or separately in individual messages.

Bandwidth Multimedia Messaging Service Center (BMMSC) is an operator-grade platform that enables multiple service providers to exchange MMS messages with other service providers who support MMS.

BMMSC offers a unique set of value-added services and capabilities that enable operators to deploy MMS quickly and efficiently, including:

  • Management of all network connections, architecture, and connectivity
  • Single point of connection to reach multiple operators/service providers
  • Maintenance of operator profiles of supported content types and sizes, as well as any other operator capabilities and limitations
  • Incorporation of a wide variety of anti-SPAM and anti-abuse methods to ensure the integrity of the inter-operator MMS traffic
  • Network Operations Center (NOC) and 24/7 customer support


  • MMS User Agent is the Multimedia Messaging browser or user interface on the mobile handset, desktop, or other devices.
  • MMS Relay/Server is a server that handles all of the various Multimedia Messaging (MM) Interfaces (defined below), as well as the routing of the message to the destination handset or operator.
  • MM4 defines the interface between MMSCs. The 3GPP/3GPP2 specified protocol is SMTP. BMMSC support for this interface includes a number of powerful security features, such as system-wide IP address blocking, SMTP mail relay prevention, system filters, SMTP authentication, and sidelining suspicious messages. These features allow operators to protect their networks from spurious intrusions, service attacks, and forgeries.

Setting up your account for messaging

Please refer to this article.

Setting up TLS for MM4

We've taken additional measures to secure messaging traffic in transit and implemented optional TLS encryption for our SMPP, MM4, and HTTP Messaging platforms.  

TLS over MM4 can be enabled both for outbound MMS traffic (FROM the customer to Bandwidth to the final destinations) and inbound traffic (TO the customer via Bandwidth). The former is typically referred to as Mobile Terminated (MT) traffic and the latter as Mobile Originated (MO) traffic.

What's supported?

  • TLS version supported: TLS 1.2
  • MMS version supported: X-Mms-3GPP-MMS-Version: 6.10.0
  • Ciphers supported: ‘ECDHE-ECDSA-AES256-GCM-SHA384’, ‘ECDHE-ECDSA-AES128-GCM-SHA256’, ‘ECDHE-RSA-AES256-SHA384’, ’ECDHE-RSA- AES128-SHA256’, ‘ECDHE-RSA-AES256-SHA’, ‘ECDHE-RSA-AES128-SHA’, ‘AES256-GCM- SHA384’,’AES128-GCM-SHA256’, ‘AES256- SHA256’, ‘AES128-SHA256’, ‘AES256-SHA’, ‘AES128-SHA’, ‘DES-CBC3-SHA’

TLS for outbound (MT) MMS traffic

To send MMS traffic over TLS, you'll send traffic to the following Fully Qualified Domain Names (FQDNs) with the port number as mentioned:

  • Dallas MMSC: To obtain the specific IPs and FQDN, please reach out to your Implementation Specialist. If you aren't currently working with one, please open a support ticket.
  • Los Angeles MMSC: To obtain the specific IPs and FQDN, please reach out to your Implementation Specialist. If you aren't currently working with one, please open a support ticket.
  • We recommend connecting on port 587. However, since some cloud hosting providers block or throttle SMTP traffic on port 587, you can also connect on port 5870. We'll automatically translate this internally to port 587.
  • Please specify the origination domain (FQDN) in the MM4 header. This is the “X-Mms-Originator-System”. Domain information in this header is used to indicate the address that the recipient MMS Relay/Server will use as the recipient address with MM4_Forward.Res.
  • Upon receiving MMS traffic on port 587, Bandwidth will automatically respond and share its digital certificate (signed by a trusted Certificate Authority - presently DigiCert). You'll then need to accept and install this certificate on your end.
  • Once this is in place, all MMS traffic will be exchanged over TLS.
  • Note that the MM4_forward.RES flow from Bandwidth to customer is set to port 587 and the traffic is sent to the origination domain (FQDN) specified in the header from the customer.

TLS for inbound (MO) MMS traffic


To enable TLS for inbound (MO) MMS traffic:

  1. Log into the Bandwidth Dashboard.
  2. In the top navigation menu, click Account and then Locations.
  3. Select a Location and click the MMS Settings drop-down.
  4. If the MMS isn't already enabled, toggle the MMS Enabled switch to enable it.
  5. Check the Transport layer security (TLS) checkbox if you want to receive inbound MMS traffic over TLS.
  6. Once the checkbox is checked, enter an FQDN in the MM4 origination hosts text box. You can also indicate the desired port, but it's optional. 
    • For example: 
  7.  Click Save Changes. At this point, we'll expect to receive a digital certificate tied to the specified FQDN and install it accordingly on our end.


  • FQDN is required for TLS. If you opt to receive inbound MMS over TLS, you must enter an FQDN in the MM4 origination hosts text box (IP addresses aren't acceptable).
  • When the Transport layer security (TLS) checkbox is checked, the portal will validate entries in MM4 origination hosts and alert you if an FQDN wasn't entered. We'll use your custom port, if you specify it beforehand. If no port is specified, we'll use 587 as the default port.
  • When Transport layer security (TLS) checkbox isn't checked, the portal will accept either IP addresses or an FQDN. We'll use 25 as the default port.
  • Bandwidth supports only those certificates from a trusted Certificate Authority such as DigiCert, GoDaddy, etc. Certificates will be validated before being accepted.
  • If Bandwidth can't establish a TLS session with your server, including successfully validating your certificate, no messages will be delivered. 

Other considerations to support TLS for MM4

Persistent connection

In order to ensure optimum performance on message throughput and to inject more predictability in delivery of MMS traffic, you'll need to maintain a persistent connection to Bandwidth.

Limited ability to troubleshoot some issues

While TLS brings a significant advantage to secure messages in transit, please note that TLS limits the ability to troubleshoot certain connectivity and deliverability issues if they arise. This is because certain data usually captured in clear text (without TLS) are now encrypted and will require more time and coordination between you and Bandwidth to troubleshoot. In such cases and if necessary, you can choose to disable TLS temporarily to better assist troubleshooting efforts.


Here's how each MM4_forward_REQ field (from the originating operator) is supported in BMMSC:

Name of Header Presence Description
X-Mms-3GPP-MMS-Version Required MMS version of originating MMSC
X-Mms-Message-Type Required The type of message used on reference point MM4: "MM4_forward.REQ".
X-Mms-Message-ID Required The type of message used on reference point MM4: "MM4_forward.REQ".
X-Mms-Transaction-ID Required The valid PLMN address of the sender. BMMSC requires a valid PLMN address. If the originator requested address hiding, this should be set. Possible formats for sender and recipient address: MMS-address = "+"E.164"/TYPE=PLMN"SMTP-address="<"MMS-address"@"domain">"system-address=system-user"@"host-subdomain
To Required For Inbound to BMMSC (customer sending an outbound message): Multiple addresses are permitted; For Outgoing from BMMSC (customer receiving an inbound message), this will be a single address or multiple addresses, depending upon the operator. Recipient address should be a valid E.164 address.
Content-Type Required Content-type - subject to transcoding based on the destination operator profile. For a full list of accepted content types, please refer to the article here.
Cc Optional See Description in To: Header
Bcc Optional See Description in To: Header
Date Optional Date & Time of the most recent forward (either from originating operator or from BMMSC)
X-Mms-Originator-System Optional When utilizing TLS, this header will be used to indicate the address that the recipient MMS Relay/Server shall use as the recipient address with MM4_Forward.Res
Sender Optional Header may be used to indicate the originator address when this differs from the address in the "From:" header.
X-Mms-Message-Class Optional Passed through BMMSC
X-Mms-Expiry Optional Passed through BMMSC
X-Mms-Delivery-Report Optional Passed through BMMSC (Not commonly supported by carriers)
X-Mms-Priority Optional Passed through BMMSC
X-Mms-Sender-Visibility Optional Passed through BMMSC
X-Mms-Read-Reply Optional Passed through BMMSC (Not commonly supported by carriers)
Subject Optional Passed through BMMSC
X-Mms-Ack-Request Optional The originator MMS Relay/Server may request a MM4_forward.RES from the BMMSC acknowledging the successful reception of the MM by BMMSC.
X-Mms-Forward-Counter Optional Passed through BMMSC. A counter indicating the number of times the particular MM was forwarded by a forwarding MMS User Agent
X-Mms-Previously-sent-by Optional Passed through BMMSC. In case of forwarding, this information element contains one or more addresses of MMS User Agent(s) that handled (i.e. forwarded or submitted) the MM prior to the MMS User Agent whose address is contained in the Sender address information element. The order of the addresses provided shall be marked. The address of the originator MMS Agent shall be marked, if present.
X-Mms-Previously-sent-date-and-time Optional Passed through BMMSC. The date(s) and time(s) associated with submission and forwarding event(s) prior to the last handling of the MM by an MMS User Agent (timestamps).

Sample: MM4_forward.REQ

From: +12345678901/TYPE=PLMN
To: +12345678910/TYPE=PLMN
X-Mms-3gpp-Mms-Version: 6.10.0
X-Mms-Message-Id: “10000140521145906922982”
X-Mms-Message-Type: MM4_forward.REQ
X-Mms-Transaction-Id: “20000140521145906306678545”
Content-Type: multipart/related; Start=”<smil>”; Type=”application/smil”;
Date: Wed, 21 May 2015 14:59:06 +0000

Content-Type: application/smil; name=smil.txt
MIME-Version: 1.0
Content-Disposition: attachment; filename=smil.txt
Content-location: smil.txt
Content-ID: “<smil.txt>”
Content-Transfer-Encoding: base64


Content-Type: text/plain; name=text_0.txt
MIME-Version: 1.0
Content-Disposition: attachment; filename=text_0.txt
Content-location: text_0.txt
Content-ID: “<text_0.txt>”
Content-Transfer-Encoding: base64


To receive ACK back, next headers should be added

X-Mms-Ack-Request: Yes


Name of Header Presence
X-Mms-3GPP-MMS-Version  Required
X-Mms-Message-Type Required
X-Mms-Message-ID Required
X-Mms-Transaction-ID Required
X-Mms-Request-Status-Code Required
X-Mms-Status-Text Optional
X-Mms-Request-Recipients Optional

Sample: MM4_forward.RES

X-MMS-3GPP-MMS-Version: 6.10.0
X-MMS-Message-Type: MM4_forward.RES
X-MMS-Transaction-ID: 20000140521145906306678
X-MMS-Message-ID: 10000140521145906922982
X-MMS-Request-Status-Code: Ok


Name of Header Presence
X-Mms-3GPP-MMS-Version Required
 X-Mms-Message-Type Required
 X-Mms-Message-ID Required
 X-Mms-Transaction-ID  Required
 From Required
To Required
X-Mms-MM-Status-Code Required
Date Optional
Sender Optional
 X-Mms-Ack-Request Optional
 X-Mms-Status-text Optional
X-Mms-Originator-System Optional

Sample: MM4_read_reply_report.REQ

Date: Wed, 13 May 2015 13:24:24 +0000 (GMT+08:00)
From: +19192711003/TYPE=PLMN
To: +19099222042/TYPE=PLMN
X-Mms-3gpp-Mms-Version: 6.10.0
X-Mms-Message-Id: “10000140521145906922983”
X-Mms-Message-Type: MM4_read_reply_report.REQ
X-Mms-Transaction-Id: “20000140521145906306679”
X-Mms-Read-Status: Read


Name of Header Presence
X-Mms-3GPP-MMS-Version Required
X-Mms-Message-Type Required
X-Mms-Transaction-ID Required
X-Mms-Request-Status-Code Required
Date Optional
Sender Optional
To Optional

Sample: MM4_read_reply_report.RES

Date: Wed, 13 May 2015 15:05:52 +0000 (GMT+08:00)
X-Mms-3gpp-Mms-Version: 6.10.0
X-Mms-Message-Id: “10000140521145906922982”
X-Mms-Message-Type: MM4_read_reply_report.RES
X-Mms-Transaction-Id: “20000140521145906306678”
X-Mms-Request-Status-Code: Ok

Standard MMS message flow


This MMS message flow outlines an MMS message from one end-user to another end-user, where a Bandwidth customer may be the originating server and a Bandwidth provider may be the recipient server.

Note: if your server is unable to accept messages or respond, we'll retry 120 times at an interval of 1 minute apart for 2 hours total.

SMTP ladder diagrams

MMS from EMMSC to BMMSC with NOOP enabled


MMS from EMMSC to BMMSC with NOOP disabled


MMS from BMMSC to EMMSC with NOOP enabled


Outbound MMS from BMMSC to EMMSC with NOOP disabled


Questions? Please open a ticket with your Bandwidth Support Team or hit us up at (855) 864-7776

Article is closed for comments.