SIP协议的学习及使用

它是SIP信令路径上的中间节点，负责接收请求、执行路由决策并将其转发至下一跳。根据是否修改Route头域，可分为无状态代理和有状态代理；根据路由决策的不同，又可以分为严格路由（若Route头域不存在或首个URI非本代理，则视为严格路由模式）和松散路由（当请求携带Route头域且第一个Route URI指向本代理时，代理将其移除并将请求发往Request-URI指定的目标）

②注册服务器

注册服务器负责接收用户的REGISTER请求，验证身份后将当前联系地址（Contact）与记录地址AOR（Address of Record）进行绑定，并存储于位置数据库中。这个过程实现了SIP的“用户可达性”机制。

关于AOR和Contact的关系可以类比为域名和IP地址的关系。AOR就像一个永久的邮箱地址（sip:alice@example.com），而Contact是这个人当前使用的具体设备地址（sip:alice@192.168.1.100:5060）

③重定向服务器

它不转发请求，向客户端返回3xx响应系列，告知其应尝试新的地址。

（3）SIP事务

一个SIP事务是在客户端和服务端的事件，包括了从第一个由客户端发送到服务端的请求，到最后一个（非1xx）服务端向客户端发出得终结应答。如果请求是一个INVITE请求，并且终结应答是一个非2xx的应答，那么事务还包括一个ACK给服务器做应答。给INVITE请求的2xx应答的ACK回应，是一个独立的事务。

下面四张图片是SIP协议中事务处理的核心状态机模型。它们清晰地展示了SIP设备在处理不同请求时，其内部事务组件的状态流转逻辑。

TU：事务用户

ICT - 邀请方客户端事务：存在于发起会话邀请的一方（主叫方）的UAC中，负责生成和发送INVITE请求，并处理来自对方的响应（如180 Ringing, 200 OK）。

NICT - 非邀请方客户端事务：存在于发送非INVITE请求的一方的UAC中，常见的非INVITE请求包括：ACK, BYE, CANCEL, OPTIONS等，负责生成和发送这些请求，并处理响应。它与INVITE事务的主要区别在于它没有"三次握手"，处理更简单。

IST - 邀请方服务器事务：存在于被邀请方（被叫方）的UAS中，负责接收和处理INVITE请求，并生成对该请求的响应。这张图描述了一个UA（作为被叫方）接收并处理INVITE请求时，其服务器事务的状态流转。

NIST - 非邀请方服务器事务：存在于接收非INVITE请求的一方的UAS中，负责接收和处理这些非INVITE请求，并生成响应。这张图描述了处理非INVITE请求的服务器端状态机。

3.请求与响应消息结构体

SIP消息遵循类HTTP的明文文本编码风格，采用ASCII字符集进行传输。每一个SIP交互都由请求或响应消息组成，他们共同构成了完整的信令对话流程。（它的基本语法遵循RFC 3261定义的ABNF规则）所有的SIP消息均可以分为两大类：请求消息和响应消息，他们都是由三个主要部分组成：起始行（Start Line）、消息头域（Header Fields）和消息体（Message Body），中间由回车换行分隔。

（1）起始行的两种类型

是每个SIP消息的第一行，用于标识该消息的基本性质，根据消息类型的不同，起始行分为“请求行”和“状态行”。

①请求行出现在请求消息中，格式如下：

Method SP Request-URI SP SIP-Version CRLF

Method:表示请求的操作类型，如INVITE,REGISTER等

Request-URI:指示目标用户的地址，通常为SIP URI格式（sip:user@domain）

SIP-Version：当前固定为SIP/2.0 代表使用的版本协议

比如：text INVITE sip:bot@192.168.1.100 SIP/2.0

②状态行出现在响应消息中，格式如下：

SIP-Version SP Status-Code SP Reason-Phrase CRLF

Status-Code:三位数字的状态码，反映请求处理结果

Reason-Phrase：对状态码的可读描述，用作参考

比如：text SIP/2.0 200 OK

（2）方法详解

