最近這幾年，企業(yè)通信或者運營商的通信業(yè)務(wù)中，融合通信的概念逐漸進入到了我們?nèi)粘５纳�活中，包括大家都時時刻刻使用的微信，QQ，飛書等工具。它的便捷性和實時性讓我們每個人真正感受到了科技的力量。其中，我們經(jīng)常使用的短信或者消息，視頻就是融合通信中主要的溝通方式。這些呈現(xiàn)方式都是IMS或者現(xiàn)代網(wǎng)絡(luò)中富媒體服務(wù)一個部分。在筆者的歷史文章中，我們已經(jīng)談?wù)摿撕芏嚓P(guān)于語音方面的技術(shù)。今天，筆者專門針對短信或者即時消息進行深入的討論。其中，在關(guān)于消息服務(wù)中，我們將針對兩個關(guān)于消息服務(wù)中主要的協(xié)議，MSRP協(xié)議所相關(guān)的RFC4975和RFC4976進行分享。

　　關(guān)于富媒體服務(wù)或者融合通信套件（Rich Communication Suite）的消息服務(wù)的討論中，我們將首先討論關(guān)于短信類型信息，富媒體的簡單背景知識，關(guān)于基于SIP消息和MSRP的區(qū)別，使用MSRP協(xié)議的原因，針對MSRP-The Message Session Relay Protocol (MSRP)-消息轉(zhuǎn)發(fā)協(xié)議和 Relay Extensions for the Message Session Relay Protocol (MSRP)-MSRP的轉(zhuǎn)發(fā)擴展協(xié)議討論。

　　當(dāng)我們討論融合通信，我們會討論到多種媒體的融合。無論從企業(yè)通信產(chǎn)品還是從運營商終端用戶，都需要文本，語音和視頻的融合。基本上就是無融合無未來。因此，我們單討論一種媒體的實現(xiàn)不能稱之為融合通信。同樣，一些企業(yè)通信產(chǎn)品（例如SBC結(jié)合IPPBX或者UC）如果僅是支持了語音，或者圖像，還是短信即時消息IM都不能稱之為融合通信。融合的目的是支持這以上三種人類溝通的基本手段。富媒體則代表了這三種表達方式的呈現(xiàn)，當(dāng)然也實現(xiàn)了更多的技術(shù)支持。

RCS測試網(wǎng)絡(luò)示例

　　現(xiàn)在我們簡單回顧關(guān)于富媒體的基本知識。根據(jù)維基百科的定義，RCS（Rich Communication Suite-富媒體單元）最早是由全球移動通信聯(lián)盟-GSMA規(guī)劃，是基于IMS網(wǎng)絡(luò)之上的具有統(tǒng)一業(yè)務(wù)集定義的技術(shù)標(biāo)準(zhǔn)， 通過手機電話移動端通訊錄實現(xiàn)語音、消息、視頻，狀態(tài)呈現(xiàn)等多媒體業(yè)務(wù)的總稱。2018年Release 8.0 Version 9.0 ，支持了聊天機器人和vcard 4.0。RCS支持的標(biāo)準(zhǔn)功能如下：

　　當(dāng)然，其部署要求的服務(wù)能力也需要支持：

　　從市場角度看，根據(jù)grandviewresearch發(fā)布的研究報告指出，在2019年，全球富媒體服務(wù)的市場規(guī)模在780.1 million 美金。預(yù)計到2027年，復(fù)合增長率到達35.4%。 從以下圖例中我們可以看出，北美市場對融合通信服務(wù)的增長非常驚人。

　　另外，受疫情影響使用RCS服務(wù)也大量增加，最多的行業(yè)包括旅游，零售，媒體娛樂，健康行業(yè)等。

　　從市場角度看，未來的消息服務(wù)市場會逐步增長。從個人社交生活到企業(yè)通信，融合通信的能力正在變得越來越復(fù)雜，要求服務(wù)越來越具有實時性和具有非常強大移動存儲能力。基本上，我們已經(jīng)從簡單的短信時代（SMS）進入了多媒體信息服務(wù)時代（MMS）。在RCS中，MSRP就是其中的一個應(yīng)用。接下來，我們首先說明關(guān)于MSRP的必要基礎(chǔ)知識。

　　我們討論關(guān)于消息的處理，這里我們討論的是Instant Messaging， 或者即時消息。在MSRP中，消息方式支持兩種基本的模式，一種是Page模式，另外一種是Session模式。關(guān)于Page模式和會話模式的實現(xiàn)方式，讀者可以參考以下示例：

