RTP协议的报文头格式结构
来源:互联网 发布:徐贲 知乎 编辑:程序博客网 时间:2024/05/19 11:49
RTP头格式如图2所示:
开始12个八进制出现在每个RTP包中,而CSRC标识列表仅出现在混合器插入时。各段含义如下:
①版本(V)
2位,标识RTP版本。
②填充标识(P)
1位,如设置填充位,在包尾将包含附加填充字,它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需要固定大小的填充字,或为在底层协议数据单元中携带几个RTP包。
③扩展(X)
1位,如设置扩展位,固定头后跟一个头扩展。
④CSRC计数(CC)
4位,CSRC计数包括紧接在固定头后CSRC标识符个数。
⑤标记(M)
1位,标记解释由设置定义,目的在于允许重要事件在包流中标记出来。设置可定义其他标示位,或通过改变位数量来指定没有标记位。
⑥载荷类型(PT)
7位,记录后面资料使用哪种 Codec , receiver 端找出相应的 decoder 解碼出來。
常用 types:
Payload Type
Codec
0
PCM μ -Law
8
PCM-A Law
9
G..722 audio codec
4
G..723 audio codec
15
G..728 audio codec
18
G..729 audio codec
34
G..763 audio codec
31
G..761 audio codec
⑦系列号
16位,系列号随每个RTP数据包而增加1,由接收者用来探测包损失。系列号初值是随机的,使对加密的文本攻击更加困难。
⑧时标
32位,时标反映RTP数据包中第一个八进制数的采样时刻,采样时刻必须从单调、线性增加的时钟导出,以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。
由上图可知,如果只有系列号,并不能完整按照顺序的将data播放出来,因为如果data中间有一段是没有资料的,只有系列号的话会造成错误,需搭配上让它知道在哪个时间将data正确播放出来,如此我们才能播放出正确无误的信息。
⑨SSRC
32位,SSRC段标识同步源。此标识不是随机选择的,目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低,所有RTP实现都必须探测并解决冲突。如源改变源传输地址,也必须选择一个新SSRC标识以避免插入成环行源。
⑩CSRC列表
0到15项,每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源,也仅标识15个。CSRC标识由混合器插入,采用作用源的SSRC标识。//=====================================
RTP头:
前12个字节在每一个RTP packet中都存在,而一系列的CSRC标记只有存在Mixer时才有。
version (V): 2 bits
标明RTP版本号。协议初始版本为0,RFC3550中规定的版本号为2。
padding (P): 1 bit
如果该位被设置,则在该packet末尾包含了额外的附加信息,附加信息的最后一个字节表示额外附加信息的长度(包含该字节本身)。该字段之所以存在是因为一些加密机制需要固定长度的数据块,或者为了在一个底层协议数据单元中传输多个RTP packets。
extension (X): 1 bit
如果该位被设置,则在固定的头部后存在一个扩展头部,格式定义在RFC3550 5.3.1节。
CSRC count (CC): 4 bits
在固定头部后存在多少个CSRC标记。
marker (M): 1 bit
该位的功能依赖于profile的定义。profile可以改变该位的长度,但是要保持marker和payload type总长度不变(一共是8 bit)。
payload type (PT): 7 bits
标记着RTP packet所携带信息的类型,标准类型列出在RFC3551中。如果接收方不能识别该类型,必须忽略该packet。
sequence number: 16 bits
序列号,每个RTP packet发送后该序列号加1,接收方可以根据该序列号重新排列数据包顺序。
timestamp: 32 bits
时间戳。反映RTP packet所携带信息包中第一个字节的采样时间。
SSRC: 32 bits
标识数据源。在一个RTP Session其间每个数据流都应该有一个不同的SSRC。
CSRC list: 0 to 15 items, 32 bits each
标识贡献的数据源。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流,在这里就列出原来每个声道的SSRC。
前12个字节在每一个RTP packet中都存在,而一系列的CSRC标记只有存在Mixer时才有。
version (V): 2 bits
标明RTP版本号。协议初始版本为0,RFC3550中规定的版本号为2。
padding (P): 1 bit
如果该位被设置,则在该packet末尾包含了额外的附加信息,附加信息的最后一个字节表示额外附加信息的长度(包含该字节本身)。该字段之所以存在是因为一些加密机制需要固定长度的数据块,或者为了在一个底层协议数据单元中传输多个RTP packets。
extension (X): 1 bit
如果该位被设置,则在固定的头部后存在一个扩展头部,格式定义在RFC3550 5.3.1节。
CSRC count (CC): 4 bits
在固定头部后存在多少个CSRC标记。
marker (M): 1 bit
该位的功能依赖于profile的定义。profile可以改变该位的长度,但是要保持marker和payload type总长度不变(一共是8 bit)。
payload type (PT): 7 bits
标记着RTP packet所携带信息的类型,标准类型列出在RFC3551中。如果接收方不能识别该类型,必须忽略该packet。
sequence number: 16 bits
序列号,每个RTP packet发送后该序列号加1,接收方可以根据该序列号重新排列数据包顺序。
timestamp: 32 bits
时间戳。反映RTP packet所携带信息包中第一个字节的采样时间。
SSRC: 32 bits
标识数据源。在一个RTP Session其间每个数据流都应该有一个不同的SSRC。
CSRC list: 0 to 15 items, 32 bits each
标识贡献的数据源。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流,在这里就列出原来每个声道的SSRC。
0 0
- RTP协议的报文头格式结构
- RTP协议的报文头格式结构
- RTP协议的报文头格式结构
- RTP协议的报文头格式结构
- RTP协议简介 & RTP报文格式
- RTP报文格式
- RTCP RTP报文结构
- ARP协议的报文格式
- ARP协议的报文格式
- ARP协议的报文格式
- PPP协议的报文格式
- ARP协议的报文格式
- ARP协议的报文格式
- ARP协议的报文格式
- ARP协议的报文格式
- HTTP协议的报文结构
- HTTP协议的报文结构
- Rtp/Rtcp协议头的定义
- RTSP信令的交互
- linux C串口常规设置参考
- java复制文件的4种方式
- 学习笔记之——实现Android控件之带有分割线的GridView格
- Mysql主从配置,实现读写分离
- RTP协议的报文头格式结构
- 一段Golang代码引发的思考
- unity3d 22
- unity手动静态批处理
- 通过反射获取实体集合属性值并赋值给另一个实体集合
- C++ Primer 5th Edition 笔记
- 如何科学的操作git ignore
- There is no Action mapped for namespace /base and action name
- java中Date的格式注意事项