One of the primary uses of RTCP is reception quality reporting, which is accomplished through RTCP receiver report (RR) packets, which are sent by all participants who receive data.

THE RTCP RR PACKET FORMAT

A receiver report packet is identified by a packet type of 201 and has the format illustrated in Figure 5.3. A receiver report packet contains the SSRC (synchronization source) of the participant who is sending the report (the reporter SSRC) followed by zero or more report blocks, denoted by the RC field.

Figure 5.3. Format of an RTCP RR Packet

Many RTCP packet types have a structure similar to that of receiver reports, with a list of items following the fixed part of the packet. Note that the fixed part of the packet remains even if the list of items is empty, implying that a receiver report with no report blocks will have RC=0, but Length=1, corresponding to the four-octet fixed RTCP header plus the four-octet reporter SSRC.

Each report block describes the reception quality of a single synchronization source from which the reporter has received RTP packets during the current reporting interval. A total of 31 report blocks can be in each RTCP RR packet. If there are more than 31 active senders, the receiver should send multiple RR packets in a compound packet. Each report block has seven fields, for a total of 24 octets.

The reportee SSRC identifies the participant to whom this report block pertains. The statistics in the report block denote the quality of reception for the reportee synchronization source, as received at the participant generating the RR packet.

The cumulative number of packets lost is a 24-bit signed integer denoting the number of packets expected, less the number of packets actually received. The number of packets expected is defined to be the extended last sequence number received, less the initial sequence number received. The number of packets received includes any that are late or duplicated, and hence may be greater than the number expected, so the cumulative number of packets lost may be negative. The cumulative number of packets lost is calculated for the entire duration of the session, not per interval. This field saturates at the maximum positive value of 0x7FFFFF if more packets than that are lost during the session.

Many of the RTCP statistics are maintained for the duration of the session, rather than per reporting interval. If an SSRC collision occurs, however, or if there is a very large gap in the sequence number space, such that the receiver cannot tell whether the fields may have wrapped, then the statistics are reset to zero.

The extended highest sequence number received in the RTP data packets from this synchronization source is calculated as discussed in Chapter 4, RTP Data Transfer Protocol, in the section titled Sequence Number. Because of possible packet reordering, this is not necessarily the extended sequence number of the last RTP packet received. The extended highest sequence number is calculated per session, not per interval.

The loss fraction is defined as the number of packets lost in this reporting interval, divided by the number expected. The loss fraction is expressed as a fixed-point number with the binary point at the left edge of the field, which is equivalent to the integer part after multiplying the loss fraction by 256 (that is, if 1/4 of the packets were lost, the loss fraction would be 1/4 × 256 = 64). If the number of packets received is greater than the number expected, because of the presence of duplicates, making the number of packets lost negative, then the loss fraction is set to zero.

The interarrival jitter is an estimate of the statistical variance in network transit time for the data packets sent by the reportee synchronization source. Interarrival jitter is measured in timestamp units, so it is expressed as a 32-bit unsigned integer, like the RTP timestamp.

