WebRTC RTCP 分析

已于 2022-03-01 13:47:30 修改
阅读量1.9k 收藏 10
点赞数 1
分类专栏： WebRTC 文章标签： rtcp webrtc
于 2020-08-15 10:59:27 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/aggresss/article/details/108019463
版权

0x00 前言

下面是 WebRTC 的 SDP 描述中的 m-line 的一个示例：

m=audio 58779 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
m=video 60372 UDP/TLS/RTP/SAVPF 100 101 116 117 96

可以看出 audio 和 video 的传输都是基于 RTP 已经定义的几种 Profile (AVP/SAVP/AVPF/SAVPF) 中最复杂的 SAVPF，这些机制里面最复杂的部分要数 Feedback，而 RTCP 是整个 Feedback 机制实现的重要组成部分（还有一部分可以通过 RTP Header Extention 实现）。本文主要介绍和分析 WebRTC 中与 RTCP 相关的内容。
对于基于 UDP 的 RTP 并不能为按顺序传送数据包提供可靠的机制，也不提供流量控制或拥塞控制，所以需要依靠 RTCP 提供这些服务。通常 RTP 算法并不作为一个独立的网络层来实现，在 RTP 会话期间，通常会配备一些 发现/安全/反馈 机制来保证基于 RTP 的应用完整实现。
在语音通信中 RTCP 主要用于传递状态和发送统计数据。而视频通信中的 RTCP 被赋予了控制功能，比如关键帧请求，重传请求，码率控制等。

0x01 RTCP 介绍

WebRTC 中的 RTCP 常见类型有：

SequenceRepresentSubtype
200SR (Sender Report)-
201RR (Receiver Report)-
202SDES (Source Description)-
203BYE-
204APP-
205RTPFB (Generic RTP Feedback)NACK/TransportFeedback
206PSFB (Payload-Specific Feedback)PLI/FIR/REMB
207XR (Extended Reports)LRLE/DRLE/PRT/RRT/DLRR/SS/VM

更多类型定义可以参考 https://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-4

RTCP 主要涉及到 3 个 RFC 文档

和下面几个补充文档

  • RFC3551 - RTP Profile for Audio and Video Conferences with Minimal Control
  • RFC5104 - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
  • RFC5124 - Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)
  • RFC5450 - Transmission Time Offsets in RTP Streams

0x02 RTCP 类型分析

① SR/RR/SDES/BYE/APP

SR

https://tools.ietf.org/html/rfc3550#section-6.4.1

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=SR=200   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SSRC of sender                        |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     sender's packet count                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      sender's octet count                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |                  profile-specific extensions                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RR

https://tools.ietf.org/html/rfc3550#section-6.4.2

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=RR=201   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     SSRC of packet sender                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |                  profile-specific extensions                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SR 和 RR 的唯一区别是 SR 多了 20 字节的 Sender Info，用于描述发送者的信息。

SDES

https://tools.ietf.org/html/rfc3550#section-6.5

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    SC   |  PT=SDES=202  |             length            |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_1                          |
  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                          SSRC/CSRC_2                          |
  2    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           SDES items                          |
       |                              ...                              |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
BYE

https://tools.ietf.org/html/rfc3550#section-6.6

   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|    SC   |   PT=BYE=203  |             length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           SSRC/CSRC                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                              ...                              :
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) |     length    |               reason for leaving            ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
APP

https://datatracker.ietf.org/doc/html/rfc3550#section-6.7

    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| subtype |   PT=APP=204  |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SSRC/CSRC                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          name (ASCII)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   application-dependent data                ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

② RTPFB/PSFB

常规的 SR/RR 是一种定时报告机制，对于因为事件引起的反馈并不是很友好，例如关键帧丢失。RTPFB/PSFB 提供了这样的保证机制，其中 RTPFB 是在 RTP Stream 层面的 Feedback，PSFB 是 RTP 所携带的负载信息的反馈机制。这种 Feedback 机制主要目的为：关键帧请求、重传请求、码率控制等。
参考 https://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml，常见 RTPFB/PSFB 类型如下表。

RTPFB

ValueNameLong NameReference
1NACKGeneric negative acknowledgementRFC4585
2ReservedRFC5104
3TMMBRTemporary Maximum Media Stream Bit Rate RequestRFC5104
4TMMBNTemporary Maximum Media Stream Bit Rate NotificationRFC5104
5SR_REQRTCP Rapid Resynchronisation RequestRFC6051
6RAMSRapid Acquisition of Multicast SessionsRFC6285
7TLLEITransport-Layer Third-Party Loss Early IndicationRFC6642
8ECNRTCP ECN FeedbackRFC6679
9PSMedia Pause/ResumeRFC7728
10DBI DelayBudget Information (DBI)[3GPP TS 26.114 v16.3.0][Ozgur_Oyman]
15TCCTransport Wide Congestion Controlhttps://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
31EXTReserved for future extensionsRFC4585

