The intention and original design goal of RTCP messages was for them to act as a distributed source of lightweight session data that would allow a range of highly fault tolerant, and reasonable scale mechanisms to be built including:
RTCP reports are designed to be sent periodically, with a frequency inversely proportional to the number of members. This can be set to constrain the bandwidth consumed by RTCP to be a known fixed fraction of the total capacity required for a many-to-many session. For multimedia conferencing this is an excellent solution for many applications requirements for such data. However there are three circumstances where this approach creates a problem: firstly, when a session starts, the members do not know the number of other members - initial membership for a scheduled session could rise very sharply, leading to a flood of initial packets; secondly, this effect can also happen for BYE messages; finally, for sessions where there is some form of floor control, or few senders compared with recipients, the fact that the RTCP reports are multicast means that they arrive at all participants- this may still represent a non-trivial fraction of the capacity to a given participant - in some cases, the state for large membership may impact on memory for small multicast devices (Internet Telephones).