　　一般情況下，Page 模式來支持SMS短信的發(fā)送，而Session 或者會話模式則支持多媒體消息業(yè)務(wù)中的消息發(fā)送，用來保證交互中其消息的穩(wěn)定性，連續(xù)性和完整性。短信發(fā)送無需考慮雙方的太多交互機制，但是即時消息（IM）則需要考慮交互雙方的狀態(tài)，接收情況，需要把雙方發(fā)送到一系列消息看作是單個的通信消息。一旦創(chuàng)建了TCP連接后，所有來自于不同終端的會話消息都需要通過此連接來執(zhí)行。

　　具體來說，Page 模式環(huán)境下，因為架構(gòu)的原因，它具有一些先天的局限性。在處理SIP消息時，SIP是通過MESSAGE（RFC3428） 方式來傳輸數(shù)據(jù)，在消息體中傳輸實際數(shù)據(jù)，消息體文件最大傳輸數(shù)據(jù)支持1200 bytes。MESSAGE請求也不會創(chuàng)建SIP dialog。如果大量數(shù)據(jù)通過代理服務(wù)器的話，可能導(dǎo)致代理服務(wù)器的性能受到影響，并且Page 模式不能保證端對端的加密（參考RFC3428-11.3），消息處理的負(fù)載比較大，對多臺終端支持不是非常友好。

　　和Page 模式相比而言，會話模式則具有很多適用于融合通信的各種擴展機制，并實現(xiàn)了會話和對數(shù)據(jù)塊的支持，其傳輸更加靈活。關(guān)于SIP對IM的支持，在Session Initiation Protocol (SIP) Extension for Instant Messaging對消息傳輸說明了具體的傳輸流程，讀者可以參考RFC3428。在其處理過程中，終端UA1直接對代理服務(wù)器發(fā)送消息，然后代理服務(wù)器轉(zhuǎn)發(fā)給UA2中。它們之間的處理中，只有一個MESSAGE和200 OK，中間再無其他協(xié)商的消息。但是，在我們實際生產(chǎn)環(huán)境中，環(huán)境會非常復(fù)雜，協(xié)商流程會增加很多的其他后續(xù)處理流程。顯然，針對SIP 即時消息的傳輸，RFC3428 缺乏更強大的支持。

　　RFC3428 即時消息傳輸

　　相反，在以下圖例中，我們可以看到，通過請求攜帶SDP以及MSRP，支持了基于SIP會話和SDP的處理，消息之間可以通過會話來綁定，消息體數(shù)據(jù)塊可以通過分解為不同大小的方式來發(fā)送。

　　關(guān)于MSRP的處理流程，其實其框架涉及到了RFC4975和其擴展協(xié)議RFC4976 兩個協(xié)議。MSRP部署環(huán)境包括了創(chuàng)建會話，創(chuàng)建MSRP會話和針對MSRP的結(jié)束拆線流程。筆者在接下來的章節(jié)中重點介紹MSRP的規(guī)范細節(jié)。

　　關(guān)于MSRP涉及了兩個主要的規(guī)范協(xié)議，一個協(xié)議是RFC4975，另外一個是RFC4976的擴展協(xié)議。下面，筆者針對其協(xié)議為大家做一個詳解說明。RFC4975 規(guī)范全稱是The Message Session Relay Protocol (MSRP)， 這里，我們翻譯為消息會話轉(zhuǎn)發(fā)協(xié)議，簡稱MSRP。

　　簡單來說，MSRP協(xié)議是在會話內(nèi)容中傳輸一系列相關(guān)的即時消息，對消息的傳輸類似于RTP的傳輸方式，對會話管理的方式類似于SIP協(xié)議中會話管理方式，僅支持TCP連接，SIP/SDP的協(xié)商機制用來支持終端之間的協(xié)商。以下圖例是基于OPENSIPS的MSRP 富媒體實現(xiàn)框架。

　　如果我們從以上圖例框架中抽象出來的話，以下圖例就是一個基本的MSRP/SIP/IM會話的處理流程：

　　如果我們進一步分解其IM會話流程，我們可以看到通過SIP協(xié)議來創(chuàng)建的會話處理流程。

　　首先，UA 1 對UA 2發(fā)送一個INVITE請求，攜帶了和MSRP相關(guān)的請求消息，例如：

　　INVITE sip：bob@biloxi.example.com SIP/2.0

　　To： <sip：bob@biloxi.example.com>

　　From： <sip：alice@atlanta.example.com>；tag=786

　　Call-ID： 3413an89KU

　　Content-Type： application/sdp

　　c=IN IP4 atlanta.example.com // IP地址

　　m=message 7654 TCP/MSRP *  // 表示了MSRP的端口和協(xié)議

　　a=accept-types：text/plain

　　// 以下a行指示MSRP的URL，表示MSRP 消息發(fā)送到目的地URL

　　// jshA7weztas 表示會話ID

