CMPP協議參考

一、CMPP協議簡介

中國移動通信互聯網短信網關接 口協議(China Mobile Peer to Peer CMPP)，是中國移動夢網內部各SMS參與節點相互交換SMS的官方協議。作爲夢網的參與方，移動夢網的增值服務商(Service Provider SP )要按照此協議規範實現SP的部分，纔可以將自己的短信通過移動的GSM網絡的數據通道傳輸到最終手機用戶上。

實際上，協議規範了3個方面的內容：

。SP與移動的互聯網短信網關（Internet Short Message Gateway,ISMG）之間的接口協議

。ISMG之間的接口協議（譬如移動各省、市之間的短信息交換通過ISMG之間進行）

。ISMG與匯接網關(Gateway Name Server GNS，類似互聯網上的DNS服務器)之間的接口協議，譬如跨省之類的短信需要GNS的幫助指出當前ISMG該如何傳遞短信。

其中，後二方面屬於移動短信息系統內部實現，對於SP來講大概可以“透明”來看待，只要實現了SP同ISMG的正確交互，就可以實現接入移動夢網短信系統。我們關心的只是SP端的開發細節。

 

二、CMPP交互模式

從手機用戶角度講，按短信的發起/接收路徑來講，有兩個叫法：

MT (Short Message Mobile Terminated, SMMT)，短信接收，短信從SP發送到手機用戶。

MO (Short Message Mobile Originate，SMMO)，短信發送，短信從手機用戶端發送到目標SP。

這兩類短信交互，從SP端來看，都是屬於Socket傳輸應用，CMPP的協議是以TCP/IP協議作爲底層承載協議的，屬於TCP/IP協議棧之上的應用。

SP同ISMG的交互連接分長連接 和短連接 。

所謂短連接，就是一次連接，傳 輸一個消息，然後等待回覆後拆除連接，顯然，效率很低，所以，基本上不被考慮.所謂長連接，就是SP建立同ISMG連接，然後不斷將數據包（一個個 CMPP消息）發送到ISMG，此處發送不必等待某條消息的ISMG迴應消息返回，就接着發送下一個消息。同時，等待ISMG返回信息或者等待ISMG發 送給SP的消息。發送同接收消息不是一定要同步的，實際採用異步（同時也時雙工）模式。從效率上，顯然，必須全雙工的異步模式才能夠滿足實際應用需求。

如下圖（摘自CMPP2.0官方文檔）所示，演示了長連接模式數據傳輸過程：

 

 

 

 

 

 

 

 

三、SP端開發

1.         消息分類

首先，圖中的CMPP消息有很多種，SP同ISMG之間交流這些消息。 大體上這些消息發出後，對方往往需要回復一個應答（RESP）類消息。注意，這些消息大多具有方向性，也就是說只能夠從一端到另一端，而不可反方向進行， 有些（少數）則可兩端都能夠發出。以下信息主要來源於移動的文檔，但針對大家易混淆或源文檔解釋不夠詳細做了明確和補充。具體見下表：

