最近这几年,企业通信或者运营商的通信业务中,融合通信的概念逐渐进入到了我们日常的生活中,包括大家都时时刻刻使用的微信,QQ,飞书等工具。它的便捷性和实时性让我们每个人真正感受到了科技的力量。其中,我们经常使用的短信或者消息,视频就是融合通信中主要的沟通方式。这些呈现方式都是IMS或者现代网络中富媒体服务一个部分。在笔者的历史文章中,我们已经谈论了很多关于语音方面的技术。今天,笔者专门针对短信或者即时消息进行深入的讨论。其中,在关于消息服务中,我们将针对两个关于消息服务中主要的协议,MSRP协议所相关的RFC4975和RFC4976进行分享。
关于富媒体服务或者融合通信套件(Rich Communication Suite)的消息服务的讨论中,我们将首先讨论关于短信类型信息,富媒体的简单背景知识,关于基于SIP消息和MSRP的区别,使用MSRP协议的原因,针对MSRP-The Message Session Relay Protocol (MSRP)-消息转发协议和 Relay Extensions for the Message Session Relay Protocol (MSRP)-MSRP的转发扩展协议讨论。
富媒体背景知识
当我们讨论融合通信,我们会讨论到多种媒体的融合。无论从企业通信产品还是从运营商终端用户,都需要文本,语音和视频的融合。基本上就是无融合无未来。因此,我们单讨论一种媒体的实现不能称之为融合通信。同样,一些企业通信产品(例如SBC结合IPPBX或者UC)如果仅是支持了语音,或者图像,还是短信即时消息IM都不能称之为融合通信。融合的目的是支持这以上三种人类沟通的基本手段。富媒体则代表了这三种表达方式的呈现,当然也实现了更多的技术支持。
![](http://www.ctiforum.com/uploadfile/2022/1008/20221008043536143.png)
RCS测试网络示例
现在我们简单回顾关于富媒体的基本知识。根据维基百科的定义,RCS(Rich Communication Suite-富媒体单元)最早是由全球移动通信联盟-GSMA规划,是基于IMS网络之上的具有统一业务集定义的技术标准, 通过手机电话移动端通讯录实现语音、消息、视频,状态呈现等多媒体业务的总称。2018年Release 8.0 Version 9.0 ,支持了聊天机器人和vcard 4.0。RCS支持的标准功能如下:
- 独立消息
- 1对1 聊天
- 组聊
- 文件传输
- 内容共享
- 社交呈现信息
- IP语音呼叫
- 尽力视频呼叫
- 地理信息交互
- 基于网络的黑名单支持能力
- 支持基于SIP OPTIONS的呈现方式的兼容能力
当然,其部署要求的服务能力也需要支持:
- 能力发现和服务的有效性
- 运营商消息能力
- 支持对多种设备发送消息的能力
- API扩展支持
- 安全支持
- RCS设置支持
从市场角度看,根据grandviewresearch发布的研究报告指出,在2019年,全球富媒体服务的市场规模在780.1 million 美金。预计到2027年,复合增长率到达35.4%。 从以下图例中我们可以看出,北美市场对融合通信服务的增长非常惊人。
![](http://www.ctiforum.com/uploadfile/2022/1008/20221008044440335.jpg)
另外,受疫情影响使用RCS服务也大量增加,最多的行业包括旅游,零售,媒体娱乐,健康行业等。
![](http://www.ctiforum.com/uploadfile/2022/1008/20221008043806899.png)
从市场角度看,未来的消息服务市场会逐步增长。从个人社交生活到企业通信,融合通信的能力正在变得越来越复杂,要求服务越来越具有实时性和具有非常强大移动存储能力。基本上,我们已经从简单的短信时代(SMS)进入了多媒体信息服务时代(MMS)。在RCS中,MSRP就是其中的一个应用。接下来,我们首先说明关于MSRP的必要基础知识。
MSRP中的Page模式和会话模式的消息处理
我们讨论关于消息的处理,这里我们讨论的是Instant Messaging, 或者即时消息。在MSRP中,消息方式支持两种基本的模式,一种是Page模式,另外一种是Session模式。关于Page模式和会话模式的实现方式,读者可以参考以下示例:
![](http://www.ctiforum.com/uploadfile/2022/1008/20221008043844996.png)
一般情况下,Page 模式来支持SMS短信的发送,而Session 或者会话模式则支持多媒体消息业务中的消息发送,用来保证交互中其消息的稳定性,连续性和完整性。短信发送无需考虑双方的太多交互机制,但是即时消息(IM)则需要考虑交互双方的状态,接收情况,需要把双方发送到一系列消息看作是单个的通信消息。一旦创建了TCP连接后,所有来自于不同终端的会话消息都需要通过此连接来执行。
具体来说,Page 模式环境下,因为架构的原因,它具有一些先天的局限性。在处理SIP消息时,SIP是通过MESSAGE(RFC3428) 方式来传输数据,在消息体中传输实际数据,消息体文件最大传输数据支持1200 bytes。MESSAGE请求也不会创建SIP dialog。如果大量数据通过代理服务器的话,可能导致代理服务器的性能受到影响,并且Page 模式不能保证端对端的加密(参考RFC3428-11.3),消息处理的负载比较大,对多台终端支持不是非常友好。
和Page 模式相比而言,会话模式则具有很多适用于融合通信的各种扩展机制,并实现了会话和对数据块的支持,其传输更加灵活。关于SIP对IM的支持,在Session Initiation Protocol (SIP) Extension for Instant Messaging对消息传输说明了具体的传输流程,读者可以参考RFC3428。在其处理过程中,终端UA1直接对代理服务器发送消息,然后代理服务器转发给UA2中。它们之间的处理中,只有一个MESSAGE和200 OK,中间再无其他协商的消息。但是,在我们实际生产环境中,环境会非常复杂,协商流程会增加很多的其他后续处理流程。显然,针对SIP 即时消息的传输,RFC3428 缺乏更强大的支持。
![](http://www.ctiforum.com/uploadfile/2022/1008/20221008043928550.png)
RFC3428 即时消息传输
相反,在以下图例中,我们可以看到,通过请求携带SDP以及MSRP,支持了基于SIP会话和SDP的处理,消息之间可以通过会话来绑定,消息体数据块可以通过分解为不同大小的方式来发送。
![](http://www.ctiforum.com/uploadfile/2022/1008/20221008043948445.png)
关于MSRP的处理流程,其实其框架涉及到了RFC4975和其扩展协议RFC4976 两个协议。MSRP部署环境包括了创建会话,创建MSRP会话和针对MSRP的结束拆线流程。笔者在接下来的章节中重点介绍MSRP的规范细节。
MSRP协议规范RFC4975和RFC4976
关于MSRP涉及了两个主要的规范协议,一个协议是RFC4975,另外一个是RFC4976的扩展协议。下面,笔者针对其协议为大家做一个详解说明。RFC4975 规范全称是The Message Session Relay Protocol (MSRP), 这里,我们翻译为消息会话转发协议,简称MSRP。
简单来说,MSRP协议是在会话内容中传输一系列相关的即时消息,对消息的传输类似于RTP的传输方式,对会话管理的方式类似于SIP协议中会话管理方式,仅支持TCP连接,SIP/SDP的协商机制用来支持终端之间的协商。以下图例是基于OPENSIPS的MSRP 富媒体实现框架。
![](http://www.ctiforum.com/uploadfile/2022/1008/20221008044036720.jpg)
如果我们从以上图例框架中抽象出来的话,以下图例就是一个基本的MSRP/SIP/IM会话的处理流程:
![](http://www.ctiforum.com/uploadfile/2022/1008/20221008044059170.png)
如果我们进一步分解其IM会话流程,我们可以看到通过SIP协议来创建的会话处理流程。
![](http://www.ctiforum.com/uploadfile/2022/1008/20221008044117762.png)
首先,UA 1 对UA 2发送一个INVITE请求,携带了和MSRP相关的请求消息,例如:
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的端口和协议
a=accept-types:text/plain
// 以下a行指示MSRP的URL,表示MSRP 消息发送到目的地URL
// jshA7weztas 表示会话ID
a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp
MSRP定义了两个请求methods, 一个是SEND 用来发送IM数据,另外一个是REPORT method,它用来发送报告上一个数据发送到状态,或发送数据的范围。具体的SEND请求执行细节如下,当UA 1 对UA 2通过SEND请求发送消息时:
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$
在学习关于MSRP协议时,我们需要注意价格比较关键的概念。首先一个是关于IM传输中的帧数据大小的问题。前面我们已经讨论过,在MSRP的传输过程中,数据是以数据块的方式来传输的。因此,如果需要几次传输数据的话,就需要设定一个framing的边界范围,避免数据接收后,重新聚合时数据的丢失。数据边界标识用来指示在数据发送时,是否仍然有后续数据待发送,数据发送是否结束。其标识符前缀七个破折号(-------)数据和数据标识,具体的数据标识如下:
+ 表示后续还有更多chunk 数据块
# 表示丢弃此消息
$ 表示这是最后的chunk数据块
另外,大家需要注意,message支持了MESSAGE ID,chunk 发送数量需要对应同一唯一的MESSAGE ID,例如,在以下的IM 发送过程中,最终发送的是:abcdEFGH, 但是通过两次发送。
// 同一会话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$ // $这里表示此数据已经是最后的chunk数据。
在MSRP协议中,REPORT method也是一个非常重要的method。它包括成功的report状态和失败的report状态。这两种状态用来表示数据发送的状态以及失败后的处理和响应码机制。以下是一个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 状态。
以下是一个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 // 状态码 408, 接收失败。
因为当前很多的网络组件需要加密,MSRP也可以通过m和a行的定义来实现加密,加密方式是在SDP的a行通过MSRPS来实现:
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 协议,在MSRP协议的应用中,大家可能会使用到另外一个RFC4975协议的扩展协议-RFC4976。此规范扩展了MSRP协议的一些其他概念,适用于转发中间节点的处理。MSRP是用来对消息在点对点的环境中进行传输的。但是,在实际生产环境中,消息传输可能经过多个中间节点,代理。通过转发扩展到使用,可以保证MSRP消息能够
可靠稳定和拥塞管理,最终实现传输的稳定性。RFC4976全称是:
Relay Extensions for the Message Session Relay Protocol。
它的主要目的包括:
- 传输任意二进制MIME数据,无需对解码修改
- 可继续支持终端对终端的操作支持
- 支持强制策略实现任意数量的转发操作
- 支持不同管理控制的转发
- 允许每个终端控制已转发的数据或者已转发了一半数据
- 防止垃圾消息,开放转发和Dos攻击
- 允许转发使用一个或者小数量的TCP或者TLS连接为多会话,接收方和发送方的承载支持。
- 支持在连接速度比较慢的环境中的大批量消息发送,不会引起阻塞。
- 支持在网络连接失败或者重新创建连接后的大数据量的信息传输,支持数据重传
- 提供在任何节点数据传输失败的提示
- 允许传输延迟
关于RFC4976更多细节,包括转发的路径,认证,定时器等相关细节,读者可以参考RFC4976的协议,这里不再赘述。
在实时通信环境中,WebRTC是目前比较热门的技术,WEBRTC的数据通道也可以实现对MSRP的数据传输(RFC8873),通过SDP的offer/answer来实现协商,支持TCP/TLS传输。但是,此规范的定义中没有关于类似于chunk的数据管理,会话管理机制,它仍然需要借助于RFC4975的处理规范。它可以实现聊天,文件转发。如果读者对基于WEBRTC的MSRP传输有兴趣的话,可以进一步阅读此规范。
总结
RFC 4975/4976 - Message Session Relay Protocol (MSRP) protocol 是富媒体服务的时代需要了解的主要协议。在本文章中,笔者主要讨论了关于即时消息IM传输的MSRP协议以及其扩展协议。首先介绍了富媒体服务的背景知识,然后说明了关于MSRP中数据传输的两种模式,page模式和会话模式。另外,笔者针对会话模式下的MSRP协议进行了深入讨论,包括传输流程,IM会话处理,关于支持会话管理,数据管理和扩展的处理。
具体来说,作者介绍了MSRP协议的语法,传输机制,和关于chunk 数据块处理,以及SEND和REPORT method来说明如何通过MSRP实现完整的数据传输。
另外,分享了关于RFC4976扩展协议的主要目的。扩展协议的目的是为了进一步保证MSRP转发的稳定性,连续性和拥塞环境下的数据管理,时延处理等控制机制。作者最后讨论了基于WEBRTC的数据通道传输MSRP的协议规范。
需要提醒读者的是,在实际应用环境中,特别是企业融合通信业务场景中,如何利用IMS网络环境下提供的IM服务,集成SBC支持,终端能力支持仍然是目前企业通信中需要进一步探讨的地方。也许,在不久的未来,我们可以看到这些IM服务在企业通信中更多的应用,更好地提升企业沟通的效率。
参考资料:
www.asterisk.org.cn
www.dinstar.cn
https://www.grandviewresearch.com/industry-analysis/rich-communication-services-market
https://www.alliedmarketresearch.com/rich-communication-services-market
https://www.gsma.com/futurenetworks/wp-content/uploads/2012/10/TIMRCSTrialAantonellaNapolitano.pdf
https://www.etsi.org/deliver/etsi_ts/102900_102999/102901/02.01.01_60/ts_102901v020101p.pdf
https://www.gsma.com/newsroom/wp-content/uploads//NG.114-v3.0.pdf
https://www.rfc-editor.org/rfc/rfc8873.html