　　a=path：msrp：//atlanta.example.com：7654/jshA7weztas；tcp

　　MSRP定義了兩個請求methods， 一個是SEND 用來發(fā)送IM數(shù)據(jù)，另外一個是REPORT method，它用來發(fā)送報告上一個數(shù)據(jù)發(fā)送到狀態(tài)，或發(fā)送數(shù)據(jù)的范圍。具體的SEND請求執(zhí)行細節(jié)如下，當(dāng)UA 1 對UA 2通過SEND請求發(fā)送消息時：

　　MSRP a786hjs2 SEND

　　To-Path： msrp：//biloxi.example.com：12763/kjhd37s2s20w2a；tcp

　　From-Path： msrp：//atlanta.example.com：7654/jshA7weztas；tcp

　　Message-ID： 87652491

　　Byte-Range： 1-25/25

　　Content-Type： text/plain

　　針對以上SEND請求，對端回復(fù)的成功的消息是，包括jshA7weztas和kjhd37s2s20w2a的雙方ID。

　　MSRP a786hjs2 200 OK // 針對a786hjs2的成功回復(fù)。

　　To-Path： msrp：//atlanta.example.com：7654/jshA7weztas；tcp

　　From-Path： msrp：//biloxi.example.com：12763/kjhd37s2s20w2a；tcp

　　-------a786hjs2$

　　在學(xué)習(xí)關(guān)于MSRP協(xié)議時，我們需要注意價格比較關(guān)鍵的概念。首先一個是關(guān)于IM傳輸中的幀數(shù)據(jù)大小的問題。前面我們已經(jīng)討論過，在MSRP的傳輸過程中，數(shù)據(jù)是以數(shù)據(jù)塊的方式來傳輸?shù)�。因此，如果需要幾次傳輸�?shù)據(jù)的話，就需要設(shè)定一個framing的邊界范圍，避免數(shù)據(jù)接收后，重新聚合時數(shù)據(jù)的丟失。數(shù)據(jù)邊界標(biāo)識用來指示在數(shù)據(jù)發(fā)送時，是否仍然有后續(xù)數(shù)據(jù)待發(fā)送，數(shù)據(jù)發(fā)送是否結(jié)束。其標(biāo)識符前綴七個破折號（-------）數(shù)據(jù)和數(shù)據(jù)標(biāo)識，具體的數(shù)據(jù)標(biāo)識如下：

　　+ 表示后續(xù)還有更多chunk 數(shù)據(jù)塊

　　# 表示丟棄此消息

　　$ 表示這是最后的chunk數(shù)據(jù)塊

　　另外，大家需要注意，message支持了MESSAGE ID，chunk 發(fā)送數(shù)量需要對應(yīng)同一唯一的MESSAGE ID，例如，在以下的IM 發(fā)送過程中，最終發(fā)送的是：abcdEFGH， 但是通過兩次發(fā)送。

　　// 同一會話ID

　　MSRP dkei38sd SEND

　　Message-ID： 4564dpWd // 同一MID

　　Byte-Range： 1-*/8

　　Content-Type： text/plain

　　abcd // 真正數(shù)據(jù)chunk

　　-------dkei38sd+ // +這里表示還有后續(xù)數(shù)據(jù)

　　MSRP dkei38ia SEND

　　Message-ID： 4564dpWd // 同一MID

　　Byte-Range： 5-8/8

　　Content-Type： text/plain

　　EFGH // 真正數(shù)據(jù)

　　-------dkei38ia$ // $這里表示此數(shù)據(jù)已經(jīng)是最后的chunk數(shù)據(jù)。

　　在MSRP協(xié)議中，REPORT method也是一個非常重要的method。它包括成功的report狀態(tài)和失敗的report狀態(tài)。這兩種狀態(tài)用來表示數(shù)據(jù)發(fā)送的狀態(tài)以及失敗后的處理和響應(yīng)碼機制。以下是一個SEND 成功的REPORT 消息：

　　MSRP dkei38sd REPORT  // REPORT method

　　To-Path： msrp：//alicepc.e

　　xample.com：7777/iau39soe

　　2843z；tcp

　　From-Path： msrp：//bob

　　.example.com：8888/9di4ea

　　e923wzd；tcp

　　Message-ID： 12339sdqwer

