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

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

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

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

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

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

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

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

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

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

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

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

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

　　RFC3428 即時(shí)消息傳輸

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

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

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

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

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

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

　　首先，UA 1 對UA 2發(fā)送一個(gè)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 表示會(huì )話(huà)ID

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

　　MSRP定義了兩個(gè)請求methods， 一個(gè)是SEND 用來(lái)發(fā)送IM數據，另外一個(gè)是REPORT method，它用來(lái)發(fā)送報告上一個(gè)數據發(fā)送到狀態(tài)，或發(fā)送數據的范圍。具體的SEND請求執行細節如下，當UA 1 對UA 2通過(guò)SEND請求發(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

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

　　MSRP a786hjs2 200 OK // 針對a786hjs2的成功回復。

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

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

　　-------a786hjs2$

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

　　+ 表示后續還有更多chunk 數據塊

　　# 表示丟棄此消息

　　$ 表示這是最后的chunk數據塊

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

　　// 同一會(huì )話(huà)ID

　　MSRP dkei38sd SEND

　　Message-ID： 4564dpWd // 同一MID

　　Byte-Range： 1-*/8

　　Content-Type： text/plain

　　abcd // 真正數據chunk

　　-------dkei38sd+ // +這里表示還有后續數據

　　MSRP dkei38ia SEND

　　Message-ID： 4564dpWd // 同一MID

　　Byte-Range： 5-8/8

　　Content-Type： text/plain

　　EFGH // 真正數據

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

　　在MSRP協(xié)議中，REPORT method也是一個(gè)非常重要的method。它包括成功的report狀態(tài)和失敗的report狀態(tài)。這兩種狀態(tài)用來(lái)表示數據發(fā)送的狀態(tài)以及失敗后的處理和響應碼機制。以下是一個(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數據。

　　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， 接收失敗。

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

　　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é)議的應用中，大家可能會(huì )使用到另外一個(gè)RFC4975協(xié)議的擴展協(xié)議-RFC4976。此規范擴展了MSRP協(xié)議的一些其他概念，適用于轉發(fā)中間節點(diǎn)的處理。MSRP是用來(lái)對消息在點(diǎn)對點(diǎn)的環(huán)境中進(jìn)行傳輸的。但是，在實(shí)際生產(chǎn)環(huán)境中，消息傳輸可能經(jīng)過(guò)多個(gè)中間節點(diǎn)，代理。通過(guò)轉發(fā)擴展到使用，可以保證MSRP消息能夠

　　可靠穩定和擁塞管理，最終實(shí)現傳輸的穩定性。RFC4976全稱(chēng)是：

　　Relay Extensions for the Message Session Relay Protocol。

　　它的主要目的包括：

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

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

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

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

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

　　需要提醒讀者的是，在實(shí)際應用環(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è)溝通的效率。