流媒体服务器的功能

流媒体服务器的主要功能是以流式协议（RTP/RTSP、MMS、RTMP等）将视频文件传输到客户端，供用户在线观看；也可从视频采集、压缩软件接收实时视频流，再以流式协议直播给客户端。典型的流媒体服务器有微软的Windows Media Service（WMS），它采用MMS协议接收、传输视频，采用Windows Media Player（WMP）作为前端播放器；RealNetworks公司的Helix Server，采用RTP/RTSP协议接收、传输视频，采用Real Player作为播放前端；Adobe公司的Flash Media Server,采用RTMP(RTMPT/RTMPE/RTMPS)协议接收、传输视频，采用Flash Player作为播放前端。值得注意的是，随着Adobe公司的Flash播放器的普及（根据Adobe官方数据，Flash播放器装机量已高达99%以上），越来越多的网络视频开始采用Flash播放器作为播放前端，因此，越来越多的企业开始采用兼容Flash播放器的流媒体服务器，而开始淘汰其他类型的流媒体服务器。支持Flash播放器的流媒体服务器，除了Adobe Flash Media Server，还有sewise的流媒体服务器软件和Ultrant Flash Media Server流媒体服务器软件，以及基于Java语言的开源软件Red5。

MirrorLink

MirrorLink由车联网联盟（Car-Connectivity-Consortium，CCC联盟）在2011年9月份正式规范命名的（此前叫做Terminal Mode）， 其目的在通过跨产业合作打造无缝隙的车内通讯环境，让智能手机、平板电脑、电子书等各式移动终端都能通过该标准，便捷而且迅速地与车载信息娱乐系统互联使用，为使用者提供最简单而直接的体验。

MirrorLink包括用户移动设备（ML服务器）和车载系统（ML客户端），还有应用程序（ML APP）。在MirrorLink运行的环境下，移动设备上的程序和服务将会被复制到汽车环境，界面和音频也将同步到车载系统，并通过车载屏幕和音响显示和播放，同时，车载触摸屏、按键、麦克风也可以通过触控或音控去访问移动设备上的这些程序和服务。

MirrorLink除了ccc定义的鉴权部分，没有新的底层技术和标准，只是结合了多种现有技术（Virtual Network Computing (VNC，核心协议)，IP，USB，Wi-Fi，Bluetooth HFP/A2DP，Real-Time Protocol (RTP)，Universal Plug and Play (UPnP)，NFC等）来满足各种可能的车内使用情境， 包括以虚拟网络运算进行画面显示与用户指令输入、通过通用随即随插寻找对应的设备与完成正确的设定配置， 运用蓝牙和实时传输协议执行声音串流等。

象百度CarLife就使用了mirrorlink作为底层框架，Android Auto和苹果CarPlay的功能也类似（因为两者采用半开放和不开放方式，底层使用了哪些协议未知）。

MirrorLink整体架构如下图所示：

MirrorLink的协议栈

连接协议，包含以IP为基础的有线（USB）或者无线（Wifi或蓝牙）甚至NFC的面向连接的服务和无连接的服务，用于传输数据和音频。以及专用的蓝牙连接方案用于传输电话音频和应用音频。

UPnP的服务协议，主要为ML服务器和客 户端之间提供广播机制， 通知ML客户端此时服务器上的应用程序列表，并对它们进行操作（开启、终 止、报告它们的状态等）。

VNC协议，复制ML服务器的显示内容到ML客户端，并将MK客户端的控制信息反馈给ML服务器。包含RFB（远程帧缓存）协议和控制事件 的传输， RFB协议是基于TCP/IP或UDP/IP协议的基础之上的，用于传输帧缓存内的数据，并提供压缩 技术。

传输音频的协议，主要有RTP协议，蓝牙的HFP和A2DP，主要用于移动设备的电话和应用程序的音频传输。

安全机制协议，用于MirrorLink的认证和保密。

MirrorLink的版本当前已发布到12，新的版本还在讨论中，整个协议栈如下图所示：

Miracast

Miracast作为DLNA、Airplay更简化和显示升级的新技术，更高的传输速率和更好的匹配也完全可能替代MirrorLink（缺点是只能单向控制，需要增加其他手段实现双方控制）。

Miracast基于WiFi联盟的WiFi-Direct协议（两个wifi设备可以直接进行连接，无须经过AP），发送者叫Source方，接收者叫Sink方，连接方式如下图所示：

Miracast底层为WiFi驱动，上面带IP、UDP、RTP协议，再上面为H264 TS码流（未来不排除采用H265这个更高效的码流协议），下图为NVidia公司的Miracast实现协议栈：

