This document describes how MMS works, with considerable technical detail and jargon. For information about higher level APIs used for sending MMS messages, including PHP scripts for sending MMS, please refer to Submitting MMS Messages, or for a simplified web interface to send MMS messages, see Send MMS Message.
There are two important standards that define MMS technology, one published by the 3GPP (3GPP TS 23.140), and the other a series of MMS specifications published by the Open Mobile Alliance (OMA). These two standard bodies cooperate to define the MMS protocols.
When MMS is discussed, you will often hear details of different MMS related protocols, such as MM1, MM3, MM4, MM7, as well as proprietary protocols such as EAIF, and various vendor specific proprietary variations of MM7. (You might also wonder about MM2, MM5, MM6, MM8, MM9, and others, but they are beyond the scope of this document, and are defined in 3GPP TS 23.140.)
MM1 is the protocol that is used between a mobile device and the MMSC Messaging Server. It defines how mobile phones send and receive messages through the MMSC. (For information on creating MM1 messaging content independent of an MMSC, see Sending MMS Notifications and Content.)
MM3 is the protocol that is used between an MMSC and other messaging systems. It is not so much a protocol, as much as a definition of requirements for how an MMSC must be able to interoperate with other messaging systems. In the real world, this is primarily done via the SMTP e-mail protocol.
MM4 is the protocol that is used to interconnect MMSCs. It is an SMTP-based protocol with additional headers defined.
MM7 is the protocol that is used to allow Value Added Service Provider (VASP) applications to send and receive MMS messages via an MMSC. The MM7 implementation defined by the 3GPP is a SOAP-based protocol which involves the exchange of XML and MIME content over HTTP POST. Because early versions of the 3GPP MMS specifications only defined MM7 at an abstract level, several vendors of operator MMSCs have defined their own versions of MM7 which are not compatible with the MM7 SOAP-based protocol defined by the 3GPP.
EAIF is a Nokia defined proprietary protocol which extends MM1 so that it can be used by Value Added Service Providers.
As mentioned earlier, the 3GPP (http://www.3gpp.org) defines MMS in 3GPP TS 23.140. This specification defines the overall architecture of MMS. However, it defines some MMS related protocols only at a higher level architectural level, leaving out the important implementation details. In particular, the MM1 protocol is only defined in somewhat of an abstract fashion within this specification, while the MM4 and MM7 protocols are defined with complete implementation details.
The Open Mobile Alliance (http://www.openmobilealliance.org) has a series of specifications regarding MMS, and these specifications define the MM1 protocol in detail. (In OMA terminology, MM1 is the MMS Encapsulation Protocol.)
In practice it is the OMA specifications that provide the specific details of how mobile devices send and receive MMS messages. So to better understand MMS, it is best to first focus on this layer of communication.
MMS messages are delivered using a combination of SMS and WAP technologies.
When a mobile phone receives an MMS message, what it is actually receiving is an MMS notification message which it receives over SMS (WAP Push). This MMS notification message contains header information about the MMS message, and a URL pointer that the recipient must fetch in order to retrieve the content of the MMS message.
This URL pointer is a dynamically generated URL for the MMS message content which is stored on the MMSC. In a typical phone-to-phone MMS transaction, the process of sending and receiving the MMS message works like this:
- The sending phone initiates a data connection that provides TCP/IP network connectivity, usually over GPRS.
- The sending phone performs an HTTP POST to an MMSC of the MMS message encoding in the MMS Encapsulation Format, as defined by the Open Mobile Alliance. The encoded MMS message includes all of the content of the MMS message, as well as header information, including a list of intended recipients for the message. (Note: In most environments, the HTTP POST will be routed through a proxy server. Some devices will use wireless profiled HTTP and TCP through a WAP 2.0 proxy server, while other devices will use the Wireless Session Protocol, WSP, through a conventional WAP proxy server/gateway.)
- The MMSC receives the MMS message submission and validates the message sender.
- The MMSC stores the content of the MMS message and makes it available as a dynamically generated URL link.
- The MMSC generates an MMS notification message, which is sent via WAP Push over SMS to the message recipient(s). This MMS notification message contains a URL pointer to the dynamically generated MMS content.
- The recipient receives the MMS notification message. It then initiates a data connection that provides TCP/IP network connectivity (usually over GPRS).
- The recipient phone performs an HTTP (or WSP) get to retrieve the MMS message content URL from the MMSC.
You can configure NowSMS to function as an MMSC, supporting this type of user-to-user messaging traffic with the MM1 protocol. That is one type of use for the NowSMS MMSC.
However, many people look to use NowSMS as an MMSC for supporting application generated MMS messages. In these situations, NowSMS might be functioning as an MMSC, or it might be acting as a gateway for interfacing with other MMSCs. Let’s explore these two types of configurations:
1.) Direct MMS delivery – In this configuration, NowSMS is an MMSC. Users and/or applications submit MMS messages to the NowSMS MMSC. The MMS message content is stored on the Now SMS & MMS Gateway, and the NowSMS MMSC publishes a dynamic URL for access to the MMS message content. NowSMS generates an MMS notification message to the recipient device which is sent over SMS, and this notification includes a URL pointer back to the MMS message content on the NowSMS server.
2.) MMS Gateway routing messages via an operator MMSC – NowSMS supports all of the major MMS related protocols, including MM7, MM4, MM1 and EAIF for this purpose. NowSMS also supports vendor specific proprietary versions of MM7, including the non-standard variations from Ericsson, LogicaCMG, and Materna AnnyWay. NowSMS also supports a generic SMTP interface which can be used as an MM3 implementation. Any of these protocols can be used for connecting to an operator MMSC. Most frequently, at least as a starting point, what we see is the use of MM1 where NowSMS makes a GPRS connection over a GSM/GPRS modem, connects to the operator WAP gateway that is designated for MMS usage by the operator, and submits the message to the operator MMSC via the WAP gateway over the GPRS connection. (The operator MMS gateway then generates the dynamic URL and MMS notification message that is ultimately received by the recipient device.)
The default configuration of NowSMS is to use the first approach (Direct MMS Delivery as an MMSC). When you perform direct delivery, the receiving MMS client needs to be able to connect to the NowSMS server in order to retrieve message content. In this case, it is important that the MMSC HTTP Port of the NowSMS server be accessible either over the internet or over the relevant mobile operator network(s). It is also important that the “Local Host Name or IP Address” configuration setting of the NowSMS MMSC be configured to a host name or IP address that is externally accessible.
The problem with the Direct MMS Delivery approach is that the MMS client on every mobile phone is pre-configured with settings for how the phone sends and receives MMS messages. To send or receive an MMS message, the phone makes a GPRS connection (to a GPRS APN). It then usually connects to the MMSC for sending/receiving messages through a WAP proxy/gateway. The pre-configured MMS settings on many mobile operator networks are setup to connect to a special MMS-only GPRS APN which connects to an MMS-only WAP gateway … and this GPRS APN/WAP gateway is configured only to allow connections to the operator MMSC. If the recipient mobile phone is subscribed to an operator that has this type of setup, and you attempt direct MMS delivery, you can send the MMS notification to the phone over SMS, but the phone cannot retrieve the MMS message from your MMSC server because the GPRS APN/WAP Gateway does not allow it.
In those cases, the only alternatives are:
a.) Use the second approach, and configure NowSMS to route messages via an operator MMSC. Additional information on this type of configuration can be found in the section Connecting to an Operator MMSC.
b.) Change the settings in the receiving mobile phone so that it can receive messages from external MMSCs. This is usually just a matter of changing the GPRS APN and WAP Gateway IP address that is defined for the MMS client . You could change them to match the similar settings already configured for the WAP browser, which should allow access to external sites. Note that in doing this, you may no longer be able to send/receive MMS through the standard operator MMSC, so this is usually only a good solution for deployment in closed user communities.
c.) Use an alternative to MMS, such as the Multimedia WAP push function in NowSMS. In this case, the multimedia objects are pushed to the WAP browser in the phone instead of the MMS client. NowSMS can be configured to convert a submitted MMS into this format for delivery. More information can be found in the section on Multimedia WAP Push.