1 简介
RTSP 英文全称 Real Time Streaming Protocol，RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议！协议主要规定定了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP体系结位于RTP和RTCP之上（RTCP用于控制传输，RTP用于数据传输），使用TCP或UDP完成数据传输。
2 rtsp基本交互过程
假设我们现在要向一个RTSP的sever发送请求获取数据，基本流程如下：
OPTIONS
C--->S
客户端向服务器端发送OPTIONS，请求可用的方法。
S--->C
服务器端回复客户端，消息中包含当前可用的方法。
DESCRIBE
C--->S
客户端向服务器请求媒体描述文件，一般通过rtsp开头的url来发起请求，格式为sdp。
S--->C
服务器回复客户端sdp文件，该文件告诉客户端服务器有哪些音视频流，有什么属性，如编解码器信息，帧率等。
SETUP
C--->S
客户端向服务器端发起建立连接请求，请求建立会话连接，准备开始接收音视频数据，请求信息描述了期望音视频数据包基于UDP还是TCP传输，指定了RTP，RTCP端口，以及是单播还是组播等信息！
S--->C
服务器端收到客户端请求后，根据客户端请求的端口号确定发送控制数据的端口以及音视频数据的端口!
PLAY
C--->S
客户端向服务端请求播放媒体。
S--->C
服务器回复客户端200 OK! 之后开始通过SETUP中指定的端口开始发送数据！
TEARDOWN
C---->S
结束播放的时候，客户端向服务器端发起结束请求
S--->C
服务端收到消息后，向客户端发送200 OK，之后断开连接
上述的流程基本涵盖了RTSP的流程，当然，RTSP除此之外，还有PAUSE，SCALE，GET_PARAMETER，SET_PARAMETER等参数。
rtsp抓包示例
3 rtsp消息格式
RTSP消息分为两大类，一类是请求（request），一类是响应（ressponse）
3.1 请求报文（request）
请求报文的格式如下：
说明：
请求报文由方法+URL+RTSP版本开头，之后跟一条或多条消息！
URL：表示接收方的地址，如rtsp://192.168.56.101:554
CR：表示回车
LF：表示换行
RTSP使用消息类型和消息体来表示不同类型的消息
最后CR LF结束
抓包示例：
该RTSP请求消息方法OPTIONS，请求目的地址 rtsp://192.168.56.101:554/test.264，RTSP版本1.0。接下来包含两种类型的消息：
第一种CSeq表示序列号，本次请求的序列号是2（服务器回复此请求的数据包序列号也是2）
第二种User-Agent，表示用户代理，值为 LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
最后一行CR LF
3.2 响应报文（resopnse）
说明：
响应报文由 RTSP版本+状态码+解释开头，之后跟一条或多条消息
状态码：表示状态，同http返回状态，如200表示OK
短语：针对状态码的文本解释
最后CR LF结束
抓包示例：OPTIONS响应报文
响应报文以Response表示，该消息中RTSP版本为1.0
服务器回复的状态码200
针对状态码200的解释为OK
包含两种类型消息：
Date:表示当前日期和时间
Public:表示服务器支持的方法，有OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
4 sdp格式详解
sdp 英文全称Session Description Protocol，会话描述协议，对应RFC2327。我们在此介绍，是因为RTSP协议中使用sdp进行媒体信息的描述，不过，sdp的应用不止于此，语音通话SIP协议，监控安防GB28181国标, 当下比较火热的webRtc都用到了sdp，可谓应用广泛！
sdp的目的就是在媒体会话中，传递媒体流信息，允许会话描述的接收者去参与会话，定义了会话描述的统一格式
4.1 sdp格式
- sdp信息由多行"<type>=<value>"组成，其中<type>是一个字符串，<value>是一个字符串，type表示类型，value的格式视type而定，整个协议区分大小写，"="两侧不允许有空格
- sdp会话描述由一个会话级描述（session_level description）和多个媒体级描述（media_level description）组成
- 会话级（session_level）的作用域是整个会话。其位置是从'v='行开始到第一个媒体描述为止
- 媒体级（media_level）描述是对单个的媒体流进行描述，如传输过程中的视频流信息，其位置是从'm='行开始到下一个媒体描述为止
会话级描述字段
Session description (会话名称和意图描述)
v= (protocol version) #协议版本
o= (owner/creator and session identifier) #所有者/创建者和会话标识符
s= (session name) #会话名称
i=* (session information) #会话信息
u=* (URI of description) #URI 描述
e=* (email address) #Email 地址
p=* (phone number) #电话号码
c=* (connection information - not required if included in all media) #连接信息 ― 如果包含在所有媒体中，则不需要该字段
b=* (zero or more bandwidth information lines) #带宽信息
One or more time descriptions ("t=" and "r=" lines, see below)
z=* (time zone adjustments) # 时区调整
k=* (encryption key) # 加密密钥 k=已定义的方法有: k=clear:<加密密钥>密钥没有变换;k=base64:<编码密钥>已编码，因为它含有SDP禁用的字符;k=uri:<获得密钥的URI>;k=prompt。SDP没有提供密钥但该会话或媒体流是要求加密的。
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description # 时间描述
t= (time the session is active) # 会话活动时间
r=* (zero or more repeat times) # 0或多次重复次数
媒体级描述字段
Media description, if present # 媒体描述
m= (media name and transport address) # 媒体名称和传输地址
i=* (media title) # 媒体标题
c=* (connection information - optional if included at session-level) # 连接信息 --- 如果包含在会话层则该字段可选
b=* (zero or more bandwidth information lines) #带宽信息
k=* (encryption key) # 加密密钥
a=* (zero or more media attribute lines) #0 个或多个会话属性行
带*号标记的行是可选的。必选的字段包括v=,o=,s=,t=,（对于会话级描述必选）m=（对于媒体级会话描述必选）
4.2 各字段描述
version（必选）
格式： v=<version>
描述: 表示sdp的版本号，不包含次版本号
origin（必选）
格式：
o=<username> <sessionid> <version> <network type> <address type> <address>
o=<用户名> <session id> <会话版本> <网络类型><地址类型> <地址>
描述：o=选项对会话的发起者进行了描述;
<username>：是用户的登录名, 如果主机不支持<username>，则用"-"代替，<username> 不能包含空格；
<session id>：是一个数字串，在整个会话中，必须是唯一的，建议使用个NTP 时间戳;
<version>: 该会话公告的版本，供公告代理服务器检测同一会话的若干个公告哪个是最新公告，基本要求是会话数据修改后该版本值递增，建议使用NTP时间戳
<networktype>: 网络类型，一般为"IN",表示internet
<addresstype>: 地址类型，一般为IP4
<adress>:地址
Session Name(必选)
格式：
s=<sessionname>
表示本sdp所描述的session的名称，没有的话使用-代替，在整个会话中有且只有一个s=
Connection Data(可选)
格式：
c=<networktype> <address type> <connection address>
描述：表示媒体连接信息；一个会话级描述中必须有"c="或者在每个媒体级描述中有一个"c="选项，也可能在会话级描述和媒体级描述中都有"c="选项；
network type表示网络类型，一般为IN，表示internet；
address type，地址类型，一般为IP4；
connection address，地址，可能为域名或ip地址两种形式。单播时，为域名或IP地址，推荐使用域名；多播，为IP地址，且IP后面必须有TTL（取值范围是0－255），地址和TTL决定了多播包被传播的范围。
Bandwidth(可选）
格式:
b=<modifier>:<bandwidth-value>
描述：该选项描述了建议的带宽，单位 kbs/s，可选，modifier包括两种类型，CT和AS，CT表示总带宽，AS表示单个媒体带宽的最大值；bandwidth-value表示具体的带宽。
Times（必选）
格式：
t=<start time> <stop time>
描述：t字段描述了会话的开始时间和结束时间，<start time> <stop time>为NTP时间，单位是秒；如果<stop time>为0表示过了<start time>之后，会话一直持续；当<start time> 和<stop time>都为0的时候，表示持久会话；建议两个值不设为0，如果设为0，不知道开始时间和结束时间，增大了调度的难度
start time和stop time均为0，表示一个持久的会话
a=（*） (可选)
格式 ：
a=<*>
描述：表示一个会话级别或媒体级别下的0个或多个属性
media information（必选)
格式：
m=<media> <port> <transport type> <fmt list>
描述：
<media>表示媒体类型，有"audio","video","application","data"（不向用户显示的数据）,"control"（描述额外的控制通道）;
<port>表示媒体流发往传输层的端口，取决于c=行规定的网络类型和接下来的传输层协议；
对于RTP，偶数端口用来传输数据，奇数端口用来传输RTCP包;
<transport>表示传输协议，与"c="一行相关联，一般用RTP/AVP表示，即 Realtime Transport Protocol using the Audio/Video profile over udp，即我们常说的RTP over udp;
<fmt list>表示媒体格式，分为静态绑定和动态绑定
静态绑定：媒体编码方式与RTP负载类型有确定的一一对应关系，如: m=audio 0 RTP/AVP 8
动态绑定：媒体编码方式没有完全确定，动态编码都大于95，需要使用"a=rtpmap"进行进一步的说明
rtpmap（可选）
格式：
a=rtpmap:<payload type> <encoding name>/<clock rate>
描述:
payload type表示动态负载类型，如 96表示h264
encoding name表示编码名称，如H.264
clock rate表示时钟频率，如90000
5 rtsp协议指令
5.1 OPTIONS
向服务器请求可用的方法
字段说明：
OPTIONS+URL+RTSP_VER
CSeq 数据包请求序列号
User-Agent 指明用户代理
Public字段描述服务器提供了哪些方法
5.2 DESCRIBE
向服务器请求会话描述信息（SDP）
字段说明：
DESCRIBE+URL+RTSP_VER
CSeq 数据包请求序列号
User-Agent 指明用户代理
Accept 指明接收数据的格式，如application/sdp表示接收sdp信息
对于DESCRIBE消息，服务端的回复有两种可能！如果需要认证，则首先返回401，并要求客户端认证，客户端再次发送包含认证信息的DESCRIBE指令，服务端收到带认证信息的DESCRIBE请求，返回sdp信息给客户端；如果不需要认证，则直接返回sdp
字段说明：
RTSP_VER+状态码+状态描述
CSeq 与请求序列号一致
Content-type 表示回复内容类型，值为application/sdp；
Cotent-Base 一般用RTSP URL表示；
Content-length 表示返回的sdp信息的长度 。
sdp信息
5.3 SETUP
SETUP请求的作用是指明媒体流该以什么方式传输，每个流PLAY之前必须执行SETUP操作。发送SETUP请求时，客户端会指定两个端口，一个端口用于接收RTP数据；另一个端口接收RTCP数据，偶数端口用来接收RTP数据，相邻的奇数端口用于接收RTCP数据
字段说明：
SETUP+URL+RTSP_VER
Transport 表明媒体流的传输方式，具体包括传输协议如RTP/UDP；指出是单播，组播还是广播；声明两个端口，一个奇数，用于接收RTCP数据，一个偶数，用于接收RTP数据；
CSeq 数据包请求序列号
User-Agent 指明用户代理
Session标识会话ID
Authorization 标识认证信息
该SETUP请求中，Transport字段声明了两个端口，53370和53371，同时指明了通过UDP发送RTP数据，53370端口用来接收RTP数据，53371端口用来接收RTCP数据,unicast表示传输方式为单播
请求之后，如果没有异常情况，RTSP服务器的回复比较简单，回复200 OK消息。在Transport字段指定收发两端的地址和端口，同时返回一个session id，用于标识本次会话连接，之后客户端发起PLAY请求的时候需要使用该字段
服务端对应SETUP请求的RTP和RTCP的传输端口分别为6970和6971
5.4 PLAY
SETUP请求被成功回复之后，客户端才可以发起PLAY请求。PLAY消息是客户端发送的播放请求，发送播放请求的时候可以指定播放区间，发起播放请求后，如果连接正常，则服务端开始播放，即开始向客户端按照之前在TRASPORT中约定好的方式发送音视频数据包，播放流程便这样开始了
字段说明：
PLAY+URL+RTSP_VER
CSeq 数据包请求序列号
User-Agent 指明用户代理
Session标识会话ID，值为SETUP请求之后，服务端返回的session id的值
Authorization 标识认证信息
Range是PLAY消息特有的，代表请求播放的时间段，使用ntp时间来表示
Range的值为"npt=0.000-"，表示从开始播放，默认一直播放
RTP-Info字段：url+seq+rtptime
seq表示第一个rtp数据包开始的序列号，rtptime表示视频开始播放的时间戳
5.5 GET_PARAMETER
向服务器获取参数，一般用于获取时间范围。当发送的请求中没有相关请求参数时，则用作保持RTSP连接
5.6 SET_PARAMETER
用于给URI指定的流地址设置参数
5.7 PAUSE
暂停请求会使得流传输暂时中断（相当于暂停），如果请求的URL指向一个流地址，则仅针对该流的回放和录制会被中断
5.8 TEARDOWN
结束流传输，同时释放与之相关的资源，TEARDWON之后，整个RTSP连接也就结束了
6 RTP包格式
RTP简介
RTP全名是Real-time Transport Protocol（实时传输协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。
RTP是一种运行在传输层的协议，通常基于 UDP 协议，但也支持 TCP 协议。
RTP数据包由两部分组成，一部分是RTP Heaeder，一部分是RTP body，RTP Header占用最少12个字节，最多72个字节；另一部分是RTP Payload，用来封装实际的数据负载，如封装h264编码的视频数据。
RTP工作机制
当应用程序提供RTSP协议建立一个RTP会话时，应用程序将确定一对目的传输地址（一个网络地址和两个端口号），其中两个端口号中的偶数端口是分配给RTP进行裸码流数据传输的，奇数端口则是分配给RTCP进行传输控制的。
RTP的发送过程如下：
- 从上层接收流媒体信息码流（如H.264），封装成RTP数据包；RTCP从上层接收控制信息，封装成RTCP控制包。
- 将RTP 数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。
6.1 RTP Header格式
字段说明：
|----------------------|----------------|-----------------------------------------------------------------------------------------------------------|
| 版本号（V） | 2bit | RTP的版本号 |
| 填充标志（P） | 1bit | 净荷末端是否包含一个或多个填充字节，净荷长度必须是4字节的倍数，因此需要填充字节使得净荷长度满足4字节倍数的要求，净荷的最后一个字节给出填充字节数 |
| 扩展位（X） | 1bit | RTP 首部扩展，RTP 首部扩展是可选的，若扩展位置1，表明在固定首部之后紧跟着一个首部扩展 |
| CSRC计数器（CC） | 4bit | RTP 首部中CSRC列表中的项数 |
| 标记（M） | 1bit | 含义取决于携带净荷的类型，对于视频，标记一帧的结束；对于音频，标记会话的开始 |
| 有效载荷类型（PT） | 7bit | RTP 净荷的格式，通常，单个 RTP 分组所包含的净荷只能用一种净荷格式对多媒体数据进行编码 |
| 序列号（sequence number） | 2Byte | 会话开始时，发送端生成随机数作为初始值，传送 RTP 分组时，每传送一组该字段增 1，在会话存在期间，顺序发送的一串 RTP 分组的序号是递增的，接收端可以根据序号检测是否存在分组丢失或错序 |
| 时间戳（timestamp） | 4Byte | 净荷中第一个采样数据的采样时间，每一个采样数据的采样时间通过一个单调且线性递增的时钟获得，时钟频率取决于净荷数据的编码格式，相邻两个 RTP 分组的时间戳差值，取决于前一个 RTP 分组净荷中包含的采样数据数目 |
| 同步源标识符（SSRC） | 4Byte | 标明同步源，同步源是一个负责发送 RTP 分组并在 RTP 分组中设置序号和时间戳的实体，标识符是会话中全局惟一的，若 RTP 分组来自混合器则同步源标识符给出的是混合器的标识符 |
| 提供源标识符列表（CSRC） | (0~15)*4Byte | 最多允许存在16个提供源标识符，若 RTP 分组来自混合器则提供源标识符列表给出进入混合器的各个信号的信号源标识符 |
抓包示例：
6.2 H264 RTP打包
6.2.1 NALU
NALU（网络抽象层单元类型）是H264用于网络传输的单元类型。NALU 单元常由 [Start Code] [NALU Header] [NALU Payload] 三部分组成，Start Code 是"00 00 00 01" 或 "00 00 01"。打包时去掉起始码，将其他数据封装成RTP包。NALU Header用一个字节表示：
- F（禁止位）：1bit，用于指示NALU是否被禁止。通常为0。
- NRI（重要性指示）：2bit，用于指示NALU的重要性。较高的重要性值表示NALU包含了重要的视频数据。（抓包看 SPS、PPS、I帧值为3，P帧值为2）。
- Type（类型）：5bit，用于指示NALU的类型。
RTP payload 中 NAL 单元的类型和 H.264 中类型字段的区别是，当 type的值为 24 ~ 31 表示这是一个特殊格式的 NAL 单元，而 H.264 中，只取 1~23 是有效的值。
打包模式
6.2.2 Single NALU
一个 RTP 包仅由一个完整的 NALU 组成。这种情况下 RTP NAL 头类型字段和原始的 H.264的NALU 头类型字段是一样的（type有效值1~23）。对于 NALU 的长度小于 MTU 大小的包，一般采用单一 NALU模式。
打包时去掉NALU起始码，格式为：RTP Header + NALU Header + NALU Data
0x67是NALU Header ---> NRI 0x3；Type：0x7，表示SPS。
6.2.3 组合封包
由多个 NALU组成一个 RTP 包。分别有4种组合方式：STAP-A，STAP-B，MTAP16， MTAP24。类型值分别是 24，25，26 ，27。当 NALU 的长度特别小时，可以把几个 NALU 单元封在一个 RTP 包中。
6.2.3 分片封包
用于把一个 NALU 单元封装成多个 RTP 包，存在两种类型 FU-A 和 FU-B，类型值分别是 28 和 29。当 NALU 的长度超过 MTU 时，就必须对 NALU 单元进行分片封包，也称为 Fragmentation Units (FUs)。
FU-A：
FU indicator：结构与H.264 NALU头结构相同，F、NRI与H.264 NALU一致，Type的值为28、29，分别对应FU-A和FU-B。
FU header：
- S：1 bit，开始位，设置成1指示分⽚NALU的开始。
- E：1 bit，结束位，设置成1指示分⽚NALU的结束。
- R：1 bit，保留位设置为0
- Type：5 bit，此处的Type就是NALU头中的Type，取1-23的那个值，表示 NAL单元荷载类型定义
FU indicator：0x7c ---> NRI 0x3；Type 28
FU header：0x85 ---> S 0x1；E 0x0；Type 0x5，分片起始，I帧
FU indicator：0x5c ---> NRI 0x2 Type 28
FU header：0x41 ---> S 0x0；E 0x1；Type 0x1，分片结束，P帧
FU indicator：0x5c ---> NRI 0x2 Type 28
FU header：0x01 ---> S 0x0；E 0x0；Type 0x1，中间分片，P帧
7 RTCP协议
RTCP代表实时传输控制协议，是英文 Real-timeTransportControlProtocol的缩写。在RFC3550中定义。RTCP与RTP携手合作。RTP执行实际数据的传递，而RTCP用于向呼叫中的参与者发送控制数据包。主要功能是提供有关RTP提供的服务质量的反馈。实时传输控制协议（RTCP）与实时传输协议（RTP）配合使用的协议，用于监视大型多播网络上的数据传递。监视交付的目的是确定RTP是否提供必要的服务质量（QoS），并在需要时补偿延迟。RTCP用于IP语音（VoIP）和互联网协议电视（IPTV）、流媒体和视频会议
RTCP包类型
根据所携带的控制信息不同，RTCP信息包可分为RR（接收者报告包）、SR（源报告包）、SEDS（源描述包）、BYE（离开申明）和APP（特殊应用包）5类：
| 类型 | 缩写表示 | 用途 |
|---|---|---|
| 200 | SR（Sender Report） | 发送端报告 |
| 201 | RR（Receiver Report） | 接收端报告 |
| 202 | SDES（Source Description Items） | 源点描述 |
| 203 | BYE | 结束传输 |
| 204 | APP | 特定应用 |
7.1 Sender Report（发送端报告）
发送端报告包，用于发送和接收活动源的统计信息，其通过多播方式向所有接收端报告发送情况。SR包的封装如下图所示：
- RTCP中可以包含多个report block，每一个SSRC都会对应一个report block，接收的每一路流对应一个SSRC
- SR中包含接收数据的信息可以用一个包就把发送和接收的数据发给对端，避免浪费一个包的资源
字段说明：
- 版本（V）：同RTP包头
- 填充（P）：同RTP包头
- 接收报告计数器（RC）：5比特，该SR包中的接收报告块的数目，可以为零
- 包类型（PT）：8比特，SR包是200
- 长度域（Length）：16比特，RTCP包的长度，包括填充的内容
- 同步源（SSRC of sender）：32比特，SR包发送者的同步源标识符。与对应RTP包中的SSRC一样
- NTP timestamp（MSW+LWS）：64比特， 表示发送此报告时间点。 结合来自各个接收器的接收报告中返回的时间戳，它可用于估计往返于接收器的往返传播时间
- RTP timestamp：32比特，与NTP时间戳对应，与RTP数据包中的RTP时间戳具有相同的单位和随机初始值
- Sender's packet count：32比特，从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数. SSRC改变时，这个域清零
- Sender`s octet count：32比特，从开始发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）。发送者改变其SSRC时，这个域要清零
- SSRC_n ：32比特，在此块中报告其接收的发送者的 SSRC 标识符
- 丢失率(Fraction Lost)：8比特，表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率
- 累计的包丢失数目（cumulative number of packets lost C ）：24比特，从开始接收到SSRC_n的包到发送SR，从SSRC_n传过来的RTP数据包的丢失总数
- 收到的扩展最大序列号(extended highest sequence number received EHSN )：从SSRC_n收到的RTP数据包中最大的序列号
- 接收抖动（Interarrival jitter）：32比特，RTP数据包接受时间的统计方差估计
- 上次SR时间戳（Last SR,LSR）：32比特，取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包，则该域清零
- 上次SR以来的延时（Delay since last SR,DLSR）：32比特，上次从SSRC_n收到SR包到发送本报告的延时
- 扩展字段 profile-specific extensions
抓包示例：
7.2 Receiver Report（接收端报告）
- 相较于SR , RR中没有sender info block
- RR与SR的payload type不同
- SR是在一端同时具有发送和接收的功能的时候使用
- RR是在一端只有接收功能的时候使用
抓包示例：
7.3 Source Description(源描述包)
SDES源描述包提供了直观的文本信息来描述会话的参加者，包括CNAME、NAME、EMAIL、PHONE、LOC等源描述项，这些为接收方获取发送方的有关信息提供了方便。SDES 包由包头与数据块组成，数据块可以没有，也可有多个
- SC 表示SSRC/CSRC的个数
- 每一个item对应一个SSRC
- item采用TLV格式(type、length、value)存放数据
- CNAME : SSRC的规范名，例如：SSRC是"123", CNAME就会命名为一个字母数字混合的长字符串, 此时ssrc和cname是唯一绑定的，webrtc中是通过cname标识每一路流的，具体该路流的SSRC是通过SDES协商的。当多个流中出现SSRC冲突的时候，就需要重新命名SSRC并且和对应的CNAME重新绑定
SDES items
CNAME(值为1)：规范终端标识，像SSRC标识，CNAME标识在RTP连接的所有参加者中应是唯一的；
NAME（值为2）：用户名称，用于描述源的用户名；
EMAIL（值为3）：电子邮件地址，用于描述源的邮件地址，格式如 John.Deo@megacorp.com；
PHONE（值为4）：用于描述源的电话号码；
LOC（值为5）：用于描述源的地理位置；
TOOL（值为6）：用于描述应用或工具的名称，表示产生流的应用的名称与版本，如"videotool 1.2"；
NOTE（值为7）：用于描述源当前状态的过渡信息；
PRIV（值为8）：用于描述针对源的扩展项；
抓包示例：
7.4 BYE（断开RTCP包）
参与者发送BYE数据包以指示一个或多个源不再活动，可选择给出离开的理由。
作为可选项，BYE包可包括一个8位八进制计数，后跟文本信息，表示离开原因，如："cameramalfunction"或"RTPloop detected"。字符串的编码与在SDES 项中所描述的相同。如字符串信息至BYE包下32位边界结束处，字符串就不以空结尾；否则，BYE包以空八进制填充。
抓包示例：
7.5 APP（定义应用的RTCP包）
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
