I have bumped into this exact question once or twice in the past month and I think it deserves a post of its own.
What’s RTCP? It’s a companion protocol to RTP – the one used to send and receive most media over IP these days. It gives it a lightweight control mechanism that provides feedback to the sender about the quality of the data it is sending – how much packets the remote side received, what got lost along the way – this kind of information.
Another use of RTCP is to know when a call can be dropped. In SIP, for example, call control can take place over UDP, where there is no way to know if one of the user agents crashed or dropped out of the network due to some extraneous reasons – especially when the only thing flowing between the user agents is the media. In such a case, monitoring RTCP reports can be used to determine if a call got dropped.
Today, RTCP can do much more. And by much more, I would like to shed light about two interesting IETF RFCs that deal with extensions to RTCP that make it quite an important part of real-time visual communications: RFC 3611 and RFC 4585.
RFC 3611: RTCP-XR (Extended Reports)
RTCP is a kind of a reporting protocol: it collects information and then reports it every once in a while. Problem is – it provides very little information. This often means that you can use it in a limited way to solve issues such as congestion.
To improve what you can achieve with RTCP, RTCP-XR (RFC 3611) was defined. RTCP-XR simply adds a bunch of additional information that can be collected:
- Now you can know not only how many packets were lost, but also what sequence numbers they had – which means that a sender can now try and retransmit them instead of sending a fresh new I-frame if he thinks this improves things.
- Now you can get know the jitter information on the receiver side. Or the MOS value he has for your voice (it’s a measurement of quality)
- Or a bunch of other stuff that may come useful if you want to improve the overall quality of the media.
What are the main additions of it over the basic reporting?
- Sequence numbers of lost packets
- Sequence numbers of duplicate packets
- Packet receipt times
- Receiver reference time
- Delay since the last RTCP Receiver Report was received
- Statistics summary
- VoIP metrics
The exact use of each is reserved for the applications themselves, but this added information gives a lot of power for optimizing solutions within the scope of the standard in a way that maintains interoperability.
Oh – and if I haven’t mentioned it – RTCP-XR is required by IMS implementations.
RFC 4585: RTCP-FB (AVPF / Feedback)
RTP is used by SIP, H.323 and even XMPP to send the actual media over the network. Once done, all the control over the media itself – negotiation of different bitrates, request for I-frames and the likes are usually done over the signaling protocols: H.245 when it comes to H.323, INFO and SDP when it comes to SIP. While this means that mapping protocols and gatewaying between them is a hassle, there’s an even bigger implication: We want media to go point-to-point as much as possible to reduce latency and increase quality, which means we would like all control mechanisms of the media to traverse the same route – and signaling is often split from the media and takes a different route through a different set of entities over the network.
To solve these issues, RTCP-FB was defined in RFC 4585, which is also known as RTP/AVPF. This defines a way for applications to send commands over RTCP from the receiver of the media to the sender.
Most of this standard deals with how sending such messages occur within RTCP in a way that won’t break the percentage RTCP takes out of the allotted bitrate for the media – a rather complex and daunting task.
But then its main use has come out in another RFC that “sits” right on top of it: RTC 5104. While this one has a bunch of control messages that can now be sent, the most useful one out of it is known as “FIR” – Full Intra Request, which is the similar to the Video Fast Update message sent in H.323.
With RFC 4585, RTCP becomes a protocol that can be used for some intelligent communication and not just pumping media over an IP network.
Oh, and it just so happens that the IMTC’s SIP Parity AG have placed the use of this RFC as an essential part of their evolving SIP Video Profile.
-
So you see, RTCP is a lot more than just an aside to RTP – it is a fully fledged protocol that is bound to be used and adopted as video calling becomes commonplace.
Make sure you take it into consideration the next time you develop a VoIP product.
