rtp协议：rtp固定头部介绍

前言：

大家好，今天开始给大家分享rtp协议的相关详细介绍，关于rtsp的介绍，大家可以暂时看官方的文档：

https://datatracker.ietf.org/doc/html/rfc2326

本文主要是介绍rtp协议，也就是在开发rtsp过程进行传输实际数据的部分，这部分内容也是参考官方的资料：

https://www.rfc-editor.org/rfc/rfc3550

介绍：

该备忘录指定了实时传输协议(RTP)，该协议为具有实时特征的数据(如交互式音频和视频)提供端到端传输服务。这些服务包括有效载荷类型识别、序列编号、时间戳和交付监控。应用程序通常在UDP之上运行RTP，以利用其多路复用和校验和服务；这两个协议都贡献了部分传输协议功能。然而，RTP可以与其他合适的底层网络或传输协议一起使用(参见第11节)。如果底层网络提供，RTP支持使用多播分发向多个目的地传输数据。

请注意，RTP本身不提供任何机制来确保及时交付或提供其他服务质量保证，而是依赖于较低层的服务来完成这些工作。它不保证传输或防止乱序传输，也不假设底层网络是可靠的并按顺序传输数据包。RTP中包含的序列号允许接收方重构发送方的数据包序列，但序列号也可以用于确定数据包的正确位置，例如在视频解码中，而不必按顺序解码数据包。

虽然RTP主要是为了满足多参与者多媒体会议的需要而设计的，但它并不局限于这种特定的应用。连续数据的存储、交互式分布式仿真、活动标识以及控制和测量应用也可能发现RTP适用。

本文档定义了RTP，由两个紧密相连的部分组成:

实时传输协议(RTP)，用于传输具有实时属性的数据。
RTP控制协议(RTCP)，用于监控服务质量并传递正在进行的会话中参与者的信息。RTCP的后一个方面可能足以满足“松散控制”会话，即没有显式成员控制和设置的会话，但它不一定旨在支持应用程序的所有控制通信需求。此功能可能全部或部分包含在单独的会话控制协议中，这超出了本文的范围。

RTP是遵循Clark和Tennenhouse[10]提出的应用层分帧和集成层处理原则的一种新型协议。也就是说，RTP旨在提供特定应用程序所需的信息，并且通常将其集成到应用程序处理中，而不是作为单独的层实现。RTP是一个故意不完整的协议框架。本文档指定了期望在所有应用程序中通用的功能，这些功能适用于RTP。传统协议可能通过使协议更通用或添加需要解析的选项机制来容纳额外的功能，而RTP则不同，RTP旨在根据需要通过修改和/或添加报头来进行定制。在章节中给出了例子5.3和6.4.3。

因此，除了本文档之外，还有一个完整的规范特定应用程序的RTP将需要一个或多个指导文件(见第13节):

一个概要规范文档，它定义了一组有效负载类型代码和它们到有效负载格式的映射(例如，媒体编码)。概要文件还可以定义特定于特定应用程序类的RTP扩展或修改。通常，一个应用程序将只在一个配置文件下运行。音频和视频数据的配置文件可以在配套的RFC3551[1]中找到。
有效载荷格式规范文档，它定义了如何在RTP中传输特定的有效载荷，例如音频或视频编码。

关于实时服务和算法实现的讨论，以及一些RTP设计决策的背景讨论，可以在[11]中找到。

定义：