总结

MirrorLink和Micacast家族到底哪种方式会占主流，让我们拭目以待。当然随着带3G、4G、5G通信协议的车机崛起，也许MirrorLink和Micacast在车机上都会退出历史舞台。不过现在仍有了解他们的必要。

前文：

网络协议

一、协议

1、HTTP协议:基于TCP连接的，主要解决如何包装数据，对应于应用层;

2、TCP/UDP协议:主要解决数据如何在网络中传输，对应于传输层;

3、IP协议:对应于网络层;

· 在传输数据时，可以只使用传输层（TCP/IP），但是那样的话，由于没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用应用层协议，应用层协议很多，有HTTP、FTP、TELNET等等，也可以自己定义应用层协议。

· web使用HTTP作传输层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发送到网络上。

· TCP/IP:传输层协议，主要解决数据如何在网络中传输。

TCP（TransmissionControl Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。

UDP是User Datagram Protocol，一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。可靠性由上层应用实现，所以要实现udp可靠性传输，必须通过应用层来实现和控制。

确认机制、重传机制、滑动窗口。

1．应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据长度将保持不变。由TCP传递给IP的信息单位称为报文段或段（segment）。

2．当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。TCP有延迟确认的功能，在此功能没有打开，则是立即确认。功能打开，则由定时器触发确认时间点。

3．TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。

4．既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。

5．既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。[2]

6．TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。

TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重传，如果在重传超时前收到确认(Acknowlegement)就关闭该重传，如果重传超时前没有收到确认，则重传该数据段。在选择重发时间的过程中，TCP必须具有自适应性。它需要根据互联网当时的通信情况，给出合适的重发时间。

这种重传策略的关键是对定时器初值的设定。采用较多的 算法 是Jacobson于1988年提出的一种不断调整超时时间间隔的动态算法。其工作原理是：对每条连接TCP都保持一个变量RTT（Round Trip Time），用于存放当前到目的端往返所需要时间最接近的估计值。当发送一个数据段时，同时启动连接的定时器，如果在定时器超时前确认到达，则记录所需要的时间（M），并修正[2] RTT的值，如果定时器超时前没有收到确认，则将RTT的值增加1倍。通过测量一系列的RTT（往返时间）值，TCP协议可以估算数据包重发前需要等待的时间。在估计该连接所需的当前延迟时通常利用一些统计学的原理和算法（如Karn算法），从而得到TCP重发之前需要等待的时间值。

TCP的一项功能就是确保每个数据段都能到达目的地。位于目的主机的TCP服务对接受到的数据进行确认，并向源应用程序发送确认信息。使用数据报头序列号以及确认号来确认已收到包含在数据段的相关的数据字节。

TCP在发回源设备的数据段中使用确认号，指示接收设备期待接收的下一字节。这个过程称为期待确认。

源主机在收到确认消息之前可以传输的数据的大小称为窗口大小。用于管理丢失数据和流量控制。

UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。

传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。实现确认机制、重传机制、窗口确认机制。

如果你不利用 Linux 协议栈以及上层socket机制，自己通过抓包和发包的方式去实现可靠性传输，那么必须实现如下功能：

发送：包的分片、包确认、包的重发

接收：包的调序、包的序号确认

目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等，从而在包丢失和网络拥塞的情况下， RTP 客户机（实时位置）面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时，可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。

实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。

RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于底层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。

基于UDP的数据传输协议（UDP-basedData Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。

本文来自地址： https://blogcsdnnet/gettogetto/article/details/76736365

实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该

协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP

和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的

是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可

以发出请求，即RTSP可以是双向的。

63 RTSP协议

实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使

实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据

。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径

，并为选择基于RTP上发送机制提供方法。

631 简介

6311 目的

实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制

流交是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控

制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对

服务器的可传输连接以发出RTSP 请求。此外，可使用无连接传输协议，如UDP。RTSP流控制

的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操

作上与HTTP/11类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下：

从媒体服务器上检索媒体：

用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体

的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。

媒体服务器邀请进入会议：

媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模

式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。

将媒体加到现成讲座中：

如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/11中类似，RTSP

请求可由代理、通道与缓存处理。

6312 协议特点

RTSP 特性如下：

可扩展性：

新方法和参数很容易加入RTSP。

易解析：

RTSP可由标准 HTTP或MIME解吸器解析。

安全：

RTSP使用网页安全机制。

独立于传输：

RTSP可使用不可数据报协议（UDP）、可数据报协议（RDP），如要实现应用级可，可

