MMS 協議學習筆記

時間 2019-11-12

標籤 mms 協議學習筆記简体版

原文原文鏈接

什麼是 MMS html

MMS 是 Multimedia Messaging Service (多媒體消息服務) 的縮寫，中文譯爲「彩信」，能夠用於傳送文字、圖片、動畫、音頻和視頻等多媒體信息。數據庫

手機終端合成多媒體消息後，能夠向網內全部合法用戶發送多媒體消息，由 MMSC ( 多媒體消息中心 )對消息進行存儲和處理，並負責將消息在不一樣MMSC之間的進行傳遞轉發，同時接收方用戶能夠從MMSC接收多媒體消息。服務器

多媒體消息服務要求一個WAP網關，一個數據傳輸網（例如：電路交換網、GPRS 或者WCDMA等）和一個短消息中心。目前MMS業務在實現時是以WAP做承載，短消息做提示通知，由MMS手機自動到MMSC中去提取。網絡

多媒體消息的大小一般在幾十K字節到上百K字節之間，這是由運營商和手機終端雙方面決定的，目前中國大部分地區的手機僅支持小於50KB的多媒體信息。架構

MMS與SMS在消息發送方式上是相同的：都是存儲一轉發業務——即消息不直接送達用戶，而是先送至消息中心，再通過消息中心轉發到目標用戶。可是MMS與SMS也存在很大差別，首先是網絡結構和承載方式的不一樣：SMS是使用GSM的信令通道，而MMS是基於WAP協議棧，走數據通道，其傳輸能力大大超過SMS，用戶再也不受帶寬的限制；第二，而MMS能夠支持豐富的數據格式，包括圖形、圖像、聲音、動畫，在帶寬容許的狀況下還能夠支持流媒體，這大大提升了消息內容的豐富程度和表達能力。併發

MMS協議概述 app

MMS是由OMA(Open Mobile Alliance)和3GPP(3G Partnership Project)共同主持制定的工業標準，其旨在尋求一種與系統無關的、開放的，使各類應用和業務可以在全球範圍內的各類終端上實現的多媒體消息通信標準。學習

MMS運行在WAP協議層之上，它不侷限於傳輸格式，既支持CSD(Circuit-Switched Data 電路交換數據格式)，也支持GPRS格式(General Packet Radio Service 通用分組無線服務)，以WAP爲載體傳送視頻、圖片、聲音和文字。優化

OMA負責定義的相關協議關注「消息如何打包」的問題，3GPP負責定義的協議則關注「消息如何發送、路由和接收」的問題。動畫

OMA的主要協議文檔：

Multimedia Messaging Service Architecture MMS架構概述；
Multimedia Messaging Service Client Transactions 關於MMS客戶端；
Multimedia Messaging Service Encapsulation Protocol MMS封裝協議；

3GPP的主要協議文檔：

(TS-22.140)Multimedia Messaging Service Stage 1 關於MMS服務層；
(TS-23.140)Multimedia Messaging Service Stage 2 關於MMS功能描述；
(TS-26.140)MMS Media formats and codes 關於MM支持的媒體格式和編碼

除以上羅列之文檔外，還有WAP無線會話協議相關的文檔須要瞭解，例如：SMIL等等。

MMS系統構成

構成MMS業務系統的主要網絡單元以下圖所示：

MMSC（多媒體消息業務中心）是整個系統的核心，它完成對MM的存儲和處理，包括消息的輸入輸出、地址解析、通知、報告等等，它由MMS中繼服務器MMS Relay 、MMS Server、User DB、Message Store共同組成。

WAP網關，由於SMS的傳輸信道對於MMS來講太窄了，因此MMS使用WAP的WSP做爲傳輸協議，所以須要一個WAP網關鏈接MMSC和無線WAP網絡。

MMS Redirector（MMS重定向器）：全網範圍內會有若干個MMSC，它們的URL地址是惟一的，MMS重定向器就是負責發送者用戶歸屬MMSC路由查詢功能的網絡實體。

ENUM-DNS（號碼域名解析器）：解析接收方用戶歸屬的MMSC的地址，接收MMSC發送的查詢請求，查詢接收者地址對應的歸屬MMSC的URI地址，並返回給MMSC，由MMSC將消息發往該用戶歸屬MMSC服務器。

MMS系統接口

注：接口命名有兩種方式，一種是MMSm / MMSR 等等 ，另外一種是MM1/MM2等 等 ，其都指相同東西；