实际应用中常见的包括：INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER。这些方法构成了SIP会话控制的核心指令集。

①INVITE用于发起一个多媒体会话。当主叫方与被叫方建立通话时，发送INVITE请求，并携带SDP消息体描述自身支持的媒体能力（如音频编码、端口）

②ACK用于确认对最终响应的接收，用于确保传输时的可靠性。对于INVITE事务，ACK必须单独发送，即使没有新的消息体。

③BYE用于正常终止已建立的对话，任何一方均可发起，接收方应回复200 OK表示接受释放。

该请求无需携带SDP，一旦确认，双方应立即停止媒体流传输并释放相关资源。

④CANCEL用于取消尚未完成的请求(通常是未收到2xx响应的INVITE)。他不能取消已成功的会话，仅影响正在进行中的呼叫尝试。

只能取消同一事务内的请求。代理服务器收到CANCEL后应立即停止转发INVITE，并向下游传播CANCEL

⑤OPTIONS类似HTTP的探测机制，用于查询对方的能力信息（如支持的方法、编解码器等），常用于心跳检测或预检路由可达性。

响应中的Allow头域返回支持的方法列表

⑥REGISTER用于用户向注册服务器声明其当前位置（Contact地址），以便其他用户可通过统一标识找到该终端。

注册服务器验证身份后，将Contact信息存入位置数据库，供后续INVITE查找使用。

（3）状态码

状态码范围	类别名称	含义
100-199	临时响应	请求已接受，正在处理中
200-299	成功响应	请求成功执行
300-399	重定向	目标有多个位置，需进一步选择
400-499	客户端错误	请求存在语法错误，或权限不足
500-599	服务器错误	服务器无法完成请求
600-699	全局失败	请求在全网范围内失败，不应重试

1XX:

100 Trying ：表示代理服务器已收到请求并开始处理，防止超时重传。

180 Ringing ：被叫方正在振铃，通知主叫等待接听。

2XX：

200 OK是最常见的成功码，用于注册、会话建立等场景

3XX：

302 Moved Temporarily ：返回一个新的Contact地址，客户端应自动重试。

4XX：

400 Bad Request ：消息语法错误，无法解析；

401 Unauthorized ：缺少认证信息，需附带WWW-Authenticate头域；

404 Not Found ：目标用户不存在于当前域；

407 Proxy Authentication Required ：需通过代理认证；

5XX:
500 Server Internal Error ：通用服务器异常；

503 Service Unavailable ：服务暂时不可用，常因过载或维护。

6XX:
603 Decline ：被叫明确拒绝接听；

604 Does Not Exist Anywhere ：用户彻底不存在。

（4）消息头域的分类与作用

SIP头域是消息控制的核心，承担路由、事务管理、安全认证等多种功能，分为三类：通用头域、请求专用头域、响应专用头域。

①通用头域：Via、Max-Forwards、Call-ID、CSeq的传输控制功能

头域	作用说明
Via	记录消息路径，确保响应沿原路返回
Max-Forwards	控制最大跳数，防环（每经过一跳减1，防止无限转发）
Call-ID	唯一标识一次会话，由客户端生成
CSeq	命令序列，格式为“序号方法”，用于排序和去重

②请求/响应专用头域：From、To、Contact、Record-Route的路径管理意义

头域	用途说明
From	发起方身份，含tag用于区分不同对话
To	目标方身份，初始无tag，响应中补全
Contact	实际联系地址，用于直接通信
Record-Route	插入路径记录，使后续请求必须经过该节点

（5）消息体封装原则（SIP中，SDP部分就是消息体）

SIP本身不处理媒体，通过消息体携带会话描述（如SDP）来协商媒体参数，它在SIP消息中的嵌入方式：Content-Type与Content-Length头域配合使用

比如：Content-Type: application/sdp （这个头部明确表示消息体是 SDP 格式）

Content-Length: 167

Content-Type 指明内容格式， Content-Length 确保接收方正确截取数据。

SIP头部和SDP消息体之间有一个空行

它的结构：（以v=0开始的多行文本）

