Content deleted Content added
→Protocol functions: {{Ref RFC}} |
m format RFCs |
||
| (6 intermediate revisions by 2 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 a binary-encoded [[out-of-band signaling|out-of-band]] [[signaling protocol]] that functions alongside the [[Real-time Transport Protocol]] (RTP)
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}}
== Protocol functions ==
Line 56:
==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
;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 RFC|3550|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.
Line 73:
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.
{{
=== Feedback Target ===
Feedback Target is a new type of member that has been firstly introduced by the Internet Draft draft-ietf-avt-rtcpssm-13.
==Standards documents==
* {{Sum RFC|3550}}
==See also==
* [[Streaming media]]
* [[Voice over IP]]
==References==
Line 92 ⟶ 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>
}}
| |||