整個MMS業務系統的運轉是全部相關網絡功能實體的相互通信協做來達成，MMS相關協議文檔的主要功能之一，就是明肯定義各網絡功能實體之間相互通信協做的標準接口，如下是相關接口的簡要說明：

MM1(MMS M ) 接口 ：MMS Relay/Server 和MMS Client之間的接口 ；
MM2(MMSS )接口：MMS Relay和MMS Server之間的接口；
MM3接口：MMS Relay/Server 與外接應用服務器之間接口；
MM4接口：不一樣MMSC之間交互的接口；
MM5接口：MMS Relay/Server和HLR（Home Location Register）之間的接口； 注：HLR是一箇中央數據庫，其記錄了每一個移動電話用戶使用GSM核心網絡功能的受權信息；
MM6接口：MMS Relay/Server 和MMS User DB之間交互的接口；
MM7接口：MMS Relay/Server和MMS增值業務應用平臺之間的接口；
MM8接口：MMS Relay/Server與計費系統之間的接口；

MM1(MMSM )接口將是咱們的學習重點，這是咱們開發彩信應用程序必需要了解的規範知識。

MMS Client 業務模型（MMS Client Transaction Model）

以MM1接口爲討論範圍，則MMS服務實現了MMS Client和MMS Proxy-Relay服務器之間的業務調用，業務（Transaction）特指信息的傳遞流程及方式，以其對MMS終端設備狀態變化的影響。下面詳述各類不一樣的與MMS Client 相關的業務類型：

M-Send ：MMS 客戶端發送消息到MMS Proxy-Relay 服務器；

M-Send業務提供了MMS Client向MMS-Relay提交多媒體彩信，並得到響應信息的基本機制，下圖是該業務的通信流程：

在MMS Client向MMS Relay提交的PDU（Protocol Data Unit）中，包含有能惟一標識其自身的ID字段，該字段使得請求/迴應（req/resp）被對應關聯起來。

當 MMS Relay服務器收到一個M-Send.req PDU時，它會迴應一個M-Send.conf數據包，其中包含有請求處理結果的狀態代碼。若是MMS Relay可以成功處理該請求，那狀態代碼將爲'OK'，並會返回一個message-ID做爲MM的惟一標識。

M-Notification ：MMS Proxy-Relay服務器發送通知到MMS 客戶端；

MMS Relay服務器發送 M-NotificationPDU 給MMS Client，以告知其有新的多媒體消息，同時MMS Client 會迴應狀態代碼，下圖是該業務的通信流程：

在MMS-Relay服務器發往MMS Client的PDU——M-Notification.ind 中包含有一個兼容於RFC2396的URI，這是收取MM的入口地址，還有消息大小、過時時間、推薦收取方式等附加信息。

MMS Client收到M-Notification.ind PDU後會主動迴應一個M-NotifyResp.ind數據包，以代表已獲得通知。

M-Retrieve ：MMS 客戶端從MMS Proxy-Relay服務器收取MM——多媒體消息；

M-Retrieve業務是MMS Client發送給 MMS Relay服務器以收取MM的請求，該請求的PDU傳輸在WSP/HTTP協議之上。取決於收取方式（即時收取or延時收取）的不一樣，在MMS-Relay服務器和MMS Client之間可能須要一個確認環節，下面分別是即時收取和延時收取時的通信流程：

MMS Client會以 M-Notification.ind PDU中的URI爲參數，向MMS Relay服務器索取MM內容。服務器會想MMS Client迴應M-retrieve.conf數據包，若是成功的話其中會包含完整的MM內容，固然迴應中的狀態代碼會指示操做是否成功。

M-Forward ：MMS 客戶端向MMS Proxy-Relay服務器發送轉發請求；

M-Forward業務使得MMS Client能夠將MMS-Relay服務器中的一條MM轉發給其它用戶，下面是該業務的通信流程：

MMS Client發送一個M-Forward.req PDU到MMS-Relay服務器，該請求中包含有定位MM的URI，以及至少1個的目標地址（即被叫用戶的號碼）等參數，MMS-Relay服務器會迴應一個M-Forward.conf PDU，其中包含指示操做是否成功的狀態碼。另外，轉發業務是一個可選功能，在某些運營商的網絡上可能不會被支持。

M-Delivery ：MMS Proxy-Relay服務器發送投送報告給MMS 客戶端；