PSFB

ValueNameLong NameReference
1PLIPicture Loss IndicationRFC4585
2SLISlice Loss IndicationRFC4585
3RPSIReference Picture Selection IndicationRFC4585
4FIRFull Intra Request CommandRFC5104
5TSTRTemporal-Spatial Trade-off RequestRFC5104
6TSTNTemporal-Spatial Trade-off NotificationRFC5104
7VBCMVideo Back Channel MessageRFC5104
8PSLEIPayload-Specific Third-Party Loss Early IndicationRFC6642
9ROIVideo region-of-interest (ROI)[3GPP TS 26.114 v16.3.0][Ozgur_Oyman]
10LRRLayer Refresh Request CommandRFC-ietf-avtext-lrr-07
15AFB(REMB)Application Layer Feedback (Receiver Estimated Maximum Bitrate)https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
31EXTReserved for future extensionsRFC4585

另外，除了关键帧请求和重传，Webrtc还支持RED／FEC等冗余编码和前向纠错手段来保证视频质量。

③ XR

RTCP XR 的目的是补充传递 RTCP SR 和 RTCP RR 包含的六个统计信息。

共定义了 7 种类型的 BT (Block Type)，见下表。

ValueNameLong NameReference
1LRLELoss RLE (Run-Length Encoding)rfc3611#section-4.1
2DRLEDuplicate RLE (Run-Length Encoding)rfc3611#section-4.2
3PRTPacket Receipt Timesrfc3611#section-4.3
4RRTReceiver Reference Timerfc3611#section-4.4
5DLRRDelay since the Last Receiver Referencerfc3611#section-4.5
6SSStatistics Summaryrfc3611#section-4.6
7VMVoIP Metricsrfc3611#section-4.7

定义的报表块类型分为三类。

  • 第一类包括收到或丢失RTP Packet 的逐包报告。
    • LRLE
    • DRLE
    • PRT
  • 第二类报告在 RTP 参与者之间传递参考时间信息。
    • RRT
    • DLRR
  • 第三类报告传递与包接收相关的度量，这些度量在本质上是摘要，但比现有 RTCP 包中传递的度量更详细，或者具有不同的类型。
    • SS
    • VM

XR 类型 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|reserved |   PT=XR=207   |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         report blocks                         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

report blocks 格式为：

  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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      BT       | type-specific |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :             type-specific block contents                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

在 WebRTC 中比较常用的为 RRT 和 DLRR，接收⽅发送 RTCP-XR RRT 后，发送⽅在下次的 RTCP 中携带 RTCP-XR DLRR，可以使接收方估算出网络的 RTT 参数。

参考文档

  1. https://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml
  2. 超越RFC3550 － RTP/RTCP协议族分析
  3. WebRTC之RTCP
  4. WebRTC之RTT计算
  5. 网络抖动(jitter)的计算