　　Byte-Range： 1-50/*  // 收到1-50 chunk數(shù)據(jù)。

　　Status： 000 200 OK // 成功，200 OK 狀態(tài)。

　　以下是一個SEND 失敗的REPORT 消息：

　　MSRP dkei38sd REPORT

　　To-Path： msrp：//alicepc.e

　　xample.com：7777/iau39soe

　　2843z；tcp

　　From-Path： msrp：//bob

　　.example.com：8888/9di4ea

　　e923wzd；tcp

　　Message-ID： 12339sdqwer

　　Byte-Range： 1-50/*

　　Status： 000 408 Timeout // 狀態(tài)碼 408， 接收失敗。

　　因為當(dāng)前很多的網(wǎng)絡(luò)組件需要加密，MSRP也可以通過m和a行的定義來實現(xiàn)加密，加密方式是在SDP的a行通過MSRPS來實現(xiàn)：

　　c=IN IP4 atlanta.example.com

　　m=message 7654 TCP/TLS/MSRP * // 支持TLS

　　a=accept-types：text/plain

　　// 支持msrps

　　a=path：msrps：//atlanta.example.com：7654/jshA7weso3ks；tcp

　　a=fingerprint：SHA-1 \

　　4A：AD：B9：B1：3F：82：18：3B：54：02：12：DF：3E：5D：49：6B：19：E5：7C：AB

　　筆者以上介紹的是RFC4975 協(xié)議，在MSRP協(xié)議的應(yīng)用中，大家可能會使用到另外一個RFC4975協(xié)議的擴展協(xié)議-RFC4976。此規(guī)范擴展了MSRP協(xié)議的一些其他概念，適用于轉(zhuǎn)發(fā)中間節(jié)點的處理。MSRP是用來對消息在點對點的環(huán)境中進行傳輸?shù)摹５�是，在實際生產(chǎn)環(huán)境中，消息傳輸可能經(jīng)過多個中間節(jié)點，代理。通過轉(zhuǎn)發(fā)擴展到使用，可以保證MSRP消息能夠

　　可靠穩(wěn)定和擁塞管理，最終實現(xiàn)傳輸?shù)姆�(wěn)定性。RFC4976全稱是：

　　Relay Extensions for the Message Session Relay Protocol。

　　它的主要目的包括：

　　關(guān)于RFC4976更多細節(jié)，包括轉(zhuǎn)發(fā)的路徑，認(rèn)證，定時器等相關(guān)細節(jié)，讀者可以參考RFC4976的協(xié)議，這里不再贅述。

　　在實時通信環(huán)境中，WebRTC是目前比較熱門的技術(shù)，WEBRTC的數(shù)據(jù)通道也可以實現(xiàn)對MSRP的數(shù)據(jù)傳輸（RFC8873），通過SDP的offer/answer來實現(xiàn)協(xié)商，支持TCP/TLS傳輸。但是，此規(guī)范的定義中沒有關(guān)于類似于chunk的數(shù)據(jù)管理，會話管理機制，它仍然需要借助于RFC4975的處理規(guī)范。它可以實現(xiàn)聊天，文件轉(zhuǎn)發(fā)。如果讀者對基于WEBRTC的MSRP傳輸有興趣的話，可以進一步閱讀此規(guī)范。

　　RFC 4975/4976 - Message Session Relay Protocol (MSRP) protocol 是富媒體服務(wù)的時代需要了解的主要協(xié)議。在本文章中，筆者主要討論了關(guān)于即時消息IM傳輸?shù)腗SRP協(xié)議以及其擴展協(xié)議。首先介紹了富媒體服務(wù)的背景知識，然后說明了關(guān)于MSRP中數(shù)據(jù)傳輸?shù)膬煞N模式，page模式和會話模式。另外，筆者針對會話模式下的MSRP協(xié)議進行了深入討論，包括傳輸流程，IM會話處理，關(guān)于支持會話管理，數(shù)據(jù)管理和擴展的處理。

　　具體來說，作者介紹了MSRP協(xié)議的語法，傳輸機制，和關(guān)于chunk 數(shù)據(jù)塊處理，以及SEND和REPORT method來說明如何通過MSRP實現(xiàn)完整的數(shù)據(jù)傳輸。

　　另外，分享了關(guān)于RFC4976擴展協(xié)議的主要目的。擴展協(xié)議的目的是為了進一步保證MSRP轉(zhuǎn)發(fā)的穩(wěn)定性，連續(xù)性和擁塞環(huán)境下的數(shù)據(jù)管理，時延處理等控制機制。作者最后討論了基于WEBRTC的數(shù)據(jù)通道傳輸MSRP的協(xié)議規(guī)范。

　　需要提醒讀者的是，在實際應(yīng)用環(huán)境中，特別是企業(yè)融合通信業(yè)務(wù)場景中，如何利用IMS網(wǎng)絡(luò)環(huán)境下提供的IM服務(wù)，集成SBC支持，終端能力支持仍然是目前企業(yè)通信中需要進一步探討的地方。也許，在不久的未來，我們可以看到這些IM服務(wù)在企業(yè)通信中更多的應(yīng)用，更好地提升企業(yè)溝通的效率。