移动内部疯传的11篇VoLTE学习笔记，看懂了你也是技术大神（三）

haha1990

作者：中国移动集团公司 张阳 （章末附作者介绍）

作者微信公众号：网优小谈（wireless_talk）

续《移动内部疯传的11篇VoLTE大作，看懂了你也是技术大神（二）》

9 承载传输协议初体验（TCP篇）

今年是北京邮电大学，这所中国信息科技产业的“黄埔军校”从建校之初至今不断引领祖国信息化变革的甲子之庆。这所坐落于北京海淀区学院路上，以信息科技为特色，工学门类为主体，管理学、文学、理学等多个学科门类协调发展的全国重点大学为我国培养了一代又一代优秀的信息以及高新科技人才。祖国的邮电事业从军工转民用，天南海北光缆的拉通，从古人只靠明月寄相思到实现千里共传音，有着他们那一辈以及我们这一辈几代人，万千人，太多艰辛的努力与无悔的付出，此篇文章旨在以最朴素的技术学习笔记方式，向北邮60岁诞祝贺，向邮电人致敬！让我们重温那些年轻的岁月，鲜活的面容。

TCP传输协议与VoLTE到底有什么关系？在VoLTE引入后，对于业务层面传输层协议进行了相应的甄选用以进行对话音业务的承载。目前主流就是TCP/UDP/RTP这些协议标准，一般TCP针对对于时延不太敏感的数据业务，而UDP/RTP这样的协议则更适合承载对时延比较敏感的话音业务。涉及到IMS的SIP/SDP协议，既可以由TCP协议来承载，也可以由UDP协议来承载。

TCP协议：

Transmission Control Protocol(TCP)早在80年代初期已经完整提出。最早的需要来源于军方对于计算机通信网络的稳定性以及可靠性，后来越来越多的被使用在了民用以及政府的计算机通信网络中。TCP协议是一种可信的，面向连接的，端到端的适用于分层架构设计的协议。其本身可以支持多种网络应用。理论上，TCP协议适合不同属性网络的互联通信，例如有线网络与分组网或者交换网之间，所以TCP的设计目标是可以在不同的因特网使得不同进程的通信得以保证，在不同的网络下的主机间的通信得以保证。

为了在网络环境中提供可靠，安全的连接服务，TCP协议需要能够实现如下功能特点

1、基本数据传输：TCP将字节数据进行分段传输，并却可以适时阻止以及继续传输数据，同时还要确保用户数据被完成传输；

2、可靠性：通过每个字节进行序号标识以及设置应答机制（ACK），TCP需要确保数据能够从损坏、丢失、复制以及乱序传输中恢复。如果超时后仍没有收到ACK，数据需要进行重传。在接收端，序号被用来修复乱序传输的片段以及重复传输副本。接收端进行校验，并且将损毁片段予以丢弃。这种机制理论上确保传输错误都能被及时修正；

3、流控：TCP提供了一种基于ACK应答方式的“窗口”指示，该窗口指示下一次接收端能够接收的数据大小，也就意味着发送端下一次可发送的字节大小；

4、复用：为了使单一主机提供多进程的TCP服务，TCP可以支持该主机一系列的地址或者端口号，将因特网通信层与网络和主机的地址级联就形成了socket，一对socket唯一标识了一个连接，这也意味着单一的socket可以同时被多个连接使用；对于经常使用的服务可以将某些socket通过固定端口的方式进行固化，而其他的一些进程的端口地址则可以通过动态机制建立获取；

5、连接：为了保持传输可靠性以及流控机制，TCP需要为每一个数据流建立以及维护一系列状态信息，这些信息包括socket，序列号，窗大小，这些信息的结合就叫做一个连接。一个连接被唯一的一对socket标识。当两个进程需要通信时，它们的TCP必须先各自通过初始化状态信息建议一个连接。当通信完成之后，连接被终止或者关闭一边释放资源给其他用户使用。由于连接由相互不可信的主机和相互不可靠的因特网通信系统建立，结合时钟序列号的握手机制被用来避免连接的错误建立。