To calculate the variance in network transit time, it is necessary to measure the transit time. Because sender and receiver typically do not have synchronized clocks, however, it is not possible to measure the absolute transit time. Instead the relative transit time is calculated as the difference between a packet's RTP timestamp and the receiver's RTP clock at the time of arrival, measured in the same units. This calculation requires the receiver to maintain a clock for each source, running at the same nominal rate as the media clock for that source, from which to derive these relative timestamps. (This clock may be the receiver's local playout clock, if that runs at the same rate as the source clocks.) Because of the lack of synchronization between the clocks of sender and receiver, the relative transit time includes an unknown constant offset. This is not a problem, because we are interested only in the variation in transit time: the difference in spacing between two packets at the receiver versus the spacing when they left the sender. In the following computation the constant offset due to unsynchronized clocks is accounted for by the subtraction.

If S_i is the RTP timestamp from packet i, and R_i is the time of arrival in RTP timestamp units for packet i, then the relative transit time is (R_i – S_i), and for two packets, i and j, the difference in relative transit time may be expressed as

Note that the timestamps, R_x and S_x, are 32-bit unsigned integers, whereas D(i,j) is a signed quantity. The calculation is performed with modulo arithmetic (in C, this means that the timestamps are of type unsigned int, provided that sizeof(unsigned int) == 4).

The interarrival jitter is calculated as each data packet is received, using the difference in relative transit times D(i,j) for that packet and the previous packet received (which is not necessarily the previous packet in sequence number order). The jitter is maintained as a moving average, according to the following formula:

Whenever a reception report is generated, the current value of J_i for the reportee SSRC is included as the interarrival jitter.

The last sender report (LSR) timestamp is the middle 32 bits out of the 64-bit NTP (Network Time Protocol) format timestamp included in the most recent RTCP SR packet received from the reportee SSRC. If no SR has been received yet, the field is set to zero.

The delay since last sender report (DLSR) is the delay, expressed in units of 1/65,536 seconds, between receiving the last SR packet from the reportee SSRC and sending this reception report block. If no SR packet has been received from the reportee SSRC, the DLSR field is set to zero.

INTERPRETING RR DATA

The reception quality feedback in RR packets is useful not only for the sender, but also for other participants and third-party monitoring tools. The feedback provided in RR packets can allow the sender to adapt its transmissions according to the feedback. In addition, other participants can determine whether problems are local or common to several receivers, and network managers may use monitors that receive only the RTCP packets to evaluate the performance of their networks.

A sender can use the LSR and DLSR fields to calculate the round-trip time between it and each receiver. On receiving an RR packet pertaining to it, the sender subtracts the LSR field from the current time, to give the delay between sending the SR and receiving this RR. The sender then subtracts the DLSR field to remove the offset introduced by the delay in the receiver, to get the network round-trip time. The process is shown in Figure 5.4, an example taken from the RTP specification. (Note that RFC 1889 contains an error in this example, which has been corrected in the new version of the RTP specification.)

Figure 5.4. Sample Round-Trip Time (RTT) Computation.

Note that the calculated value is the network round-trip time, and it excludes any processing at the endpoints. For example, the receiver must buffer the data to smooth the effects of jitter before it can play the media (see Chapter 6, Media Capture, Playout, and Timing).

The round-trip time is important in interactive applications because delay hinders interactivity. Studies have shown that it is difficult to conduct conversations when the total round-trip time exceeds about 300 milliseconds⁶¹ (this number is approximate and depends on the listener and the task being performed). A sender may use knowledge of the round-trip time to optimize the media encoding—for example, by generating packets that contain less data to reduce packetization delays—or to drive the use of error correction codes (see Chapter 9, Error Correction).

The fraction lost gives an indication of the short-term packet loss rates to a receiver. By watching trends in the reported statistics, a sender can judge whether the loss is a transient or a long-term effect. Many of the statistics in RR packets are cumulative values, to allow long-term averaging. Differences can be calculated between any two RR packets, making measurements over both short and long periods possible and giving resilience to the loss of reports.

For example, the packet loss rate over the interval between RR packets can be derived from the cumulative statistics, as well as being directly reported. The difference in the cumulative number of packets lost gives the number lost during that interval, and the difference in the extended last sequence numbers gives the number of packets expected during the interval. The ratio of these values is the fraction of packets lost. This number should be equal to the fraction lost field in the RR packet if the calculation is done with consecutive RR packets, but the ratio also gives an estimate of the loss fraction if one or more RR packets have been lost, and it can show negative loss when there are duplicate packets. The advantage of the fraction lost field is that it provides loss information from a single RR packet. This is useful in very large sessions, in which the reporting interval is long enough that two RR packets may not have been received.

Loss rates can be used to influence the choice of media format and error protection coding used (see Chapter 9, Error Correction). In particular, a higher loss rate indicates that a more loss-tolerant format should be used, and that, if possible, the data rate should be reduced (because most loss is caused by congestion; see Chapter 2, Voice and Video Communication over Packet Networks, and Chapter 10, Congestion Control).

The jitter field may also be used to detect the onset of congestion: A sudden increase in jitter will often precede the onset of packet loss. This effect depends on the network topology and the number of flows, with high degrees of statistical multiplexing reducing the correlation between increased jitter and the onset of packet congestion.

Senders should be aware that the jitter estimate depends on packets being sent with spacing that matches their timestamp. If the sender delays some packets, that delay will be counted as part of the network jitter. This can be an issue with video, where multiple packets are often generated with the same timestamp but are spaced for transmission rather than being sent as a burst. This is not necessarily a problem, because the jitter measure still gives an indication of the amount of buffer space that the receiver will require (because the buffer space needs to accommodate both the jitter and the spacing delay).

In addition to reception quality reports from receivers, RTCP conveys sender report (SR) packets sent by participants that have recently sent data. These provide information on the media being sent, primarily so that receivers can synchronize multiple media streams (for example, to lipsync audio and video).

THE RTCP SR PACKET FORMAT

A sender report packet is identified by a packet type of 200 and has the format illustrated in Figure 5.5. The payload contains a 24-octet sender information block followed by zero or more receiver report blocks, denoted by the RC field, exactly as if this were a receiver report packet. Receiver report blocks are present when the sender is also a receiver.

Figure 5.5. Format of an RTCP SR Packet

The NTP timestamp is a 64-bit unsigned value that indicates the time at which this RTCP SR packet was sent. It is in the format of an NTP timestamp, counting seconds since January 1, 1900, in the upper 32 bits, with the lower 32 bits representing fractions of a second (that is, a 64-bit fixed-point value, with the binary point after 32 bits). To convert a UNIX timestamp (seconds since 1970) to NTP time, add 2,208,988,800 seconds.

Although the NTP timestamp in RTCP SR packets uses the format of an NTP timestamp, the clock does not have to be synchronized with the Network Time Protocol or have any particular accuracy, resolution, or stability. For a receiver to synchronize two media streams, however, those streams must be related to the same clock. The Network Time Protocol⁵ is occasionally useful for synchronizing the sending clocks, although it is needed only if the media streams to be synchronized are generated by different systems. These issues are discussed further in Chapter 7, Lip Synchronization.

The RTP timestamp corresponds to the same instant as the NTP timestamp, but it is expressed in the units of the RTP media clock. The value is generally not the same as the RTP timestamp of the previous data packet, because some time will have elapsed since the data in that packet was sampled. Figure 5.6 shows an example of the SR packet timestamps. The SR packet has the RTP timestamp corresponding to the time at which it is sent, which does not correspond to either of the surrounding RTP data packets.

Figure 5.6. Use of Timestamps in RTCP SR Packets

The sender's packet count is the number of data packets that this synchronization source has generated since the beginning of the session. The sender's octet count is the number of octets contained in the payload of those data packets (not including the headers or any padding).

The packet count and octet count fields are reset if a sender changes its SSRC (for example, because of a collision). They will eventually wrap around if the source continues to transmit for a long time, but generally this is not a problem. Subtraction of an older value from a newer value will give the correct result if 32-bit modulo arithmetic is used and no more than 2³² counts occurred in between, even if there was a wrap-around (in C, this means that the counters are of type unsigned int, as long as sizeof(unsigned int) == 4). The packet and octet counts enable receivers to calculate the average data rate of the source.

RTCP can also be used to convey source description (SDES) packets that provide participant identification and supplementary details, such as location, e-mail address, and telephone number. The information in SDES packets is typically entered by the user and is often displayed in the graphical user interface of an application, although this depends on the nature of the application (for example, a system providing a gateway from the telephone system into RTP might use the SDES packets to convey caller ID).

THE RTCP SDES PACKET FORMAT

Each source description packet has the format illustrated in Figure 5.7 and uses RTCP packet type 202. SDES packets comprise zero or more lists of SDES items, the exact number denoted by the SC header field, each of which contains information on a single source.

Figure 5.7. Format of an RTCP SDES Packet

It is possible for an application to generate packets with empty lists of SDES items, in which case the SC and length fields in the RTCP common header will both be zero. In normal use, SC is equal to one (mixers and translators that are aggregating forwarded information will generate packets with larger lists of SDES items).

Each list of SDES items starts with the SSRC of the source being described, followed by one or more entries with the format shown in Figure 5.8. Each entry starts with a type and a length field, then the item text itself in UTF-8 format.¹³ The length field indicates how many octets of text are present; the text is not null-terminated.

Figure 5.8. Format of an SDES Item

The entries in each SDES item are packed into the packet in a continuous manner, with no separation or padding. The list of items is terminated by one or more null octets, the first of which is interpreted as an item of type zero to denote the end of the list. No length octet follows the null item type octet, but additional null octets must be included if needed to pad until a 32-bit boundary is reached. Note that this padding is separate from that indicated by the P bit in the RTCP header. A list with zero items (four null octets) is valid but useless.

Several types of SDES items are defined in the RTP specification, and others may be defined by future profiles. Item type zero is reserved and indicates the end of the list of items. The other standard item types are CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE, and PRIV.

STANDARD SDES ITEMS

The CNAME item (type = 1) provides a canonical name (CNAME) for each participant. It provides a stable and persistent identifier, independent of the synchronization source (because the SSRC will change if an application restarts or if an SSRC collision occurs). The CNAME can be used to associate multiple media streams from a participant across different RTP sessions (for example, to associate voice and video that need to be synchronized), and to name a participant across restarts of a media tool. It is the only mandatory SDES item; all implementations are required to send SDES CNAME items.

The CNAME is allocated algorithmically from the user name and host IP address of the participant. For example, if the author were using an IPv4-based application, the CNAME might be [email protected]. IPv6 applications use the colon-separated numeric form of the address.¹⁶ If the application is running on a system with no notion of user names, the host IP address only is used (with no user name or @ symbol).

As long as each participant joins only a single RTP session—or a related set of sessions that are intended to be synchronized—the use of user name and host IP address is sufficient to generate a consistent unique identifier. If media streams from multiple hosts, or from multiple users, are to be synchronized, then the senders of those streams must collude to generate a consistent CNAME (which typically is the one chosen algorithmically by one of the participants).

The use of private addresses and Network Address Translation (NAT) means that IP addresses are no longer globally unique. For lip synchronization and other uses of associated RTP sessions to operate correctly through Network Address Translation, the translator must also translate the RTCP CNAME to a unique form when crossing domain boundaries. This translation must be consistent across multiple RTP streams.

The NAME item (type = 2) conveys the participant's name and is intended primarily to be displayed in lists of participants as part of the user interface. This value is typically entered by the user, so applications should not assume anything about its value; in particular, it should not be assumed to be unique.

The EMAIL item (type = 3) conveys the e-mail address of a participant formatted as in RFC 822²—for example, [email protected]. Sending applications should attempt to validate that the EMAIL value is a syntactically correct e-mail address before including it in an SDES item; receivers cannot assume that it is a valid address.

The PHONE item (type = 4) conveys the telephone number of a participant. The RTP specification recommends that this be a complete international number, with a plus sign replacing the international access code (for example, +1 918 555 1212 for a number in the United States), but many implementations allow users to enter this value with no check on format.

The LOC item (type = 5) conveys the location of the participant. Many implementations allow the user to enter the value directly, but it is possible to convey location in any format. For example, an implementation could be linked to the Global Positioning System and include GPS coordinates as its location.

The TOOL item (type = 6) indicates the RTP implementation—the tool—in use by the participant. This field is intended for debugging and marketing purposes. It should include the name and version number of the implementation. Typically the user is not able to edit the contents of this field.

The NOTE item (type = 7) allows the participant to make a brief statement about anything. It works well for a “back in five minutes” type of note, but it is not really suitable for instant messaging, because of the potentially long delay between RTCP packets.

PRIV items (type = 8) are a private extension mechanism, used to define experimental or application-specific SDES extensions. The text of the item begins with an additional single-octet length field and prefix string, followed by a value string that fills the remainder of the item. The intention is that the initial prefix names the extension and is followed by the value of that extension. PRIV items are rarely used; extensions can more efficiently be managed if new SDES item types are defined.

The CNAME is the only SDES item that applications are required to transmit. An implementation should be prepared to receive any of the SDES items, even if it ignores them. There are various privacy issues with SDES (see the section titled Security and Privacy later in this chapter), which means that an implementation should not send any information in addition to the CNAME unless the user has explicitly authorized it to do so.

Figure 5.9 shows an example of a complete RTCP source description packet containing CNAME and NAME items. Note the use of padding at the end of the list of SDES items, to ensure that the packet fits into a multiple of 32 bits.

Figure 5.9. A Sample SDES Packet

RTCP provides for loose membership control through RTCP BYE packets, which indicate that some participants have left the session. A BYE packet is generated when a participant leaves the session, or when it changes its SSRC—for example, because of a collision. BYE packets may be lost in transit, and some applications do not generate them; so a receiver must be prepared to time out participants who have not been heard from for some time, even if no BYE has been received from them.

The significance of a BYE packet depends, to some extent, on the application. It always indicates that a participant is leaving the RTP session, but there may also be a signaling relationship between the participants (for example, SIP, RTSP, or H.323). An RTCP BYE packet does not terminate any other relationship between the participants.

BYE packets are identified by packet type 203 and have the format shown in Figure 5.10. The RC field in the common RTCP header indicates the number of SSRC identifiers in the packet. A value of zero is valid but useless. On receiving a BYE packet, an implementation should assume that the listed sources have left the session and ignore any further RTP and RTCP packets from that source. It is important to keep state for departing participants for some time after a BYE has been received, to allow for delayed data packets.

Figure 5.10. Format of an RTCP BYE Packet

The section titled Participant Database later in this chapter further describes the state maintenance issues relating to timeout of participants and RTCP BYE packets.

A BYE packet may also contain text indicating the reason for leaving a session, suitable for display in the user interface. This text is optional, but an implementation must be prepared to receive it (even though the text may be ignored).

The final class of RTCP packet (APP) allows for application-defined extensions. It has packet type 204, and the format shown in Figure 5.11. The application-defined packet name is a four-character prefix intended to uniquely identify this extension, with each character being chosen from the ASCII character set, and uppercase and lowercase characters being treated as distinct. It is recommended that the packet name be chosen to match the application it represents, with the choice of subtype values being coordinated by the application. The remainder of the packet is application-specific.

Figure 5.11. Format of an RTCP APP Packet

Application-defined packets are used for nonstandard extensions to RTCP, and for experimentation with new features. The intent is that experimenters use APP as a first place to try new features, and then register new packet types if the features have wider use. Several applications generate APP packets, and implementations should be prepared to ignore unrecognized APP packets.

As noted earlier, RTCP packets are never sent individually, but rather are packed into a compound packet for transmission. Various rules govern the structure of compound packets, as detailed next.

If the participant generating the compound RTCP packet is an active data sender, the compound must start with an RTCP SR packet. Otherwise it must start with an RTCP RR packet. This is true even if no data has been sent or received, in which case the SR/RR packet contains no receiver report blocks (the RC header field is zero). On the other hand, if data is received from many sources and there are too many reports to fit into a single SR/RR packet, the compound should begin with an SR/RR packet followed by several RR packets.

Following the SR/RR packet is an SDES packet. This packet must include a CNAME item, and it may include other items. The frequency of inclusion of the other (non-CNAME) SDES items is determined by the RTP profile in use. For example, the audio/video profile⁷ specifies that other items may be included with every third compound RTCP packet sent, with a NAME item being sent seven out of eight times within that slot and the remaining SDES cyclically taking up the eighth slot. Other profiles may specify different choices.

BYE packets, when ready for transmission, must be placed as the last packet in a compound. Other RTCP packets to be sent may be included in any order. These strict ordering rules are intended to make packet validation easier because it is highly unlikely that a misdirected packet will meet these constraints.

A potentially difficult issue in the generation of compound RTCP packets is how to handle sessions with larger numbers of active senders. If there are more than 31 active senders, it is necessary to include additional RR packets within the compound. This may be repeated as often as is required, up to the maximum transmission unit (MTU) of the network. If there are so many senders that the receiver reports cannot all fit within the MTU, the receiver reports for some senders must be omitted. In that case, reports that are omitted should be included in the next compound packet generated (requiring a receiver to keep track of the sources reported on in each interval).

A similar issue arises when the SDES items to be included within the packet exceed the maximum packet size. The trade-off between including additional receiver reports and including source description information is left to the implementation. There is no single correct solution.

Sometimes it is necessary to pad a compound RTCP packet out beyond its natural size. In such cases the padding is added to the last RTCP packet in the compound only, and the P bit is set in that last packet. Padding is an area where some implementations are incorrect; the section titled Packet Validation later in this chapter discusses common problems.

Compound RTCP packets are sent periodically, according to a randomized timer. The average time each participant waits between sending RTCP packets is known as the reporting interval. It is calculated on the basis of several factors:

If the number of senders is greater than zero but less than one-quarter of the total number of participants, the reporting interval depends on whether we are sending. If we are sending, the reporting interval is set to the number of senders multiplied by the average size of RTCP packets, divided by 25% of the desired RTCP bandwidth. If we are not sending, the reporting interval is set to the number of receivers multiplied by the average size of RTCP packets, divided by 75% of the desired RTCP bandwidth:

If ((senders > 0) and (senders < (25% of total number of participants)) {
    If (we are sending) {
        Interval = average RTCP size * senders / (25% of RTCP bandwidth)
    } else {
        Interval = average RTCP size * receivers / (75% of RTCP bandwidth)
    }
}

If there are no senders, or if more than one-quarter of the members are senders, the reporting interval is calculated as the average size of the RTCP packets multiplied by the total number of members, divided by the desired RTCP bandwidth:

if ((senders = 0) or (senders > (25% of total number of participants)) {
  Interval = average RTCP size * total number of members / RTCP bandwidth
}

These rules ensure that senders have a significant fraction of the RTCP bandwidth, sharing at least one-quarter of the total RTCP bandwidth. The RTCP packets required for lip synchronization and identification of senders can therefore be sent comparatively quickly, while still allowing reports from receivers.

The resulting interval is always compared to an absolute minimum value, which by default is chosen to be 5 seconds. If the interval is less than the minimum interval, it is set to the minimum:

If (Interval < minimum interval) {
    Interval = minimum interval
}

In some cases it is desirable to send RTCP more often than the default minimum interval. For example, if the data rate is high and the application demands more timely reception quality statistics, a short default interval will be required. The latest revision of the RTP specification allows for a reduced minimum interval in these cases:

Minimum interval = 360 / (session bandwidth in Kbps)

This reduced minimum is smaller than 5 seconds for session bandwidths greater than 72 Kbps. When the reduced minimum is being used, it is important to remember that some participants may still be using the default value of 5 seconds, and to take this into account when determining whether to time out a participant because of inactivity.

The resulting interval is the average time between RTCP packets. The transmission rules described next are then used to convert this value into the actual send time for each packet. The reporting interval should be recalculated whenever the number of participants in a session changes, or when the fraction of senders changes.

When an application starts, the first RTCP packet is scheduled for transmission on the basis of an initial estimate of the reporting interval. When the first packet is sent, the second packet is scheduled, and so on. The actual time between packets is randomized, between one-half and one and a half times the reporting interval, to avoid synchronization of the participants' reports, which could cause them to arrive all at once, every time. Finally, if this is the first RTCP packet sent, the interval is halved to provide faster feedback that a new member has joined, thereby allowing the next send time to be calculated as shown here:

I = (Interval * random[0.5, 1.5])

if (this is the first RTCP packet we are sending) {
    I *= 0.5
}
next_rtcp_send_time = current_time + I

The routine random[0.5, 1.5] generates a random number in the interval 0.5 to 1.5. On some platforms it may be implemented by the rand() system call; on others, a call such as drand48() may be a better source of randomness.

As an example of the basic transmission rules, consider an Internet radio station sending 128-Kbps MP3 audio using RTP-over-IP multicast, with an audience of 1,000 members. The default values for the minimum reporting interval (5 seconds) and RTCP bandwidth fraction (5%) are used, and the average size of RTCP packets is assumed to be 90 octets (including UDP/IP headers). When a new audience member starts up, it will not be aware of the other listeners, because it has not yet received any RTCP data. It must assume that the only other member is the sender and calculate its initial reporting interval accordingly. The fraction of members who are senders (the single source) is more than 25% of the known membership (the source and this one receiver), so the reporting interval is calculated like this:

Interval = average RTCP size * total number of members / RTCP bandwidth
         =   90 octets       *         2               / (5% of 128 Kbps)
         =   180 octets      /  800 octets per second
         =   0.225 seconds

Because 0.225 seconds is less than the minimum, the minimum interval of 5 seconds is used as the interval. This value is then randomized and halved because this is the first RTCP packet to be sent. Thus the first RTCP packet is sent between 1.25 and 3.75 seconds after the application is started.

During the time between starting the application and sending the first RTCP packet, several receiver reports will have been received from the other members of the session, allowing the implementation to update its estimate of the number of members. This updated estimate is used to schedule the second RTCP packet.

As we will see later, 1,000 listeners is enough that the average interval will be greater than the minimum, so the rate at which RTCP packets are received in aggregate from all listeners is 75% × 800 bytes per second ÷ 90 bytes per packet = 6.66 packets per second. If the application sends its first RTCP packet after, say, 2.86 seconds, the known audience size will be approximately 2.86 seconds × 6.66 per second = 19.

Because the fraction of senders is now less than 25% of the known membership, the reporting interval for the second packet is then calculated in this way:

Interval = receivers * average RTCP size / (75% of RTCP bandwidth)
         =     19    *        90         / (75% of (5% of 128 Kbps))
         =         1710          / (0.75 * (0.05 * 16000 octets/second))
         =         1710          / 600
         =           2.85 seconds

Again, this value is increased to the minimum interval and randomized. The second RTCP packet is sent between 2.5 and 7.5 seconds after the first.

The process repeats, with an average of 33 new receivers being heard from between sending the first and second RTCP packets, for a total known membership of 52. The result will be an average interval of 7.8 seconds, which, because it is greater than the minimum, is used directly. Consequently the third packet is sent between 3.9 and 11.7 seconds after the second. The average interval between packets increases as the other receivers become known, until the complete audience has been heard from. The interval is then calculated in this way:

Interval = receivers * average RTCP size / (75% of RTCP bandwidth)
         =    1000   *      90           / (75% of (5% of 128 Kbps))
         =         90000        / (0.75 * (0.05 * 16000 octets/second))
         =         90000        / 600
         =           150 seconds

An interval of 150 seconds is equivalent to 1/150 = 0.0066 packets per second, which with 1,000 listeners gives the average RTCP reception rate of 6.66 packets per second.

The proposed standard version of RTP⁶ uses only these basic transmission rules. Although these are sufficient for many applications, they have some limitations that cause problems in sessions with rapid changes in membership. The concept of reconsideration was introduced to avoid these problems.

As the preceding section suggested, when the session is large, it takes a certain number of reporting intervals before a new member knows the total size of the session. During this learning period, the new member is sending packets faster than the “correct” rate, because of incomplete knowledge. This issue becomes acute when many members join at once, a situation known as a step join. A typical scenario in which a step join may occur is at the start of an event, when an application starts automatically for many participants at once.

In the case of a step join, if only the basic transmission rules are used, each participant will join and schedule its first RTCP packet on the basis of an initial estimate of zero participants. It will send that packet after an average of half of the minimum interval, and it will schedule the next RTCP packet on the basis of the observed number of participants at that time, which can now be several hundreds or even thousands. Because of the low initial estimate for the size of the group, there is a burst of RTCP traffic when all participants join the session, and this can congest the network.

Rosenberg has studied this phenomenon¹⁰⁰ and reports on the case in which 10,000 members join a session at once. His simulations show that in such a step join, all 10,000 members try to send an RTCP packet within the first 2.5 seconds, which is almost 3,000 times the desired rate. Such a burst of packets will cause extreme network congestion—not the desired outcome for a low-rate control protocol.

Continually updating the estimate of the number of participants and the fraction who are senders, and then using these numbers to reconsider the send time of each RTCP packet, can solve this problem. When the scheduled transmission time arrives, the interval is recalculated on the basis of the updated estimate of the group size, and this value is used to calculate a new send time. If the new send time is in the future, the packet is not sent but is rescheduled for that time.

This procedure may sound complex, but it is actually simple to implement. Consider the pseudocode for the basic transmission rules, which can be written like this:

if (current_time >= next_rtcp_send_time) {
    send RTCP packet
    next_rtcp_send_time = rtcp_interval() + current_time
}

With forward reconsideration, this changes to the following:

if (current_time >= next_rtcp_check_time) {
  new_rtcp_send_time = (rtcp_interval() / 1.21828) + last_rtcp_send_time
  if (current_time >= new_rtcp_send_time) {
    send RTCP packet
    next_rtcp_check_time = (rtcp_interval() /1.21828) + current_time
  } else {
    next_rtcp_check_time = new_send_time
  }
}

Here the function rtcp_interval() returns a randomized sampling of the reporting interval, based on the current estimate of the session size. Note the division of rtcp_interval() by a factor of 1.21828 (Euler's constant e minus 1.5). This is a compensating factor for the effects of the reconsideration algorithm, which converges to a value below the desired 5% bandwidth fraction.

The effect of reconsideration is to delay RTCP packets when the estimate of the group size is increasing. This effect is shown in Figure 5.13, which illustrates that the initial burst of packets is greatly reduced when reconsideration is used, comprising only 75 packets—rather than 10,000—before the other participants learn to scale back their reporting interval.

Figure 5.13. The Effect of Forward Reconsideration on RTCP Send Rates (Adapted from J. Rosenberg and H. Schulzrinne, “Timer Reconsideration for Enhanced RTP Scalability,” Proceedings of IEEE Infocom '98, San Francisco, CA, March 1998. © 1998 IEEE.)

As another example, consider the scenario discussed in the previous section, Basic Transmission Rules, in which a new listener is joining an established Internet radio station using multicast RTP. When the listener is joining the session, the first RTCP packet is scheduled as before, between 1.25 and 3.75 seconds after the application is started. The difference comes when the scheduled transmission time arrives: Rather than sending the packet, the application reconsiders the schedule on the basis of the current estimate of the number of members. As was calculated before, assuming a random initial interval of 2.86 seconds, the application will have received about 19 RTCP packets from the other members, and a new average interval of 2.85 seconds will be calculated:

Interval = number of receivers * average RTCP size / (75% of RTCP bandwidth)
         =    19  *  90 / (0.75  * (0.05 * 16000 octets/second))
        = 1710/ 600
        = 2.85 seconds

The result is less than the minimum, so the minimum of 5 seconds is used, randomized and divided by the scaling factor. If the resulting value is less than the current time (in this example 2.85 seconds after the application started), then the packet is sent. If not—for example, if the new randomized value is 5.97 seconds— the packet is rescheduled for the later time.

After the new timer expires (in this example 5.97 seconds after the application started), the reconsideration process takes place again. At this time the receiver will have received RTCP packets from approximately 5.97 seconds × 6.66 per second = 40 other members, and the recalculated RTCP interval will be 6 seconds before randomization and scaling. The process repeats until the reconsidered send time comes out before the current time. At that point the first RTCP packet is sent, and the second is scheduled.

Reconsideration is simple to implement, and it is recommended that all implementations include it, even though it has significant effects only after the number of participants reaches several hundred. An implementation that includes forward reconsideration will be safe no matter what size the session, or how many participants join simultaneously. One that uses only the basic transmission rules may send RTCP too often, causing network congestion in large sessions with synchronized joins.

If there are problems with step joins, one might reasonably expect there to be problems due to the rapid departure of many participants (a step leave). This is indeed the case with the basic transmission rules, although the problem is not with RTCP being sent too often and causing congestion, but with it not being sent often enough, causing premature timeout of participants.

The problem occurs when most, but not all, of the members leave a large session. As a result the reporting interval decreases rapidly, perhaps from several minutes to several seconds. With the basic transmission rules, however, packets are not rescheduled after the change, although the timeout interval is updated. The result is that those members who did not leave are marked as having timed out; their packets do not arrive within the new timeout period.

The problem is solved in a similar way to that of step joins: When each BYE packet is received, the estimate of the number of participants is updated, and the send time of the next RTCP packet is reconsidered. The difference from forward reconsideration is that the estimate will be getting smaller, so the next packet is sent earlier than it would otherwise have been.

When a BYE packet is received, the new transmission time is calculated on the basis of the fraction of members still present after the BYE, and the amount of time left before the original scheduled transmission time. The procedure is as follows:

if (BYE packet received) {
  member_fraction = num_members_after_BYE / num_members_before_BYE
  time_remaining  = next_rtcp_send_time – current_time
  next_rtcp_send_time = current_time + member_fraction * time_remaining
}

The result is a new transmission time that is earlier than the original value, but later than the current time. Packets are therefore scheduled early enough that the remaining members do not time each other out, preventing the estimate of the number of participants from erroneously falling to zero.

Implementation of reverse reconsideration is a secondary concern: It's an issue only in sessions with several hundred participants and rapid changes in membership, and failing to implement it may result in false timeouts but no networkwide problems.

In the proposed standard version of RTP,⁶ a member desiring to leave a session sends a BYE packet immediately, then exits. If many members decide to leave at once, this can cause a flood of BYE packets and can result in network congestion (much as happens with RTCP packets during a step join, if forward reconsideration is not employed).

To avoid this problem, the current version of RTP allows BYE packets to be sent immediately only if there are fewer than 50 members when a participant decides to leave. If there are more than 50 members, the leaving member should delay sending a BYE if other BYE packets are received while it is preparing to leave, a process called BYE reconsideration.

BYE reconsideration is analogous to forward reconsideration, but based on a count of the number of BYE packets received, rather than the number of other members. When a participant wants to leave a session, it suspends normal processing of RTP/RTCP packets and schedules a BYE packet according to the forward reconsideration rules, calculated as if there were no other members and as if this were the first RTCP packet to be sent. While waiting for the scheduled transmission time, the participant ignores all RTP and RTCP packets except for BYE packets. The BYE packets received are counted, and when the scheduled BYE transmission time arrives, it is reconsidered on the basis of this count. The process continues until the BYE is sent, and then the participant leaves the session.

As this description suggests, the delay before a BYE can be sent depends on the number of members leaving. If only a single member decides to leave, the BYE will be delayed between 1.026 and 3.078 seconds (based on a 5-second minimum reporting interval, halved because BYE packets are treated as if they're the initial RTCP packet). If many participants decide to leave at once, there may be a considerable delay between deciding to leave a session and being able to send the BYE packet. If a fast exit is needed, it is safe to leave the session without sending a BYE; other participants will time out their state eventually.

The use of BYE reconsideration is a relatively minor decision: It is useful only when many participants leave a session at once, and when the others care about receiving notification that a participant has left. It is safe to leave large sessions without sending a BYE, rather than implementing the BYE reconsideration algorithm.

The reconsideration rules were introduced to allow RTCP to scale to very large sessions in which the membership changes rapidly. I recommend that all implementations include reconsideration, even if they are initially intended only for use in small sessions; this will prevent future problems if the tool is used in a way the designer did not foresee.

On first reading, the reconsideration rules appear complex and difficult to implement. In practice, they add a small amount of additional code. My implementation of RTP and RTCP consists of about 2,500 lines of C code (excluding sockets and encryption code). Forward and reverse reconsideration together add only 15 lines of code. BYE reconsideration is more complex, at 33 lines of code, but still not a major source of difficulty.

Correct operation of the reconsideration rules depends to a large extent on the statistical average of the behavior of many individual participants. A single incorrect implementation in a large session will cause little noticeable difference to the behavior, but many incorrect implementations in a single session can lead to significant congestion problems. For small sessions, this is largely a theoretical problem, but as the session size increases, the effects of bad RTCP implementations are magnified and can cause network congestion that will affect the quality of the audio and/or video.

The most common problems observed with RTCP implementations relate to the basic transmission rules, and to the bandwidth calculation:

When testing the behavior of an RTCP implementation, it is important to use a range of scenarios. Problems can be found in tests of both large and small sessions, sessions in which the membership changes rapidly, sessions in which a large fraction of the participants are senders and in which few are senders, and sessions in which step joins and leaves occur. Testing large-scale sessions is inherently difficult. If an implementation can be structured to be independent of the underlying network transport system, it will allow the simulation of large sessions on a single test machine.

The IETF audio/video transport working group has produced a document describing testing strategies for RTP implementations,⁴⁰ which may also be useful.