漫游RTP/RTCP协议(卷一)

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

一、概念

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
打包类型,见图六
说明:
    
图五 NRI说明表
图六 NAL单元类型说明表
 

2.3.1 打包类型

1、Single NAL Unit Packet: 该负载类型只包含一个NAL单元。NAL单元类型字段值范围为对应上图1~23, 具体格式如下:
图七  RTP payload format for single NAL unit packet
       

单NAL单元报文定义: 只包含一个NAL单元。也就是说聚合报文和分片报文都不能放在单NAL单元报文中。单NAL单元报文构造的时候,必须和RTP sequence的顺序是一致的

2、 Aggregation Packet: 该类型包含多个NAL单元到一个RTP负载中, NAL单元类型字段值范围为对应图六的24~27,具体格式如下:
图八  RTP payload format for aggregation packets
 
3、 Fragementation unit: 一个NAL单元的包大小超过1MTU,那么一个NAL单元分片到多个RTP报文中。有两个版本: FUa, FUb, NAL单元类型字段值分别对应图六的28,29, 具体格式如下:
图九、 RTP payload format for FU-B
图十、FU indicator
图十一  FU header
说明:
FU indicator就不说了,此处说一下 FU header,具体说明如下:
 
字段
位宽
含义
S
1
0:起始包 1:分包
E
1
0:分包 1:终止包
R
1
缺省预留
Type
5
打包类型,见图六
当然还有另外一种打包类型FUb,这里就不讲了,大家有兴趣的可以去参考RFC6428协议。
 

三、参考

[1]      RFC文档:RFC3550对应RTP/RTCP,RTC6184对应Playload format for h264 

[2]      http://www.faqs.org/rfcs/,上面有全面的英文RFC文档

[3]      http://www.cnpaf.net/,有不少协议分析文档,也有中文RFC文档,但质量不是特别高。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值