1. 引言
1.1 编写目的
编写此文档的目的是为了开发人员对该协议有个更好的了解以及开发参考。
1.2 定义
列出本文中用到的专门术语的定义和外文首字组词的原词组。
1.3 参考资料
RTSP 参考《RFC2326》
RTP 参考《RFC3550》《RFC 3605》
RTCP 参考《RFC3550》
SDP 参考《RFC 4566》
1. 系统概述
1.1 RTSP概述
RTSP（Real Time Streaming Protocol），参考标准为RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议。RTSP在体系结构上位于RTP和RTCP之上，其使用TCP或UDP完成数据的传输；HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应，使用 RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的；RTSP是用来控制声音或影像多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通信协定并不在其定义范围内。RTSP协议默认端口：554，默认承载协议为TCP。
1.2 RTSP特性
2.2.1 流控分离
从控制逻辑上来说RTSP和FTP相似，流控和数据流是分开的。
2.2.2 可扩展性
RTSP协议是基于文本的协议，所以具有较强的可扩展性。
2.2.3 安全机制
RTSP使用网页安全机制。
2.2.4 记录设备控制
协议可控制记录和回放设备。
2.2.5 代理和防火墙友好
协议可由应用和传输防火墙代理，防火墙需要理解SETUP方法，为UDP流打开一个“缺口”。
1.1 RTSP状态转换图解
1.1 传输过程图解
1.1 RTSP消息格式
2.5.1 请求格式（Request）
2.5.2 回应消息格式（Response）
1.1 RTSP中的C（Client）与 S（Server）交互流程图解
1.1 RTSP关键字段说明
2.7.1 关键字：OPTIONS
得到服务器提供的可用方法（OPTION、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、SCALE、GET_PARAMETER、SET_PARAMETER）。
2.7.2 关键字：DESCRIBE
请求流的SDP信息。
注解：此处需要了解H264 Law Data 如何生成SPS PPS信息。
2.7.3关键字：SETUP
客户端提醒服务器建立会话，并建立传输模式。
注解：此处确定了RTP传输交互式采用TCP（面向连接）还是UDP（无连接）模式。
2.7.4 关键字：PLAY
客户端发送播放请求。
注解：此处引入RTP协议及RTCP协议。
2.7.8 关键字：PAUSE
播放暂停请求。
注解：此关键字经常用在录像回放当中，实时视频流几乎用不到。
2.7.9 关键字:TEARDOWN
客户端发送关闭请求
2.7.10 关键字:GET_PARAMETER
从服务器获取参数，目前主要获取时间参数（可扩展）
2.7.11 关键字：SET_PARAMETER
给指定的URL或者流设置参数（可扩展）
2.8 SDP信息解释
v=
o=
s=
i=
u=
e=
p=
c=
b=:
t=
r=
start-time>
z=....
k=
k=:
a=
a=:
m=
v = （协议版本）
o = （所有者/创建者和会话标识符）
s = （会话名称）
i = * （会话信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （电话号码）
c = * （连接信息）
b = * （带宽信息）
z = * （时间区域调整）
k = * （加密密钥）
a = * （0 个或多个会话属性行）
时间描述：
t = （会话活动时间）
r = * （0或多次重复次数）
媒体描述：
m = （媒体名称和传输地址）
i = * （媒体标题）
c = * （连接信息 — 如果包含在会话层则该字段可选）
b = * （带宽信息）
k = * （加密密钥）
a = * （0 个或多个媒体属性行）
注解：如果该协议仅仅用在视频流媒体当中，不考虑带宽及其他会话信息，常用到的SDP描述关键字段分别为：
1）m字段：“m=”：
样例：m=video 0 RTP/AVP 96
解释：作为媒体描述的重要组成部分描述了媒体信息的详细内容：表示一个Session的video是通过RTP格式来传送的，其中Payload值是96，传输端口开没有确定；其中Payload值请参考RFC文档。
2）b字段：“b=:”：
样例：b=AS:70
解释：70是VIDEO的bitrate
3）a字段：“a=:”：
样例：a=control:trackID=0
解释：表示通过流媒体0来传输VIDEO，a的属性有很多种，常用的是control，比如“a=range:npt=0-72.080000 ”
表示流媒体的长度，再比如：“a=rtpmap:96 MPEG4-GENERIC/32000/2” 表示音频为AAC的其sample为32000等等，根据具体的要求来使用。
4）v字段：表示SDP的版本，一般填0。
5）o字段：定义了SDP一些源信息，“o=
”
username：该服务器的名称；session id：会话ID，版本信息，网络类型：IPV4或IPV6 传输地址；
样例：“o=StreamingServer 3331435948 1116907222000 IN IP4 192.168.1.123”
6）c字段：“c=IN IP4 0.0.0.0 //connect 的信息，分别描述了：网络协议，地址的类型，连接地址”
7）t字段：“t=0 0 //时间信息，分别表示开始的时间和结束的时间，一般在流媒体的直播的时移中见的比较多”。
2.9 RTP协议概述
RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。
2.10 RTP应用环境
RTP用于在单播或多播网络中传送实时数据。
2.10.1 简单的音频会议：语音通信通过一个多播地址和一对端口来实现，一个用于音频数据（RTP），另一个用于控制包（RTCP）。
2.10.2音频和视频会议：音频和视频会议。如果在一次会议中同时使用了音频和视频会议，这两种媒体将分别在不同的RTP会话中传送，每一个会话使用不同的传输地址（IP地址＋端口）。如果一个用户同时使用了两个会话，则每个会话对应的RTCP包都使用规范化名字CNAME（Canonical Name）。与会者可以根据RTCP包中的CNAME来获取相关联的音频和视频，然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。
2.10.3 翻译器和混合器。翻译器和混合器都是RTP级的中继系统。翻译器用在通过IP多播不能直接到达的用户区，例如发送者和接收者之间存在防火墙。当与会者能接收的音频编码格式不一样，比如有一个与会者通过一条低速链路接入到高速会议，这时就要使用混合器。在进入音频数据格式需要变化的网络前，混合器将来自一个源或多个源的音频包进行重构，并把重构后的多个音频合并，采用另一种音频编码进行编码后，再转发这个新的RTP包。从一个混合器出来的所有数据包要用混合器作为它们的同步源（SSRC，见RTP的封装）来识别，可以通过贡献源列表可以确认谈话者。
2.11 RTP报头格式
说明：
1）V：RTP协议的版本号，占2位，当前版本号为2。
2）P：填充标志，占1位，如果P=1，该报文在尾部填充一个或多个额外的8位组，他们不是有效载荷的一部分。
3）X：扩展标志，占1位，如果X=1，则在RTP报头后面跟一个扩展报头。
4）CC：CSRC技术器，占4位，指示CSRC标识的个数。
5）M：标记，占1位，不同的有效载荷有不同的含义，对于视频标记一帧的结束；对于音频，标记会话的开始。
6）同步信源（SSRC）标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
7）特约信源（CSRC）标识符：占32位，可以有0~15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。
8）PT：有效载荷，占7位，用于说明RTP报文中有效载荷的类型，如AAC，H264等。
9）序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序号增加1，接收者通过序列号来检测报文丢失情况，重新排列报文，恢复数据。
10）时间戳（TimeStamp）：占32位，时间戳反映了该RTP报文的第一个八位组的采样时刻。接受者使用时间戳来计算延迟和抖动，并进行同步控制。
2.12RTCP协议概述
RTCP的主要功能是：服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识。在RTP会话期 间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，各参与者可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
2.13 RTCP功能介绍
2.13.1 提供数据发布的质量反馈
RTCP是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP多播经验表明，从发送者收到反馈对诊断发送错误是至关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP多播等发布机制使网络服务提供商之类的团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
2.13.2 RTCP带有称作规范名字(CNAME)的RTP源持久传输层标识
如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME与相关RTP连接中给定的几个数据流联系。
2.13.3 可选功能是传送最小连接控制信息，如辨识参加者。
2.14 RTCP报文格式
RTCP包括五种类型的报文：
SR（Sender Report）报文：发送者报文。
RR（Receiver Report）报文：接收者报文。
SDES（Source Description）报文：源描述报文。
BYE（GoodBye）报文：退出报文。
APP（Application-Defined）报文：自定义报文
下面分别介绍一下各自的报文格式：
1）SR报文：
解释：
SR报文由三部分组成：第一部分8字节长度，分别为：V版本（2比特，当前为2）；填料P（1比特），如设置填料比特，该RTCP包在末端包含一些附加填料比特，并不是控制信息的基本部分，填料的最后一个比特统计了多少字节必须忽略，在复合的RTCP包中，复合包作为一个整体加密，填料比特只能加在最后一个单包的后面；接收报告块计数RC（5比特），该包中所含接收报告块的数目，零值有效；包类型PT（8比特），包含常数200，用于识别RTCP的SR包；长度Length（16比特），以32比特字为单位，该RTCP包的长度减一，包括头和任何填料；SSRC（32比特），SR包发起的同步源标识符；
第二部分：发射机信息20比特，此域包含以下信息，NTP时间标识（64比特）；RTP时间标识（32比特）；发送报文数（32比特）；发送字节数（32比特）；
第三部分：零到多个接收报告块，SSRC_n（源识别符）32比特；累计包丢失数24比特；接收到的扩展的最高序列号32比特；到达间隔抖动32比特；上一报文（LSR）32比特；DLSR32比特。
注：具体细节参考RFC文档
2）RR报文格式
解释：
接收者报告RR与SR包基本相同，除了包类型包含常数201和没有SR中5个字（NTP，RTP和发射机包及字节计数），余下的与SR包的相同。
3）SDES报文
SDES报文分为三层结构，由头和数据块组成，数据块可以没有也可以有多个，具体描述如下：
（1）项描述如下：
①版本V，填充（P）、长度：如SR包中所描述。
②包类型（PT）：8位，包含常数202，标识RTCP SDES包。
③源计数（X）：1位，包含在SDES包中的SSRC/CSRC块中，0值有效，但没有意义
（2）源描述项
①CNAME：规范终端标识SDES项；CNAME标识在RTP连接的所有参加者中应是唯一的。
②NAME：用户名称SDES项，描述源的真正名称。
③E-mail：电子邮件地址SDES项，邮件格式参考RFC822规定；连接期间电子邮件保持常数3。
④PHONE：电话号码SDES项，PHONE=4常量。
⑤LOC：用户地理位置SDES项，LOC=5常量。
⑥TOOL：应用或工具名称SDES项，NOTE=7常量。
⑦NOTE：通知/状态SDES项，NOTE=7常量。
⑧PRIV：专用扩展SDES项。
4）BYE报文
解释：
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC／CSRC标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个八位组计数，后跟表示离开原因的很多八位组文本，如：“cameramalfunction"或"RTP loopdetected"。字符串具有同样的编码，如在SDES中所描述的。如字符串填充包至下32位边界，字符中就不以空结尾；否则，BYE包以空八位组填充。
5）APP报文
解释：
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段
3. 软件体系总体结构设计
3.1 设计目标
针对系统方案中提出的相关功能、性能要求，提出解决方案、达到的目标。
3.1 软件系统状态转换图示
3.1 功能模块设计
3.3.1 功能模块的划分
整个RTSP流媒体主要有四个组成部分：
第一个部分：网络层，该层基于TCP/IP四层结构。
第二个部分：应用层服务器构建，该层级取决于构建该服务器的系统（Linux，Windows）以及所涉及的并发访问数量。
第三个部分：RTP/RTCP传输。
第四个部分：H264 Stream及Audio Stream。
4. 数据结构设计
4.1 数据结构设计
4.1.1 基本宏定义
4.1.2 RTSP 状态结构体
4.1.3 RTSP Session Info 结构体
4.1.4 RTP TCP Token结构体
4.1.5 RTP Over Tcp Header结构体
4.1.6 RTP Sender Struct结构体
4.1.7 RTSP Server Info 结构体
4.1.8 RTSP Stream CallBack 结构体
4.1.9 RTSP Server 配置结构体
4.1.10 RTP PayLoad Struct 结构体
4.1.11 RTSP CODEC 类型结构体
4.1.12 RTSP Trans Method 结构体
4.1.13 RTP传输模式结构体
4.1.14 RTP Header 结构体
4.1.5 RTP之 H264 NUAL 结构体
4.2 SPS PPS解释（具体参考H264标准）
4.2.1 H264帧
对于H.264而言，每帧的界定符为00 00 00 01 或者00 00 01。
如下一个H264帧的片段：
00 00 00 01 67 42 C0 28 DA 01 E0 08 9F 96 10 00 00 03 00 10 00 00 03 01 48 F1 83 2A 00 00 00 01 68 CE 3C 80 00 00 01 06 05 FF FF 5D DC 45 E9 BD E6 D9 48 B7 96 2C D8 20 D9 23 EE EF …
第一帧是：00 00 00 01 67 42 C0 28 DA 01 E0 08 9F 96 10 00 00 03 00 10 00 00 03 01 48 F1 83 2A。
第二帧是：00 00 00 01 68 CE 3C 80。
第三帧是：00 00 01 06 05 FF FF 5D DC 45 E9 BD E6 D9 48 B7 96 2C D8 20 D9 23 EE EF ..
帧类型有：
NAL_SLICE = 1 非关键帧
NAL_SLICE_DPA = 2
NAL_SLICE_DPB = 3
NAL_SLICE_DPC =4
NAL_SLICE_IDR =5 关键帧
NAL_SEI = 6
NAL_SPS = 7 SPS帧
NAL_PPS = 8 PPS帧
NAL_AUD = 9
NAL_FILLER = 12
4.2.2 SPS（序列参数集Sequence Parameter Set）
SPS 对于H264而言，就是编码后的第一帧，如果是读取的H264文件，就是第一个帧界定符和第二个帧界定符之间的数据的长度是4
4.2.3 PPS（图像参数集Picture Parameter Set）
PPS 就是编码后的第二帧，如果是读取的H264文件，就是第二帧界定符和第三帧界定符中间的数据长度不固定。
4.2.4 IDR（及时解码刷新 Instantaneous Decoding Refresh）
I和IDR帧都是使用帧内预测的。它们都是同一个东西而已,在编码和解码中为了方便，要首个I帧和其他I帧区别开，所以才把第一个首个I帧叫IDR，这样就方便控制编码和解码流程。IDR帧的作用是立刻刷新,使错误不致传播,从IDR帧开始,重新算一个新的序列开始编码。而I帧不具有随机访问的能力，这个功能是由IDR承担。IDR会导致DPB（DecodedPictureBuffer参考帧列表——这是关键所在）清空，而I不会。IDR图像一定是I图像，但I图像不一定是IDR图像。一个序列中可以有很多的I图像，I图像之后的图像可以引用I图像之间的图像做运动参考。一个序列中可以有很多的I图像，I图像之后的图象可以引用I图像之间的图像做运动参考。 对于IDR帧来说，在IDR帧之后的所有帧都不能引用任何IDR帧之前的帧的内容，与此相反，对于普通的I-帧来说，位于其之后的B-和P-帧可以引用位于普通I-帧之前的I-帧。从随机存取的视频流中，播放器永远可以从一个IDR帧播放，因为在它之后没有任何帧引用之前的帧。但是，不能在一个没有IDR帧的视频中从任意点开始播放，因为后面的帧总是会引用前面的帧。