使用可流协议。

多服务器支持：

每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在

传输层执行。

记录设备控制：

协议可控制记录和回放设备。

流控与会议开始分离：

仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H323

可用来邀请服务器入会。

适合专业应用：

通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑

演示描述中立：

协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP

URI。

代理与防火墙友好：

协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个"缺

口"。

HTTP友好：

此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台

（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法

。 适当的服务器控制：

如用户启动一个流，他必须也可以停止一个流。

传输协调；

实际处理连续媒体流前，用户 可协调传输方法。

性能协调：

如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的

用户界面。

6313扩展RTSP

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP 可以

如下三种方式扩展，这里以改变大小排序：

以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。

加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次

尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支

持的方法。

定义新版本协议，允许改变所有部分。（除了协议版本号位置）

6314操作模式

每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义

。使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。

为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说

明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参

数外，网络目标地址和端口也需要决定。下面区分几种操作模式：

单播：

以用户选择的端口号将媒体发送到RTSP请求源。

组播，服务器选择地址：

媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。

组播，用户选择地址：

如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。

6315 RTSP状态

RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数

据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个

媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的

连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着

重要的作用：

SETUP：

让服务器给流分配资源，启动RTSP连接。

PLAY与RECORD：

启动SETUP 分配流的数据传输。

PAUSE：

临时停止流，而不释放服务器资源。

TEARDOWN：

释放流的资源，RTSP连接停止。

标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连

接产生连接标识。

6316 与其他协议关系

RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目

前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，

演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户

不全依HTTP。

但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发

出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的

；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好

处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。

当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格

式可表示包含几个媒体流的演示的静态与临时属性。

632 协议参数

633 RTSP 信息

RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但

接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易

。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容

易以脚本语言（如：Tcl、Visual Basic与Perl）实现研究原型。

10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有

重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx。RTSP信息可通过任何低层传输协议

携带。

请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器

端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：

不管实体头段是否出现在信息中，不包括信息体的的响应信息总以头段后第一和空行结束。

如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。

服务器关闭连接。

注意：RTSP目前并不支持HTTP/11"块"传输编码，需要有内容长度头。假如返回适度演示描

述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即

使必须有内容长度，且长度没显式给出，规则可确保行为合理。

从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP

定义了附加状态代码，而没有定义任何HTTP代码。

634 实体

如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和试

题体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可

分别指用户和服务器。

实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附

加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽

略，而让代理转发。

635 连接

RTSP请求可以几种不同方式传送：

1、持久传输连接，用于多个请求/响应传输。

2、每个请求/响应传输一个连接。

3、无连接模式。

传输连接类型由RTSP URI来定义。对 "rtsp" 方案，需要持续连接；而"rtspu"方案，调用

RTSP 请求发送，而不用建立连接。

不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否

则媒体服务器没有可途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途

径。

636 方法定义

方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。

某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和

服务器操作复杂，并强加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通

过TCP传输时才可使用。流数据（如RTP包）用一个ASCII美圆符号封装，后跟一个一字节通道标

识，其后是封装二进制数据的长度，两字节整数。

实时传送协议（Real-time Transport Protocol或简写RTP，也可以写成RTTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。

RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTCP协议或者RTSP协议）。因为RTP自身具有Time stamp所以在ffmpeg 中被用做一种formate

RTP协议格式：

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P|X|  CC   |M|     PT      |       sequence number         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                           timestamp                           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|           synchronization source (SSRC) identifier            |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

|            contributing source (CSRC) identifiers             |

|                                                          |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

上图引自rfc3550，由上图中可知道RTP报文由两个部分构成--RTP报头和RTP的负载：

RTP报文由两部分组成：报头和有效载荷。RTP报头格式如图67所示，其中：

1V：RTP协议的版本号，占2位，当前协议版本号为2。

2 P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。

3 X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。

4  CC：CSRC计数器，占4位，指示CSRC 标识符的个数。

5 M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。

6 PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。

7 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，在helix服务器中这个字段是从0开始的，同时音频包和视频包的sequence是分别记数的。

8 时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。

9 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

10 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

如果扩展标志被置位则说明紧跟在报头后面是一个头扩展，其格式如下：

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|      defined by profile       |           length              |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        header extension                       |

|                                                          |

RTP协议的用途：

概述中已经基本阐述了RTP协议的用途了，其主要用于在互联网上传递音频和视频的标准数据包。在当前三网融合中RTP可以用来承载TS流，进行电视媒体数据的传播。RTP可以用来传送像TS流这种自身已经具有formate的媒体流，同时也可以用来承载AVC，AAC等去除了fromate的媒体流，这时rtp协议可被看做为一种formate，这种形式最少常见于helix 流媒体服务器的rtp流。其控制流由RTSP协议来提供。

