RTP包是用于在互联网上传输实时音视频，或其他类型时间敏感数据的标准数据包格式。它是多媒体通信领域中的核心组件，尤其在实时流媒体应用（比如：视频会议、在线直播、IP电话、安防监控等）中扮演着至关重要的角色。RTP包由RTP报文头和RTP负载两部分组成，其中，RTP报文头是固定的12个字节，而RTP负载则是可变的，取决于具体的媒体数据。
RTP报文头包含了必要的信息来识别、同步和管理数据包，其格式如下。
Version (V)：占2位，表示RTP协议的版本，当前的标准版本为2。
Padding (P)：占1位，若置位，则表示包尾存在一些填充字节，用于确保下一层协议（比如：UDP）的数据包长度是某些特定值的整数倍。
Extension (X)：占1位，指示是否包含RTP头部扩展。如果有扩展，它们紧跟在标准头部之后。
CSRC Count (CC)：占4位，表示“贡献源”（Contribution Source）标识符（CSRC）的数目，用于标识参与混音的多个源。
Marker (M)：占1位，通常用于标记负载中的重要事件或边界（比如：视频帧的关键帧）。
Payload Type (PT)：占7位，指定负载中携带的媒体数据类型（比如：G711语音、H264视频等）。具体的类型值可通过RFC 3551等文档查询，或者由应用层协商确定。PT值表示的媒体数据类型分为两种：静态类型和动态类型。静态类型的PT值的范围为0-95，对应于常见的音频、视频编码格式，比如：G711语音为PT=0、H264视频为PT=96等。动态类型的PT值的范围为96-127，用于私有或特定应用的编码格式，这些类型通常在会话建立阶段通过SDP或其他信令协议协商确定。
Sequence Number (SN)：占16位，用于标识发送者发出的RTP包的顺序。接收方可以根据序列号检测数据包丢失、重排序等情况，并进行相应的恢复处理。
Timestamp (TS)：占32位，表示媒体数据的采样时间，是实现媒体同步的关键。对于连续媒体，该值通常表示从会话开始以来的采样时间增量。对于离散媒体（比如：静态图像），可能表示绝对时间或相对时间戳。
SSRC (Synchronization Source Identifier)：占32位，全局唯一，标识数据包的发送源。即使在一个会话中有多个同步源（比如：多路视频流），每个源都有自己的SSRC，便于接收方区分并同步不同的媒体流。
CSRC List：如果CC非零，这里将列出CC个32位的CSRC标识符，每个代表一个参与混合的音频源。
RTP报文头扩展用于为标准RTP报文头增加额外的可选字段，以满足特定应用的需求或提供增强的功能。通过使用报文头扩展，可以在不修改基本RTP协议的情况下，为RTP数据包添加定制化的信息，提高协议的灵活性和可扩展性。
RTP报文头扩展包含的具体字段如下。
Extension Profile ID：16位字段，标识使用的扩展类型。该值由IANA维护的RTP Header Extension Registry分配给特定的扩展规范，比如：1对应于One-Byte Header Extensions（RFC 5285），2对应于Two-Byte Header Extensions（RFC 8285）。
Length：16位字段，表示扩展数据（不包括Profile ID和Length字段本身）的字节数，长度必须是4字节的整数倍。
Header Extension Data：包含实际的扩展字段。每个扩展字段由一个或多个32位字组成，其布局和解释取决于所使用的扩展类型和Profile ID。
下面重点介绍一下One-Byte Header Extensions和Two-Byte Header Extensions。
One-Byte Header Extensions：这种扩展格式的每个字段由一个1字节的类型标签（Type）和一个1字节的长度字段（Length）组成，后面跟着实际的值（Value）。每个字段占用至少4字节，并且可以连续放置多个字段。
Two-Byte Header Extensions：这种扩展格式适用于需要更多类型的扩展字段。每个字段由一个2字节的类型标签（Type）和一个2字节的长度字段（Length）组成，后面跟着实际的值（Value）。每个字段占用至少6字节，同样可以连续放置多个字段。
需要特别注意的是：由于报文头扩展增加了RTP包的大小，可能会影响MTU的计算和分片处理。应合理选择和配置扩展字段，避免过度增大包尺寸导致传输效率降低。
RTP负载是紧跟在RTP报文头之后的部分，它承载着实际的实时媒体数据，比如：视频帧、音频帧等。RTP负载的结构、内容和格式，直接与RTP报文头中的负载类型（Payload Type，PT）字段所指定的媒体编码类型密切相关。下面，介绍一些典型的负载格式。
视频：视频负载通常包含一个或多个压缩编码的视频帧。一个帧可能由多个NAL单元组成。比如：H.264编码中，每个NAL单元前通常有一个起始码（0x000001或0x00000001），用于在传输过程中定位帧的边界。帧的内容可能包括I帧（关键帧）、P帧（预测帧）或B帧（双向预测帧），以及相应的编码参数。
音频：对于音频编码，负载通常包含一串音频采样。每个采样可能是一个或多个字节，具体取决于编码算法（比如：PCM、ADPCM、AAC等）。采样可能按照单声道、立体声或多声道排列，并且可能需要按照特定的字节顺序进行打包。
文本：可能包含文本消息或聊天记录，按照特定字符编码（如UTF-8）进行序列化。
在某些情况下，RTP负载可能还需要进一步封装，以适应特定的传输或处理需求。某些负载可能包含特定于编码的头部信息，比如：H.264 NAL单元前的起始码、AAC音频的ADTS头部等。对于大型媒体数据单元（比如：大的视频帧），可能需要按照RFC 2198进行分片，每个RTP包携带一个分片，并使用特定的PT值和头部字段来标识分片顺序和重组信息。
接收端在接收到RTP包后，首先根据RTP头部的Payload Type字段确定负载的媒体类型和编码格式。然后，按照对应的负载格式解析数据，提取出视频帧、音频帧等媒体数据。最后，结合时间戳、序列号等信息进行同步、错误检测和恢复操作。如果RTP包使用了头部扩展或负载封装，还需相应地处理这些附加信息。
RTP包的结构简单而高效，能够满足实时音视频传输的需求。通过详细分析RTP报文的各个字段，我们可以更好地理解RTP的工作原理，以及如何优化基于RTP的流媒体应用。