【RTSP/RTP/RTCP/SDP】协议详解
一、RTSP协议
RTSP（Real Time Streaming Protocol）是一个有效地在IP网络上传输流媒体数据的应用层协议。RTSP对流媒体提供了诸如暂停，快进、停止等控制，而它本身并不传输数据，RTSP的作用相当于流媒体服务器的远程控制。它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
RTSP和HTTP的区别和联系:
（1）联系：两者都用纯文本来发送消息，且rtsp协议的语法也和HTTP类似。Rtsp一开始这样设计，也是为了能够兼容使用以前写的HTTP协议分析代码 。
（2）区别：rtsp是有状态的，不同的是RTSP的命令需要知道现在正处于一个什么状态，也就是说rtsp的命令总是按照顺序来发送，某个命令总在另外一个命令之前要发送。Rtsp不管处于什么状态都不会去断掉连接。，而http则不保存状态，协议在发送一个命令以后，连接就会断开，且命令之间是没有依赖性的。rtsp协议使用554端口，http使用80端口。
RTSP有两类报文：请求报文和响应报文。请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。
RTSP常用的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。
RTSP方法小结：
| 方法 |
方向 |
要求 |
含义 |
| DESCRIBE |
C->S |
推荐 |
获取媒体对象的描述，也允许使用接收头指定用户理解的描述格式。 |
| ANNOUNCE |
C->S S->C |
可选 |
当从客户端发往服务器时，ANNOUNCE将请求URL识别的媒体对象描述发送给服务器； 当从服务器发往客户端时，ANNOUNCE实时更新连接描述。如新媒体加入或变更，整个演示描述再次发送 |
| GET_PARAMETER |
C->S S->C |
可选 |
GET_PARAMETER请求检查URL指定的媒体的参数值。没有实体体时，GET_PARAMETER也许能用来测试用户与服务器的连通情况 |
| OPTIONS |
C->S S->C |
要求 |
获取服务器支持的方法或在任意时刻发出OPTIONS请求，确认服务器或客户端状态 |
| PAUSE |
C->S |
推荐 |
PAUSE请求引起流发送临时中断。如请求URL命名一个流，仅回放和记录被停止；如请求URL命名一个演示或流组，演示或组中所有当前活动的流发送都停止。恢复回放或记录后，必须维持同步。 |
| PLAY |
C->S |
要求 |
PLAY告诉服务器以SETUP指定的机制开始发送数据；必须等到SETUP请求被成功响应后，客户端才可发送PLAY请求。PLAY请求将正常播放时间设置在所指定范围的起始处，发送流数据直到范围的结束处。PLAY请求可排成队列，服务器将PLAY请求排成队列，顺序执行 |
| RECORD |
C->S |
可选 |
该方法根据演示描述初始化媒体数据记录范围，时标反映开始和结束时间；如没有给出时间范围，使用演示描述提供的开始和结束时间。如连接已经启动，立即开始记录，服务器数据请求URL或其他URL决定是否存储记录的数据；如服务器没有使用URL请求，响应应为201（创建），并包含描述请求状态和参考新资源的实体与位置头。支持现场演示记录的媒体服务器必须支持时钟范围格式，smpte格式没有意义 |
| REDIRECT |
S->C |
可选 |
重定向请求通知客户端连接到另一服务器地址。它包含强制头地址，指示客户端发布URL请求；也可能包括参数范围，以指明重定向何时生效。若客户端要继续发送或接收URL媒体，客户端必须对当前连接发送TEARDOWN请求，而对指定主执新连接发送SETUP请求 |
| SETUP |
C->S |
要求 |
对URL的SETUP请求指定用于流媒体的传输机制。也可以使客户端对正播放的流发布一个SETUP请求，以改变服务器允许的传输参数。如不允许这样做，响应错误为"455 Method Not Valid In This State”。为了透过防火墙，客户端必须指明传输参数，即使对这些参数没有影响 |
| SET_PARAMETER |
C->S S->C |
可选 |
这个方法请求设置演示或URL指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用SETUP命令设置。将设置传输参数限制为SETUP有利于防火墙。将参数划分成规则排列形式，结果有更多有意义的错误指示 |
| TEARDOWN |
C->S |
要求 |
TEARDOWN请求停止给定URL流发送，释放相关资源。 |
RTSP报文由三部分组成，即开始行、首部行和实体主体。
在请求报文中，开始行就是请求行，RTSP请求报文的结构如下图所示。
响应报文的开始行是状态行，RTSP响应报文的结构如下图所示：
简单的rtsp交互过程
C表示rtsp客户端,S表示rtsp服务端
1.C->S:OPTION request //询问S有哪些方法可用
1.S->C:OPTION response //S回应信息中包括提供的所有可用方法
2.C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息
2.S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp
3.C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会话
3.S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息
4.C->S:PLAY request //C请求播放
4.S->C:PLAY response //S回应该请求的信息
5.S->C:发送流媒体数据
6.C->S:TEARDOWN request //C请求关闭会话
6.S->C:TEARDOWN response //S回应该请求
上述的过程是标准的、友好的rtsp流程，但实际的需求中并不一定按部就班来。
其中第3和4步是必需的！只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第2步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。第5步，可以根据系统需求的设计来决定是否需要。
二、RTP协议
RTP全名是Real-time Transport Protocol（实时传输协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。RTP被划分在传输层或应用层，它建立在UDP上，同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。
RTP的封装：
版本号（V）：2比特，用来标志使用的RTP版本。
填充位（P）：1比特，如果该位置位，则该RTP包的尾部就包含附加的填充字节。
扩展位（X）：1比特，如果该位置位的话，RTP固定头部后面就跟有一个扩展头部。
CSRC计数器（CC）：4比特，含有固定头部后面跟着的CSRC的数目。
标记位（M）：1比特,该位的解释由配置文档（Profile）来承担.
载荷类型（PT）：7比特，标识了RTP载荷的类型。
序列号（SN）：16比特，发送方在每发送完一个RTP包后就将该值增加1，接收方可以由该值确定包的丢失及恢复包序列。序列号的初始值是随机的。
时间戳：32比特，记录了该包中数据的第一个字节的采样时刻。在一次会话开始时，时间戳初始化成一个初始值。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加（时间在流逝嘛）。时间戳是去除抖动和实现同步不可缺少的。
同步源标识符(SSRC)：32比特，同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的 RFC1889推荐了MD5随机算法。
贡献源列表（CSRC List）：0～15项，每项32比特，用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来，以便接收端能正确指出交谈双方的身份。
三、RTCP
RTCP(Real-time ControlProtocol，RTCP)实时传输控制协议的主要功能是：服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识。在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包。每个RTCP信息包不封装声音数据或者电视数据，而是封装发送端（和 / 或者）接收端的统计报表。RTCP也是用UDP来传送的。
根据所携带的控制信息不同RTCP信息包可分为RR（接收者报告包）、SR（源报告包）、SEDS（源描述包）、BYE（离开申明）和APP（特殊应用包）五类5类：
| 类型 |
缩写表示 |
用途 |
| 200 |
SR（Sender Report） |
发送端报告 |
| 201 |
RR（Receiver Report） |
接收端报告 |
| 202 |
SDES（Source Description Items） |
源点描述 |
| 203 |
BYE |
结束传输 |
| 204 |
APP |
特定应用 |
1、SR：
发送端报告包，用于发送和接收活动源的统计信息；
发送端报告分组SR（Sender Report）用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有：相应的RTP流的SSRC（定义同步源），RTP流中最新产生的RTP分组的时间戳和NTP，RTP流包含的分组数，RTP流包含的字节数。SR包的封装如下图所示：
版本（V）：同RTP包头域。
填充（P）：同RTP包头域。
接收报告计数器（RC）：5比特，该SR包中的接收报告块的数目，可以为零。
包类型（PT）：8比特，SR包是200。
长度域（Length）：16比特，其中存放的是该SR包以32比特为单位的总长度减一。
同步源（SSRC of sender）：SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。
NTP Timestamp（Network time protocol）SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。
RTP Timestamp：与NTP时间戳对应，与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。
Sender’s packet count：从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数. SSRC改变时，这个域清零。
Sender`s octet count：从开始发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）。发送者改变其SSRC时，这个域要清零。
同步源n的SSRC标识符：该报告块中包含的是从该源接收到的包的统计信息。
丢失率（Fraction Lost）：表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。
累计的包丢失数目：从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。
收到的扩展最大序列号：从SSRC_n收到的RTP数据包中最大的序列号，
接收抖动（Interarrival jitter）：RTP数据包接受时间的统计方差估计
上次SR时间戳（Last SR,LSR）：取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包，则该域清零。
上次SR以来的延时（Delay since last SR,DLSR）：上次从SSRC_n收到SR包到发送本报告的延时。
2、RR：
接收者报告包，用于接收非活动站的统计信息；
SR源报告包和RR接收者报告包用于提供接收质量反馈，除包类型代码外，SR与RR间唯一的差别是源报告包含有一个20字节发送者信息段。RR针对每个信源都提供信息包丢失数、已收信息包最大序列号、到达时间抖动、接收最后一个SR的时间、接收最后一个SR的延迟等信息。SR不仅提供接收质量反馈信息（与RR相同），而且提供SSRC标识符、NTP时间戳、RTP时间戳、发送包数以及发送字节数等。根据接收者是否为发送者来决定使用SR还是RR包，活动源在发出最后一个数据包之后或前一个数据包与下一个数据包间隔期间发送SR；否则，就发送RR；SR和RR包都可没有接收报告块也可以包括多个接收报告块，其发布报告表示的源不一定是在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。最大可有31个接收报告块嵌入在SR 或 RR包中，丢失包累计数差别给出间隔期间丢包的数量，而系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。
3、SDES：
源描述包，用于报告和站点相关的信息，包括CNAME；
SDES源描述包提供了直观的文本信息来描述会话的参加者，包括CNAME、NAME、EMAIL、PHONE、LOC等源描述项，这些为接收方获取发送方的有关信息提供了方便。SDES 包由包头与数据块组成，数据块可以没有，也可有多个。包头由版本（V）、填充（P）、长度指示、包类型（PT）和源计数（SC）组成。PT占8位，用于识别RTCP的SDES包，SC占5位，指示包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。数据块由源描述项组成，源描述项的内容如下：
CNAME: 规范终端标识SDES项
类似SSRC标识，RTCP为RTP连接中每一个参加者赋予唯一一个CNAME标识。在发生冲突或重启程序时，由于随机分配的SSRC标识可能发生变化，CNAME项可以提供从SSRC标识到仍为常量的源标识的绑定。
为方便第三方监控，CNAME应适合程序或人员定位源。
NAME：用户名称SDES项
这是用于描述源的真正的名称，如"John Doe, Bit Recycler, Megacorp"，可以是用户想要的任意形式。由于采用文本信息来描述，对诸如会议应用，可以对参加者直接列表显示，NAME项是除CNAME项以外发送最频繁的项目。NAME值在一次RTP会话期间应该保持为常数，但它不该成为连接的所有参加者中唯一依赖。
EMAIL：电子邮件地址SDES项
邮件地址格式由RFC822规定，如"[email protected]"。一次RTP会话期间，EMAIL项的内容希望保持不变。
PHONE：电话号码SDES项
电话号码应带有加号，代替国际接入代码，如"+1 908 555 1212"即为美国电话号码。
LOC：用户地理位置SDES项
根据应用，此项具有不同程度的细节。对会议应用，字符串如"Murray Hill, New Jersey"就足够了。然而，对活动标记系统，字符串如"Room 2A244, AT&T BL MH"也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在一次RTP会话期间，除移动主机外，LOC值期望保持不变。
TOOL：应用或工具名称SDES项
TOOL项包含一个字符串，表示产生流的应用的名称与版本，如"videotool 1.2"。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在一次RTP会话期间保持不变。
NOTE: 通知/状态SDES项
NOTE 项旨在描述源当前状态的过渡信息，如"on the phone, can't talk"，或在讲座期间用于传送谈话的题目，它的语法可在设置中显式定义。NOTE项一般只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，损害协议的性能。一般NOTE 项不作为用户设置文件的项目，也不会自动产生。
由于NOTE项对显示很重要，当会话的参加者处于活动状态时，其它非CNAME项（如NAME）传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，并以一个串长为零的字符串通知接收者。
PRIV: 专用扩展SDES项
PRIV项用于定义实验或应用特定的SDES扩展，它由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值组成。前缀长度段为8位。前缀字符串是定义PRIV项人员选择的名称，唯一对应应用接收到的其它PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其它人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。
注意，前缀应尽可能的短。SDES的PRIV项前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性， IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀，从而简化应用，并提高传输的效率。
4、BYE：
断开RTCP包，是站点离开系统的报告，表示结束；
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，在关闭之前它应该发出一个BYE包，列出混合器处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟文本信息，表示离开原因，如："cameramalfunction"或"RTPloop detected"。字符串的编码与在SDES 项中所描述的相同。如字符串信息至BYE包下32位边界结束处，字符串就不以空结尾；否则，BYE包以空八进制填充。
5、APP：
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
应用特定函数。
小结：
RTSP负责建立和控制会话，RTP负责多媒体的传输，RTCP配合RTP做控制和流量统计，他们是合作的关系。
四、SDP协议
SDP（Session Description Protocol）是一个用来描述多媒体会话的应用层控制协议，为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述；它是一个基于文本的协议。
SDP一般包括以下方面内容：
(1)会话的名称和目的
(2)会话存活时间
(3)包含在会话中的媒体信息，包括：媒体类型(video,audio, etc)、传输协议(RTP/UDP/IP,H.320, etc)、媒体格式(H.261video, MPEG video, etc)、多播或远端（单播）地址和端口
(4)为接收媒体而需的信息(addresses, ports, formats and so on)
(5)使用的带宽信息
(6)可信赖的接洽信息（Contact information）
SDP会话描述由多行
SDP会话描述由一个会话级描述（session_level description）和多个媒体级描述（media_level description）组成。会话级（session_level）的作用域是整个会话。其位置是从’v=’行开始到下一个媒体描述为止。媒体级（media_level）描述是对单个的媒体流进行描述，其位置是从’m=’行开始到下一个媒体描述为止。总之，除非媒体部分重载，会话级的值是各个媒体的缺省默认值（就是说媒体级描述其实也是一个会话级描述，只不过没写出来的会话级描述参数都用的缺省值）。
各个字段的描述：
1.Version（必选）
v=0 ------协议版本，不包括次版本号。
2．origion（必选）
o=
对会话的发起者进行了描述：
o=<用户名>
：地址
3．Session Name（必选）
s=
会话名称，在整个会话中有且只有一个”s=”。
4．Connection Data（可选）
c=
表示媒体的连接信息。例如：c=IN IP4 224.2.1.1/127
一个会话声明中，会话级描述中必须有”c=”项或者在每个媒体级描述中有一个”c=”项。可能在会话级描述和每个媒体级描述中都有”c=”项。
：地址类型，一般为IP4。
5．Bandwidth（可选）
b=
带宽信息，单位kilobits per second。
6．Times（必选）, RepeatTimesand Time Zones
t=
描述了会话的开始时间和结束时间。
7．Media Announcements （必选）
m=
媒体名称和传输地址。一个媒体描述以”m=”开始到下一个”m=”结束。
m=
对于RTP，偶数端口被用来传输数据，奇数端口用来传输RTCP包。例：
m=video49170/2 RTP/AVP 31 ：端口49170和49171为第一对RTP/RTCP端口，49172和49173为第二对的端口。传输协议是RTP/AVP，媒体格式为31（媒体格式是rtp头中payload参数对应的）。
m=audio49232 RTP/AVP 0
动态绑定的例子：16位线形编码，采样率为16KHZ，假如我们希望动态RTP/AVP 类型98表示此此流，写法如下：
m=video49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2
8．rtpmap（可选）
a=rtpmap:
0 个或多个会话属性行：a=rtpmap:<负载类型><编码名>/<时钟速率>[/<编码参数>]
9．SuggestedAttributes（可选）
a=
a=framerate:<帧速率>//单位:帧/秒 1s播放几个rtp包 倒数为一个rtp包承载的数据播放的时间单位s
音频的话 a=framerate:50 1byte*8000hz*20ms=160B
则每个rtp包的音频数据量为160B 时间戳增值为160
a=lang:<语言标记>//会话描述的缺省语言或媒体描述的语言
注： 如果SDP语法分析器不能识别某一类型(Type),则整个描述丢失。
如果”a=”的某属性值不理解,则予以丢失此属性。
会话级的描述就是媒体级描述的缺省值（就是说媒体级描述其实也是一个会话级描述，只不过没写出来的会话级描述参数都用的缺省值）。