2. RTP and RTCP Packet Formats and Protocol Behavior

2.1. RTP

The rules defined in [2] also apply to this profile except for those rules mentioned in the following:

RTCP packet types:

Two additional RTCP packet types are registered and the corresponding FB messages to convey feedback information are defined in Section 6 of this memo.

RTCP report intervals:

This document describes three modes of operation that influence the RTCP report intervals (see Section 3.2 of this memo). In Regular RTCP mode, all rules from [1] apply except for the recommended minimal interval of five seconds between two RTCP reports from the same RTP entity. In both Immediate Feedback and Early RTCP modes, the minimal interval of five seconds between two RTCP reports is dropped and, additionally, the rules specified in Section 3 of this memo apply if RTCP packets containing FB messages (defined in Section 4 of this memo) are to be transmitted.

The rules set forth in [1] may be overridden by session descriptions specifying different parameters (e.g., for the bandwidth share assigned to RTCP for senders and receivers, respectively). For sessions defined using the Session Description Protocol (SDP) [3], the rules of [4] apply.

Congestion control:

The same basic rules as detailed in [2] apply. Beyond this, in Section 7, further consideration is given to the impact of feedback and a sender's reaction to FB messages.

2.2. Underlying Transport Protocols

RTP is intended to be used on top of unreliable transport protocols, including UDP and the Datagram Congestion Control Protocol (DCCP). This section briefly describes the specifics beyond plain RTP operation introduced by RTCP feedback as specified in this memo.

UDP: UDP provides best-effort delivery of datagrams for point-to-point as well as for multicast communications. UDP does not support congestion control or error repair. The RTCP-based feedback defined in this memo is able to provide minimal support for limited error repair. As RTCP feedback is not guaranteed to operate on sufficiently small timescales (in the order of RTT), RTCP feedback is not suitable to support congestion control. This memo addresses both unicast and multicast operation.

DCCP: DCCP [19] provides for congestion-controlled but unreliable datagram flows for unicast communications. With TCP Friendly Rate Control (TFRC)-based [20] congestion control (CCID 3), DCCP is particularly suitable for audio and video communications. DCCP's acknowledgement messages may provide detailed feedback reporting about received and missed datagrams (and thus about congestion).

When running RTP over DCCP, congestion control is performed at the DCCP layer and no additional mechanisms are required at the RTP layer. Furthermore, an RTCP-feedback-capable sender may leverage the more frequent DCCP-based feedback and thus a receiver may refrain from using (additional) Generic Feedback messages where appropriate.