- 浏览: 177061 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
hety163:
socket并不一定是长连接吧。。。
【转】关于socket长连接的心跳包 -
u013490012:
楼主,这个加阴影不是很清楚.我按照文章介绍的,程序出错啊
Android自定义Shape 加上阴影shadow之方法 -
cz2861856:
很好的文章!
Android自定义Shape 加上阴影shadow之方法 -
ezfantasy:
好文,转走了
Android 使用xliff 格式化字符串 -
songfantasy:
ericbaner 写道Android官方blog:http: ...
Android HTTP Clients使用选择介绍
RTP
控制协议
RTCP
RTP
控制协议
(RTCP)
向会议中所有成员周期性发送控制包
,
利用与数据包相同的传输机制
.
底层协议必须提供数据包和控制包的复用
,
例如用不同的
UDP
端口
.RTCP
执行四个功能
.
-
基本功能是提供数据传输质量的反馈
.
这是
RTP
作为一种传输协议的主要作用
,
它与其他协议的流量和阻塞控制相关
.
反馈可能对自适应编码有直接作用
,
但是
IP
组播的实验表明它对于从接收机得到反馈信息以诊断传输故障也有决定性作用
.
向所有成员发送接收反馈可以使
"
观察员
"
评估这些问题是局部的还是全局的
.
利用类似多点广播的传输机制
,
可以使某些实体
,
诸如没有加入会议的网络网络业务观察员
,
接收到反馈信息并作为第三类监视员来诊断网络故障
.
反馈功能通过
RTCP
发射机和接收机报告实现
.
- RTCP
为每个
RTP
源传输一个固定的识别符
,
称为标称名或
CNAME.
由于当发生冲突或程序重启时
SSRC
可能改变
,
接收机要用
CNAME
来跟踪每个成员
.
接收机还要用
CNAME
来关联一系列相关
RTP
会话期中来自同一个成员的多个数据流
,
例如同步语音和图象
.
-
头两个功能要求所有成员都发送
RTCP
包
,
因此必须控制速率以使
RTP
成员数可以逐级增长
.
通过让每个成员向所有成员发送控制包
,
各个成员都可以独立地观察会议中所有成员的数目
.
此数目可以用来估计发包数率
.
-
第四个可选的功能是传输最少的会议控制信息
,
例如在用户接口中显示的成员识别
.
这最可能在
"
松散控制
"
的会议中起作用
,
在
"
松散控制
"
会议里
,
成员可以不经过资格控制和参数协商而加入或退出会议
.RTCP
作为一个延伸到所有成员的方便通路
,
必须要支持具体应用所需的所有控制信息通信
.
-
在
RTP
用于
IP
多点广播时
,
功能
1-3
是强制的
,
在所有情况下都推荐使用
.
建议
RTP
应用开发商避免使用只能用于单向广播而不能递增到多用户的方法
.
RTCP
包格式
这部分定义了几个
RTCP
包类型
,
可以传送不同的控制信息
:
- SR:
发射机报告
,
描述作为活跃发射机成员的发送和接收统计数字
;
- RR:
接收机报告
,
描述非活跃发射机成员的接收统计数字
;
在本文中详细介绍
SR
和
RR.
每个
RTCP
包的开始部分是与
RTP
数据包相类似的固定部分
,
随后是一块结构化单元
,
它随负载类型不同长度发生变化
,
但是总以
32
比特终止
.
对齐要求和长度域使
RTCP
包可
"
堆栈
",
既可以将多个
RTCP
包形成一个复合
RTCP
包
,
在底层协议
(
如
UDP)
中
,
通常都是将复合包作为一个包传输的
.
复合包中的每个
RTCP
单包可以单独处理
,
而无需考虑包复合的顺序
.
然而
,
为了实现某些协议功能
,
添加以下限制
:
-
接收统计数字
(SR
或
RR),
经常作为带宽限制值
,
尽可能达到统计数字的最大分辨率
,
因此每个周期发送的
RTCP
包必须包含一个报告包
.
-
必须限制首次在复合包中出现的包类型数目
,
以增加在第一个字中常数比特的数目
,
这样可以增加
RTCP
包的有效性
,
以区分误传的
RTP
包和其他无关包
.
因此
,
所有
RTCP
包必须在至少包含两个单包的复合包中传输
,
具有以下推荐格式
:
-
加密前缀
:
当且仅当复合包被加密时
,
对每个
RTCP
复合包加
32
比特的前缀
.
- SR
或
RR:
复合包中的第一个
RTCP
包必须是一个报告包
.
即使没有数据发送和接收
,
此时发送空的
RR
包
,
或者复合包中其他的唯一包是
BYE
包
,
也必须发送报告包
.
-
附加的
RR:
若被报告的接收统计源数目超过
SR/RR
包中最大允许的
31
个
,
附加的
RR
必须跟在最初的报告包后面
.
RTCP
发送机制
RTCP
包发送机制
:
在两次
RTCP
报文之间
,
若端点没有发出任何
RTP
报文
,
则端点此次发送
RR(
接收报文
),
否则
,
端点发送
SR(
发送报文
),RTCP
包每秒发送一次
.
发射机和接收机报告
RTP
接收机利用
RTCP
报告包提供接收质量反馈
,
根据接收机是否同时还是发射机
RTCP
包采取两种不同的形式
.
发射机报告
(SR)
和接收机报告
(RR)
格式中唯一的不同
,
包括包类型码
,
在于发射机报告包括
20
字节活跃发射机专有的发射机信息部分
.
SR
包和
RR
包都包括零到多个接收报告块
,
针对该接收机发出上一个报告块后接收到
RTP
包的起始同步源
,
每个源一个块
.
在
CSRC
列表中陈列的有贡献源不发送报告块
.
每个接收报告块提供从此块中指示的特定源接收到数据的统计数字
.
由于在
SR/RR
包中最多允许
31
接收报告块
,
可以在最初的
SR
或
RR
包之后堆栈附加的
RR
包
,
包含在上一个报告以来的间隔内收听到的所有源的接收报告
.
以下部分定义了两种报告的格式
.
SR:
发射机报告
RTCP
包
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=SR=200 |
长度
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
发送者的
SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP
时戳
,
高字节
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP
时戳
,
低字节
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP
时戳
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
发送的报文数
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
发送的字节数
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (
第一个源的
SSRC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
丢包率
|
累计包丢失数
|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
接收到的扩展的最高序列号
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
到达间隔抖动
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
上一
SR
报文
(LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
自上一
SR
的时间
(DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (
第二个源的
SSRC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
特定协议扩展
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
发射机报告包由
3
部分组成
,
若定义
,
可能跟随第
4
个面向协议的扩展部分
.
第一部分
,8
字节长
.
该域有以下意义
:
版本
(V):2
比特
RTP
版本识别符
,
在
RTCP
包内的意义与
RTP
包中的相同
.
此协议中定义的版本号为
2.
填料
(P):1
比特
若设置填料比特
,
该
RTCP
包在末端包含一些附加填料比特
,
并不是控制信息的基本部分
.
填料的最后一个比特统计了多少个字节必须被忽略
.
某些有固定块大小的加密算法可能需要填料比特
.
在复合
RTCP
包中
,
复合包作为一个整体加密
,
填料比特只能加在最后一个单包的后面
.
接收报告块计数
(RC):5
比特
该包中所含接收报告块的数目
.
零值有效
.
包类型
(PT):8
比特
包含常数
200,
用以识别这个为
RTCP SR
包
.
长度
:16
比特
以
32
比特字为单位
,
该
RTCP
包的长度减一
,
包括头和任何填料
.(
偏移量
1
保证零值有效
,
避免了在扫描
RTCP
包长度时可能发生的无限循环
,
同时以
32
比特为单位避免了对以
4
为倍数的有效性检测
.)
SSRC:32
比特
SR
包发起者的同步源标识符
.
第二部分
,
发射机信息
,20
比特长
,
在每个发射机报告包中出现
.
它概括了从此发射机发出的数据传输情况
.
此域有以下意义
:
NTP
时间标志
:64
比特
指示了此报告发送时的壁钟时刻
,
它可以与从其它接收机返回的接收报告块中的时间标志结合起来
,
测量到这些接收机的环路时沿
.
接收机必须期望此时间标志的准确度远低于
NTP
时间标志的分辨率
.
测量的不确定度不可知
,
因此也无需指示
.
某个发射机
,
能够跟踪逝去时间但是无法跟踪壁钟时间
,
可以用加入会议后的逝去时间代替
.
假定该值小于
68
年
,
则最高比特为零
.
允许用抽样时钟估计逝去壁钟时间
.
无法用壁钟时间或逝去时间的可以设置此项为零
.
RTP
时间标志
:32
比特
与以上的
NTP
时间标志对应同一时刻
,
但是与数据包中的
RTP
时间标志具有相同的单位和偏移量
.
这个一致性可以用来让
NTP
时间标志已经同步的源间进行媒体内
/
间同步
,
还可以让与媒体无关的接收机估计标称
RTP
时钟频率
.
注意在大多数情况下此时间标志不等于任何临近的
RTP
包中的时间标志
.
然而
,
通过
"RTP
时间标志计数器
"
和
"
由在抽样点上周期性检测壁钟时间得到的实际时间
"
两者之间的关系
,
可以通过相应的
NTP
时间标志计算得到此
RTP
时间标志
.
发送的报文数
:32
比特
从开始传输到此
SR
包产生时该发射机发送的
RTP
数据包总数
.
若发射机改变
SSRC
识别符
,
该计数器重设
.
发送的字节文数
:32
比特
从开始传输到此
SR
包产生时该发射机在
RTP
数据包发送的字节总数
(
不包括头和填料
).
若发射机改变
SSRC
识别符
,
该计数器重设
.
此域可以用来估计平均负载类型数据速率
.
第三部分零到多个接收报告块
,
块数等于从上一个报告以来该发射机收听到的其它源的数目
.
每个接收报告块传输关于从某个同步源来的数据包的接收统计信息
.
若某个源因冲突而改变其
SSRC
识别符
,
接收机并不延续统计数字
.
这些统计数字是
:
SSRC_n(
源识别符
):32
比特
在此接收报告块中信息所属源的
SSRC
识别符
.
丢包率
:8
比特
自从前一
SR
包或
RR
包发射以来
,
从
SSRC_n
传来的
RTP
数据包的损失比例
,
以固定点小数的形式表示
,
小数点在此域的左侧
,
等于将损失比例乘
256
后取整数部分
.
该值定义为损失包数被期望接收的包数除
,
在下一段中定义
.
若由于复制而导致包损为负值
,
损失比例值设为零
.
注意在收到上一个包后
,
接收机无法告之以后的包是否丢失
,
若在上一个接收报告间隔内从某个源发出的所有数据包都丢失
,
那么将不为此源发送接收报告块
.
累计包丢失数
:24
比特
从开始接收到现在
,
从源
SSRC_n
发到本源的
RTP
数据包的丢包总数
.
该值定义为期望接收的包数减去实际接收的包数
,
接收的包括复制的或迟到的
.
由于迟到的包不算作损失
,
在发生复制时包损可能为负值
.
期望接收的包数定义为扩展的上一接收序号
(
随后定义
)
减去最初接收序号
.
接收到的扩展的最高序列号
:32
比特
低
16
比特包含从源
SSRC_n
来的最高接收序列号
,
高
16
比特用相应的序列号周期计数器扩展该序列号
.
注意在同一会议中的不同接收机
,
若启动时间明显不同
,
将产生不同的扩展项
.
到达间隔抖动
:32
比特
RTP
数据包到达时刻统计方差的估计值
,
以时间标志为单位测量
,
用无符号整数表达
.
到达时刻抖动
J
定义为一对包中接收机相对发射机的时间跨度差值的平均偏差
(
平滑后的绝对值
).
如以下等式所示
,
该值等于两个包相对传输时间的差值
,
相对传输时间是指包的
RTP
时间标志和到达时刻接收机时钟
,
以同一单位的差值
.
若
Si
是包
i
的
RTP
时间标志
,Ri
是包
i
以
RTP
时间标志单位的到达时刻值
,
对于两个包
i
和
j,D
可以表达为
D(i,j)=(Rj-Sj)-(Ri-Si);
到达时刻抖动可以在收到从源
SSRC_n
来的每个数据包
i
后连续计算
,
利用该包和前一包
i-1
的偏差
D(
按到达顺序
,
而非序号顺序
),
根据公式
J=J+(|D(i-1,i)|-J)/16
计算
.
无论何时发送接收报告
,
都用当前的
J
值
.
此处描述的抖动计算允许与协议独立的监视器对来自不同实现的报告进行有效的解释
.
上一
SR
报文
(LSR):32
比特
接收到的来自源
SSRC_n
的最新
RTCP
发射机报告
(SR)
的
64
位
NTP
时间标志的中间
32
位
.
若还没有接收到
SR,
该域值为零
.
自上一
SR
的时间
(DLSR):32
比特
是从收到来自
SSRC_n
的
SR
包到发送此接收报告块之间的延时
,
以
1/65536
秒为单位
.
若还未收到来自
SSRC_n
的
SR
包
,
该域值为零
.
假设
SSRC_r
为发出此接收报告块的接收机
.
源
SSRC_n
可以通过记录收到此接收报告块的时刻
A
来计算到
SSRC_r
的环路传输时延
.
可以利用最新的
SR
时间标志
(LSR)
域计算整个环路时间
A-LSR,
然后减去此
DLSR
域得到环路传播时延
.
可以用此来近似测量到一族接收机的距离
,
尽管有些连接可能有非常不对称的时延
.
接收机报告
RTCP
包
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=RR=201 |
长度
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
报文发送者的
SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (
第一个源的
SSRC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
丢包率
|
累计包丢失数
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
接收到的扩展的最高序列号
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
到达间隔抖动
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
上一
SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
自上一
SR
的时间
(DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (
第二个源的
SSRC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
特定协议扩展
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
接收机报告包
(RR)
与发射机报告包基本相同
,
除了包类型域包含常数
201
和没有发射机信息的
5
个字
(NTP
和
RTP
时间标志和发射机包和字节计数
).
余下区域与
SR
包意义相同
.
若没有发送和接收据报告
,
在
RTCP
复合包头部加入空的
RR
包
(RC=0).
分析发射机和接收机报告
接收质量反馈不仅对发射机有用
,
而且对于其它接收机和第三派监视器也有作用
.
发射机可以基于反馈修正发送信息量
;
接收机可以判断问题是本地的
,
区域内的还是全球的
;
网络管理者可以利用与协议无关的监视器
(
只接收
RTCP
包但是不接收相应的
RTP
包
)
去评估多点传送网络的性能
.
在发射机信息和接收机报告块中都连续统计丢包数
,
因此可以计算任何两个报告块中的差别
,
在短时间和长时间内都可以进行测算
,
最近收到的两个包之间差值可以评估当前传输质量
.
包中有
NTP
时间标志
,
可以用两个报告间隔的差值计算传输速率
.
由于此时间间隔与数据编码始终速率独立
,
可以实现与编码及协议独立的质量监视
.
从发射机信息中
,
第三派监视器可以在一个时间间隔内计算平均负载数据速率和平均发包速率
,
而无需考虑数据接收
.
两个值的比就是平均负载大小
.
若能假定包损与包的大小无关
,
那么某个特定接收机收到的包数乘以平均负载大小
(
或相应的包大小
)
就得出接收机可得到的外在吞吐量
.
除了累计计数允许利用报告间差值进行长期包损测量外
,
单个报告的包损比例域提供一个短时测量数据
.
当会议规模递增到无法为所有接收机保存接收状态信息
,
或者报告间隔变得足够长以至于从一个特定接收机只能收到一个报告时
,
短时测量数据变得更重要
.
到达间隔抖动域提供另一个有关网络阻塞的短时测量量
.
包损追踪长期阻塞
,
抖动测量追踪短时阻塞
.
抖动测量可以在导致包损前指示阻塞
.
由于到达间隔抖动
域仅仅是发送报告时刻抖动的一个快照
,
因此需要在一个网络内在一段时间内分析来自某个接收机的报告
,
或者分析来自多个接收机的报告
.
负载类型
注意并非所有
RTP
所用的编码方式都分配了静态负载类型号
.
可以建立在
96-127
间的负载类型值与编码方式间的动态匹配
.
可用的负载类型空间比较小
.
仅在满足以下条件时分配新的静态负载类型
:
-
很多因特网社团都对此编码感兴趣
;
-
与现存编码方式比较有好处和
/
或要求与现有广泛使用会议及多媒体系统互通
;
-
描述足以建立一个译码器
.
下表
为
RTP
数据头的
PT
域定义了静态负载类型
.
此外
,96-127
之间的负载类型值可以通过会议控制协议动态定义
.
例如
,
一个会话期可以在一个给定会话期内
,
指定负载类型
96
指示
PCMU
编码
,8,000
抽样率
,
双通道
.
负载类型值表的
"
保留
"
项用以使
RTP
和
RTCP
包可以被可靠识别
.
一个
RTP
源在任何给定时刻
,
只能发射一个
RTP
负载类型
;
不允许在一个
RTP
对话期中交织多个
RTP
负载类型
,
但是可以并行存在多个
RTP
对话期以发送多媒体
.
此协议中定义的负载类型传输或者语音
,
或者图象
,
但是不允许两者同传
.
PT
编码
语音
/
图象
时钟速率
通道
(A/V) (Hz) (
语音
)
0 PCMU A 8000 1
8 PCMA A 8000 1
9 G722 A 8000 1
4 G723 A 8000 1
15 G728 A 8000 1
18 G729 A 8000 1
31 H261 V 90000
34 H263 V 90000
96-127
动态
注意
:
负载类型
1-7,10-14,16-30
保留
.
端口分配
同
RTP
协议定义所述
,RTP
数据在偶数
UDP
端口传输
,
相应的
RTCP
包在下一个高
(
奇
)
端口传输
.
依据此协议的应用程序可以用任意这样的
UDP
端口对
.
例如
,
可以用对话期管理程序随机分配
.
由于在同一台主机上可以运行多个利用本协议的应用程序
,
而有些操作系统不允许同一个
UDP
端口与不同的多点传送地址结合进行多重处理
,
因此不能要求固定的端口对
.
端口对在
5000
以上选择
,
以适应
UNIX
操作系统端口号分配惯例
:1024
以下用来进行特权处理
,1024
到
5000
之间被操作系统动态分配
.
发表评论
-
smart shuffle or shuffle play
2007-09-19 23:55 1031smart shuffle (from: http://e-w ... -
基于XML的可升级矢量图像(SVG)浅析
2007-09-20 00:48 977基于XML的可升级矢 ... -
SVG矢量图技术
2007-09-20 00:55 1164一、SVG 概述: ... -
工业标准的矢量图像格式----SVG
2007-09-20 00:58 984工业标准的矢量图像格式----SVG 什么是SVG ... -
H.264中的NAL技术
2009-03-02 21:11 938NAL技术 1.NAL概述 NAL全称Network Ab ... -
纵览视频编码标准H.264/AVC
2009-03-02 21:21 814Video.com.cn(视频网)2006-09-25 15: ... -
RTP协议
2009-03-02 21:49 881RTP 协议 RTP 协议 实时传输协 ... -
H.264视频编码
2009-03-02 21:56 953视频如果不压制,容量 ...
相关推荐
**RTP协议** RTP的设计目标是为了解决多媒体数据在网络中的实时传输问题。它定义了数据包的格式,包含了时间戳和序列号,使得接收端可以准确地恢复原始流并同步多路传输的数据。RTP不保证数据包的可靠传输,而是依赖...
- 版本号(Version):2位,用于标识RTP协议版本,当前为2。 - 填充标志(Padding):1位,表示数据是否包含填充字节。 - 扩展标志(Extension):1位,表示是否有扩展头部。 - CSRC计数(CSRC Count):4位,...
- **RTCP控制协议**:主要关注于监控数据传输的质量,通过周期性地发送控制报文来收集和报告关于数据传输的信息,包括丢包率、抖动等指标。 #### 五、总结 RTP和RTCP协议为实时多媒体应用提供了一套完整的解决方案...
**RTP协议详解** RTP是一种面向数据包的传输协议,设计目标是为了解决实时数据(如音频和视频)在网络中的传输问题。它的核心特点包括: 1. **时间戳和序列号**:每个RTP数据包都包含一个时间戳和序列号,用于接收...
RTP协议的核心功能包括: 1. 数据包时间戳:每个RTP数据包包含一个时间戳,用于在接收端恢复数据流的原始顺序和同步。 2. 序列号:序列号确保数据包的正确接收和丢失检测,因为它们可以按照发送顺序进行排序。 3. ...
英文版、中文版RTP/RTCP协议文档(rfc1889.pdf、RFC1889协议中文概要.ppt)。 RTP(Real-time Transport Protocol)协议详细说明了在互联网上传递音频和视频的标准数据包格式。它是由IETF的多媒体传输工作小组1996...
RTP协议主要负责实时数据的传输,它设计的核心目标是确保数据的低延迟和有序到达。RTP数据包包括一个固定头部和可选的扩展部分。头部包含了时间戳、序列号、源标识符等关键信息,用于同步接收端的数据流,检测丢失和...
RTCP协议是RTP协议的伴随协议,用于监控和控制RTP传输的服务质量。RTCP协议提供了反馈机制,允许接收端反馈发送端关于数据传输的信息,以便发送端可以调整传输速率和质量。RTCP协议还提供了会话管理和成员管理的功能...
RTSP(Real Time Streaming Protocol,实时流传输协议)、RTP(Real-time Transport Protocol,实时传输协议)、RTCP(Real-time Transport Control Protocol,实时传输控制协议)以及RTMP(Real-Time Messaging ...
1. 提供数据传输质量的反馈:这是RTP协议的关键特性,通过收集和发送接收反馈,帮助实现流量和阻塞控制,同时也用于自适应编码和故障诊断。通过向所有成员广播接收状态,可以判断问题的局部性或全局性。发射机和接收...
RTP协议的主要目标是为实时数据提供端到端的传输服务,包括低延迟、顺序传送和时间戳,以确保数据的正确播放。RTP不保证数据传输的可靠性,而是依赖于更低层的传输协议(如UDP)来处理丢包和错误。RTP头部包含序列号...
### 基于RTP/RTCP协议视频数据网络传输的实现 #### 重要知识点解析 ##### RTP/RTCP协议概述 RTP (Real-time Transport Protocol) 和 RTCP (Real-time Transport Control Protocol) 是一对旨在支持实时多媒体数据...
rtp/rtcp实现的协议 实用性的代码,可以应用。
**RTP协议** RTP是一种面向数据包的传输协议,设计目标是在不可靠的网络环境中尽可能高效地传输实时数据,如音频和视频。RTP包含两部分:头部和负载。头部包含了时间戳、序列号、源标识符等信息,用于同步和丢包检测...
为了支持跨应用程序的互操作性,开发者应当使用标准的RTP协议而不是专有方案,以便用户能够使用不同开发者的应用进行通信。 RTP允许为每个媒体源分配一个单独的RTP数据流,从而支持如多目标广播场景中的视频会议,...
RTP协议主要用于实现实时音频、视频等多媒体数据在网络上的高效传输,它位于应用层与UDP之间,不负责数据的可靠传输,而是专注于实时数据的组织、定时和同步等方面。 **2.2 RTP的特点** - **实时性**:虽然被称为...
RTP协议: 1. RTP设计目标:RTP旨在提供一种机制,使得音频、视频或其他实时数据能够被高效且可靠地传输。它支持在不可靠的网络环境下进行实时交互,如UDP之上。 2. RTP头结构:RTP数据包通常包含一个固定头部和可选...
RTP协议不保证数据的可靠传输,而是依赖于下层传输协议(如UDP)来处理数据包的发送,从而实现低延迟。RTP数据包包含序列号、时间戳和SSRC(同步源标识符),这些字段有助于接收端正确重组数据流并进行时间同步。 ...
RTCP(Real-time Transport Control Protocol)是 RTP 的伴随协议,用于监控和控制 RTP 传输的质量。 使用 Wireshark 抓 RTSP、RTP、RTCP 网络包的步骤: 1. 安装 Wireshark 软件,并确保已经安装了 init.lua 文件...
RTP协议通过时间戳和序列号来确保数据的有序接收,并能够检测和处理丢失或重复的数据包。 RTCP则与RTP协同工作,主要负责监测和控制RTP会话的质量。它提供了服务质量(QoS)的反馈,包括丢包率、网络延迟、 jitter...