漫游RTP/RTCP协议(卷一)

最新推荐文章于 2024-09-10 23:23:23 发布

大朝书房

最新推荐文章于 2024-09-10 23:23:23 发布

阅读量717

点赞数

分类专栏： WebRTC技术详解文章标签： RTP/RTCP WebRTC

本文链接：https://blog.csdn.net/lenyusun/article/details/107179425

版权

WebRTC技术详解专栏收录该内容

6 篇文章 7 订阅

订阅专栏

本来是想一篇文章介绍完的，写着写着发现太多了，所以就分割成两篇文章，请各位鉴赏，有问题留言，谢谢。

一、概念

1.1 RTP/RTCP是什么

RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为 RFC3550。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。

RTCP全名是Real-time Transport Control Protocol（实时传输控制协议），是RTP的配套协议，主要用于音视频同步，流量控制，拥塞控制，保证流数据的可靠性。

1.2 RTP的应用环境

RTP用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。

A、简单的多播音频会议

语音通信通过一个多播地址和一对端口来实现。一个用于音频数据（RTP），另一个用于控制包（RTCP）。

B、音频和视频会议，比如WebRTC

如果在一次会议中同时使用了音频和视频会议，这两种媒体将分别在不同的RTP会话中传送，每一个会话使用不同的传输地址（IP地址＋端口）。如果一个用户同时使用了两个会话，则每个会话对应的RTCP包都使用规范化名字CNAME（Canonical Name）。与会者可以根据RTCP包中的CNAME来获取相关联的音频和视频，然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。

二、RTP详解

2.1 RTP的协议层次

图 1 流媒体体系结构

从上图中可以看出，RTP/RTCP被划分在传输层，它建立在UDP/TCP上。RTP主要是基于UDP协议传输，当然也可以基于TCP，但由于TCP协议的可靠性保证，如果应用于流媒体数据包传输会比较重，但可以作为一个备选方案，如果在某个特殊局域网内，在UDP不通的情况下，可以走TCP。

图二、基于UDP协议的RTP分组示意图

2.2. RTP Header

RTP 数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个 RTP 数据报都由头部（Header）和有效载荷（Payload）两个部分组成，其中头部前 12 个字节 的含义是固定的，而负载则可以是音频或者视频数据。RTP 数据报的头部格式如图：

图三 RTP的头部格式

RTP Header解析

字段	位宽	含义
V	2	RTP 协议的版本号，当前协议版本号为 2。
P	1	填充标志，如果 P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
X	1	扩展标志，如果 X=1，则在 RTP 报头后跟有一个扩展报头。
CC	4	CSRC 计数器，指示 CSRC 标识符的个数。
M	1	标记，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。
PT	7	有效载荷类型，用于说明 RTP 报文中有效载荷的类型，如 GSM 音频、JPEM 图像等。
sequence number	16	用于标识发送者所发送的 RTP 报文的序列号，每发送一个报文，序列号增 1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。
timestamp	32	时戳反映了该 RTP 报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
SSRC	32	用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的 SSRC。
CSRC	32	每个 CSRC 标识符占 32 位，可以有 0～15 个。每个 CSRC 标识了包含在该 RTP 报文有效载荷中的所有特约信源。

RTP Header头结构定义


   /*
    * RTP data header
    */
   typedef struct {
       unsigned int version:2;   /* protocol version */
       unsigned int p:1;         /* padding flag */
       unsigned int x:1;         /* header extension flag */
       unsigned int cc:4;        /* CSRC count */
       unsigned int m:1;         /* marker bit */
       unsigned int pt:7;        /* payload type */
       unsigned int seq:16;      /* sequence number */
       u_int32 ts;               /* timestamp */
       u_int32 ssrc;             /* synchronization source */
       u_int32 csrc[1];          /* optional CSRC list */
   } rtp_hdr_t;

RTP Header码流举例：

80 e0 00 1e 00 00 d2 f0 00 00 00 00 41 9b 6b 49 €?....??....A?kI

e1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P.

cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|?

f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q??

cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ????

头解析如下：

80 ===> 10_0_0_0000 ====> V_P_X_CC

e0 ===> 1_1110000 ====> M_PT

00 1e    ===>    SequenceNum

00 00 d2 f0 ===>     Timestamp

00 00 00 00 ===>     SSRC

2.3 RTP PayLoad

根据RTP Header中PT值，我们可以判断PayLoad是什么格式，具体可以看 Real-Time Transport Protocol (RTP) Parameters。本文以最常用的H.264编码格式来介绍Payload Format，具体协议请参考 RFC6184.

H264 PayLoad是通过Network Abstraction Layer Units (NALUs)来封装的，定义了三种不同payload打包格式，在PayLoad的第一个字节里type有定义，具体看下面格式。

图四 NALU Type字段说明

字段	位宽	含义
F	1	0代表NAL单元类型字段和其内容可能存在bit级别的错误或其他语义错误部分。1代表包含bit不存在bit级别的错误或其他语义错误部分
NRI	2	此帧数据是否影响参考帧完整性，取值从00 ~ 11重要性依次递增，00：不用来为I帧来重构参考帧 11：表示 I帧，见图五
Type	5	打包类型，见图六