⼀篇⽂章读懂流媒体传输协议RTP、RTCP、RTSP、 SRTPSRTCP
概要
⼀句话：RTSP发起/终结流媒体、RTP传输流媒体数据 、RTCP对RTP进⾏控制，同步。 雷诺护垫
因为CTC标准⾥没有对RTCP进⾏要求，因此在标准RTSP的代码中没有看到相关的部分。⽽在私有RTSP的代码中，有关控制、同步等，是在RTP Header中做扩展定义实现的。另外，可以看作是的升级⽂档，只看/即可。
国家新农合信息平台
RTP
RTP简介
RTP(Real Time Transport Protocol)是针对Internet上多媒体数据流的⼀个传输协议, 由IETF(Internet⼯程任务组)作为RFC1889发布。RTP被定义为在⼀对⼀或⼀对多的传输情况下⼯作，其⽬的是提供时间信息和实现流同步。RTP的典型应⽤建⽴在UDP上，但也可以在TCP或ATM等其他协议之上⼯作。RTP本⾝只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 RTP⼯作机制
多媒体数据传输的⼀个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达⽤以播放和回放。rtp协议就是提供了时间标签，序列号以及其它的结构⽤于控制适时数据的流放。在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包⾥隐蔽的设置了时间标
签。在接受端收到数据包后，就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不⼀样的。但是rtp本⾝并不负责同步，rtp只是传输层协议，为了简化运输层处理，提⾼该层的效率。将部分运输层协议功能（⽐如流量控制）上移到应⽤层完成。同步就是属于应⽤层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不⽀持资源预留，也不保证服务质量。rtp报⽂甚⾄不包括长度和报⽂边界的描述。同时rtp协议的数据报⽂和控制报⽂的使⽤相邻的不同端⼝，这样⼤⼤提⾼了协议的灵活性和处理的简单性。
rtp协议和udp⼆者共同完成运输层协议功能。udp协议只是传输数据包，不管数据包传输的时间顺序。 rtp的协议数据单元是⽤udp分组来承载的。在承载rtp数据包的时候，有时候⼀帧数据被分割成⼏个包具有相同的时间标签，则可以知道时间标签并不是必须的。⽽udp的多路复⽤让rtp协议利⽤⽀持显式的多点投递，可以满⾜多媒体会话的需求。
rtp协议虽然是传输层协议但是它没有作为osi体系结构中单独的⼀层来实现。rtp协议通常根据⼀个具体的应⽤来提供服务，rtp只提供协议框架，开发者可以根据应⽤的具体要求对协议进⾏充分的扩展。
RTP协议报⽂结构
如下图所⽰邱宗志
开始12个⼋进制出现在每个RTP包中，⽽CSRC标识列表仅出现在混合器插⼊时。各段含义如下：
①版本（V）
version (V): 2 bits 2位，标识RTP版本，协议初始版本为0，RFC3550中规定的版本号为2。。
②填充标识（P）
padding (P): 1 bit 1位，如设置填充位，在包末尾包含了额外的附加信息，它不属于有效载荷。附加信息的最后⼀个字节表⽰额外附加信息的长度（包含该字节本⾝）。该字段之所以存在是因为某些加密算法需要固定⼤⼩的填充字，或为在底层协议数据单元中携带⼏个RTP 包。
③扩展（X）
extension (X): 1 bit 1位，如果该位被设置，则在固定的头部后存在⼀个扩展头部，格式定义在RFC3550 5.3.1节。
④CSRC计数（CC）
CSRC count (CC): 4 bits 4位，CSRC计数包括紧接在固定头后标识CSRC个数。
⑤标记（M）
marker (M): 1 bit 1位，标记解释由设置定义，⽬的在于允许重要事件在包流中标记出来。设置可定义其他标⽰位，或通过改变位数量来指定没有标记位，该位的功能依赖于profile的定义。profile可以改变该位的长度，但是要保持marker和payload type总长度不变（⼀共是8 bit）。。
⑥载荷类型（PT）
payload type (PT): 7 bits 7位，记录后⾯资料使⽤哪种 Codec ， receiver 端出相应的 decoder 解碼出來，该位标记着RTP packet 所携带信息的类型，标准类型列出在RFC3551中。如果接收⽅不能识别该类型，必须忽略该packet。
⑦系列号
sequence number:16 bits 16位，系列号随每个RTP数据包发送后⽽增加1，接收⽅可以根据该序列号重新排列数据包顺序，或者探测包损失。系列号初值是随机的，使对加密的⽂本攻击更加困难。
⑧时标
timestamp: 32 bits 32位，时标反映RTP数据包中第⼀个⼋进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。
由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有⼀段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确⽆误的信息。
⑨SSRC
SSRC: 32 bits 32位，SSRC段标识同步源。此标识不是随机选择的，⽬的在于使同⼀RTP包连接中没有两个同步源有相同的SSRC标识，也就是在⼀个RTP Session其间每个数据流都应该有⼀个不同的SSRC。尽管多个源选择同⼀个标识的概率很低，所有RTP 实现都必须探测并解决冲突。如源改变源传输地址，也必须选择⼀个新SSRC标识以避免插⼊成环⾏源。
⑩CSRC列表
CSRC list: 0 to 15 items bits0到15项，每项32位。CSRC列表表⽰包内的对载荷起作⽤的源。标识
数量由CC段给出。如超出15个作⽤源，也仅标识15个。CSRC标识由混合器插⼊，采⽤作⽤源的SSRC标识。只有存在Mixer的时候才有效。如⼀个将多声道的语⾳流合并成⼀个单声道的语⾳流，在这⾥就列出原来每个声道的SSRC。
从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP协议的⽬的是提供实时数据（如交互式的⾳频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建⽴在底层的⾯向连接或⾯向⾮连接的传输协议之上；RTP也不依赖于特别的⽹络地址格式，⽽仅仅只需要底层传输协议⽀持组帧（Framing）和分段（Segmentation）就⾜够了；另外RTP本⾝还不提供任何可靠性机制，这些都要由传输协议或者应⽤程序⾃⼰来保证。在典型的应⽤场合下，RTP⼀般是在传输协议之上作为应⽤程序的⼀部分加以实现的 ，如下图所⽰：
RTCP
RTCP简介
RTCP(Real Time Contorl Protocol)负责管理传输质量在当前应⽤进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利⽤这些信息动态地改变传输速率，甚⾄改变有效载荷类型。RTP和RTCP配合使⽤，能以有效的反馈和最⼩的开销使传输效率最佳化，故特别适合传送⽹上的实时数据。
RTCP⼯作机制
当应⽤程序开始⼀个rtp会话时将使⽤两个端⼝：⼀个给rtp，⼀个给rtcp。rtp本⾝并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠rtcp提供这些服务。在rtp的会话之间周期的发放⼀些rtcp包以⽤来传监听服务质量和交换会话⽤户信息等功能。rtcp包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利⽤这些信息动态地改变传输速率，甚⾄改变有效载荷类型。rtp和rtcp配合使⽤，它们能以有效的反馈和最⼩的开销使传输效率最佳化，因⽽特别适合传送⽹上的实时数据。根据⽤户间的数据传输反馈信息，可以制定流量控制的策略，⽽会话⽤户信息的交互，可以制定会话控制的策略。二苯乙烯
RTCP协议将控制包周期发送给所有连接者，应⽤与数据包相同的分布机制。低层协议提供数据与控制包的复⽤，如使⽤单独的UDP端⼝号。RTCP执⾏下列四⼤功能：
主要是提供数据发布的质量反馈。是作为RTP传输协议的⼀部分，与其他传输协议的流和阻塞控制有关。反馈对⾃适应编码控制直接起作⽤，但IP组播经验表明，从发送者收到反馈对诊断发送错误是致关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP组播等发布机制使⽹络服务提供商类团体可能接收反馈信息，充当第三⽅监控者来诊断⽹络问题。反馈功能由RTCP发送者和接收者报告执⾏。
RTCP带有称作规范名字（CNAME）的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME 与相关RTP连接中给定的⼏个数据流联系
前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到⼤规模数量，速率必须受到控制。让每个参加者给其它参加者发送控制包，就⼤独⽴观察参加者数量。该数量⽤语计算包发送的速率。
第四个可选功能是传送最⼩连接控制信息，如参加者辨识。最可能⽤在"松散控制"连接，那⾥参加者⾃由进⼊或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的⽅便通道，但不必⽀持应⽤的所有控制通讯要求。在IP组播场合应⽤RTP时，前3个功能是必须的，推荐⽤于所有情形。RTP应⽤设计⼈员必须避免使⽤仅在单播模式下⼯作的机制，那将导致⽆法扩展规模。
RTCP数据报
在RTCP通信控制中，RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下⼏种类型：
①SR：发送端报告，所谓发送端是指发出RTP数据报的应⽤程序或者终端，发送端同时也可以是接收端。
②RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应⽤程序或者终端。
③SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如⽤户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。知识树
④BYE：通知离开，主要功能是指⽰某⼀个或者⼏个源不再有效，即通知会话中的其他成员⾃⼰将退出会话。
⑤APP：由应⽤程序⾃⼰定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很⼤的灵活性。
SDES: 源描述RTCP包
SDES 包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。项描述如下：
版本（V）、填充（P）、长度： 如SR包中所描述。
包类型（PT）： 8位，包含常数202，识别RTCP SDES包。
源计数（SC）： 5位，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。
源描述项内容如下：
CNAME: 规范终端标识SDES项 CNAME标识属性如下：
如发⽣冲突或重启程序，由于随机分配的SSRC标识可能发⽣变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。
象SSRC标识，CNAME标识在RTP连接的所有参加者中应是唯⼀的。 为了提供⼀套相关RTP连接中某个参加者所采⽤的跨多媒体⼯具间的绑定，CNAME应固定为那个参加者。 为⽅便第三⽅监控，CNAME应适合程序或⼈员定位源。
NAME：⽤户名称SDES项
BYE：断开RTCP包
如混合器接收到⼀个BYE包，混合器转发BYE包，⽽不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出⼀个BYE包，列出它所处理的所有源，⽽不只是⾃⼰的SSRC标识。作为可选项，BYE包可包括⼀个8位⼋进制计数，后跟很多⼋进制⽂本，表⽰离开原因，如："camera malfunction"或"RTP loop detected"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包⾄下32位边界，字符串就不以空结尾；否则，BYE包以空⼋进制填充。
APP：定义应⽤的RTCP包
APP包⽤于开发新应⽤和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应⽤⼴泛，推荐重新定义每个APP包，⽽不⽤向IANA注册⼦类型和名称段。
RTSP
RTSP简介
是由Real Networks和Netscape共同提出的。该协议定义了⼀对多应⽤程序如何有效地通过IP⽹络传送多媒体数据。RTSP提供了⼀个可扩展框架，使实时数据，如⾳频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议⽬的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供⽅法。RTSP参考⽂档
RTSP（Real Time Streaming Protocol）是⽤来控制声⾳或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所⽤的⽹络通讯协定并不在其定义的范围内，服务器端可以⾃⾏选择使⽤TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以⽐较能容忍⽹络延迟。⽽前⾯提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的⽹络⽤量，更进⽽⽀持多⽅视讯会议（Video Conference）。 因为与HTTP1.1的运作⽅式相似，所以代理服务器《Proxy》的快取功能《Cache》也同样适⽤于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过⼤的负载集中于同⼀服务器⽽造成延迟。
RTSP协 议以客户服务器⽅式⼯作，它是⼀个多媒体播放控制协议，⽤来使⽤户在播放从因特⽹下载的实时数据（⾳频和视频流）时能够进⾏控制，如：暂停/继 续、后退、前进等。因此 RTSP ⼜称为“因特⽹录像机遥控协议”。
田家英要实现 RTSP 的控制功能，不仅要有协议，⽽且要有专门的媒体播放器(media player)和 媒体服务器(media server)。媒体服务器与媒体播放器的关系是服务器与客户的关系。媒体服务器与普通的万维⽹服务器的最⼤区别就是媒体服务器⽀持流式⾳频和视频的传送，因⽽在客户端的媒体播放器可以边下载边播放（需要先缓存⼀⼩段时间的节 ⽬）。但从普通万维⽹服务器下载多媒体节⽬时，是先将整个⽂件下载完毕，然后再进⾏播放。RTSP 仅仅是使媒体播放器能控制多媒体流的传送。因此，RTSP ⼜称为带外协议，⽽多媒体流是使⽤ RTP 在带内传送的。如图所⽰
RTSP协议特点
● 可扩展性：新⽅法和参数很容易加⼊RTSP。
● 易解析：RTSP可由标准 HTTP或MIME解析器解析。
● 安全：RTSP使⽤⽹页安全机制。
● 独⽴于传输：RTSP传输通道，可使⽤不可靠数据包协议（UDP）或可靠数据包协议（RDP），如要实现应⽤级可靠，可使⽤诸如TCP 的可靠流协议。
● 记录设备控制：协议可控制记录和回放设备。
● 适合专业应⽤：通过SMPTE 时标，RTSP⽀持帧级精度，允许远程数字编辑。
● 演⽰描述中⽴：协议未强加特殊演⽰或元⽂件，可传送所⽤格式类型；然⽽，演⽰描述⾄少需包含⼀个RTSP URI。
● 代理与防⽕墙友好：协议可由应⽤和传输层防⽕墙处理。防⽕墙需要理解SETUP⽅法，为UDP媒体流打开⼀个“缺⼝”。
● 适当的服务器控制：如⽤户启动⼀个流，则也可以停⽌⼀个流。
● 传输协调：实际处理连续媒体流前，⽤户可协调传输⽅法。
● 性能协调：如基本特征⽆效，则必须有⼀些清理机制让⽤户决定那种⽅法不⽣效。这允许⽤户提出适合⾃⼰的界⾯。
RTSP与HTTP
RTSP在功能上与HTTP有重叠，最明显的交叉是在流媒体内容的发布上——----⼤多是通过⽹页进⾏的。⽬前的协议规范同时允许⽹页服务器和流媒体服务器⽀持RTSP实现。例如，演⽰描述可通过HTTP或RTSP获取，这样减少了基于浏览器情况下的往返传递时间，同时也⽀持独⽴的RTSP 服务器与不依赖HTTP的客户端通信。
但是，RTSP与HTTP 的本质差别在于以下五个⽅⾯
● RTSP和HTTP是两个不同的协议，它们采⽤不同的⽅法和协议标志符。
● RTSP协议的数据发送不占⽤协议带宽，并且以不同的协议发送。
● HTTP是⼀个不对称协议，客户端发出请求，服务器应答。在RTSP中，客户端和服务器都可发出请求，且请求是有状态的。
● HTTP是⼀个⽆状态协议，⽽RTSP在任何情况下，必须保持⼀定状态，以便在请求确认后的很长时间内，仍可设置参数，控制媒体流。
● RTSP使⽤ISO 10646（UTF-8）定义，⽽不使⽤ISO 8859-1定义，保持与当前的HTML⼀致。
虽然⼤多数实时媒体采⽤RTP作为传输协议，但RTSP并不绑定RTP。重⽤HTTP的功能⾄少在两个⽅⾯有好处：安全和代理。由于要求⾮常接近，因此在缓存、代理和授权上采⽤HTTP功能是有价值的。
HTTP与RTSP传输的差别。概括的讲，RTSP被许多公司防⽕墙拒绝，⽽HTTP可以作为⼀个普通的⽂件通过；RTSP适合于⼤数据量、⾼可⽤性的流，如直播事件、长事件或⼤型⽂件；HTTP更适合于较⼩的数据传输和交互；当终端⽤户正在观看时，RTSP允许⽤户在服务器有效的回放媒体，HTTP更象下载⼀段媒体并在客户机上播放。从终端⽤户观点来看，RTSP看起来像是⽂件从中⼼位置播放，有点象⼴播，⽽HTTP感觉更象时从视频库中取视频，并在家⾥的机器上播放。从服务质量的观点上看，对
于流，RTSP有更好的体验，RTSP提供类似于VCR的媒体控制，如暂停、快进、倒退和绝对定位。使⽤HTTP传输，只能在整个流下载完成后，播放器软件再模拟该过程。虽
然，RTSP能够使⽤TCP或UDP，但是RTSP控制经常与RTP联合使⽤，以最好的服务质量传送实际的媒体数据。
RTSP 报⽂结构
RTSP有两类报⽂：请求报⽂和响应报⽂。
请求报⽂是指从客户向服务器发送请求报⽂，响应报⽂是指从服务器到客户的回答。由于RTSP是⾯向正⽂的(text-oriented)，因此在报⽂中的每⼀个字段都是⼀些 ASCII 码串，因⽽每个字段的长度都是不确定的。RTSP报⽂由三部分组成，即开始⾏、⾸部⾏和实体主体。在请求报⽂中，开始⾏就是请求⾏，RTSP请求报⽂的结构如图所⽰。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议