MMS Protocol Learning Notes

"Reprint" Address: http://www.iteye.com/topic/618885

MMS Protocol Learning Notes

What is MMS

MMS is the abbreviation of Multimedia Messaging Service (multimedia messaging), which is translated into "MMS" and can be used to transfer multimedia information such as text, pictures, animations, audio and video.

After the mobile phone terminal synthesizes The multimedia message, may send the multimedia message to all legitimate users in the net, by the MMSC (Multimedia Message Center) carries on the storage and the processing to the message, and is responsible for transmits the message between the different MMSC, simultaneously the receiver user may receive the multimedia message from the MMSC.

Multimedia Messaging service requires a WAP gateway, a data transmission network (such as: Circuit switching network, GPRS or WCDMA, etc.) and a short message center. At present, MMS is implemented in the implementation of WAP as a bearer, short message for prompt notification, from MMS mobile phones automatically to MMSc to extract.

The size of the multimedia message is usually between dozens of K bytes to the hundred K bytes, which is determined by both the operator and the handset terminal, and currently in most parts of China, mobile phones support only less than 50KB of multimedia information.

MMS and SMS are the same in the way messages are sent: they are stored as a forwarding service-messages are not delivered directly to the user, but are sent to the message center before being forwarded to the target user via the message center. But MMS and SMS also differ greatly, the first is the network structure and the load mode is different: SMS is the use of GSM signaling channel, and MMS is based on WAP protocol stack, take the data channel, its transmission capacity is much more than SMS, users are no longer subject to bandwidth constraints; second, MMS can support rich data formats , including graphics, images, sounds, animations, can also support streaming media when bandwidth allows, which greatly enhances the richness and expressiveness of message content.

MMS Protocol Overview

MMS is an industry standard developed by OMA (Open Mobile Alliance) and 3GPP (3G Partnership Project) and is designed to seek a system-independent, open, Multimedia messaging standards that enable applications and businesses to be implemented on a global scale for a variety of terminals.

MMS runs on top of the WAP protocol layer, it is not limited to transmission format, it supports both CSD (Circuit-switched Data Circuit Interchange Format) and GPRS format (General Packet Radio Service Universal Packet Radio service), WAP as a carrier for the transmission of video, pictures, sounds and text.

The protocols that OMA is responsible for defining concern about how the message is packaged, and the protocol that 3GPP is responsible for is concerned with the issue of how messages are sent, routed, and received.

OMA's main protocol document: Multimedia Messaging Service architecture MMS Architecture overview; Multimedia Messaging Service client transactions about MMS clients; Multimedia Messaging Service Encapsulation Protocol MMS Encapsulation Protocol;

3GPP Main protocol documents: (TS-22.140) Multimedia Messaging Service Stage 1 on MMS service layer; TS-23.140 Multimedia Service Messaging 2 MMS feature description; (TS-26.140) MMS Media formats and codes medium format and encoding for MM support

In addition to the documents listed above, there are WAP wireless session protocol related documents that need to be understood, such as smil and so on.

MMS System Composition

The main network units that make up the MMS business system are shown in the following illustration:

MMSC (Multimedia Messaging Service center) is the core of the entire system, which completes the storage and processing of MM, including the input and output of messages, address resolution, notifications, reports, etc., it is by MMS Relay server MMS Relay, MMS Server, User DB, message The store is made up together.

WAP gateway, because the SMS transmission channel is too narrow for MMS, MMS uses WAP WSP as the transport protocol, so it needs a WAP gateway to connect MMSC and wireless WAP network.

MMS Redirector (MMS Redirector): There are several mmsc throughout the network, and their URL addresses are unique, and the MMS redirector is the network entity that is responsible for the sender's user attribution MMSc routing query function.

Enum-dns (number domain resolver): resolves the mmsc address of the receiver's user, receives the query request sent by the MMSc, inquires the URI address of the corresponding mmsc of the recipient address, and returns it to MMSC, and sends the message to the MMSC server by MMSc.

MMS System Interface

Note: There are two ways to name the interface, one is MMSM/MMSR and so on, the other is mm1/mm2 and so on, it refers to the same thing;

The entire MMS business system is the operation of all relevant network functional entities to achieve mutual communication, the MMS related protocol documents, one of the main functions is to clearly define the network functional entities to communicate the collaboration between the standard interface, the following is a brief description of the relevant interface: MM1 (MMS M) interface : The interface between MMS Relay/server and MMS client ;
MM2 (MMSS) interface: interface between MMS relay and MMS Server;
MM3 interface: interface between MMS Relay/server and external application server;
MM4 interface: interface between different mmsc; MM5 interface: interface between MMS Relay/server and HLR (home Location Register); Note: HLR is a central database, It records the licensing information for each mobile phone user using the GSM core network function; MM6 interface: interface between MMS Relay/server and MMS user db; MM7 interface: MMS relay/ interface between server and MMS value-added service application platform; MM8 interface: interface between MMS Relay/server and billing system;

MM1 (MMSM) interface will be the focus of our learning, this is our development of MMS applications must understand the normative knowledge.

MMS Client Business model (MMS client Transaction models)