v=0 ← 协议版本

o=用户名会话ID 版本网络类型地址类型地址

s=会话名称

c=连接信息

t=时间信息

m=媒体信息

a=属性

二.SIP服务环境配置

需要让两个客户端配置为同一SIP服务域下的两个不同分机，

Linphone是分机 19999

Kapanga是分机 19998

注册过程：

客户端告诉服务器：我是sip:XXX，我现在在XXX这个网络位置

呼叫流程：

如果Kapanga（19998）呼叫Linphone（19999）时：

Kapanga向SIP服务器发送请求：“我想呼叫XXX”

服务器查询数据库，发现19999的当前联系地址是Linphone所在的IP

服务器将呼叫请求转发给Linphone

1.Linphone

SIP地址就是SIP身份标识，格式为sip:用户名@域名。19999是分机号

SIP服务器地址（SIP注册服务器的实际位置），Linphone向这个地址发送注册和呼叫请求，指定了服务器的IP、端口和传输协议

登记期限，每隔100秒，Linphone会向服务器报告还在线，以保持注册状态。

交通工具，信令传输协议，这里的tcp与服务器中的transport=tcp对应

路线，信令发送路径，通常与SIP服务器地址相同，表示所有信令都通过这个地址路由

注册开关，开启，Linphone才会向SIP服务器进行注册

2.Kapnga

在SIP参数设置里，username需要填写自己的分机号

在代理配置里，需要与Linphone的配置相对应。

Domain/Realm，SIP服务域，与SIP地址中@后面部分一致

SIP Proxy，SIP代理服务器，指向SIP服务器地址

Authorization User，认证用户名，就是分机号，用于向服务器证明身份，需要与上图中的Username一致

Password，认证密码

三.抓包分析

1.基本概念

(1)SDP和RTP的概念

SDP是会话描述协议，用于描述多媒体会话的参数，而不是传输媒体流。它在消息的正文部分出现，使用Content-Type:application/sdp标识。

RTP是实时传输协议，用于实际传输媒体流数据。运行在UDP之上，提供低延迟传输，但不保证可靠性。他的数据包格式是在媒体数据前添加RTP头部，包含序列号、时间戳等信息。

（2）dialog（对话）、transaction（事务）

①事务：由一个SIP请求和它触发的所有临时响应和最终响应组成。他的标识是via头域中的branch参数。

②对话：它代表了两个用户之间的一个持续性的信令对等关系，从一个初始请求的成功响应开始，到一个终止请求成功结束。他的标识是由Call-ID、From tag、To tag组成

2.REGISTER

下图为一次注册过程，先register，然后401需要认证，接着再register,最后回复200O,标识注册成功

①

首先是请求行：操作类型目标用户的地址使用的版本

Method:一个注册请求

Request-URI：注册服务器地址

Resent Packet: false = 这是首次发送的原始数据包（Resent Packet: true = 这是因超时或丢包而重传的数据包）

Via：消息路径，确保响应可以沿原路返回；branch是事务的唯一标识

From：发起方身份,tag对话标识符之一

To:目标方身份，初始无tag，响应中补全

Contact:实际联系地址，用于直接联系客户端

Call-ID:对话标识符之一

User-Agent:客户端软件信息（目前的状态是，未注册）

Supported：支持的扩展（会话定时刷新，替换对话）

CSeq:命令序列，序列号通常从1开始，同一个对话中的序列号是单调递增的

Max-Forwards：最大转发跳数，每经过一跳减1

Event：事件类型

Allow-Events：支持的事件通知类型

Expires:注册有效期

Allow：支持的所有SIP方法

Content-Length:消息体长度

后续相同的字段不再说明

②

服务器发给客户端的响应

状态行表示这是响应消息：401未授权错误。使用的协议版本状态码对状态码的描述

To：增加了tag,可以标识对话中的服务器端

WWW-Authenticate:认证挑战，要求需要什么认证

Server：服务器软件

③

是第二次尝试的认证请求

包含Authorization头：带有认证信息

