Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
RTP Control Protocol
open-in-new
<h2 id="protocol-functions">Protocol functions</h2> <p>Typically RTP will be sent on an even-numbered <a href="/facts/User_Datagram_Protocol/dxLU0D6q">UDP</a> port, with RTCP messages being sent over the next higher odd-numbered port.<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a> </p><p>RTCP itself does not provide any flow encryption or authentication methods. Such mechanisms may be implemented, for example, with the <a href="/facts/Secure_Real-time_Transport_Protocol/LBXehUtz">Secure Real-time Transport Protocol</a> (SRTP)<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> </p><p>RTCP provides basic functions expected to be implemented in all RTP sessions: </p> <ul><li>The primary function of RTCP is to gather statistics on quality aspects of the media distribution during a session and transmit this data to the session media source and other session participants. Such information may be used by the source for adaptive media encoding (<a href="/facts/Codec/C7b7Am8t">codec</a>) and detection of transmission faults. If the session is carried over a multicast network, this permits non-intrusive session quality monitoring.</li> <li>RTCP provides canonical end-point identifiers (CNAME) to all session participants. Although a source identifier (SSRC) of an RTP stream is expected to be unique, the instantaneous binding of source identifiers to end-points may change during a session. The CNAME establishes unique identification of end-points across an application instance (multiple use of media tools) and for third-party monitoring.</li> <li>Provisioning of session control functions. RTCP is a convenient means to reach all session participants, whereas RTP itself is not. RTP is only transmitted by a media source.</li></ul> <p>RTCP reports are expected to be sent by all participants, even in a multicast session which may involve thousands of recipients. Such traffic will increase proportionally with the number of participants. Thus, to avoid network congestion, the protocol must include session bandwidth management. This is achieved by dynamically controlling the frequency of report transmissions. RTCP bandwidth usage should generally not exceed 5% of the total session bandwidth. Furthermore, 25% of the RTCP bandwidth should be reserved to media sources at all times, so that in large conferences new participants can receive the CNAME identifiers of the senders without excessive delay. </p><p>The RTCP reporting interval is randomized to prevent unintended synchronization of reporting. The recommended minimum RTCP report interval per station is 5 seconds. Stations should not transmit RTCP reports more often than once every 5 seconds. </p> <h2 id="packet-header">Packet header</h2> RTCP packet header<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a><table><tbody><tr><th><i>Offset</i></th><th><a href="/facts/Octet_(computing)/dqCHsuUF">Octet</a></th><th colspan="8">0</th><th colspan="8">1</th><th colspan="8">2</th><th colspan="8">3</th></tr><tr><th>Octet</th><th><a href="/facts/Bit/S972NSaD">Bit</a></th><th>0</th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th><th>8</th><th>9</th><th>10</th><th>11</th><th>12</th><th>13</th><th>14</th><th>15</th><th>16</th><th>17</th><th>18</th><th>19</th><th>20</th><th>21</th><th>22</th><th>23</th><th>24</th><th>25</th><th>26</th><th>27</th><th>28</th><th>29</th><th>30</th><th>31</th></tr><tr><th>0</th><th>0</th><td colspan="2"><i>Version</i></td><td><i>P</i></td><td colspan="5"><i>RC</i></td><td colspan="8"><i>PT</i></td><td colspan="16"><i>Length</i></td></tr><tr><th>4</th><th>32</th><td colspan="32"><i>SSRC Identifier</i></td></tr></tbody></table> Version: 2 bits Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. The version defined by this specification is two (2). Padding (P): 1 bit Indicates if there are extra padding bytes at the end of the RTP packet. Padding may be used to fill up a block of certain size, for example as required by an encryption algorithm. The last byte of the padding contains the number of padding bytes that were added (including itself). Reception Report Count (RC): 5 bits The number of reception report blocks contained in this packet. A value of zero is valid. Packet Type (PT): 8 bits Contains a constant to identify RTCP packet type. Length: 16 bits Indicates the length of this RTCP packet (including the header itself) in 32-bit units minus one. SSRC Identifier: 32 bits <i>Synchronization Source Identifier</i> uniquely identifies the source of a stream. <p>Note that multiple reports can be concatenated into a single compound RTCP packet, each with its own packet header. </p> <h2 id="message-types">Message types</h2> <p>RTCP distinguishes several types of packets: <i>sender report</i>, <i>receiver report</i>, <i>source description</i>, and <i>goodbye</i>. In addition, the protocol is extensible and allows application-specific RTCP packets. A standards-based extension of RTCP is the <i>extended report</i> packet type.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> </p> Sender report (SR) 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 two distinct timestamps, an absolute timestamp, represented using the timestamp format of the Network Time Protocol (NTP) (which is in seconds relative to midnight UTC on 1 January 1900) and an RTP timestamp that corresponds to the same time as the NTP timestamp, but in the same units and with the same random offset as the RTP timestamps in data packets described by this Sender Report.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a>: 12,37 The absolute timestamp allows the receiver to synchronize RTP messages. It is particularly important when both audio and video are transmitted simultaneously because audio and video streams use independent relative timestamps. Receiver report (RR) 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 (SDES) The Source Description message is used to send the CNAME item to session participants. It may also be used to provide additional information such as the name, e-mail address, telephone number, and address of the owner or controller of the source. Goodbye (BYE) A source sends a BYE message to shut down a stream. It allows an endpoint 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 useful to a media mixer. Application-specific message (APP) The application-specific message provides a mechanism to design application-specific extensions to the RTCP protocol. <h2 id="scalability-in-large-deployments">Scalability in large deployments</h2> <p>In large-scale applications, such as in <a href="/facts/Internet_Protocol_television/tHqsXX6h">Internet Protocol television</a> (IPTV), very long delays (minutes to hours) between RTCP reports may occur, because of the RTCP bandwidth control mechanism required to control congestion (see Protocol functions). Acceptable frequencies are usually less than one per minute. This affords the potential of inappropriate reporting of the relevant statistics by the receiver or causes evaluation by the media sender to be inaccurate relative to the current state of the session. Methods have been introduced to alleviate the problems:<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> RTCP filtering, RTCP biasing and <a href="/facts/RTCP_hierarchical_aggregation/grCfaxxe">hierarchical aggregation</a>.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> </p> <h3>Hierarchical aggregation</h3> <p>The Hierarchical Aggregation (or also known as RTCP feedback hierarchy) is an optimization of the RTCP feedback model and its aim is to shift the maximum number of users limit further together with <a href="/facts/Quality_of_service/joz9VkUm">quality of service</a> (QoS) measurement.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a><a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> The <a href="/facts/RTCP/grCfaxxe">RTCP</a> <a href="/facts/Bandwidth_(computing)/lY6Tb4gX">bandwidth</a> is constant and takes just 5% of session bandwidth. Therefore, the reporting interval about QoS depends, among others, on a number of session members and for very large sessions it can become very high (minutes or even hours).<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> However, the acceptable interval is about 10 seconds of reporting. Bigger values would cause time-shifted and very inaccurate reported status about the current session status and any optimization made by the sender could even have a negative effect on network or QoS conditions. </p><p>The Hierarchical Aggregation is used with <a href="/facts/Source-Specific_Multicast/WHm5IJ5D">Source-Specific Multicast</a> where only a single source is allowed, i.e. <a href="/facts/IPTV/tHqsXX6h">IPTV</a>. Another type of multicast could be <a href="/facts/Any-Source_Multicast/uNqc5vA0">Any-Source Multicast</a> but it is not so suitable for large-scale applications with huge number of users. </p><p>As of June 2007<a href="https://en.wikipedia.org/w/index.php?title=RTP_Control_Protocol&action=edit">[update]</a>, only the most modern IPTV systems use Hierarchical aggregation. </p> <h3>Feedback Target</h3> <p>Feedback Target is a new type of member that has been firstly introduced by the Internet Draft draft-ietf-avt-rtcpssm-13.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> The Hierarchical Aggregation method has extended its functionality. The function of this member is to receive Receiver Reports (RR) (see <a href="/facts/RTCP/grCfaxxe">RTCP</a>) and retransmit summarized RR packets, so-called Receiver Summary Information (RSI)<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a> to a sender (in case of single-level hierarchy). </p> <h2 id="standards-documents">Standards documents</h2> <ul><li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc3550">3550</a> – RTP: A Transport Protocol for Real-Time Applications, <i>Internet Standard 64.</i></li></ul> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Streaming_media/4rPhSq0Y">Streaming media</a></li> <li><a href="/facts/Voice_over_IP/5QGBbXYg">Voice over IP</a></li></ul> <h2 id="further-reading">Further reading</h2> <ul><li>Perkins, Colin (2003). <a href="https://books.google.com/books?id=OM7YJAy9_m8C"><i>RTP</i></a>. Addison-Wesley. p. 414. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-0-672-32249-5.</li> <li>Peterson, Larry L.; Bruce S. Davie (2007). <i>Computer Networks</i> (4 ed.). Morgan Kaufmann. p. 806. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-0-12-374013-7.</li> <li><a href="https://books.google.com/books?id=D_GrQa2ZcLwC&pg=PA145">"RTCP"</a>. <i>Network Protocols Handbook</i>. Javvin Technologies. 2005. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-0-9740945-2-6.</li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>C. Huitema (October 2003). Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP). Network Working Group. doi:10.17487/RFC3605. RFC 3605. Proposed Standard. <a href="/wiki/Christian_Huitema" target="_blank">/wiki/Christian_Huitema</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>M. Baugher; D. McGrew; M. Naslund; E. Carrara; K. Norrman (March 2004). The Secure Real-time Transport Protocol (SRTP). Network Working Group. doi:10.17487/RFC3711. RFC 3711. Informational. Updated by RFC 9335, 5506 and 6904. <a href="https://datatracker.ietf.org/doc/html/rfc3711" target="_blank">https://datatracker.ietf.org/doc/html/rfc3711</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>H. Schulzrinne; S. Casner; R. Frederick; V. Jacobson (July 2003). RTP: A Transport Protocol for Real-Time Applications. Network Working Group. doi:10.17487/RFC3550. STD 64. RFC 3550. Internet Standard 64. Updated by RFC 8860, 7160, 5761, 5506, 6051, 6222, 7022, 7164 and 8083. Obsoletes RFC 1889. <a href="/wiki/Van_Jacobson" target="_blank">/wiki/Van_Jacobson</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>T. Friedman; R. Caceres; A. Clark, eds. (November 2003). RTP Control Protocol Extended Reports (RTCP XR). Network Working Group. doi:10.17487/RFC3611. RFC 3611. Proposed Standard. <a href="https://datatracker.ietf.org/doc/html/rfc3611" target="_blank">https://datatracker.ietf.org/doc/html/rfc3611</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>H. Schulzrinne; S. Casner; R. Frederick; V. Jacobson (July 2003). RTP: A Transport Protocol for Real-Time Applications. Network Working Group. doi:10.17487/RFC3550. STD 64. RFC 3550. Internet Standard 64. Updated by RFC 8860, 7160, 5761, 5506, 6051, 6222, 7022, 7164 and 8083. Obsoletes RFC 1889. <a href="/wiki/Van_Jacobson" target="_blank">/wiki/Van_Jacobson</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Vít Novotný, Dan Komosný, Large-Scale RTCP Feedback Optimization, Journal of Networks, Vol.3 (3), March 2008 <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Realtime control protocol and its improvements for Internet Protocol Television <a href="http://www.academypublisher.com/jnw/vol03/no03/jnw03030110.pdf" target="_blank">http://www.academypublisher.com/jnw/vol03/no03/jnw03030110.pdf</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>KOMOSNY D., NOVOTNY V. Tree Structure for Specific-Source Multicast with feedback Aggregation, in ICN07 - The Sixth International Conference on Networking . Martinique, 2007 ISBN 0-7695-2805-8 <a href="https://web.archive.org/web/20070509035431/http://adela.utko.feec.vutbr.cz/projects/publications/#2" target="_blank">https://web.archive.org/web/20070509035431/http://adela.utko.feec.vutbr.cz/projects/publications/#2</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>NOVOTNY, V., KOMOSNY, D. Optimization of Large-Scale RTCP Feedback Reporting in ICWMC 2007. ICWMC 2007 - The Third International Conference on Wireless and Mobile Communications. Guadeloupe, 2007 ISBN 0-7695-2796-5 <a href="https://web.archive.org/web/20070509035431/http://adela.utko.feec.vutbr.cz/projects/publications/#2" target="_blank">https://web.archive.org/web/20070509035431/http://adela.utko.feec.vutbr.cz/projects/publications/#2</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>H. Schulzrinne; S. Casner; R. Frederick; V. Jacobson (July 2003). RTP: A Transport Protocol for Real-Time Applications. Network Working Group. doi:10.17487/RFC3550. STD 64. RFC 3550. Internet Standard 64. Updated by RFC 8860, 7160, 5761, 5506, 6051, 6222, 7022, 7164 and 8083. Obsoletes RFC 1889. <a href="/wiki/Van_Jacobson" target="_blank">/wiki/Van_Jacobson</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>J. Ott; J. Chesterfield; E. Schooler (February 2010). RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback. Internet Engineering Task Force. doi:10.17487/RFC5760. RFC 5760. Proposed Standard. Updated by RFC 6128. <a href="https://datatracker.ietf.org/doc/html/rfc5760" target="_blank">https://datatracker.ietf.org/doc/html/rfc5760</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>J. Ott; J. Chesterfield; E. Schooler (February 2010). RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback. Internet Engineering Task Force. doi:10.17487/RFC5760. RFC 5760. Proposed Standard. Updated by RFC 6128. <a href="https://datatracker.ietf.org/doc/html/rfc5760" target="_blank">https://datatracker.ietf.org/doc/html/rfc5760</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> </ol>