VoLTE学习笔记杂谈(12)-承载传输协议初体验（RTP&RTCP篇）
RTP协议作为一种实时传输协议，主要提供类似音频和视频这样的端到端的实时数据业务。RTP虽然和UDP同属于传输层协议，而一般典型的上层应用依靠二者协同提供传输协议的功能，例如处于RTP之下的UDP协议可以提供复用和校验和功能，以对接收分片进行整合和丢弃。RTP协议本身不保障数据包的及时传递以及相应的QOS，而是依赖于底层服务去处理这些。RTP协议也不保证传递，不纠正乱序传递，同时也不确信底层保证的可靠性。RTP按顺序传递数据包（UDP协议里面是没有序号的），RTP协议依据数据包序号可在收端重建发端数据包的序号，而且RTP协议也可以利用序号来确定数据包的合适位置。
相对TCP/UDP协议的通用性，RTP是一种新型的协议，RTP与上层应用结合的更紧密，所以设计之初并不单纯将RTP当作独立一层来看待。另外RTP协议更倾向于依据不同的上层应用需求对包头进行相应的修改以及增补来适应。
RTP协议的架构与应用相关，这里分别描述下各自的特点：
简单多播音频会议业务，RTP与RTCP（RTP控制协议，主要用于监测QOS质量以及传递参与会议用户信息）对于每一用户参与者而言都是分别在两个端口上传递包的，一个端口用来传递接收音频数据包，另一个端口用来传递接收RTCP控制包。参与音频会议的终端是以20ms间隔发送小音频数据包，而每个数据包前都被前缀了RTP包头，RTP的包头和数据以交替的方式承载在UDP包上。RTP包头主要指明了音频数据编码方式（PCM，ADPCM或者LPC），这样对于连接带宽情况或者应对于网络的拥塞，参与音频会话方可以自适应的调节音频编码方式以有利于通话质量。RTP包头还包含了定时信息以及序列号，通过这些信息的传递，接收端能够恢复出发送端的定时信息以及评估多少包在传输过程中丢失了。会议通话中，总有些参与方陆续加入或者离开会话，RTCP控制端口就将这些用户标识信息以及用户接收的情况进行传递，同时对自适应编码进行控制。
音频和视频会议，音频和视频媒体独立承载在不同的RTP会话上，这意味着独立的RTP和RTCP包（音频与视频媒体独立）在不同的UDP端口上和或者不同地址上传输。除了有些特殊情况，例如音频与视频统一的名称外，RTP层面，音频和视频媒体无法直接进行耦合。这样的好处显而易见，有些用户需要播放视频，有些播放音频，这样独立处理更简单。这里，RTCP携带了时间戳信息，这样可以在收端将音频以及视频进行同步回放。
混合器（Mixer）和翻译器（Translater）技术，混合器的作用是将一些低速率的小包混合成同一媒体流，或者将编码后的媒体流分发为多股小速率媒体流。这样，处于不同带宽网络下的会话无需适配低带宽，低质量的通话。翻译器技术与混合器技术略有不同，它是将非IP的一些包转化为IP包（例如对于某些应用的防火墙），因此一般需要两个翻译器，防火墙外一个翻译器将多播的包汇聚通过安全的通道传到防火墙内的翻译器，而内部翻译器则将多播包分发出去。RTP包头里面包含的混合信源标识可以传递给接收端。混合器与翻译器技术的应用很广。
分层编码技术，将不同带宽的RTP传输通过编码的协商进行适配，这样处于会话的双方依据自身所处网络环境进行相应的编码自适应，使得各方的通话质量“因地制宜”的达到最优。但是对于多播系统的异构接收端，这样动态自适应效果往往不好，这样导致最终多播用户之间的通话只好采取“最小公分母”原则，即适配最小的通话管道的质量以及音质保真，这显然不是最佳策略。分层编码技术采取发端与收端协同配合原则，即发端根据多播环境进行标识分组，收端可以自适应网络的异构情况，并相应将带宽调整匹配至相应的多播组里，这样可以做到高带宽的在一组，低带宽的一组，避免相互的串扰影响。
RTP包头结构
上图说明例如RTP的包头结构，其中前12字节在任何RTP的包头中均出现，详细的字段定义可以参考RFC 3550。这里较值得一提的是8-11字节（共32bit）的SSRC标识，SSRC是个同步源标识。为了在同一个RTP会话中任意俩个同步源都被区分开，这个标识符按照某种规则随机生成，如果同步源改变了源传输地址，那么需要选择新的SSRC标识。设计RTP协议架构应该大致遵循以下的原则：
1、 音频与视频媒体不应被复用在同一个RTP会话中，即使针对不同媒体使用不同SSRC标识，但承载在同一个RTP会话中也是不妥的；
2、 针对多播会话，在同一个RTP会话中，通过使用不同的SSRC标识值，将同一媒体的不同源进行复用则恰恰是标准规范
RTCP协议可以看作RTP的控制协议，同样可以认为是RTP协议的补充，RTCP协议通过和数据包同样的分发机制，周期性的传递控制包。下层协议UDP通过不同端口的方式实现了RTP数据包和RTCP控制包的复用。总体来说RTCP实现了如下四个功能：
1、 最主要的功能提供了数据分发质量的反馈。这些反馈可以被直接用来控制自适应编码的调整，但是实际情况却是对过接收端的反馈来定位数据分发中的错误原因却不是那么理想。发送接收反馈到所有会话参与者可以帮助评估问题属于局部问题还是全局问题。另外对于类似IP多播的分发机制，可以使得非会话参与方的第三方进行监控并定位网络问题。RTCP的发送端以及接收端都应具备反馈机制；
2、 RTCP针对一个RTP源头携带了永久的传输层标识，称作canonical name(标准名称)或者CNAME。由于SSRC标识可以能由于随机冲突或者程序重启导致变动，接收端需要通过CNAME追踪每个会话参与者。接收端可以通过CNAME将给定会话参与者的一些里RTP会话，例如音频或者视频多媒体数据流进行同步。多媒体数据流之间的同步也同时需要数据发端发出的RTCP控制包中协议带NTP和RTP时间戳；
3、 前两个功能需要所有会话参与者发送RTCP包，因此速率需要根据会话参与者的数量合理控制。通过每个会话参与者发送控制包至所有会话参与方，每一个会话参与者都能够独立评估会话参与者的数量，这些数量可以被用来进行计算包的发送速率；
4、 除了以上必须的功能实现，还有一个可选的功能需求是传递最小的会话控制信息，例如将参与者的标识信息展示在用户界面。这个对于类似参与者进入和离开会话不需要会员控制或者参数协商的“宽松控制”的会话来讲是比较有用的。RTCP可以作为一种连接各个参与者的便捷通道，但是并不是必须支持一个上层应用的所有通信控制需求。这些通信控制需求可以由更高层的会话控制协议来实现。
对于RTCP协议包的传送方式设计是比较复杂的，这是由于在会话过程中，尤其针对多方会议中，RTP的包传送是天生被抑制的，即大家不会同时讲话，因此，同时参与会话的人相对较少，但是RTCP不一样，这是对通话质量统计的控制包，有可能随着人数的增加大量传送，即使会话参与方处于静默期，这样有可能将有限的通话带宽迅速淹没掉，因此RTCP的包采用周期间隔的方式进行传送，在通话环境不变的时候周期恒定，如果会话环境发生了改变，例如，有新用户加入，或者老用户离开，那么相应的周期就按照一定的规则进行灵活的适配，主要目的就是为了控制RTCP包占用较小的通话带宽，一般推荐RTCP占用会话带宽为5%。
RTP接收端通过RTCP包提供接收质量反馈。RTCP有两种包的格式，一种是发送报告（SR）格式，另外一种是接收报告（RR）格式。除了包类型码，二者包格式的唯一区别就是发端报告包含一个20字节的发端信息。当上一次报告发送出后的周期间隔内，接收端发送了任何数据包，那么下一次的RTCP格式就是SR格式，反之，则是RR格式。不管SR或者RR格式都要包含0或者多个接收块，每一个接收块都是对于上一次报告之后接收到数据包的同步源。报告并不针对mixer建立的CSRC列表中的贡献源进行反馈。每一个接收报告块同时提供了该接收块中指示的同步源来的数据接收情况统计。由于SR或者RR包只能容纳最多31个接收报告块，因此多余的RR包需要“堆砌“在初始SR包或者RR包之后。如果这些包含必要RR包的合成包达到超过了网络路径最大传输单元的程度，那么该复用包被分割成多个子集的方式在多个传输周期中被全部发送。
为什么RTCP协议SR包格式需要分别包括发端信息和接收报告块格式呢？
接收端的质量反馈不仅对于发端有用，同时对于其他的接收端和第三方的监测同样有用。发端可以通过接收到的质量反馈进行传输的调整（例如编码），其他接收端可以通过反馈来确定出现的问题属于本地，局部或者是全局。而网络管理者可以通过接收到的RTCP包独立监控多播分发的网络性能。对于发端信息和接收报告块的持续计数可以使得二者的差异用来分别进行长期和短期的测量，同时相互弥补了报告丢失损失。最近两次报告的差异可以用来评估最近的质量分布。两次报告的携带的NTP时间戳可以用来计算计数差异的速率。由于时间戳独立于数据加密，因此实现独立于加密和应用的第三方监控是可行的。另外，连续收到的两次报告之间关于丢包统计的计算可以用来计算两次间隔之间的丢包率。对于发端信息，第三方监测可以直接计算平均载荷数据速率和平均包速率而不需要实际接收数据。二者之间比例可以用来计算平均载荷大小。如果假定包的丢失独立于包大小，那么对于特定接收端可以通过接收到的包的数量乘以平均载荷大小或者包大小计算接收吞吐率。除了丢包率之外的统计，到达jitter的计算也可以用来评估短期的网络拥塞情况，相比包丢失的的统计表征网络的长期拥塞状况，jitter表征了瞬时的网络拥塞。Jitter的评估一般属于“预见式”的，由此指示的网络拥塞会带来后续的丢包。但是也不可否认，jitter只是报告对网络拥塞表征的一种快照，是定性的评估，而一般不用做定量的评估。
现网RTP协议举例
以下的RTP属于主叫流程中的28或者30阶段，属于初始的语音包的传递。
蓝色框标注的Payload type：AMR-WR（104）意味着该语音的编码方式是通过某种会议控制协议进行动态调整的。
红色框标注了该终端需要连续接收的包的编码格式，CMR=15意味着该终端没有任何选择偏好，既可以接受AMR编码也可以接受AMR-WB编码。
未完待续，不定期更新～
张阳，英国布鲁内尔大学（Brunel Univ.）设计与工程学院电子与计算机工程博士，高级工程师，博士阶段主要进行LTE物理层、处理优化算法研究。主要从事TD-LTE/TD-SCDMA网络优化工作。曾参加中国移动无线网络优化技术高级培训，荣获优秀学员称号，参加中国移动LTE维护优化技能竞赛，荣获一等奖。长期关注跟踪一线实际优化工作，具有丰富的理论基础及实践经验。在国内外通信期刊发表学术论文数十篇，并合著有《TD-LTE无线网络优化与应用》一书。