CSeq：序列号为2表示是第二次尝试

用户状态仍未尚未注册成功

④

服务器对客户端的成功响应

状态码为200 代表操作成功

在整个对话中，Call-ID、From tag、To tag是不变的,所以他们是一个对话的标识符。

后续会有注册刷新，客户端定期向SIP服务器重新注册，用来保持在线状态的可达性。类似于心跳。如下图所示：

3.INVITE、BYE

这是一次完整的SIP语音通话过程

①呼叫建立阶段：向19999发起呼叫，主叫方发送INVITE请求给服务器，第二次INVITE是服务器转发给被叫方。接着有三次100 Trying，第一次是服务器告诉主叫方“我收到了你的INVITE”，第二次是被叫方告诉服务器“我收到了你的INVITE”，第三次是服务器转发被叫方的确认给主叫方。

②振铃阶段：第一次Ringing是被叫方开始振铃，第二次Ringing是服务器转发给主叫方

③接通通话：被叫方回复服务器的INVITE请求，接听200 OK；第二次200 OK是服务器转发给主叫方。主叫方收到之后，回复ACK确认给服务器；第二次ACK确认服务器转发给被叫方。

④通话进行：约3分钟

⑤结束通话：被叫方结束通话，发送BYE给服务器；第二次BYE服务器转发给主叫方。主叫方收到之后，向服务器回复BYE请求，回复确认挂断200 OK；第二次服务器把200 OK转发给被叫方。整个流程结束。

在SIP中，也有三次握手，分别是INVITE（主叫方“我想和你通话”）、200 OK（被叫方“我同意通话”）、ACK（主叫方“好的，开始通话”），保证了会话的可靠性。除了INVITE请求，其他的都不需要ACK确认。

对包的分析：

①

Content-Length:消息体的长度（字节数）

其中的消息体内容：

会话层信息：

V：协议版本

O:用户名会话ID 会话版本号网络类型 IP地址类型地址

S:会话名称

C:连接信息（指明了媒体流应该发送到的目标网络和IP地址）

t：时间信息

媒体层信息：

m:媒体信息（音频接收RTP数据包的本地端口号协议支持的音频编解码器列表）

后面的a都是媒体属性，是对媒体信息的详细说明

Media Attribute (a): rtpmap:0 PCMU/8000

含义：定义RTP负载类型0对应的是 G.711 μ-law 编解码器，采样率是8000Hz。这是一种高音质、高带宽的编码。

Media Attribute (a): rtpmap:8 PCMA/8000

含义：定义RTP负载类型8对应的是 G.711 A-law 编解码器，采样率是8000Hz。这也是高音质编码，与PCMU类似，但压缩律不同。

Media Attribute (a): rtpmap:101 telephone-event/8000

含义：定义RTP负载类型101对应的是电话事件（DTMF音）。用于在RTP流中传输像按键音（0-9, *, #）这样的事件，而不是通过音频编码传输，这样更精确、更节省带宽。

Media Attribute (a): ftmp:101 0-15,36

含义：这是对101（电话事件）的格式参数说明。它定义了支持哪些事件类型，这里的 0-15,36表示支持0到15号事件（基本DTMF键和一些扩展）以及36号事件（通常是CNG舒适噪音）。

Media Attribute (a): sendrecv

含义：媒体流的方向是双向的（既发送也接收）。这是正常电话通话的模式。

Media Attribute (a): rtcp:5113

含义： RTCP（RTP控制协议）使用的端口号是5113。端口号通常是RTP端口号+1。

Media Attribute (a): ptime:20

含义：打包时长。每个RTP数据包包含20毫秒的音频数据。

Media Attribute (a): maxptime:20

含义：最大打包时长。最大允许包含20毫秒的音频数据。

②

关于Record-Route什么时候添加