6、优先级以及安全：TCP用户需要指明他们用户的安全级别和优先级。如果这些特性不被指明，那么使用默认设置。

对于数据传输，TCP协议提供了两种方法，一种通过push flag(推送标签)的方式设置push function(推送功能)，一种是传输紧急数据。当push function发送时，发端将所有未发送数据全部发送，而接收端一旦收到push flag，则不再继续等待从发端来的数据，而将现有数据传递至接收进程。推送进程以及推送标签的目的就是将发端数据推送至接收端，它并不提供记录服务。TCP的另外一种传输数据的方法是发送紧急数据，虽然TCP协议对于接收端收到紧急数据做何处理没有严格定义，但一般接收进程都会对于紧急扎数据进行快速处理。

TCP协议有几个鲜明的特点，例如控制承载不分离，三次握手协议，建立同步等等。TCP协议通过一些控制字段进行同步与响应，例如在连接建立或者初始化过程中，两个TCP必须与彼此的初始序列号同步，主要通过交换控制比特“SYN”以及初始序列号来实现。所谓的三次握手本质是四次，只不过接收端可将ACK消息以及初始化的SYN捆绑一起发送，这样双方在数据传输前就进行了同步。同时，由于TCP协议并不与时钟进行同步，因此三次握手保障机制也通过“接收端请求发送端校验第一次发送的SYN”的方式确保了TCP双方的同步。另外,TCP协议通过设置MSL（Maximum Segment Lifetime）与2^32个循环序列号的方式（采样频率恒定）确保序列传输中的唯一性。例如在第一次传送数据后等待响应的阶段，下一次发送数据的序列号都是以增量的方式进行发送，直到收到响应。

TCP协议一般与IP协议捆绑使用，也是目前互联网中最为重要的协议族之一。TCP协议是OSI架构中传输层的协议，而IP协议是OSI架构中网络层的协议，相对于电信网络中控制与承载分离的协议设计架构（控制面，用户面），TCP/IP协议并不将控制面与数据业务面进行逻辑分离，相反通过一些包头（header）的方式封装控制字段。在移动互联网中（从网络架构角度可以认为就是电信基础网络承载互联网），TCP/IP被用作用户面的协议，电信AS/NAS协议栈打通了电信控制面的路由，而具体对于数据业务传输过程中的控制，则由TCP/IP，或者UDP，RTP等其他协议进行参与。TCP协议与IP协议像一对优势互补的“合作伙伴”，IP协议提供了点到点的服务（就如同投递员投递信件一样，投到准确的每家每户，因此门牌号也就是IP地址需要唯一的标识），但是IP协议也具有其局限性，即其不可靠性，不能确保IP数据报成功地到达目的地（这就好比投递员不负责用户是否能够成功接收到邮件，只负责投递）。同时，还具有无连接的缺点，即数据报的的接收不按照次序。这些局限性IP层不负责解决，而是由其上层TCP进行解决，因此可以说TCP提供了流程上的保障，提供了所谓端到端的服务，二者结合一起的协议簇，对于数据传递的准确性提供了保障，但是相应的开销就是时延。

TCP协议中通过一些基本特性对数据包传输的准确性以及及时性进行保证：