With the MM1 interface as the discussion scope, the MMS service implements the business invocation between the MMS client and the MMS Proxy-relay server, and the business (Transaction) refers to the transmission process and mode of the information, in order to influence the state change of MMS terminal equipment. Details of the different types of business related to MMS Client are described below:

m-send : MMS client sends message to MMS Proxy-relay server;

The M-send service provides the basic mechanism for MMS client to submit multimedia MMS to Mms-relay and obtain response information, the following figure is the communication flow of the business:

In the PDU (Protocol Data unit) that MMS client submits to MMS relay, it contains an ID field that uniquely identifies itself, which causes the request/response (REQ/RESP) to be correlated.

When the MMS relay server receives a m-send.req PDU, it responds to a m-send.conf packet that contains a status code with the result of the request processing. If the MMS relay can successfully process the request, the status code will be ' OK ' and return a Message-id as the unique identifier for MM.

m-notification : MMS proxy-relay server sends notifications to MMS clients;

The MMS Relay server sends M-NOTIFICATIONPDU to the MMS client to inform it of new multimedia messages, while MMS client responds to status codes, and the following figure is the communication flow of the business:

The pdu--m-notification.ind that is sent to MMS client by the Mms-relay server contains a RFC2396-compatible URI, which is the entry address for MM, as well as additional information such as message size, expiration time, recommended collection, and so on.

MMS client responds to a M-NOTIFYRESP.IND packet after receiving the M-notification.ind PDU to indicate that it has been notified.

m-retrieve : MMS Client collects mm--multimedia message from MMS Proxy-relay server;

The M-retrieve business is MMS client sent to the MMS Relay server to receive a request for MM, the requested PDU is transmitted on the WSP/HTTP protocol. Depending on how the charge is received (or deferred), there may be a confirmation link between the Mms-relay server and the MMS client, which is the following communication flow for immediate and deferred charges:

MMS client requests mm content from the MMS relay server using the URI in the M-notification.ind PDU as the parameter. The server will want the MMS client to respond to the m-retrieve.conf packet, if successful it will contain the full mm content, and of course the status code in the response will indicate whether the operation was successful.

m-forward : MMS client sends forward request to MMS Proxy-relay server;

The M-forward business allows MMS clients to forward a mm in the Mms-relay server to other users, and the following is the communication flow of the business:

MMS client sends a m-forward.req PDU to the Mms-relay server, which contains the URI of the location mm and at least 1 target addresses (that is, the number of the called user). The Mms-relay server responds to a m-forward.conf PDU, which contains a status code indicating whether the operation was successful. In addition, the forwarding business is an optional feature that may not be supported on some carriers ' networks.

m-delivery : MMS proxy-relay server sends delivery report to MMS client;

The M-delivery business allows the source MMS Client (that is, the user sending MMS) to receive timely notification of information being posted, which is a m-delivery.ind packet, and the following is the communication flow of the business:

There is only one step in the business, there is no response, the PDU sent to MMS client contains the source message sent, if there are multiple target users, there will be more than one m-delivery.ind packet.

In addition, similar to the delivery report is a "read report", depending on the version of the client side will have two different situations: mm reading report, PDU reading report.

m-cancel : MMS proxy-relay server sends cancellation request to MMS client;

The M-cancel business allows the Mms-relay server to send a request to the MMS clinet to revoke a multimedia message, following is a communication flowchart for the business:

The Mms-relay server sends a M-CANCEL.REQ packet to the MMS client that contains the ID of the target mm, for example: Cancel ID. The business is optional and may not be implemented on some carriers ' networks.

m-delete : MMS client deletes multimedia message from MMS Proxy-relay server;

The M-delete business allows MMS client to delete a multimedia message on the Mms-relay server, and the following is a communication flowchart for the business:

MMS client wants to delete 1 or more of the mm stored on the Mms-relay server, You can send a M-DELETE.REQ packet to a mms-relay server that contains 1 or more URIs that identify the specific mm, and the Mms-relay server responds to the M-DELETE.CONF packet, which contains a status code with the operation completed.

MMS message format and encapsulation

In the introduction of the above business model, the main body in the communication process is the PDUs (Protocol data Units) for carrying the business data, and this section will pay attention to several aspects such as the basic mechanism, content composition, encapsulation coding of these data units. The content type (content-type) of the MMS PDU must be specified as application/vnd.-wap.mms-message for accurate identification by the client.

Basic Structure

The MMS PDU consists of a message header (header) and a body of messages. Header specifically describes the specific PDU information, the body is the specific content of the message (bodies are optional). Most MMS PDUs contain only Header domains that are used to establish and maintain communications, and the body is used only in M-send.req and m-retrieve.conf two packets. The following figure is a schematic diagram of the basic structure of the MMS PDU:

A message header (header) consists of a series of domains, including the PDU type, the receiver, the sender, the time of delivery, and so on. The items in the header field are divided into optional and required options, and when the MM header field is encoded, X-mms-message-type,x-mms-transaction-id and x-mms-mms-version must be at the beginning of the MM header. Also, strictly in the order listed, the Content-type header field must be at the end of the MMS header field, followed by the message body, and the order of the other fields can be arranged randomly.