Content deleted Content added
m Reverted edits by 41.114.213.154 (talk) to last version by Kvng |
grammar |
||
Line 18:
*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.
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.
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.
Line 82:
* '''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) Used to indicate if there are extra padding bytes at the end of the RTP packet.
* '''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/>
Line 98:
==Scalability in large deployments==
In large-scale applications, such as in [[Internet Protocol Television]] (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| 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
[http://www.academypublisher.com/jnw/vol03/no03/jnw03030110.pdf Realtime control protocol and its improvements for Internet Protocol Television]</ref>
===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 name=RFC3550/>. 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
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.
Line 109:
=== 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 name=HA4/>. 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 name=HA4/> to a sender (in case of single
==Standards documents==
| |||