消息名	傳遞方向	解釋說明
CMPP­_CONNECT	SP---à ISMG	CMPP_CONNECT操作的目的是SP向ISMG註冊作爲一個合法SP身份，此消息需要向ISMG發出驗證信息，驗證方式採用md5加密密碼方式，若註冊成功後即建立了應用層的連接(否則ISMG會立即斷開Socket)，此後SP可以通過此ISMG接收和發送短信。 ISMG以CMPP_CONNECT_RESP消息響應SP的請求。具體的算法實現參考CMPP2.0文檔和本文附件代碼。
CMPP_CONNECT_RESP	SPß ---ISMG	ISMG對CMPP_CONNECT消息的回覆（無論是否驗證成功）；如果未通過，會在消息中包含參考信息，但ISMG會立即斷開連接。
CMPP­_ACTIVE_TEST	SPß à ISMG	這個消息通信雙方都可以發出，目的是在沒有其他消息發送時，保持雙方的通信鏈路的連接，避免系統認爲通信通道已經關閉。每一個收到此消息的實體應當返回CMPP_ACTIVE_TEST_RESP消息，以“禮節性”表示自己的還在通信，維持數據連接有效性。 不 過，據網友交流，有些廠家實現的ISMG，僅僅靠自己發出此消息等待SP回答CMPP_ACTIVE_TEST_RESP來確定數據鏈路的有效性，而忽略 SP的CMPP_ACTIVE_TEST消息（有些霸道吧？）這個值得注意，不要僅僅實現發送而不響應此消息，避免數據連接失效。
CMPP_ACTIVE_TEST_RESP	SPß à ISMG	對通信的另一端的CMPP_ACTIVE_TEST消息的回覆。作用參考CMPP_ACTIVE_TEST的解釋。
CMPP­_SUBMIT	SP---à ISMG	在 正確建立了數據連接後，SP向ISMG發送一個SMS數據包。本消息需要仔細研究。接收到此消息後，ISMG需要以CMPP_SUBMIT_RESP消息 作爲回答。如果在一定時間時間內（移動給出的參考值60秒）內未得到消息迴應，那麼SP需要重新發送此數據包，以確保消息得到投遞。如果重發達到3次後仍 然得不到迴應，SP端應該考慮可能ISMG已經失效，應當停止發送此短消息。
CMPP­_SUBMIT_RESP	SPß ---ISMG	該 消息由ISMG發送給SP，同時返回一個“收條”(源CMPP_SUBMIT消息的ISMG端的標示MSGID)給SP，表示“我ISMG已經確認收到你 這條消息了”。收到此消息後，SP需要保留此“收條”，因爲後面ISMG會最終報告本消息是否正確發送到用戶手機。那個報告就是以此消息的“收條”作爲確 認那一條消息的。
CMPP_QUERY	SP---à ISMG	這個查詢不是查詢單條消息的，是查詢SP發送給ISMG的短信的業務情況。可以查總計數，還可以分類查詢。（基本就是發起對移動sms業務數據庫的查詢統計）
CMPP_QUERY_RESP	SPß ---ISMG	ISMG將查詢的數據返回給SP。
CMPP_CANCEL	SP---à ISMG	SP發起的取消某條消息的命令消息，其中包含了之前已經發送給ISMG消息的“收條”以便ISMG可以確定是那一條消息。如果消息已經發送給用戶了，那麼此消息/命令會無效，ISMG返回失敗。
CMPP_CANCEL_RES	SPß ---ISMG	ISMG返回的對CMPP_CANCEL的回覆，並告知是否刪除成功。
CMPP_DELIVER	SPß ---ISMG	當有MO或者狀態報告時，ISMG發送此消息。注意，此消息的數據可以是用戶手機發送給SP的消息，也可是對於之前SP發送到ISMG的短信的最終狀態的回覆，報告短信的最終狀態。
CMPP_DELIVER_RESP	SP---à ISMG	SP禮節性的回覆告知收到CMPP_DELIVER消息。要指出SP報告的CMPP_DELIVER消息的MSGID，以便ISMG知道那一條消息SP已經確認收到。
CMPP_TERMINAT	SPß à ISMG	SP和ISMG都可以主動發消息給對方，自己這端由於某種原因需要終止當前的數據連接。終止後，要經過重新Connection（驗證）之後纔可以（進入事務階段）發送SMS數據消息。
CMPP­_TERMINATE_RES	SPß à ISMG	通知對方，本端已經最好撤除連接的準備。

                    

2.         交互階段

整個CMPP協議交互分爲驗證 、事務 兩個階段。驗證階段，發送CMPP_CONNECTION消息進行驗證，通過驗證後（必須要通過才）進入CMPP事務階段，可以發送短信數據了。上表中的CMPP_CONNECTION以下的消息都屬於事務階段的消息。

 

3.         消息數據結構

每一個消息包含 消息頭 和 消息體 兩 個部分，頭固定長度爲12字節，其他消息長度各異，但是同一類型消息的長度是固定的。所有消息的各個字段基本上僅有3種類型：Unsigned Integer （無符號整型）  、Integer（整型）、Octet String（字符串），每種類型具體長度不定，網絡字節順序。

1、 消息頭(3個Unsigned Integer字段組成)：

4字節的Total_Length （Unsigned Integer），包含了此消息的總計（包括了頭部分）長度。

4字節的Command_Id（Unsigned Integer），指明瞭此消息到底是什麼消息，就是上表中消息的枚舉值。應用程序根據此值確定本數據包到底是什麼消息，從而可以按照確定的消息類型，解析餘下的消息體。

4字節的 Sequence_Id（Unsigned Integer），指明瞭此數據包在發送此消息端的唯一編號。這個唯一編號，實際上可以看作流水操作編號。因爲分析到交互模式我們看到，SP發送數據到 ISMG，不是每發送一個就停下來等待ISMG的回覆，而是“一下子”發送多個數據包過去，然後等待ISMG的迴應。然而，怎麼知道迴應的消息是到底對應 之前發送過去的消息中的那一條呢？本字段就是解決此難題。SP按照編號發送消息過去，等待ISMG的迴應—一般情形下回應消息數據結構都有表明本消息迴應 的是SP發出的哪一條消息，這個對應就是依靠Sequence_Id。它並不要求一定要嚴格唯一，但是在給定的一段時間內，必須唯一（基本上只要SP發送 過去的消息中沒有重複就行了）。如果是需要SP回答的消息，SP也必須將ISMG發送過來的消息的Sequence_Id填入相應字段，表明這是某個消息 的迴應。SP端和ISMG端Sequence_ID都沒有確定具體的算法。SP可以(但不推薦)採用數據庫的唯一Id作爲此值。

 

