The RTP Control Protocol (RTCP) is a sister protocol of the Real-time Transport Protocol (RTP). It is defined in RFC 3550 (which supersedes RFC 1889).

RTCP provides out-of-band control information for an RTP flow. It partners RTP in the delivery and packaging of multimedia data, but does not transport any data itself. It is used periodically to transmit control packets to participants in a streaming multimedia session. The primary function of RTCP is to provide feedback on the quality of service being provided by RTP.

RTCP gathers statistics on a media connection and information such as bytes sent, packets sent, lost packets, jitter, feedback and round trip delay. An application may use this information to increase the quality of service, perhaps by limiting flow or using a different codec.

There are several type of RTCP packets: Sender report packet, Receiver report packet, Source Description RTCP Packet, Goodbye RTCP Packet and Application Specific RTCP packets.

RTCP itself does not provide any flow encryption or authentication means. SRTCP can be used for that purpose.

Problems and potential further development of RTCP

RTCP has some issues with deployment on large scale applications of types that could inflict very long delay between RTCP reports (such as IPTV). This could make the receiver's reporting messages and its evaluation by sender inaccurate relative to the real state of the session. Due to this there are some methods to deal with this issue: these are filtering, biasing and hierarchical aggregation.

• Described in more detail by Realtime control protocol and its improvements for Internet Protocol Television

Types of message

RTP allows only one type of message, one that carries data from the source to the destination. In many cases, there is a need for other messages in a session. These messages control the flow and quality of data and allow the recipient to send feedback to the source or sources. Real-time transport control protocol(RTCP) is a protocol designed for this purpose. RTCP has five types of messages: sender report, receiver report, source description message, bye message, application-specific message.

Sender Report

The sender report is sent periodically by the active senders in a conference to report transmission and reception statistics for all RTP packets sent during the interval. The sender report includes an absolute timestamp, which is the number of seconds elapsed since midnight on January 1, 1900. The absolute timestamp allows the receiver to sychronize different RTP messages. It is particularly important when both audio and video are transmitted (audio and video transmissions use separate relative timestamps).

Receiver Report

The receiver report is for passive participants, those that do not send RTP packets. The report informs the sender and other receivers about the quality of service.

Source Description Message

The source periodically sends a source description message to give additional information about itself. This information can be the name, e-mail address, telephone number, and address of the owner or controller of the source.

Bye Message

A source sends a bye message to shut down a stream. It allows the source to announce that it is leaving the conference. Although other sources can detect the absence of a source, this message is a direct announcement. It is also very useful to a mixer.

Application-Specific Message

The application-specific message is a packet for an application that wants to use new applicatons (not defined in the standard). It allows the definition of a new message type.

See also

• Real-time Transport Protocol
• Streaming media
• Quality of service

External links

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

This computer network-related article is a stub. You can help Wikipedia by expanding it.