(1) RTP payload(rtp负载): 通过rtp传输的数据包中的数据，比如说音频样本数据或者压缩的视频数据(补充，这里的意思是说，rtp传输的数据是打包的音频数据或者视频数据，或者传输两者的复合流)。有效载荷格式和解释超出了本文的范围。
（2）RTP packet(rtp数据包)：一个数据包，由固定的RTP报头、可能为空的贡献源列表(见下文)和有效负载数据组成。(这里换句话的意思，是说，一个rtp包数据，是rtp header + rtp payload)。一些底层协议可能需要定义RTP包的封装。通常，底层协议的一个包包含一个RTP包，但如果封装方法允许，也可以包含多个RTP包(见第11节)。
(3) RTCP packet : 一种控制报文，由固定的报头部分组成，类似于RTP数据包的报头部分，后面是根据RTCP报文类型而变化的结构化元素。格式在第6节中定义。通常，多个RTCP数据包作为复合RTCP数据包在底层协议的单个数据包中一起发送;这是由每个RTCP包的固定报头中的长度字段启用的。
(4)port: 传输协议用来区分给定主机内的多个目的地的“抽象”。TCP/IP协议使用小的正整数标识端口。OSI传输层使用的传输选择器(TSEL)相当于端口。RTP依赖于底层协议来提供一些机制，例如端口来复用会话的RTP和RTCP数据包。
(5)transprot address(传输地址) : 标识传输级端点的网络地址和端口的组合，例如IP地址和UDP端口。数据包从源传输地址发送到目的传输地址。
RTP media type(rtp媒体类型): RTP媒体类型是可以在单个RTP会话中携带的有效负载类型的集合。RTP配置文件将RTP媒体类型分配给RTP有效负载类型。
Multimedia session(多媒体会话) : 在一组共同的参与者之间的一组并发RTP会话。例如，视频会议(多媒体会话)可能包含音频RTP会话和视频RTP会话。
RTP session (rtp会话) ：一组与RTP通信的参与者之间的关联。一个参与者可以同时参与多个RTP会话。在多媒体会话中，除非编码本身将多个媒体多路复用到单个数据流中，否则每种媒体通常在单独的RTP会话中携带其自己的RTCP数据包。参与者通过接收使用不同目的传输地址对的多个RTP会话来区分它们，其中一对传输地址包括一个网络地址加上RTP和RTCP的一对端口号。所有参与RTP会话的成员可以共享一个通用的目的传输地址对，如IP多播的情况，或者对于每个参与者，这些地址对可能是不同的，如在单独的单播网络地址和端口对的情况。在单播情况下，一个参与者可能使用相同的端口对从会话中的所有其他参与者接收数据，或者也可能为每个参与者使用一对不同的端口。RTP会话的一个显著特点是，每个会话都维护一个完整独立的SSRC（同步源标识符）标识空间（接下来会定义）。包含在一个RTP会话中的参与者集合，由那些能够接收到任何一个参与者传输的SSRC标识符的参与者组成，无论是作为RTP中的SSRC还是RTCP中的CSRC（下面也会定义）。例如，考虑一个使用单播UDP实现的三方会议，每个参与者通过各自的端口对从其他两个参与者接收数据。如果每个参与者只将自己接收到的来自另一个参与者的数据的RTCP反馈信息发送回那个特定的参与者，那么这个会议就由三个独立的点对点RTP会话组成。如果每个参与者将自己接收到的另一个参与者的数据的RTCP反馈信息提供给另外两个参与者，那么这个会议就由一个多方RTP会话组成。后一种情况模拟了三个参与者之间使用IP多播通信时会发生的行为。RTP框架允许这里定义的变化，但是特定的控制协议或应用设计通常会对这些变化施加限制。
synchronization source(SSRC)-同步源：流媒体中RTP数据包序列的源头，通过在RTP头部携带的32位数字SSRC（同步源标识符）来识别，这样做的目的是使其不依赖于网络地址。来自同一同步源的所有数据包都是同一个时间和序列号空间的一部分，因此接收器会根据同步源对数据包进行分组以便播放。同步源的例子包括来自如麦克风或摄像机等信号源的数据包流发送者，或者是RTP混音器（见下文）。同步源可能会随时间改变其数据格式，例如音频编码。SSRC标识符是一个随机选择的值，旨在在特定的RTP会话中全局唯一（见第8节）。参与者不必在多媒体会话中的所有RTP会话中使用相同的SSRC标识符；SSRC标识符的绑定是通过RTCP提供的（见第6.5.1节）。如果一个参与者在一个RTP会话中生成多个流，例如来自不同的摄像机，每个流都必须被标识为不同的SSRC。
Contributing source(CSRC) 参与源/贡献源/：一个RTP数据包流的源头，该源头对RTP混音器（见下文）产生的合成流有所贡献。混音器将一个SSRC列表插入到该数据包的RTP头部中。这个列表被称为CSRC列表。一个应用示例是音频会议，在这种情况下，混音器标示了所有发言者，他们的语音被合成以产生外发的数据包，允许接收器指出当前的发言者，尽管所有的音频数据包包含相同的SSRC标识符（即混音器的标识符）。
end system(终端系统): 一个生成将要通过RTP数据包发送的内容和/或消费接收到的RTP数据包内容的应用程序。一个终端系统可以在特定的RTP会话中充当一个或多个同步源，但通常只有一个。
mixer: 一个中间系统，它从一个或多个源接收RTP数据包，可能会改变数据格式，以某种方式合并这些数据包，然后转发一个新的RTP数据包。由于多个输入源之间的时序通常不会同步，因此混音器会在各个流之间进行时序调整，并为其合成的流生成自己的时序。因此，所有源自混音器的数据包都会被识别为混音器作为它们的同步源。
translator: 一个转发RTP数据包同时保持其同步源标识符不变的中间系统。转换器的例子包括不进行混合的编码转换设备、从多播到单播的复制器，以及防火墙中的应用层过滤器。
Monitor: 一个接收RTP会话参与者发送的RTCP数据包，特别是接收报告，并估算当前服务质量的应用程序，用于分发监控、故障诊断和长期统计。监控功能很可能被集成到参与会话的应用程序中，但也可能是一个不参与其他活动且不发送或接收RTP数据包的独立应用程序（因为它们在不同的端口上）。这些被称为第三方监控器。对于第三方监控器来说，也可以接收RTP数据包但不发送RTCP数据包，或者在会话中不被计入也是可以接受的。
Non-RTP means : 除了RTP之外，可能还需要一些协议和机制来提供可用的服务。特别是对于多媒体会议，控制协议可能会分发多播地址和加密密钥，协商要使用的加密算法，并为那些没有预定义负载类型值的格式定义RTP负载类型值与它们所表示的有效载荷格式之间的动态映射。这类协议的例子包括会话初始协议（SIP）（RFC 3261 [13]），国际电信联盟建议H.323 [14]以及使用SDP（RFC 2327 [15]）的应用程序，如RTSP（RFC 2326 [16]）。对于简单的应用程序，电子邮件或会议数据库也可能被使用。这些协议和机制的规范不在本文档的讨论范围内。