在某些情况下，SIP 信令路径中的代理服务器可能需要在整个会话期间查看端点之间的所有消息。例如，如果 biloxi.com 代理服务器希望在初始 INVITE 之后仍留在 SIP 消息路径中，它会在 INVITE 中添加一个名为 Record-Route 的必填路由头字段，其中包含一个解析为代理服务器主机名或 IP 地址的 URI。此信息将被鲍勃的 SIP 电话和（由于 Record-Route 头字段在 200（OK）中回传）爱丽丝的软电话接收并保存在整个对话期间。biloxi.com 代理服务器随后会接收并代理 ACK、BYE 和 BYE 的 200（OK）。每个代理都可以独立决定接收后续消息，这些消息将通过所有选择接收它们的代理。此功能常用于提供通话中功能的代理服务器。

所以Record-Route是代理服务器添加的

与上面不同的是，有两个via头域，新的是客户端到代理服务器的消息路径，第二个是第一次客户端发送INVITE请求的via头域。代理服务器插入Record-Route是为了确保后续所有这个对话的请求也都经过它。

③

这个数据包是服务器收到客户端的INVITE请求后，返回的一个临时响应。

响应中的 Via头域和请求中的一样，是因为SIP协议规定响应必须沿着请求来时的路径原路返回。

④

顶层头域是SIP代理服务器（IP:192.168.121.150）在收到客户端的请求后，在消息的顶部插入的。这样响应层会按照via头域，与请求相反的顺序，按照原路返回

⑤

Record-Route头域的存在，恰这个对话的所有请求（包括 ACK）都必须经过这个代理服务器（192.168.121.150），而不能由两个客户端直接通信。

⑥

180 Ringing是一个临时响应，表示被叫方（19999）的电话已经开始振铃，但尚未接听。

SIP代理服务器（192.168.121.150）添加的Via头,表示响应需要先经过这个代理服务器。

主叫客户端（19998）最初在INVITE请求中添加的Via头,表示响应的最终目的地是主叫方。

To头域中的tag参数证明被叫方已经处理了这个呼叫请求。

第二次:服务器转发给主叫方的180 Ringing

⑦被叫方发送给服务器的响应

200 OK 最终成功响应，表示被叫方已经接听电话，呼叫已成功建立。被叫方19999已经接听电话。媒体通道就绪：双方已交换媒体能力，可以在端口60849上建立音频流。

服务器发送给主叫方的响应

200 OK响应告诉主叫方：被叫方已经接听。

⑧

ACK是一个确认请求，由主叫方（19998）发送给被叫方，用于确认已收到对方的 200 OK响应，完成呼叫建立的最终确认。

sip:19999@192.168.121.150;transport=tcp：请求的目标地址。注意这里指向代理服务器（192.168.121.150）而不是被叫方的直接地址，因为之前有 Record-Route设置

服务器（192.168.121.150）转发给被叫方（19999）的ACK确认请求。

代理服务器添加的Via头，表示ACK请求先到达代理。

主叫客户端添加的Via头，是响应的最终目的地。

⑨接着进行了三分钟的通话后，被叫方主动挂断。

被叫方（19999）主动挂断电话时发出的 SIP BYE 请求。这个请求用于主动终止一个已建立的对话。先发送给服务器

第二次：服务器转发该请求给主叫方

⑩

主叫方（19998）在收到BYE请求后，发出的 SIP 200 OK 响应，表示它已经接受并确认了通话的终止。这个响应是SIP对话终止流程的最后一步。在这个响应之后：双方客户端会立即停止发送和接收语音流（RTP包）。释放为这次通话所占用的网络端口、音频设备等所有资源。

代理服务器转发给被叫方（19999）的 200 OK 响应，用于确认之前的 BYE请求

4.CANCEL

尝试建立呼叫，但最终被取消，未能接通成功。前面的部分还是和接通过程的包是一样的。从第一个CANAEL开始，主叫方在对方接听之前主动取消了本次呼叫先发送到了服务器，第二次CANAEL是服务器转发给被叫方。

被叫方收到CANCEL后，先终止其内部的振铃，回复200 OK来确认收到了CANCEL请求并已执行取消操作（这里的200 OK是针对CANCEL请求本身的响应），服务器将这个200 OK（CANCEL）响应转发给主叫方。

