First, it is most certainly not the link bandwidth. This would not scale, as then a large number of sessions could saturate the link with RTCP traffic, even if each used just 5% of the link bandwidth for RTCP. Secondly, the CONCEPT of link bandwidth is ill-defined in a heterogeneous network.

The session bandwidth is the nominal DATA bandwidth plus the IP, UDP and RTP headers (40 bytes). For example, for 64 kb/s PCM audio packetized in 20 ms increments, the session bandwidth would be (160 + 40) / 0.02 bytes/second or 80 kb/s. If there are multiple senders, the sum of their individual BANDWIDTHS is used.

The session bandwidth is typically defined out-of-band, e.g., in a session announcement protocol, based on reasonable estimates of the number of concurrent senders and their average bandwidth. Distributed and consistent on-line estimation of the session bandwidth may be hard as the number of senders and their bandwidth changes. The absolute value is less important than that all participants agree on a common value. (After all, there is nothing SPECIAL about choosing the RTCP bandwidth to be 5% of the session bandwidth, it just has to be agreed upon by all participants to avoid timing out members prematurely.)

First, it is most certainly not the link bandwidth. This would not scale, as then a large number of sessions could saturate the link with RTCP traffic, even if each used just 5% of the link bandwidth for RTCP. Secondly, the concept of link bandwidth is ill-defined in a heterogeneous network.

The session bandwidth is the nominal data bandwidth plus the IP, UDP and RTP headers (40 bytes). For example, for 64 kb/s PCM audio packetized in 20 ms increments, the session bandwidth would be (160 + 40) / 0.02 bytes/second or 80 kb/s. If there are multiple senders, the sum of their individual bandwidths is used.

The session bandwidth is typically defined out-of-band, e.g., in a session announcement protocol, based on reasonable estimates of the number of concurrent senders and their average bandwidth. Distributed and consistent on-line estimation of the session bandwidth may be hard as the number of senders and their bandwidth changes. The absolute value is less important than that all participants agree on a common value. (After all, there is nothing special about choosing the RTCP bandwidth to be 5% of the session bandwidth, it just has to be agreed upon by all participants to avoid timing out members prematurely.)