RTP Data Transfer Protocol：RTP数据传输协议

RTP Fixed Header Fields:RTP固定头部字段

前12个八位组在每个RTP数据包中都存在，而CSRC标识符列表只有在混音器插入时才出现。这些字段具有以下含义：

version (V): 2 bits：这个字段标识了RTP的版本。本规范定义的版本是二（2）。（值1由RTP的第一个草案版本使用，值0由最初在"vat"音频工具中实现的协议使用。）
padding(填充位)（P）1bit: 如果设置了填充位，则数据包的末尾包含一个或多个额外的填充八位字节，这些填充字节不包含在有效载荷中。填充的最后一个八位字节包含一个计数，指明了应该忽略多少填充八位字节，包括它自己。某些具有固定块大小的加密算法或为了在一个更低层协议数据单元中携带几个RTP数据包，可能需要使用填充。
extension(扩展位)(X) 1 bit : 如果设置了扩展位，固定头部必须紧跟一个头部扩展，其格式在第5.3.1节中定义。
CSRC count (CC) 4bit : CSRC计数包含跟随在固定头部之后的CSRC标识符的数量。
marker 标记位(M) 1bit : 标记位的解释由一个配置文件定义。它的目的是允许在数据包流中标记重要事件，如帧边界。配置文件可以定义额外的标记位，或者通过改变负载类型字段中的位数来指定没有标记位（参见第5.3节）。
payload type 负载类型(PT) 7bit : 该字段用于标识RTP负载的格式，并通过应用程序确定其解释方式。配置文件可以指定负载类型代码到负载格式的默认静态映射。额外的负载类型代码可以通过非RTP方式动态定义（参见第3节）。在配套的RFC 3551 [1]中，为音频和视频指定了一组默认映射。RTP源可以在会话期间更改负载类型，但这个字段不应用于复用不同的媒体流（参见第5.2节）。接收方必须忽略它不理解的有效载荷类型的数据包。比如说，在实际的开发过程中，PT值如果为96则h264, AAC为97,通常使用96-127(动态序号)，如下图的一个实际场景：