aggresss
关注
专栏目录
【webrtc】SDP: rtcp-mux
突围
06-13 223
sdp
webrtc rtcp SenderReport
chinabinlang的专栏
09-23 669
rtcp 中 的SenderReport ，不多说了： bool SenderReport::Parse(const CommonHeader& packet) { RTC_DCHECK_EQ(packet.type(), kPacketType); const uint8_t report_block_count = packet.count(); if (packet...
WebRTC Windows版编译(支持H264+OpenSSL)
sonysuqin的专栏
03-24 5492
摘要 本文介绍了在Windows下编译WebRTC的方法，WebRTC默认支持VP8、VP9(谷歌自己的编码)和BoringSSL (谷歌的OpenSSL分支，主要修复一些OpenSSL主线的漏洞)，本文将介绍在Windows下让WebRTC支持使用更广泛的H264、OpenSSL的方法。 版本 本文使用的版本是57，我下载WebRTC代码的时候最新版本是62，但是为了方便编译...
webrtc中rtcp反馈与码率控制模块分析
MeRcy_PM的博客
05-09 5344
webrtc中rtcp反馈与码率控制模块分析
webrtc tcc详解
最新发布
sweibd的专栏
07-28 746
webrtc的tcc算法，具体做法是，接收端监控两个数据，并反馈给发送端。丢包率: 接收端计算出丢包率，定期发送rtcp rr报文(内有丢包率)给发送端，发送端通过丢包率的大小来决定是否降低编码的bitrate；
rtcp webrtc 接收_【转】WebRTC之RTCP
weixin_34923852的博客
12-29 277
转自：https://blog.csdn.net/momo0853/article/details/88051312#RTPFBTransport_layer_FB_messagesNACKTransportFeedback_245文章目录RTCPSR(Sender Report RTCP Packet)RR(Receiver Report RTCP Packet)SDES(Source Desc...
WebRTC RTCP
clark的专栏
04-06 850
RTCP作为RTP控制协议，对于弱网下音视频质量和会话控制具有重要的作用。 RTCP header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
WebRTC之RTCP
sunxiaopengsun的专栏
06-10 174
https://blog.csdn.net/momo0853/article/details/88051312
webrtc中的RTCP简介
The_Old_man_and_sea的博客
03-14 743
mediasoup ICE提名选举过程1 ICE 状态2 ICE 提名流程图 1 ICE 状态 mediasoup 的 ICE 有4种状态，分别是NEW,CONNECTED,COMPLETED,DISCONNECTED。 状态 解使 NEW webrtctransport 新建立，没有收到任何的STUN包 CONNECTED 收到了符合要求的STUN包，但该STUN包没有携带hasUseCandidate，设置STUN包对应的IP:PORT 处于候选列表中 DISCONNEC
流媒体协议分析之webrtc之rtcp
yinshipin007的博客
03-29 350
TCP作为控制协议，对于弱网下音视频质量和会话控制具有重要的作用。
rtcp webrtc 接收_webrtc中的rtcp处理
weixin_32440005的博客
12-29 400
在webrtc中，处理rtcp，目前的版本是在,rtcp_sender.h 和rtcp_sender.cpp中实现；当收到rtcp packet时，调用过程，主要是以下三个函数：接收-》解析-》响应；IncomingPacket -》{ParseCompoundPacket -》TriggerCallbacksFromRtcpPacket }；当然，还是实现了(根据rtcp)延时计算：/...
WebRTC系列-Qos系列之RTP/RTCP协议分析rtcp-1
HOSTEN的博客
01-08 614
上一篇文章介绍了RTP协议，通常RTP负责传输数据，RTCP一起工作，RTCP负责对RTP的通信和会话进行控制（如流量控制、拥塞控制、会话源管理等）；同rtp协议一样，协议由 IETF（http://www.ietf.org/）定义在和3551中；
WebRTC中RTCP协议详解
永远积极向上、永远热泪盈眶、永远豪情满怀、永远坦坦荡荡
11-16 1040
一、RTCP协议 |Data| |RTCP Header|Data| |UDP Header|RTCP Header|Data| |IP Header|UDP Header|RTCP Header|Data| |Mac Header|IP Header|UDP Header|RTCP Header|Data|Mac Tailer| 14byte 20byte 8byte 4byte 可变长度 4
WebRTC | 网络传输协议 RTP 和 RTCP
ProgramNovice的博客
05-25 1365
WebRTC | 网络传输协议 RTP 和 RTCP
从WebRtc学习RTCP协议
hanhan的博客
02-11 2273
RTCP是RTP的控制协议. 那么RTCP能对RTP做哪些控制呢？其中最为大家熟知的就是丢包控制。 发送端发送数据后，接收端如果发现有RTP包丢失了，可以使用RTCP的NACK报文通知发送方，告诉对方具体是哪些包丢失了，然后让发送方重发前面丢失的包。 此外，接收端还可以使用RTCP的RR报文向发送端发送接收报告，报告中记录着从上一次报告到本次报告之间丢失了多少包、丢包率是多少、延时是多少等一系列信息。 同理，发送端也可以向接收端发送SR报文，报告一段时间内一共发送了多少包等。 RTCP支持的消息非常多，在此
webrtc rtcp mux及其对 传统voip的影响
RTC hacker
01-06 4589
本文原创自 http://blog.csdn.net/voipmaker  转载注明出处 rtcp mux是一种通过一个socket端口同时传输rtp和rtcp的方法，webrtc规范强制使用 rtcp mux方法，但是 许多传统voip设置并不支持此方法，通常都是rtp用一个端口，rtcp用rtp+1端口号，至少目前chrome和firefox都是强制使用rtcp-mux, 所以如果传统v
WebRTC RTCP XR
clark的专栏
04-09 1804
RTCP扩展报告(XR)用于补充RTCP 的发送方报告 (SR) 和接收方报告 (RR) 数据包的报告块中的六个统计信息。 Value Name Long Name Description Reference 1 RRT Receiver Reference Time 接收方参考时间 rfc3611#section-4.4 2 DLSR Delay since the last Sender Report 自上次发送方报告以来的延迟
webrtc基础 - RTP/RTCP
tuan8888888的博客
10-22 1761
1、简介 RTP—实时传输协议，其在多点传送（多播）或单点传送（单播）的网络上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP没有为实时服务提供资源预留的功能，也不保证QoS（服务质量）。 RTP的数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传输（多播）网络，并提供最小限度的控制和鉴别功能。RTP 和 RTCP 被设计成和下面的传输层和网络层无关。 总结： RTP 只是简单数据的封
WebRTC源码分析
08-02
下面是对WebRTC源码的简要分析： WebRTC源码主要分为以下几个模块： 1. 信令（Signaling）模块：负责建立和维护通信的连接。它使用WebSocket或者其他协议进行通信，包括传输SDP（Session Description Protocol）和...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值