RTP协议的使用：

RTP的使用实例之一如上图：

上面是某省IPTV20早期的一个数据包的情况。从包中可以看出RTP是怎么和RTSP配合一起使用的。从包402到411为RTSP的协商过程，RTSP在PLAYer命令后数据包就到来。紧跟其后412包就是一个mpeg 的PES包，它是有由rtp来承载的TS来形成。从在420包中就可以更加清析的看出这个RTP流的情况。其PT即payload type为mpeg2 transport streams 也就是ts流，其SSRC为：0x65737D6c，其Seq号为15764，从中也可以看出对于一个RTP流其SEQ号可以开始于一个随机的数值，但是肯定是逐包递增的。下图为420包的展开图：

从中可以看出承载RTP的为UDP的数据流这个包中有x标志位为1则说明其有 header extensions其header extensions为最下面。extension 的 profile为23128,长度为：2内容如上图最后两部分。

RF3550定义实时传输协议RTP和它的控制协议RTCP。RTP协议是Internet上针对流媒体传输的基础协议，该协议详细说明在互联网上传输音视频的标准数据包格式。RTP本身只保证实时数据的传输，并不能提供可靠传输、流量控制和拥塞控制等服务质量保证，这需要RTCP协议提供这些服务。</br>

RTCP协议负责流媒体的传输质量保证，提供流量控制和拥塞控制等服务。在RTP会话期间，各参与者周期性彼此发送RTCP报文。报文中包含各参与者数据发送和接收等统计信息，参与者可以据此动态控制流媒体传输质量。RTP和RTCP配合使用，通过有效反馈使使流媒体传输效率最佳化。</br>

IETF的RFC3550定义RTP/RTCP协议的基本内容，包括报文格式、传输规则等。除此之外，IETF还定义一系列扩展协议，包括RTP档次扩展，RTCP报文类型扩展，等等。本文对这些协议进行初步归纳总结，在分析RFC3550的基础上，以档次为主线分析RTP系列协议，以报文类型为主线分析RTCP系列协议。</br>

RFC3550 - RTP: A Transport Protocol for Real-Time Applications (RTP)</br>

RFC3550协议定义RTP和RTCP协议的最基本内容，包括报文格式及头部扩展、发送和接收规则、RTP Mixer和Translator、协议安全等内容。详细内容都在协议中定义，这里只简述RTP和RTCP报文的基本格式。</br>

RTP报文由固定头部、(可选)扩展头部和负载三部分组成，如图1所示。头部中的X域标示固定头部后面是否跟随扩展头部，PT域定义负载类型。各部分的详细定义请参考RFC3550[1]。</br>

RFC3550根据RTCP报文类型定义SR、RR、SDES、BYE和APP五种报文格式。图2显示了SR(Sender Report)的报文格式，包括固定头部、发送端信息和报告块三部分组成：发送端信息携带NTP时间同步和数据发送统计等内容，报告块则包含发送端接收到数据的统计信息。关于RTCP报文格式的详细信息，请继续参考RFC3550 [1]。</br>

RFC3550关于RTP档次的定义如下[1]：</br>

“档次定义了一系列负载类型和对应的负载格式，也定义了特定于具体应用的RTP扩展和修改。典型地，某个应用仅基于一个档次运行。”</br>

IETF针对RFC3550在档次方面定义了一系列扩展协议，总结如下表1：</br>

RFC3551(RTP/AVP)在RFC3550的基础上针对RTP档次进行补充形成RTP/APVP档次，被用在具有最小会话控制的音视频会议中，是其它扩展档次的基础。该档次在没有参数协商和成员控制的会话中非常有用。该档次也为音视频定义一系列编码和负载格式。对于具体的流媒体负载格式，IETF也定义一系列协议详细描述，如VP8视频负载格式[6]和H264视频负载格式[7]，等等。</br>

RFC3711(SRTP，也即RTP/SAVP)是RTP/AVP在安全方面进行扩展形成的档次，为RTP/RTCP提供数据加密、消息认证、重放保护等功能。SRTP具有高吞吐量和低数据膨胀等特点，是异构环境下对RTP/RTCP数据的有效保护。</br>