sequence number 序列号 16bit : 序列号对于每个发送的RTP数据包增加1，接收方可以使用它来检测数据包丢失并恢复数据包序列。序列号的初始值应该是随机的（不可预测的），即使源本身不按照第9.1节中的方法进行加密，这样做也是为了使对加密的已知明文攻击更加困难，因为数据包可能会流经一个转换器。选择不可预测数字的技术在[17]中进行了讨论。
timestamp 时间戳 32bit : 时间戳反映了RTP数据包中第一个八位字节的采样瞬间。采样瞬间必须从一个单调递增且随时间线性变化的时钟中派生出来，以便进行同步和抖动计算（参见第6.4.1节）。时钟的分辨率必须足以满足所需的同步精度和测量数据包到达抖动（通常每个视频帧的一个时钟刻度是不够的）。时钟频率取决于作为负载携带的数据格式，并在定义格式的配置文件或负载格式规范中静态指定，或者对于通过非RTP方式定义的负载格式，可以动态指定。如果RTP数据包是定期生成的，应该使用从采样时钟确定的名义采样瞬间，而不是系统时钟的读数。例如，对于固定速率的音频，时间戳时钟可能会在每个采样周期增加1。如果音频应用程序从输入设备读取覆盖160个采样周期的块，那么对于每个这样的块，时间戳将增加160，无论该块是传输在数据包中还是作为静音被丢弃。

时间戳的初始值应该是随机的，就像序列号一样。如果几个连续的RTP数据包是（逻辑上）同时生成的，例如，属于同一个视频帧，那么它们的时间戳将会相等。如果数据不是按照采样的顺序传输的，例如在MPEG插值视频帧的情况下，连续的RTP数据包可能包含非单调的时间戳。（尽管如此，传输的数据包的序列号仍然是单调的。）。不同媒体流的RTP时间戳可能以不同的速率前进，并且通常具有独立的、随机的偏移量。因此，尽管这些时间戳足以重建单个流的时间，但直接比较来自不同媒体的RTP时间戳并不适合进行同步。相反，对于每种媒体，RTP时间戳通过将其与参考时钟（墙上时钟）的时间戳配对来与采样瞬间相关联，该参考时钟代表了对应于RTP时间戳的数据被采样的时间。这个参考时钟被所有需要同步的媒体所共享。时间戳对不会在每个数据包中传输，而是以较低的频率在RTCP SR数据包中传输，如第6.4节所述。采样瞬间被选作RTP时间戳的参考点，因为它为传输端点所知，并且对于所有媒体都有一个共同的定义，不受编码延迟或其他处理的影响。其目的是允许在同一时间采样的所有媒体同步呈现。与实时采样数据不同，传输存储数据的应用程序通常使用从墙上时钟时间派生出的虚拟呈现时间线来决定存储数据中的下一帧或其他每种媒体单元应该何时呈现。在这种情况下，RTP时间戳将反映每个单元的呈现时间。也就是说，每个单元的RTP时间戳将与墙上时钟时间相关联，在这个时间点上，该单元在虚拟呈现时间线上变为当前的。实际的呈现会在稍后的时间发生，具体时间由接收端决定。一个描述实时音频解说预先录制视频的例子，说明了选择采样瞬间作为参考点的重要性。在这种情况下，视频将在本地展示给解说者观看，并且会同时使用RTP进行传输。RTP中传输的视频帧的“采样瞬间”将通过将其时间戳与解说者观看该视频帧时的墙上时钟时间进行对比来确定。包含解说者语音的音频RTP数据包的采样瞬间，将通过参考采样音频时的相同墙上时钟时间来确定。即使音频和视频由不同的主机传输，只要这两个主机的参考时钟通过某种方式（如NTP）进行了同步，这也是可行的。接收器随后可以通过在RTCP SR数据包中使用时间戳对来关联它们的RTP时间戳，从而同步音频和视频数据包的呈现。简单概括：表示当前数据的采样时刻；同一个帧，不同RTP包的时间戳应该相同；当RTP包为视频时候时间戳的基准则为90KH(90000)。RTP包为音频则通常按照音频采样率为时间基准，时间基准通常在RTSP信令SDP中指定；当传输的音视频帧是按照固定周期生成(固定帧率)，则时间戳采用累加的时间，而不是获取系统时间，如视频固定帧率25帧，则时间戳的增量为90000/25=3600，第一帧时间戳采用系统时间或者随机时间，第二帧时间戳则在第一帧的基础上加3600；占用32bit大小。又比如说音频时间戳的计算：

SSRC 32bit : SSRC字段用于识别同步源。这个标识符应当随机选择，目的是确保在同一RTP会话中的不同同步源不会有相同的SSRC标识符。附录A.6中提供了一个生成随机标识符的算法示例。尽管多个源选择相同标识符的概率很低，但所有RTP实现都必须准备好检测并解决冲突。第8节描述了冲突的概率以及一个基于SSRC标识符的唯一性来解决冲突和检测RTP级别转发循环的机制。如果一个源改变了其源传输地址，它也必须选择一个新的SSRC标识符，以避免被误认为是循环源（见第8.2节）。
CSRC list 0~15 items 32bit each : CSRC列表用于识别包含在此数据包中的负载的贡献源。标识符的数量由CC字段给出。如果贡献源超过15个，只能识别15个。CSRC标识符由混音器（参见第7.1节）插入，使用贡献源的SSRC标识符。例如，对于音频数据包，所有混合在一起创建数据包的源的SSRC标识符都会被列出，这样接收端就能正确地指示说话者。