这个时候，CANCEL事务结束了，但是最初的INVITE事务还需要一个最终响应，被叫方针对INVITE请求，发送一个错误响应：487 Request Terminated，表示请求终止，原因就是收到了CANCEL。服务器再将此响应转发给主叫方。

对于INVITE请求的响应，主叫方回复ACK进行确认，主叫方向服务器发送ACK，服务器再将其转发给被叫方。这里的ACK不是同意取消，而是确认收到了“487”这个消息。

①第一个CANAEL请求开始，主叫方在对方接听之前主动取消了本次呼叫先发送到了服务器

②服务器转发请求给被叫方，并且添加自己的头域

③被叫方收到CANCEL后，先终止其内部的振铃，回复 20O OK来确认收到了CANCEL请求并已执行取消操作（这里的 200 OK是针对CANCEL请求本身的响应）

④CANCEL事务结束了，但是最初的INVITE事务还需要一个最终响应，被叫方针对INVITE 请求，发送一个错误响应：487 Request Terminated，表示请求终止，原因就是收到了CANCEL。先发送给服务器。

⑤服务器将这个 200 OK（CANCEL）响应转发给主叫方。并且移除自己最顶部的头域

⑥服务器再将此响应转发给主叫方。并且移除自己最顶部的头域

⑦对于INVITE请求的响应，主叫方回复ACK进行确认，主叫方向服务器发送ACK，这里的ACK不是同意取消，而是确认收到了“487”这个消息。

⑧服务器再将其转发给被叫方。

5.RTP媒体流

1.同步源（SSRC）是媒体流的唯一标识。图中是两个完全不同的SSRC，所以他是一个双向的语音通话。

两个设备都在同时向对方发送RTP语音流，每个设备都有自己的SSRC标识符和自己的序列号空间，表示双方是实时对讲。

2.具体的数据包

这是一个RTP媒体流数据包，协议明确标识为 "Real-time Transport Protocol"，这是他的完整名称。

[Stream setup by SDP (frame 261)]：表示这个RTP流是通过第261帧的SDP（会话描述协议）消息建立的。

Version: RFC 1889 Version（2）：RTP协议版本号，目前固定为2。

Padding: False和 Extension: False：表示该RTP包没有填充字段和扩展头。

Payload type: ITU-T G.711 PCMU (0)：负载类型。这是最关键字段之一，它指明RTP数据包内承载的音频数据使用的是 G.711 μ-law编解码器。这是一种标准的、未压缩的语音编码格式。

Sequence number:序列号，用于检测数据包是否丢失或乱序，接收方会按此序号重新排序数据包。

imestamp:时间戳。用于音频同步

Synchronization Source identifier: 同步源标识符。一个随机生成的唯一数字，用于在RTP会话中唯一标识这一个音频流。

SRTP：这是RTP的加密版本，为媒体流提供机密性、完整性和防重放攻击保护。

3.波形

这是一个音频波形图。波形在中心线上下的起伏程度代表了声音的振幅。振幅越大，声音听起来就越响亮。

如果波形图显示的是一条完全平稳、没有任何起伏的水平直线，那就说明没有声音信号，或者说处于静音状态。

6.RTCP

1.RTCP和RTP之间有什么关系

RTCP是RTP的控制协议，RTP用来传输媒体数据，RTCP用来传输控制信息（告诉对方已经收到了数据）。一个RTP端口用于发送和接收媒体数据，RTCP端口通常是RTP端口+1。下面举出一个使用示例：

假设Alice正在和Bob进行视频通话：

①建立连接：通过SIP/SDP交换，Alice和Bob互相告知自己的IP地址和RTP/RTCP端口号。

②传输开始：

Alice的设备通过RTP端口持续地将她的视频和音频数据包发送给Bob。

同时，Bob的设备也通过RTP端口将他的音视频发送给Alice。

③监控与反馈（RTCP发挥作用）：

