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

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

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

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

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

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

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

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

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

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

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

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

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

　　RFC3428 即時(shí)消息傳輸

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

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

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

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

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

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

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

　　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 表示會(huì)話ID

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

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

　　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

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

　　MSRP a786hjs2 200 OK // 針對(duì)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é)議時(shí)，我們需要注意價(jià)格比較關(guān)鍵的概念。首先一個(gè)是關(guān)于IM傳輸中的幀數(shù)據(jù)大小的問(wèn)題。前面我們已經(jīng)討論過(guò)，在MSRP的傳輸過(guò)程中，數(shù)據(jù)是以數(shù)據(jù)塊的方式來(lái)傳輸?shù)摹Ｒ虼�，如果需要幾次傳輸�?shù)據(jù)的話，就需要設(shè)定一個(gè)framing的邊界范圍，避免數(shù)據(jù)接收后，重新聚合時(shí)數(shù)據(jù)的丟失。數(shù)據(jù)邊界標(biāo)識(shí)用來(lái)指示在數(shù)據(jù)發(fā)送時(shí)，是否仍然有后續(xù)數(shù)據(jù)待發(fā)送，數(shù)據(jù)發(fā)送是否結(jié)束。其標(biāo)識(shí)符前綴七個(gè)破折號(hào)（-------）數(shù)據(jù)和數(shù)據(jù)標(biāo)識(shí)，具體的數(shù)據(jù)標(biāo)識(shí)如下：

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

　　# 表示丟棄此消息

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

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

　　// 同一會(huì)話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也是一個(gè)非常重要的method。它包括成功的report狀態(tài)和失敗的report狀態(tài)。這兩種狀態(tài)用來(lái)表示數(shù)據(jù)發(fā)送的狀態(tài)以及失敗后的處理和響應(yīng)碼機(jī)制。以下是一個(gè)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)。

　　以下是一個(gè)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， 接收失敗。

　　因?yàn)楫?dāng)前很多的網(wǎng)絡(luò)組件需要加密，MSRP也可以通過(guò)m和a行的定義來(lái)實(shí)現(xiàn)加密，加密方式是在SDP的a行通過(guò)MSRPS來(lái)實(shí)現(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)用中，大家可能會(huì)使用到另外一個(gè)RFC4975協(xié)議的擴(kuò)展協(xié)議-RFC4976。此規(guī)范擴(kuò)展了MSRP協(xié)議的一些其他概念，適用于轉(zhuǎn)發(fā)中間節(jié)點(diǎn)的處理。MSRP是用來(lái)對(duì)消息在點(diǎn)對(duì)點(diǎn)的環(huán)境中進(jìn)行傳輸?shù)�。但是，在�?shí)際生產(chǎn)環(huán)境中，消息傳輸可能經(jīng)過(guò)多個(gè)中間節(jié)點(diǎn)，代理。通過(guò)轉(zhuǎn)發(fā)擴(kuò)展到使用，可以保證MSRP消息能夠

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

　　Relay Extensions for the Message Session Relay Protocol。

　　它的主要目的包括：

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

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

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

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

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

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