M-Delivery業務容許源MMS Client（即發送彩信的用戶）及時獲得信息被投遞的通知，該通知是一個M-Delivery.ind數據包，下面是該業務的通信流程：

該業務只有一個步驟，沒有對應迴應環節，其發送給MMS Client的PDU 包含了源消息的發送狀況，若是有多個目標用戶，則會有多條 M-Delivery.ind 數據包。

另外，與投遞報告類似的還有「已讀報告（Read Report）」，取決於Client端的版本會有兩種不一樣的狀況：MM閱讀報告、PDU閱讀報告。

M-Cancel ：MMS Proxy-Relay服務器向MMS 客戶端發送取消請求；

M-Cancel業務容許MMS-Relay服務器向MMS Clinet發送撤銷一條多媒體消息的請求，下面是該業務的通信流程圖：

MMS-Relay服務器會向MMS Client發送M-Cancel.req數據包，其中包含了目標MM的ID，例如：cancel ID。該業務是可選功能，在某些運營商的網絡上可能不會實現。

M-Delete ：MMS 客戶端從MMS Proxy-Relay服務器上刪除多媒體消息；

M-Delete業務容許MMS Client刪除MMS-Relay服務器上的一條多媒體信息，下面是該業務的通信流程圖：

MMS Client想要刪除1條或多條存儲在MMS-Relay服務器上的MM時，能夠發送M-Delete.req數據包到MMS-Relay服務器，該數據包含1個或多個標識具體MM的URI，而MMS-Relay服務器會迴應M-Delete.conf數據包，其中包含有操做完成狀況的狀態碼。

MMS消息格式及封裝

在以上業務模型的介紹中，通信流程中的主體是用於承載業務數據的PDUs（Protocol Data Units），本節將關注這些數據單元的基本機構、內容組成、封裝編碼等幾個方面。 MMS PDU的內容類型（content-type）必須被指定爲 application/vnd.-wap.mms-message ，用於被客戶端準確識別。

基本結構

MMS PDU由消息頭（Header）和消息體（Body）組成。Header具體描述了PDU的特定信息，Body是消息的具體內容（Body體是可選的）。大多數MMS PDU只含有 Header 域，用於創建和維持通訊， Body體只用在M-Send.req 和 M-Retrieve.conf 兩個數據包中。下圖是MMS PDU基本結構的示意圖：

消息頭（Header） 由一系列的域組成，包括PDU類型，接受方，發送方，發送時間等等。Header域中的項分爲可選項和必選項，而且在編碼MM頭域時，X-Mms-Message-Type，X-Mms-Transaction-ID 和 X-Mms-MMS-Version必須位於MM頭的最開始，並且要嚴格按照所列順序，Content-Type頭域必須在MMS頭域的最後，其後爲消息體，其它域的順序能夠隨意安排。

消息體（ Body ） 是多個不一樣類型的多媒體對象組成的，每一個對象佔據一個部分——Part(參見RFC2387標準)，根據各個部分是否有序，消息的組裝方式分爲：

.application/vnd.wap.multipart.mixed ：全部的消息內容混合在一塊兒，沒有時間上的順序，終端同一時間一次就把全部的消息內容顯示出來。
.application/vnd.wap.multipart.related ：消息內容的各部分之間有必定的關係，該關係多是顯示時間上的前後，或者顯示位置的不一樣，等等。這使得消息可以像「幻燈片」同樣的顯示。

消息體的內容組成

在application/vnd.wap.multipart.mixed類型的PDU中，僅包含有組成MM的全部多媒體內容，而在application/vnd.wap.multipart.related類型的PDU中還會包括Presentation —— 即消息內容的顯示控制部分，該部分使用SMIL標記語言編寫，用來描述MM中各部分的播放次序，顯示/播放時間，結束時間以及在屏幕中的顯示位置，等控制信息。

一般， Presentation部分是消息體的第一個part，若不是則必須使用start 字段指出其所在位置， Presentation部分並不會被顯示出來，而僅僅是讓終端根據它獲取一些控制信息，這些信息決定了其它內容的顯示大小、前後順序、位置等。

最後採用 MIME標準（ Multipurpose Internet Mail Extensions - 多用途互聯網郵件擴展）將完整的MM（包括： SMIL 、文本、圖像、聲音、視頻等各個獨立部分）打包封裝在一塊兒，併發送。 MIME標準定義在RFC2045 、RFC2046 、RFC2047 、RFC2048、RFC2049 等多個RFC標準之中。