MM4 messaging (MMS) integration guide

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

Definitions

• 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 in to the Bandwidth App.
2. In the side navigation bar, 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: example.company.com:587. 
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.

Notes

• 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 Bandwidth App 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 Bandwidth App 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.

MM4_forward_REQ

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”;
boundary=”===============Y4P3B9i3YGj2Ntv9bZ6K==”
Date: Wed, 21 May 2015 14:59:06 +0000

--===============Y4P3B9i3YGj2Ntv9bZ6K==
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

PHNtaWw+PGhlYWQ+PGxheW91dD48cm9vdC1sYXlvdXQgd2lkdGg9IjExMzRweCIgaGVp
Z2h0PSI3MjBweCIvPjxyZWdpb24gaWQ9IlRleHQiIGxlZnQ9IjAiIHRvcD0iNjQ4IiB3
aWR0aD0iMTEzNHB4IiBoZWlnaHQ9IjcycHgiIGZpdD0ibWVldCIvPjwvbGF5b3V0Pjwv
aGVhZD48Ym9keT48cGFyIGR1cj0iNTAwMG1zIj48dGV4dCBzcmM9InRleHRfMC50eHQi
IHJlZ2lvbj0iVGV4dCIvPjwvcGFyPjwvYm9keT48L3NtaWw+
--===============Y4P3B9i3YGj2Ntv9bZ6K==

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

VGVzdCBNTVM=--===============Y4P3B9i3YGj2Ntv9bZ6K==--

To receive ACK back, next headers should be added

X-Mms-Ack-Request: Yes
X-Mms-Originator-System: system@your.domain.com

MM4_forward.RES

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

From: system@your.domain.com
To: system-user@mms.lab.bandwidth.com
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

MM4_delivery_report.REQ

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
Sender: system@test.com

MM4_read_reply_report.RES

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)
From: system@your.domain.com
To: system-user@mms.lab.bandwidth.com
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