universally accepted, because in some scenarios (wireless hand-off, announcement server, call center, and so forth) it might be desirable to send media from multiple sources during the progress of a call.

RTP supports encryption of the media through the secure RTP (SRTP) profile discussed in Chapter 14. RTP supports a number of different topologies [3] including unicast (point-to-point) and multicast (point-to-multipoint). They are summarized in Table 12.1. In RTP, a translator is an element that converts the codec or sampling rate of an RTP stream. An RTP mixer is an element that combines multiple RTP streams into a single RTP stream in a media specific way.

At the start of an RTP session, the sender randomly chooses an initial value of the timestamp and SSRC. If both the sender and receiver happen to choose the same SSRC, both sides choose again to ensure each have a different SSRC. Media samples are encoded by the codec. Based on the packetization interval, once a complete frame of media data is available, the RTP header is populated and the packet sent. The sampling instant is used to update the timestamp. The sequence number is updated for each RTP packet sent. The receiver first validates the RTP header, using the sequence number to determine if any packets have been lost or received out of sequence. The timestamp is used to playout the media sample by the codec.

12.2 RTP Control Protocol (RTCP)

The RTP Control Protocol (RTCP) is a related protocol also defined in RFC 3550 that allows participants in an RTP session to send each other quality reports and statistics, and exchange some basic identity information. The five types of RTCP packets are shown in Table 12.2. RTCP has been designed to scale for very large conferences. Because RTCP traffic is all overhead, the bandwidth allocated to these messages remains fixed regardless of the number of participants. That is, the more participants in a conference, the less frequently RTCP packets

Table 12.1

RTP Topologies

Point to point

Point to multipoint using multicast

Point to multipoint using an RTP translator

Point to multipoint using an RTP mixer

Point to multipoint using video switching MCUs

Point to multipoint using RTCP-terminating MCU

Nonsymmetric mixer/translators

Combined topologies

Table 12.2

RTCP Reports

Sender report (SR)

Receiver report (RR)

Source description (SDES)

Bye (BYE)

Application specific (APP)

are sent. For example, in a basic two-participant audio RTP session, the RTP/ AVP profile states that RTCP packets are to be sent about every 5 seconds; for four participants, RTCP packets can be sent every 10 seconds. Sender reports (SR) or receiver reports (RR) packets are sent the most frequently, with the other packet types being sent less frequently. The use of reports allows feedback on the quality of the connection including information such as:

•Number of packets sent and received;

•Number of packets lost;

•Packet jitter.

By default, RTCP uses the next highest port from the RTP port, although this can be changed in the offer/answer exchange as discussed in Chapter 13.

12.2.1 RTCP Reports

RTCP is always sent as a compound packet. This means that every RTCP packet starts with a sender report (SR) or receiver report (RR), then any additional packets. As their name suggests, sender reports are sent by media senders while receiver reports are sent by media receivers. Since RTP is unidirectional, a bidirection media session will have two RTP sessions and two RTCP sessions. A source description (SDES) packet is used to exchange information about the sender or receiver. A bye (BYE) packet is used to leave a multicast session. An application specific (APP) packet is used for RTCP extensions. An important RTCP extension is described in the next section.

12.2.2 RTCP Extended Reports

RTCP extended reports (RTCP-XR) [4] defines seven additional report blocks. They were defined due to limitation of the basic SR and RR. For example, the receiver report contains information about the average packet loss rate. However, for call quality, information about burst packet loss is much more important than average packet loss, since a good codec can cope with individual lost packets but not a long sequence of lost packets. In addition, RTCP-XR defines a way to