multiplexing RTP Session，多路复用rtp会话：

为了高效的协议处理，正如综合层处理设计原则[10]所描述的，应该尽量减少复用点的数量。在RTP（实时传输协议）中，复用是通过目的传输地址（网络地址和端口号）来实现的，每个RTP会话都有不同的目的地传输地址。例如，在一个由分别编码的音频和视频媒体组成的视频会议中，每种媒介都应该在有自己目的地传输地址的单独RTP会话中传输。应该不在单个RTP会话中携带分开的音频和视频流，并根据负载类型或SSRC字段进行解复用。使用相同的SSRC交错传输不同RTP媒体类型的数据包将引入几个问题：

1、如果两个音频流共享同一个RTP会话和相同的SSRC值，而其中一个流改变了编码方式，从而获得了不同的RTP负载类型，那么就没有通用的方法来识别是哪个流改变了编码。
2、SSRC（同步源标识符）被定义用来识别单一的时间和序列号空间。如果交错传输的多种负载类型具有不同的媒体时钟频率，那么将需要不同的时间空间，并且需要不同的序列号空间来辨别是哪种负载类型遭受了数据包丢失。
3、实时传输控制协议（RTCP）的发送方报告和接收方报告（参见第6.4节）只能描述每个同步源标识符（SSRC）的一个定时和序列号空间，并且不携带有效载荷类型字段。
4、RTP混音器无法将不兼容媒体的交错流合并到一个流中。
5、在一个RTP会话中携带多种媒体会排除以下可能性：根据需要使用不同的网络路径或网络资源分配；如果需要的话，接收媒体的子集，例如，如果视频会超过可用带宽，只接收音频；以及使用不同进程处理不同媒体的接收器实现，而使用分开的RTP会话则允许使用单进程或多进程实现。

为每种媒介使用不同的同步源标识符（SSRC），但将它们发送在同一个实时传输协议（RTP）会话中，将避免前三个问题，但不会解决后两个问题。

另一方面，在同一个实时传输协议（RTP）会话中使用不同的同步源标识符（SSRC）值复用同一媒介的多个相关源是多播会话的常规做法。上述列出的问题不适用：例如，一个RTP混音器可以组合多个音频源，并且相同的处理方式适用于它们所有。在最后两个问题不适用的其他情况下，使用不同的SSRC值复用同一媒介的流也可能是合适的。

Profile-Specific Modifications to the RTP Header 对实时传输协议（RTP）头部的特定配置文件修改：

现有的实时传输协议（RTP）数据包头部被认为已经包含了RTP可能支持的所有应用类别所需的功能集。然而，根据应用层过滤（ALF）设计原则，头部可以通过在配置文件规范中定义的修改或增加来进行定制，同时仍然允许独立于配置文件的监控和记录工具正常工作。

标记位和负载类型字段携带特定配置文件的信息，但它们被分配在固定头部中，因为预计许多应用程序将需要它们，否则可能不得不添加另一个32位字仅用来容纳它们。包含这些字段的字节可以通过配置文件重新定义以适应不同的需求，例如具有更多或更少的标记位。如果有任何标记位，应该将一个放置在字节的最高有效位，因为独立于配置文件的监控器可能能够观察到数据包丢失模式和标记位之间的相关性。
对于特定负载格式（如视频编码）所需的额外信息，应携带在数据包的负载部分。这可能位于负载部分开始处始终存在的头部中，或者可能由数据模式中的一个保留值指示。
如果特定类别的应用程序需要与负载格式无关的额外功能，那么这些应用程序运行的配置文件应该定义额外的固定字段，以便紧跟在现有固定头部的SSRC字段之后。这些应用程序将能够快速且直接地访问这些额外字段，而独立于配置文件的监控器或录像机仍然可以通过仅解释前十二个字节来处理RTP数据包。

如果最终发现所有配置文件都需要额外的功能，那么应该定义一个新版本的RTP，以对固定头部进行永久性的更改。