RTP Control Protocol: Difference between revisions

Revision as of 23:27, 14 October 2023

Latest revision as of 20:07, 13 August 2025

(14 intermediate revisions by 6 users not shown)

Line 1:

{{short description|Sister protocol of the Real-time Transport Protocol that provides control information}}

{{distinguish|Real Time Streaming Protocol}}

{{Infobox networking protocol

| title = RTP Control Protocol

Line 15 ⟶ 17:

| osilayer =

| ports =

| rfcs = {{IETF RFC|3550|plainlink=yes}}

| hardware =

}}

{{distinguish|Real Time Streaming Protocol}}

{{short description|Sister protocol of the Real-time Transport Protocol that provides control information}}

The '''RTP Control Protocol''' ('''RTCP''') is ana binary-encoded [[out-of-band signaling|out-of-band]] [[signaling protocol]] that functions alongside the [[Real-time Transport Protocol]] (RTP). Its basic functionality and packet structure is defined in RFC 3550. RTCP provides statistics and control information for an RTP session. It partners with RTP in the delivery and packaging of multimedia data but does not transport any media data itself.

The primary function of RTCP is to provide feedback on the [[quality of service]] (QoS) in media distribution by periodically sending statistics information such as transmitted [[Octet (computing)|octet]] and packet counts, [[packet loss]], [[packet delay variation]], and [[round-trip delay time]] to participants in a streaming multimedia session. An application may use this information to control quality of service parameters, perhaps by limiting flow, or using a different [[codec]].

{{Internet protocol suite|application=RTP Control Protocol}}

{{IPstack}}

== Protocol functions ==

Typically RTP will be sent on an even-numbered [[User Datagram Protocol|UDP]] port, with RTCP messages being sent over the next higher odd-numbered port.<ref>{{cite IETFRef RFC|RFC=3605 |title=Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) |author=C. Huitema |date=October 2003}}</ref>

RTCP itself does not provide any flow encryption or authentication methods. Such mechanisms may be implemented, for example, with the [[Secure Real-time Transport Protocol]] (SRTP) defined in{{Ref RFC |3711.}}

RTCP provides basic functions expected to be implemented in all RTP sessions:

Line 42:

==Packet header==

{{APHD|start|title=RTCP packet header{{Ref RFC|3550}}}}

{| class="wikitable" style="text-align:center"

{{APHD|0|bits1=2|field1=Version|field2=P|bits3=5|field3=RC|bits4=8|field4=PT|bits5=16|field5=Length}}

|+RTCP packet header

{{APHD|4|bits1=32|field1=SSRC Identifier}}

!''Offsets''

{{APHD|end}}

!Octet

* ''';{{APHD|def|name=Version''': (|length=2 bits) |text=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).<ref name=RFC3550/>}}

! colspan="8" |0

* ''';{{APHD|def|name=Padding|short=P (Padding)''': (|length=1 bits) bit|text=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).<ref name=RFC3550/>}}

! colspan="8" |1

* '''RC (;{{APHD|def|name=Reception reportReport count)''': (Count|short=RC|length=5 bits) |text=The number of reception report blocks contained in this packet. A value of zero is valid.<ref name=RFC3550/>}}

! colspan="8" |2

*;{{APHD|def|name=Packet '''Type|short=PT (Packet type)''': (|length=8 bits) |text=Contains a constant to identify RTCP packet type.<ref name=RFC3550/>}}

! colspan="8" |3

* ''';{{APHD|def|name=Length''': (|length=16 bits) |text=Indicates the length of this RTCP packet (including the header itself) in 32-bit units minus one.<ref name=RFC3550/>}}

|-

* ''';{{APHD|def|name=SSRC''': (Identifier|length=32 bits) |text=''Synchronization sourceSource identifierIdentifier'' uniquely identifies the source of a stream.<ref name=RFC3550/>}}

!Octet

! Bit {{efn|Bits are ordered most significant to least significant; bit offset 0 is the most significant bit of the first octet. Octets are transmitted in [[network order]]. Bit transmission order is medium dependent.}}

! 0

!1

! colspan="1" | 2

! colspan="1" | 3

!4

!5

!6

!7

! colspan="1" | 8

!9

!10

!11

!12

!13

!14

!15

!16

!17

!18

!19

!20

!21

!22

!23

!24

!25

!26

!27

!28

!29

!30

!31

|- align="center"

!

! 0

| colspan="2" |Version

| colspan="1" |P

| colspan="5" |RC

| colspan="8" |PT

| colspan="16" |length

|- align="center"

!

! colspan="1" |32

| colspan="32" |SSRC identifier

|- align="center"

