Wireshark Wiki 中文翻译整理专题首页原始页面

RTCP

RTCP 与 RTP 一起使用，例如用于 VoIP（另请参见 VOIPProtocolFamily）。

历史

RTCP 最初在 RFC1889 中规定，该 RFC 已被 RFC3550 取代。

协议依赖

UDP：通常，RTCP 使用 UDP 作为其传输协议。RTCP 没有 well known UDP port。相反，端口是动态分配的，然后使用不同的协议（如 SDP 和 H245）进行信令通知。

示例流量

Real-time Transport Control Protocol (Sender Report) [Stream setup by H245 (frame 51)] [Setup frame: 51] [Setup Method: H245] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0001 = Reception report count: 1 Packet type: Sender Report (200) Length: 12 (52 bytes) Sender SSRC: 0xbcdc0094 (3168534676) Timestamp, MSW: 11 (0x0000000b) Timestamp, LSW: 22544384 (0x01580000) [MSW and LSW as NTP timestamp: Feb 7, 2036 06:28:27,0052 UTC] RTP timestamp: 49823528 Sender's packet count: 166 Sender's octet count: 9960 Source 1 Identifier: 0xf5e33db0 (4125310384) SSRC contents Fraction lost: 0 / 256 Cumulative number of packets lost: 0 Extended highest sequence number received: 28620 Sequence number cycles count: 0 Highest sequence number received: 28620 Interarrival jitter: 0 Last SR timestamp: 0 (0x00000000) Delay since last SR timestamp: 0 (0 milliseconds)Real-time Transport Control Protocol (Source description) [Stream setup by H245 (frame 51)] [Setup frame: 51] [Setup Method: H245] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0001 = Source count: 1 Packet type: Source description (202) Length: 11 (48 bytes) Chunk 1, SSRC/CSRC 0xBCDC0094 Identifier: 0xbcdc0094 (3168534676) SDES items Type: CNAME (user and domain) (1) Length: 14 Text: IP200A@0.0.0.0 Type: NAME (common name) (2) Length: 6 Text: IP200A Type: TOOL (name/version of source app) (6) Length: 11 Text: innovaphone Type: END (0)[RTCP frame length check: OK - 100 bytes]

Wireshark

RTCP dissector 功能完整。

偏好设置

有四项影响 RTCP 的偏好设置。

显示 stream setup 信息。默认开启。
尝试在 conversations 之外解码 RTCP。默认关闭，
显示相对 roundtrip 计算。默认关闭。
要报告的最小 roundtrip 计算值（ms）。默认值为 10

示例捕获文件

SampleCaptures/rtp_example.raw.gz（libpcap）一个 H323 call 的 VoIP 示例捕获（包括 H225、H245、RTP 和 RTCP）。

显示过滤器

完整的 RTCP display filter fields 列表可以在 display filter reference 中找到

只显示基于 RTCP 的流量：

 rtcp

捕获过滤器

捕获时不能直接过滤 RTCP 协议。不过，如果你知道所使用的 UDP 端口（见上文），可以基于该端口进行过滤。

Roundtrip Delay 的计算

RTCP dissector 可以执行此计算（见上面的偏好设置），该计算在 RFC3550 的 6.4.1 中描述。下面是一个说明该计算如何执行的图示。

数学背景

数学背景可阅读论文 Optimization of Large-Scale RTCP Feedback Reporting in Fixed and Mobile Networks 中的第 I. 和 II.A) 节。

RTCP 的进一步研究与开发

Realtime control protocol and its improvements for Internet Protocol Television
Optimization of Large-Scale RTCP Feedback Reporting in Fixed and Mobile Networks
Dan Komosny publications

外部链接

RFC3550RTP: A Transport Protocol for Real-Time Applications 也描述了 RTCP
RFC3611RTP Control Protocol Extended Reports (RTCP XR)
RFC1890RTP Profile for Audio and Video Conferences with Minimal Control
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-13.txtRTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback
PoC User PlaneTalk Burst Control Protocol

讨论

我希望这里是讨论 Wireshark RTCP parser 可能增强功能的合适位置。

RTCP 支持在单个 UDP packet 中包含多个 reports（一个 compound packet）。parser 当前似乎只显示/分析第一个 packet。
.... 这并不正确（例如参见本 wiki 上的示例 SIP_CALL_RTP_G711——它包含一个带有 3 个 reports 的单个 RTCP packet）。你是否有无法正确解析的 compound packet 示例？（martinm）
... 啊，你是对的，我也发现了一个能解析多个 sub-packets 的例子。也许我看到的情况与下面的 encryption 情况有关。我最好如何提供示例？（BurtHarris）
你可以把它发到 developers list，或者创建一个 bug 并附加它。dissector 不解析所有 reports 的另一个原因是它检测到了 length discrepancy——不过在这种情况下，问题应该会被清楚地报告出来。
RTCP 和 SRTP（RFC 3711）可以一起使用，从而产生 SRTCP。当前 parser 不知道 SRTCP 中额外的字段，并且如果启用了 encryption，可能会显示无意义的值。

SRT(C)P handling 最近已添加到两个 dissectors 中。（JaapKeuter）

Imported from https://wiki.wireshark.org/RTCP on 2020-08-11 23:24:09 UTC

原始页面图片

RTCP ​

历史 ​

协议依赖 ​

示例流量 ​

Wireshark ​

偏好设置 ​

示例捕获文件 ​

显示过滤器 ​

捕获过滤器 ​

Roundtrip Delay 的计算 ​

数学背景 ​

RTCP 的进一步研究与开发 ​

外部链接 ​

讨论 ​

原始页面图片 ​

相关 Wireshark Wiki 页面 ​