details about rtp and rtcp

最新推荐文章于 2024-03-04 15:48:15 发布

mahout_xb

最新推荐文章于 2024-03-04 15:48:15 发布

阅读量2.7k

点赞数

分类专栏： webrtc 文章标签： tcp 视频会议电话 types 网络服务器

本文链接：https://blog.csdn.net/mahout_xb/article/details/7645338

版权

webrtc 专栏收录该内容

7 篇文章 1 订阅

订阅专栏

准备分析webrtc的rtp_rtcp模块的源代码（webrtc_root/src/modules/rtp_rtcp), 工欲善其事，必先利其器，

先对rtp&rtcp的相关知识做一个总结：

RTP是基于UDP而不是TCP
原因：
1. tcp内置的重传机制不适合实时传输
2. tcp是点到点的协议，而不直接支持多播机制
3. UDP和TCP的包中都没有时间戳，因此需要在应用层另建一套RTP
RTP提供了哪些功能
1. payload types标识：
   即标识数据负载类型，不同的负载类型对应不同的编码格式，后面会做详细介绍。
2. 来源标识：
   对于音频或视频会议，就要知道数据的来源
3. 序列号
4. 时间戳
   用来计算延迟，控制视音频的同步
RTP packet

V（2） : 版本号
P（1）：标识包的末尾是否有填充，有的应用要求定长的包，因此会需要填充
X（1）：标识RTP的包头之后是否还扩展头
CC（4）：CSRC的个数
M（1）：一般的标记位，不同的载荷可能有不同的含义，如，对于音频标识会话的开始，对于视频，标示一帧的结束
PT（7）：payload type, 载荷的类型, 不同的音频，视频编码格式，对应不同的载荷。
Sequence number （16）：序列号, 用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，
网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，在helix服务器中这个字段是从0开始的，同时音频包和视频包的sequence是分别记数的。
Timestamp: 时间戳
SSRC: 同步信源， SSRC和CSRC的理解牵涉到mixer, 下面会有关于mixer的介绍。
CSRC: 实际信源，在同一会话中，每个CSRC应不同，因此，需要一定的机制来检测它。
PAYLOAD: 实际的媒体数据
payload type

这个表来自RFC 1890, 补充一下， H263的PT是34， H264的PT是109
Mixer
混合器，它有多种用途，一种常见的场景是：电话会议，有的client的带宽高，有的带宽低，那么他们怎么同步呢？
当然，可以都使用低带宽，这样电话的质量必然就差了。而使用Mixer就是一种较好的办法，将高带宽的包混合后转换成
低带宽的包，显然，mixer应放在低带宽一端。SSRC即混合后的信源，而那些组成这一混合信源的数据源就是CSRC。
RTCP的功能
RTCP的包类型
1. SR: Sender Report
2. RR: Receiver Report
3. SDES: Source Description
4. BYE: Goodbye
5. APP: Application-defined packet
SR & RR

SR

RR

SR比RR除了多了NTP timestamp 和RTP timestamp外，其余都一样；有了SR和RR后，我们就可以得到packet loss, RTT, jitter.
fraction lost即为last sender到receiver之间的丢包率；
计算 RTT:
A-LSR-DLSR
即sender收到RR的时间 - sender发送SR的时间 - receiver在接收到SR和发送RR耽搁的时间＝ sender和receiver一来一回路上发的时间。

计算jitter:
int transit = arrival - r->ts;
int d = | transit - s->transit |;
s->transit = transit;
s->jitter += (1./16.) * ((double)d - s->jitter);
rr->jitter = (u_int32) s->jitter;
其中arrival即收到rtp包的时间, r->ts为rtp包中的时间戳，s为session, 记录了transit和jitter,
s->jitter初始化为0, rr即为 RR包。
REMB 和 TMMBR
RTCP带宽估算