RFC4585(RTP/AVPF)是RTP/AVP在及时反馈方面进行扩展形成的档次，使得接收端能够向发送端提供及时反馈，实现短时调整和基于反馈的修复机制。该协议定义早期RTCP报文以实现及时反馈，并定义一系列通用RTCP反馈报文和特定于应用的反馈报文，如NACK、PLI、SLI、RPSI等。</br>

RTC5124(RTP/SAVPF)则是RTP/SAVP和RTP/AVPF的综合。SAVP和AVPF在使用时，需要参与者借助于SDP协议[8]就档次和参数信息达成一致。但是对一个RTP会话来说，这两种档次不能同时被协商。而实际应用中，我们有同时使用这两种档次的需要。因此，RTP/SAVPF档次应运而生，它能够使得RTP会话同时具有安全和及时反馈两方面的特性。</br>

本节对RFC3550在档次方面扩展形成的一系列协议进行初步分析。可以看到，RFC3550只定义最基本的内容，在实际应用中会对其在安全性、及时反馈等方面进行扩展。</br>

RFC 3550定义五种RTCP报文，类型在报文头部的PT域定义。表2对它们作简单描述。</br>

SR报文用于发送端报告本端的数据发送统计信息和数据接收统计信息，RR报文用于报告本端的数据接收统计信息，SDES报文用于报告本端的描述性信息，BYE在本端离开会话时发送，而APP则是特定于应用的数据。</br>

IETF根据实际需求对RTCP的报文类型进行扩展，定义了一系列协议。对这类RTCP报文总结如表3所示：</br>

下面对这些RFC做进一步分析：</br>

RFC5450 - Transmission Time Offsets in RTP Streams</br>

该协议在定义一种更精细地描述传输时间的方法的基础上，定义一种改进的Jitter报告报文，负载类型为195。</br>

RFC5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)</br>

该协议对RFC4585 AVPF档次进一步补充，定义一系列传输层和特定于负载的RTCP报文格式。该系列报文对SR/RR报文的RC域重定义为FMT域，用以区分报文的子类型。综合RFC4585所定义的报文，如下表4所示：</br>

RFC3611 - RTP Control Protocol Extended Reports (RTCP XR)</br>

该协议定义RTCP扩展报告块，负载类型为207。RTCP扩展报告块在SR/RR报告块的基础上传输更多的信息。RFC3661定义了7种子报告块，总结如表5:</br>

本节以报文类型为主线，归纳总结RTCP报文及其扩展报文，内容比较多也比较繁琐。这些报文为RTP提供更丰富的控制信息和统计数据。</br>

本文在分析RTP/RTCP基础协议RFC3550的基础上，以档次为主线分析RTP系列扩展协议，以报文类型为主线分析RTCP系列扩展协议。通过以上工作，得到一个较为清晰的框架和流程，为进一步学习RTP/RTCP协议打下良好基础。</br>

</br>

[1] RFC3550 - RTP: A Transport Protocol for Real-Time Applications </br>

[2] RFC3551 - RTP Profile for Audio and Video Conferences with Minimal Control </br>

[3] RFC3711 - The Secure Real-time Transport Protocol (SRTP) </br>

[4] RFC4585 - Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) </br>

[5] RFC5124 - Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) </br>

[6] RFC7741 - RTP Payload Format for VP8 Video </br>

[7] RFC6184 - RTP Payload Format for H264 Video </br>

[8] RFC4566 - SDP: Session Description Protocol </br>

[9] RFC 5450 - Transmission Time Offsets in RTP Streams </br>

[10] RFC 5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) </br>

[11] RFC3611 - RTP Control Protocol Extended Reports (RTCP XR) </br>

RTP: Real-time Transport Protocol,实时传输协议，一般用于多媒体数据的传输。

RTCP: RTP Control Protocol，实时传输控制协议，同RTP一起用于数据传输的监视，控制功能。

RTSP: Real Time Streaming Protocol,实时流协议，用于多媒体数据流的控制，如播放，暂停等。

RTP/RTCP相对于底层传输层，和RTSP，SIP等上层协议一起可以实现视频会议，视频直播等应用。 rtsp发起/终结流媒体（通过sdp）

rtp传输流媒体数据

rtcp对rtp进行控制，同步。RTSP的请求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顾名思义可以知道起对话和控制作用

RTP/RTCP是实际传输数据的协议

RTP传输音频/视频数据，如果是PLAY，Server发送到Client端，如果是RECORD，可以由Client发送到Server

RTCP包括Sender Report和Receiver Report，用来进行音频/视频的同步以及其他用途，是一种控制协议 RTSP的对话过程中SETUP可以确定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以开始或者停止RTP的发送，等等 (ixmy)