每隔几秒钟，Alice的设备会汇总她发送数据的情况（发送了多少包、多少字节、时间戳），生成一个 RTCP发送者报告（SR），并通过RTCP端口发送给Bob。

Bob的设备收到Alice的RTP流后，会计算网络状况：比如发现最近5秒内丢了2%的包，并且抖动有点大。它会将这些信息放入一个 RTCP接收者报告（RR），并通过RTCP端口发送回给Alice。

④自适应调整：

Alice的设备收到Bob的RR报告后，发现丢包率上升了。她的视频编码器可能会据此降低视频码率或启用前向纠错，以适应当前的网络状况，从而改善Bob的观看体验。

2.SR与RR

①Sender Report ：发送者报告

正在通过RTP发送音频或视频数据流的参与者。它需要向接收方和其他参与者报告“作为发送方”的数据统计，为接受方提供关键的时序信息，用于音视频同步。

SR报文包含两个主要部分：发送方信息部分和接收报告块

发送方信息部分：关于我发送出去的媒体流的数据。

NTP Timestamp：一个高精度的绝对时钟时间。这是整个报告的时间基准。

RTP Timestamp：与上述NTP时间对应的RTP时间戳。这个对应关系是音视频同步的关键。

Sender's packet count：到生成此SR时，我总共发送了多少个RTP数据包。

Sender's octet count：到生成此SR时，我总共发送了多少字节的RTP载荷数据。

接收报告块：关于我从某个发送者那里接收到的媒体流的数据。一个SR可以包含多个这样的块，分别对应不同的发送源。

Fraction Lost：自上一个报告以来，丢包率的百分比。

Cumulative number of packets lost：从会话开始到现在的总丢包数。

Extended highest sequence number：接收到的RTP序列号信息，用于判断乱序和丢包。

Interarrival jitter：数据包到达时间的抖动统计，是网络稳定性的重要指标。

Last SR timestamp：记录我收到的上一个来自该发送源的SR的NTP时间戳。

Delay since last SR：记录自收到上一个SR到我现在发送这个报告之间的延迟。

②Receiver Report ：接收者报告

当前没有发送媒体流，但正在接收媒体流的参与者

SIP报文：接收报告块（没有发送方信息部分），与SR报文中的“接收报告块”完全一样。他们两个之中都包含一个或多个接收报告块。

3.RTCP的统计：jitter,delay,loss

①Loss (丢包)

概念：在网络传输过程中，发送了但未被接收端成功收到的RTP数据包的比例。这是衡量网络可靠性的最直接指标。

Fraction lost: 0 / 256：丢包率。这里是 0/256 = 0%。

Cumulative number of packets lost: 0：累计丢包数。从会话开始到现在总共丢失的包数。这里是 0。

影响：丢包会导致音频出现嘎嘎声、视频出现马赛克或卡顿。即使是1%的丢包率，也可能对语音质量产生明显影响。

②Jitter (抖动)

概念：数据包到达时间间隔的变化量。它衡量的是网络延迟的稳定性，而不是延迟本身。抖动值越小越好。

假设你每隔20毫秒发送一个包。在理想网络中，它们应该每隔20毫秒精准到达。但在真实网络中，第一个包可能延迟30ms到达，第二个延迟50ms，第三个延迟25ms。这种到达时间的不稳定性就是抖动。

Interarrival jitter: 159。如果时钟频率是8000Hz，那么抖动大约是 159 / 8000 = 0.02 秒（20毫秒）

影响：高抖动会导致接收端的播放缓冲区清空或溢出，从而引起音频/视频的卡顿。为了对抗抖动，接收端会设置一个去抖动缓冲区，但这会增加整体的端到端延迟。

③Delay (延迟) - 这里特指 DLSR

概念：在RTCP中，这个 Delay特指接收端的处理延迟。即从接收端收到发送端的最后一个R 包，到它准备发送当前这个RR 包，这中间经过的时间。（SR ：发送端报告；RR ：接收端报告）

Delay since last SR timestamp: 351221 (5359 milliseconds)。这个延迟是 5359毫秒（约5.4秒）。