2、消息體。消息體長度根據消息不同，長度不一。其他的參考移動的文檔《中國移動通信互聯網短信網關接口協議(China Mobile Peer to Peer, CMPP)（V2.0）》，這裏着重講講2個重要消息的消息體數據結構：

       CMPP­_SUBMIT 的消息體：

字段名	長度(byte)	類型	描述
Msg_Id	8	Unsigned Integer	信息標識，應該由SP側ISMG本身產生，本處填空，供ISMG傳輸時使用。SP提交時候應當留空。
Pk_total	1	Unsigned Integer	相同Msg_Id的信息總條數，從1開始。如果一條消息長度超多一條短信，可能需要分解成多條消息，那麼實際上這多條消息屬於一條完整消息，所以可以根據此給分解得到的多條短信進行編號，那麼總計需要編成多少條短信，此處就填寫多少。
Pk_number	1	Unsigned Integer	相同Msg_Id的信息序號，從1開始。編號決定消息的相對位置。
Registered_Delivery	1	Unsigned Integer	是否要求返回狀態確認報告： 0：不需要 1：需要 2：產生SMC話單（該類型短信僅供網關計費使用，不發送給目的終端）。 一 般情況下，都需要確認報告。SMC話單也需要返回是否成功的報告。這條消息用於包月SMC時，當你發送消息給移動的ISMG，移動的計費系統會一次性扣除 用戶的信息費，但是此消息不會送到用戶手機。但是注意，有的ISMG廠商(很可能是移動要求)實現此消息時候，如果你並沒有發送任何此包月類型的消息給用 戶手機，是不發生扣費行爲的。移動會認爲這是屬於違規的“代收費”行爲，會影響同移動的合作關係。
Msg_level	1	Unsigned Integer	信息級別，信息的優先級。不過實際當中，感覺ISMG端並沒有區分優先級。
Service_Id	10	Octet String	業務類型，是數字、字母和符號的組合。這個表示業務的字符串可以給發出的短信分類。通過此字段大約可以知道每個服務項目的業務量，有利於統計和計費以及結算。
Fee_UserType	1	Unsigned Integer	計費用戶類型字段 0：對目的終端MSISDN計費； 1：對源終端MSISDN計費； 2：對SP計費; 3：表示本字段無效，對誰計費參見Fee_terminal_Id 字段。
Fee_terminal_Id	21	Unsigned Integer	被計費用戶的號碼（如本字節填空，則表示本字段無效，對誰計費參見Fee_UserType字段，本字段與Fee_UserType字段取0、1、2時互斥）
TP_pId	1	Unsigned Integer	GSM協議類型。詳細是解釋請參考GSM03.40中的9.2.3.9
TP_udhi	1	Unsigned Integer	GSM協議類型。詳細是解釋請參考GSM03.40中的9.2.3.23,僅使用1位，右對齊
Msg_Fmt	1	Unsigned Integer	信息格式  0：ASCII串  3：短信寫卡操作   4：二進制信息  8：UCS2編碼 15：含GB漢字   這個決定了Msg_Content字段的字節內容應該按照什麼編碼來解碼/編碼。
Msg_src	6	Octet String	信息內容來源(SP的企業代碼)，例如919000。
FeeType	2	Octet String	資費類別 01：對“計費用戶號碼”免費 02：對“計費用戶號碼”按條計信息費 03：對“計費用戶號碼”按包月收信息費 04：對“計費用戶號碼”的信息費封頂 05：對“計費用戶號碼”的收費是由SP實現。 通常值爲02，注意這是一個字符串，並非整型。
FeeCode	6	Octet String	資費代碼（以分爲單位），如：“ 0050 ”代表人民幣 0.50 元。
ValId_Time	17	Octet String	存活有效期，格式遵循SMPP3.3協議
At_Time	17	Octet String	定時發送時間，格式遵循SMPP3.3協議。這個字段可以讓短信在規定的時間給手機用戶。一般情況下不填，保留爲空字符串。
Src_Id	21	Octet String	源號碼 SP的服務代碼或前綴爲服務代碼的長號碼, 網關將該號碼完整的填到SMPP協議Submit_SM消息相應的source_addr字段，該號碼最終在用戶手機上顯示爲短消息的主叫號碼。實際上就是服務代碼，可以是長號碼
DestUsr_tl	1	Unsigned Integer	接收信息的用戶數量(小於100個用戶)，通常是1。移動是忌諱一條消息發給多個用戶的。
Dest_terminal_Id	21*DestUsr_tl	Octet String	接收短信的MSISDN號碼，一個類似字符串數組的結構。受DestUsr_tl的約束，決定了本字段的長度。
Msg_Length	1	Unsigned Integer	信 息長度(Msg_Fmt值爲0時：<160個字節；其它<=140個字節)。如果是ASCII碼，可以達到160個英文字母。原因是因爲英文 字母僅佔用7bit，而中文等雙字節代碼需要16位，同時每一個字節最高爲都佔用，所以最多140個字節，也就是70個漢字。
Msg_Content