确认和超时：TCP使用确认（ACK）机制以及超时重传机制来确保每一个分片的成功传送。这里有点像LTE在做初始RRC连接时发送随机接入的msg1（Random access request），如果在一定时间间隔内（这里是由backoff指定的一个随机变量）没有收到msg2(random access response,RAR)，那么会继续发送msg1,直到达到最大发送次数。而TCP协议这里却没有最大发送次数的限制，也就意味着一旦网络中出现问题，发端TCP会不断的进行重传。因此将超时重传间隔设置很小，可以导致对服务器的信令冲击。由于在数据传送过程中可能经历不同的网络，因此重传超时需要动态的设置。需要注意的是，RTO的设置（retransmission timeout）至少应该大于RTT（Round Trip Time）。值得一提的是，在TCP与上层协议的控制信息交互中，对于不同的上层用户控制命令中带的timeout的参数的值，作用意义也都有不同，而且在TCP的不同状态中会随之相应更新。例如在OPEN指令中如果携带timeout，意味着如果在该timeout之内的发端没有将数据全部成功发送到收端，那么TCP就会终止该连接，该值默认为5分钟；在SEND指令中如果携带timeout，那么当前的timeout就被替换更新了。一般来说timeout有三种，用户超时(user timeout)，重传超时(retransmission timeout)和时间等待超时(time-waittimeout，该值用于CLOSING流程，设置值为2MSL，MSL即最大片段生命周期，rfc793协议规定为经验值2分钟)，除了重传超时的处理不同外，用户超时和时间等待超时后，上层对于TCP的处理是一样的，即删除已建立的TCP，进入CLOSED状态，并反馈上层。

窗口：这里的窗口有三种，发送窗(sendwindow)，接收窗(receive window)，片段窗(segment window)。

发送窗：表示着远端TCP能够接收的数据序列号的大小。一般通过数据接收过程从远端TCP收到的指示。发送窗其实是本地和远端TCP相交互的信息，通过分片窗口大小进行本地更新。当发送窗设置为0时，本地发端TCP也应至少发送一个字节的新数据，并且发端TCP应该周期性的重发至收端TCP，一般周期间隔推荐为2分钟，这样的好处是无论任一端TCP窗口为0，当重新打开窗口（大于0）的时候，能够可靠的将该设置通知另一端。

接收窗：表示本地（收端）TCP可以接收的序列号。如果收到的分片序号等同于在窗内的序号，本地TCP认为收到正确数据或者控制消息，否则，则认为是重传序列予以丢弃。当接收窗口为0的时候，除了ACK分片外，其他的数据分片都不被接收。因此，对于TCP可以存在0接收窗口的情况，这样其可以发送数据的同时只接受ACK。另外，即使接收窗为0，收端TCP还是可以对任意的分片中所含RST和URG字段进行处理。

分片窗口：分片窗口是传送分片中的一个域，通过该域的值来传递远端TCP的接收窗口以供给本地发端TCP窗口进行相应更新。

面向连接（同步）：TCP是一种面向连接的协议，这也同时确保通信双方的通信和数据传输是一种同步双工机制。连接由用户OPEN指令调用建立，同时TCP提供用户建立连接的名字以供用户后续引用。OPEN调用指出了该连接是主动建立的或者被动等待建立。主动建立是高层通过active OPEN指令触发，而被动连接则是通过收到分片中所携带SYN字段，并通过后续的握手机制来建立。被动OPEN(passive OPEN)要求意味着进程可以接受来访建立请求，一般passive OPEN意味着可以接受任意的远端连接建立请求。在这种情况下，全“0”配置的外部socket表征未明确的socket，这种未明确的socket设置只允许应用在passive OPEN。窗口的设计需要进行平衡，指示较大窗口鼓励更多的数据传输，一旦超过其接收能力，会导致重传从而网络以及TCP的负荷。指示较小的窗口则会对数据进行过多的分片，由于过多的握手机制导致传输时延的增加。

状态转换：TCP含有多种状态，例如LISTEN,SYN-SENT,SYN-RECEIVED,ESTABLIASHED,FIN-WAIT-2,FIN-WAIT-2,CLOSE-WAIT,CLOSING,LAST-ACK，TIME-WAIT,CLOSED，这些状态之间的转换通过用户调用的事件（OPEN,SEND,RECEIVE,CLOSE,ABORT,STATUS），接收到携带标志位(SYN,ACK,RST,FIN)的分片和超时进行相互转化，详见RFC 793。

