RTCP works alongside RTP to monitor and control media streams with QoS feedback, synchronization and session management . This writeup describes the key format and functions of this protocol
- RTCP (Real-Time Transport Control Protocol )
- RTCP XR (Extended Reports)
- Extended RTP Profile for RTCP Based Feedback (RTP/AVPF)
- RTCP operation modes
- RTCP for multicast sessions with unicast feedback
- RTCP Extensions for Multiplexed Media Streams
RTCP (Real-Time Transport Control Protocol )
Real-time Transport Control Protocol (RTCP) defined in RFC 3550, is used to send control packets and feedback on QoS to participants in a call along with RTP which sends actual media packets. RTCP provides monitoring of the data delivery, qos in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.
RTCP is typically on port RTP+1, e.g., RTP=5004 → RTCP=5005.
Also RTCP uses 5% of total session bandwidth (RTP uses 95%). One can also adjust RTCP report intervals to avoid congestion.
RTCP Control and Management
RTCP provides feedback on the quality of the data distribution, congestion control, fault diagnosis, control of adaptive encoding. It is a periodic transmission of control packets. Since the control traffic is not self-limiting, the RR (Receiver Reports) from participants should be rate adjusted to limit traffic to the sender thus we observe for number of participants to estimate RTCP Transmission Interval for scaling up. This allows the communication system to monitor multimedia delivered on large multicast networks with hundreds of receivers. The underlying protocol must provide multiplexing of the data and control packets to convey minimal session control information such as Bytes sent, packets sent, lost packets, jitter, feedback and round trip delay.
Gathers statistics on media connection
Some metrics gathered by RTCP reports are :
- timestamps
- tp : last RTCP transmit time
- tr : curr time
- tn : next schedule RTCP transmission time
- pmembers : last estimated count of members
- members: a current estimate of the number of session members
- senders
- rtcp_bw
- avg_rtcp_size
- flags as
- initial
- we_sent if the participant is sender ie has sent an RTP packet
- constants
- n is set to the number of receivers = members – senders
- C : If sender then C =avg_rtcp_size / 25% of rtcp_bw else C=avg_rtcp_size / 75% of rtcp_bw
Time Intervals calculation should be random but should give at least 25 of bw to senders and if sender >25% of members then split equally. This is done so that it is uniformly distributed and should avoid unintended synchronization or burst of RTCP packets to the sender.
- step 1 : Tmin=2.5 seconds if not yet sent an RTCP packet, else Tmin=5 seconds.
- step 2 : Td = max(Tmin, n*C)
- step 3 : T = 0.5 or 1.5 times Td.
- step 4 : resulting T is divided by e-3/2=1.21828 to compensate for the fact that the timer reconsideration algorithm converges to a value of the RTCP bandwidth below the intended average.
Application may use this information to increase the quality of service, perhaps by limiting flow or using a different codec.
RTCP often uses the next consecutive port( odd number) as RTP( even number). Example screenshot shows port 20720 for RTP
And next consecutive port 20721 for RTCP
When RTCP is not being used or the CNAME identifier corresponding to a synchronization source has not been received yet, the participant associated with a synchronization source is not known.
- (+) RTCP helps in monitoring the quality of service for every session
- (+) RTCP sender and receiver reports allow the implementation of adaptive streaming where senders scale their bandwidth consumption based on network load.
- (+) RCP SDES contains additional information like CNAME which helps in tracing of troublesome multimedia sources.( via email , phone number etc )
Types of RTCP packet
- SR: Sender report, for transmission and reception statistics from participants that are active senders
- RR: Receiver report, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources
- SDES: Source description items, including CNAME,email or phone
- BYE: Indicates end of participation
- APP: Application-specific functions
SR is issued if a site has sent any data packets during the interval since issuing the last report or the previous one, otherwise the RR is issued.
SR: Sender Report RTCP Packet
Sender Report RTCP Packet.
Expanded Sender Report RTCP Packet has sender information is 20 octets long and is present in every sender report packet. It summarizes the data transmissions from this sender.
- NTP timestamp 64 bit
- RTP Timestamp 32 bit
- sender’s packet count: 32 bits, total number of RTP data packets transmitted by the sender since starting transmission up until the time this SR packet was generated.
- sender’s octet count: 32 bits
Explanation for some attributes
- highest sequence number received: 32 bits
- fraction lost: 8 bits, fraction of RTP data packets from source SSRC_n lost since the previous SR or RR packet was sent
- cumulative number of packets lost: 24 bits size, total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception.
- interarrival jitter: 32 bits, estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp unit. Jitter J is mean deviation (smoothed absolute value) of the difference D is packet spacing at the receiver compared to the sender for a pair of packets.
Synchronization and exposing delays using RTCP : For multimedia conferences the NTP timestamp from RTCP SR is used to give a common time reference that can associate these independent timestamps with a wall clock shared time. the NTP timestamps also help the endpoints measure their delays.
RR: Receiver Report RTCP Packet
Snapshot
SDES: Source Description RTCP Packet
abbrev. name value
- END end of SDES list 0
- CNAME canonical name 1
- NAME user name 2
- EMAIL user’s electronic mail address 3
- PHONE user’s phone number 4
- LOC geographic user location 5
- TOOL name of application or tool 6
- NOTE notice about the source 7
- PRIV private extensions 8
BYE: Goodbye RTCP Packet
APP: Application-Defined RTCP Packet
Intended for experimental use
Instance of RTCP sender and receiver reports on transmission and reception statistics
Real-time Transport Control Protocol (Receiver Report)
[Stream setup by SDP (frame 4)]
[Setup frame: 4]
[Setup Method: SDP]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0001 = Reception report count: 1
Packet type: Receiver Report (201)
Length: 7 (32 bytes)
Sender SSRC: 0x796dd0d6 (2037240022)
Source 1
Identifier: 0x00000000 (0)
SSRC contents
Fraction lost: 0 / 256
Cumulative number of packets lost: 1
Extended highest sequence number received: 6534
Sequence number cycles count: 0
Highest sequence number received: 6534
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 SDP (frame 4)]
[Setup frame: 4]
[Setup Method: SDP]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0001 = Source count: 1
Packet type: Source description (202)
Length: 6 (28 bytes)
Chunk 1, SSRC/CSRC 0x796DD0D6
Identifier: 0x796dd0d6 (2037240022)
SDES items
Type: CNAME (user and domain) (1)
Length: 8
Text: 796dd0d6
Type: NOTE (note about source) (7)
Length: 5
Text: telecomorg
Type: END (0)
Negative Acknowledgment (NACK) packets can be used to explicitly indicate that packets have not been received.
Full Intra Request (FIR) and Picture Loss Indication (PLI) packets are used for video to indicate that there is a need for the sender to produce a refresh point( key frame) in the stream.
Receiver-Estimated Maximum Bitrate (REMB) feedback packets signal to a sender the maximum bitrate a receiver wishes to receive.
Transport-wide Congestion Control (TCC) feedback packets are used to provide detailed packet-by-packet reception information from a receiver to the sender.
RTCP XR (Extended Reports)
The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP’s Sender Report (SR) and Receiver Report (RR) packets.
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Categories
- packet-by-packet reports on received or lost RTP packets
Loss RLE Report Block (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=1 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Duplicate RLE Report Block ( 2)
Packet Receipt Times Report Block (3)
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=3 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (begin_seq + 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (end_seq - 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- reference time information between RTP participants
Receiver Reference Time Report Block : Receiver-end wallclock timestamps(4)
DLRR Report Block : delay since the last Receiver Reference Time Report Block was received (5)
3. metrics relating to packet receipts, that are summary in nature
Statistics summary block (6)
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=6 |L|D|J|ToH|rsvd.| block length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mean_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dev_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VOIP metric report block (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=7 | reserved | block length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst density | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst duration | gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| round trip delay | end system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal level | noise level | RERL | Gmin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R factor | ext. R factor | MOS-LQ | MOS-CQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RX config | reserved | JB nominal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JB maximum | JB abs max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended RTP Profile for RTCP Based Feedback (RTP/AVPF)
RTP provides continuous feedback about the overall reception quality from all receivers — thereby allowing the sender(s) in the mid-term to adapt their coding scheme and transmission behavior to the observed network quality of service (QoS).
RTP makes no provision for timely feedback that would allow a sender to repair the media stream immediately: through retransmissions, retroactive Forward Error Correction (FEC) control, or media-specific mechanisms for some video codecs, such as reference picture selection.
Components of RTCP based feedback
- Status reports contained in sender report (SR)/received report (RR) packet transmitted at regular intervals . Can also contain SDES
- FB ( Feedback ) messages . Indicate loss or reception of particular pieces of a media stream
Types of RTCP Feedback packet
Minimal compound RTCP feedback packet
This is to minimize the size of the RTCP packet transmitted to convey feedback and maximize the frequency at which feedback can be provided. MUST contain only the mandatory information :
- encryption prefix if necessary,
- exactly one RR or SR,
- exactly one SDES with only the CNAME item present, and
- FB message(s)
Full compound RTCP feedback packet
MAY contain any additional number of RTCP packet
RTCP operation modes
- Immediate Feedback mode
- Early RTCP mode
- Regular RTCP Mode
The Application specific feedback threshold is a function of a number of parameters including (but not necessarily limited to):
- type of feedback used (e.g., ACK vs. NACK),
- bandwidth,
- packet rate,
- packet loss
- probability and distribution,
- media type,
- codec,
- (worst case or observed) frequency of events to report (e.g., frame received, packet lost).
Payload specific Feedback messages
Three payload-specific FB messages are defined so far plus an application layer FB message. They are identified by means of the FMT parameter as follows:
- 0: unassigned
- 1: Picture Loss Indication (PLI)
- 2: Slice Loss Indication (SLI)
- 3: Reference Picture Selection Indication (RPSI)
- 4-14: unassigned
- 15: Application layer FB (AFB) message
- 16-30: unassigned
- 31: reserved for future expansion of the sequence number space
RTCP for multicast sessions with unicast feedback
Single-source multicast sessions (e.g., IPTV, live streaming) where receivers provide feedback via unicast RTCP. These feedbacks can quickly overwhelm the sender as it will receive as many feedback as the number of viewers which is many folds in case of large scale deployments for example webinars.
To mitigate this feedback implosion, sender aggregates reports instead of processing individual multicast feedback in Multicast Acquisition Report (MAR)
a=rtcp-fb:* x-mar unicast // Supports MAR over unicast
a=rtcp-fb:* nack unicast // NACKs sent via unicast
RTCP Extensions for Multiplexed Media Streams
For multiplexed media streams , where different kinds of media share a common port, we use payload type and SSRC to distinguish streams. we can mux the rtcp too. The Offer/Answer Negotiation has the following attribute in SDP
a=rtcp-mux
| Features | RTP and RTCP on different port | RTP , RTCP mux |
| Number of ports | 2 | 1 |
| NAT simplicity | complex with per stream overhead for ICE candidates gathering | relatively simple , only 1 pinhole |
References :
- RFC 3611 RTP Control Protocol Extended Reports (RTCP XR)
- RFC 4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
- RFC 7002 RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting
- RFC 7003 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting
Telecom R & D 