Real-time Control Protocol (RTCP)

RTCP is used together with RTP e.g. for VoIP (see also VOIPProtocolFamily).

History

RTCP was first specified in RFC1889 which is obsoleted by RFC3550.

Protocol dependencies

  • UDP: Typically, RTCP uses UDP as its transport protocol. RTCP does not have a well known UDP port. Instead, the ports are allocated dynamically and then signaled using a different protocol such as SDP and H245.

Example traffic

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: [email protected]
            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

The RTCP dissector is fully functional.

Preference Settings

There are four preference settings affecting RTCP.

* Show stream setup information. Default ON.

* Try to decode RTCP outside of conversations. default OFF,

* Show relative roundtrip calculation. Default OFF.

* Minimum roundtrip calculations to report(ms). Default is 10

Example capture file

SampleCaptures/rtp_example.raw.gz (libpcap) A VoIP sample capture of a H323 call (including H225, H245, RTP and RTCP).

Display Filter

A complete list of RTCP display filter fields can be found in the display filter reference

Show only the RTCP based traffic:

 rtcp 

Capture Filter

You cannot directly filter RTCP protocols while capturing. However, if you know the UDP port used (see above), you can filter on that one.

Calculation of Roundtrip Delay

The RTCP dissector can do this calculation (see preference settings above) which is described in 6.4.1 of RFC3550. Here is a diagram explaining how this calculation is performed.

rtcp_roundtrip.png

Mathematical background

Mathematical background could be read in section I. and II.A) in paper Optimization of Large-Scale RTCP Feedback Reporting in Fixed and Mobile Networks

Further research and development of RTCP

External links

Discussion

I hope this is this an appropriate place to discuss possible enhancements to the Wireshark RTCP parser.

  • RTCP supports multiple reports in a single UDP packet (a compound packet). The parser currently seems to only display/analyze the first packet.

    • …. This isn't true (see e.g. the sample SIP_CALL_RTP_G711 on this wiki - it contains a single RTCP packet with 3 reports). Do you have a compound packet example that doesn't parse properly? (martinm)

    • … Ahh, your right, I found one that parsed multiple sub-packets as well. Perhaps the case I'm seeing is related to the encryption situation below. How would I best provide an example? (BurtHarris)

    • - You could mail it to the developers list, or create a bug and attach it. The other reason for the dissector not parsing all of the reports is if it detects a length discrepency - in this case the problem should be clearly reported though.

  • RTCP & SRTP (RFC 3711) can be used together, producing SRTCP. The current parser is unaware of the additional , fields in SRTCP, and may, if encryption is enabled, display meaningless values.

    SRT(C)P handling was recently added to both dissectors. (JaapKeuter)


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