与上层协议接口的异步机制：TCP与上层进程通信可以采用异步机制，当TCP通知上层用户时，确定的信息就传递到用户。这些信息主要是报错机制或者进程事件完成标志（例如SEND或者RECEIVE）。

PUSH Flag与Urgent Flag：PUSHFlag与Urgent Flag的作用相似，是分片携带中的一个标识字段，如果收端读取到该字段，则无需等待是否到达了buffer的边界，而将buffer里面存在的数据同时上传。如果发端触发了PUSH Function，则立即将发端buffer里面未发送的数据立即发出。Urgent Flag是通过分片中的Urgent Pointer来传递信息的，通知收端在Urgent Pointer之前的数据还没有完全接收，收端的Urgent Flag（on）通知收端上层进程进入紧急模式（Urgent Mode），意味着额外的紧急数据等待接收，如果Urgent Flag置为off，则向上层返回当前所有紧急数据，至于后续连续序号的非紧急数据则不会在同一个buffer中被传递给上层进程（除非buffer中明确划分了边界）。PUSH Flag与Urgent Flag是TCP中对于向上层推送数据的一种特殊处理方式，即确定了那些数据无需等待，可以优先推送给用户，PUSH Flag对于分片中的数据进行了标识推送，而Urgent Flag则对可能跨分片的数据进行标识推送。

TCP的crash保护机制:对于TCP本地进程的崩溃(crash)，一般TCP不提供记忆机制，即本地TCP并不记得之前发送过什么，以及发送序号是什么，而是通过一种“半开启连接发现”机制来进行本地crash之后的进程回复，其实与远端的信息交互触发本地的RESET机制，从而使得本地与远端进行重新同步，详见RFC 793。

梦绕神州路，怅秋风，连营画角，故宫离黍。

底事昆仑倾砥柱，九地黄流乱注？聚万落千村狐兔。

天意从来高难问，况人情易老悲难诉。

更南浦，送君去。

凉生柳岸催残暑，耿斜河，疏星淡月，断云微度。

万里江山知何处，回首对床夜语。雁不到，书成谁与？

目尽青天怀今古，肯儿曹恩怨相尔汝！

君且去，休回顾。

10 承载传输协议初体验（UDP篇）

机械师是笔者比较喜欢的一部影片，风格冷峻、镜头犀利，主要是主人公的演绎，艺高胆大，处理问题冷静，个性极其鲜明，好像“专业”内没有什么难事。这篇UDP协议解读就好像主人公所面对的一个简单的“任务”一样，相比其他协议流程，要简单的多。不过还是先让我们重温一下影片中经典的桥段吧。

相比TCP协议，UDP的协议要简单的多，UDP协议默认下层网络层协议为IP协议，因此一般UDP/IP是协议栈的形式出现的。相比TCP协议面向连接，UDP协议是面对交互流程的，由于没有类似TCP等ACK反馈机制，因此数据报传递的准确性难以得到保障。

用户数据报表头结构(UserDatagram Header Format)

源端口（Source Port）是一个可选配置，指明了发端端口，如果该域不使用，则置为0。

目标端口(Destination Port)指明了网络目标地址的端口。

长度（Length）指明了UDP报文封装中数据包+包头的最长度，单位为字节（octet），这意味着该值最小设置为8字节，包含源端口，目标端口，长度以及校验和。

UDP提供16bit校验和，校验机制的流程与TCP协议一致。

UDP协议与上层的用户接口设计需要能够创建接收端口，能够将收到的数据字节以及发端端口地址予以反馈并且能够允许数据报以正确的格式发送（如上图结构）发送。

与IP层协议的设计可以采取紧耦合的方式，及接口层将全部的数据报上传（不仅包含UDP的包头也包含IP的包头），有利于接收流程的响应。

UDP协议主要用于INS（Internet Name Server）以及TFTP（Trivial File Transfer Protocol），因此该传输层协议适合一些对时延较敏感的小文件传输协议，相比TCP协议传输的可靠性较差。

11 承载传输协议初体验（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编码。