|}

* '''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).<ref name=RFC3550/>

* '''P (Padding)''': (1 bits) 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).<ref name=RFC3550/>

* '''RC (Reception report count)''': (5 bits) The number of reception report blocks contained in this packet. A value of zero is valid.<ref name=RFC3550/>

* '''PT (Packet type)''': (8 bits) Contains a constant to identify RTCP packet type.<ref name=RFC3550/>

* '''Length''': (16 bits) Indicates the length of this RTCP packet (including the header itself) in 32-bit units minus one.<ref name=RFC3550/>

* '''SSRC''': (32 bits) ''Synchronization source identifier'' uniquely identifies the source of a stream.<ref name=RFC3550/>

Note that multiple reports can be concatenated into a single compound RTCP packet, each with its own packet header.

==Message types==

RTCP distinguishes several types of packets: ''sender report'', ''receiver report'', ''source description'', and ''goodbye''. In addition, the protocol is extensible and allows application-specific RTCP packets. A standards-based extension of RTCP is the ''extended report'' packet type introduced by.{{Ref RFC |3611.<ref>RFC 3611, ''RTP Control Protocol Extended Reports (RTCP XR)'', T. Friedman (Ed.), R. Caceres, A. Clark (Ed.), The Internet Society (November 2003)</ref>}}

;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.<ref name=RFC3550>{{Cite IETFRef RFC|last=Jacobson |first=V. |last2=Frederick |first2=R. |last3=Casner |first3=S. |last4=Schulzrinne |first4=H. |date= |title=RTP: A Transport Protocol for Real-Time Applications |rfc=3550 |languagerp=en}}</ref>{{rp|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.

Line 123 ⟶ 69:

===Hierarchical aggregation===

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 [[quality of service]] (QoS) measurement.<ref name=HA1/><ref name=HA2/> The [[RTCP]] [[Bandwidth (computing)|bandwidth]] 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).<ref{{Ref name=RFC3550/>RFC|3550}} 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.

The Hierarchical Aggregation is used with [[Source-Specific Multicast]] where only a single source is allowed, i.e. [[IPTV]]. Another type of multicast could be [[Any-Source Multicast]] but it is not so suitable for large-scale applications with huge number of users.

{{asofas of|June 2007}}, only the most modern IPTV systems use Hierarchical aggregation.{{Citation needed|date=March 2009}}

=== Feedback Target ===

Feedback Target is a new type of member that has been firstly introduced by the Internet Draft draft-ietf-avt-rtcpssm-13.<ref{{Ref name=HA4/>RFC|5760}} The Hierarchical Aggregation method has extended its functionality. The function of this member is to receive Receiver Reports (RR) (see [[RTCP]]) and retransmit summarized RR packets, so-called Receiver Summary Information (RSI)<ref{{Ref name=HA4/>RFC|5760}} to a sender (in case of single-level hierarchy).

==Standards documents==

* {{Sum RFC|3550}}

* {{IETF RFC|3550}}, Standard 64, ''RTP: A Transport Protocol for Real-Time Applications''

==See also==

* [[Streaming media]]

* [[Voice over IP]]

==Notes==

{{reflist|group=lower-alpha}}

==References==

Line 146 ⟶ 89:

<ref name=HA1>[https://web.archive.org/web/20070509035431/http://adela.utko.feec.vutbr.cz/projects/publications/#2 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}}</ref>

<ref name=HA2>[https://web.archive.org/web/20070509035431/http://adela.utko.feec.vutbr.cz/projects/publications/#2 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}}</ref>

<ref name=HA4>{{cite IETF |RFC=5760 |author1=J. Ott |author2=J. Chesterfield |author3=E. Schooler |title=RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback}}</ref>

}}

==Further reading==

* {{cite book|last=Perkins|first=Colin|title=RTP|publisher=Addison-Wesley|year=2003|pages=414|isbn=978-0-672-32249-5|url=https://books.google.com/books?id=OM7YJAy9_m8C}}

* {{cite book |last=Peterson |first=Larry L. |author2=Bruce S. Davie |title=Computer Networks |publisher=Morgan Kaufmann |year=2007 |edition=4 |pages=806 |isbn=978-0-12-374013-7 |url=https://books.google.com/books?id=zGVVuO-6w3IC}}{{Dead link|date=August 2023 |bot=InternetArchiveBot |fix-attempted=yes }}

* {{cite book|publisher=Javvin Technologies | title=Network Protocols Handbook |chapter=RTCP |chapter-url=https://books.google.com/books?id=D_GrQa2ZcLwC&pg=PA145 | year=2005 | isbn=978-0-9740945-2-6}}