diff options
Diffstat (limited to 'doc/rfc/rfc5506.txt')
| -rw-r--r-- | doc/rfc/rfc5506.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5506.txt b/doc/rfc/rfc5506.txt new file mode 100644 index 0000000..6e9d84e --- /dev/null +++ b/doc/rfc/rfc5506.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group I. Johansson +Request for Comments: 5506 M. Westerlund +Updates: 3550, 3711, 4585 Ericsson AB +Category: Standards Track April 2009 + + + Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): + Opportunities and Consequences + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + +Johansson & Westerlund Standards Track [Page 1] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + +Abstract + + This memo discusses benefits and issues that arise when allowing + Real-time Transport Protocol (RTCP) packets to be transmitted with + reduced size. The size can be reduced if the rules on how to create + compound packets outlined in RFC 3550 are removed or changed. Based + on that analysis, this memo defines certain changes to the rules to + allow feedback messages to be sent as Reduced-Size RTCP packets under + certain conditions when using the RTP/AVPF (Real-time Transport + Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). + This document updates RFC 3550, RFC 3711, and RFC 4585. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 3. Use Cases and Design Rationale ..................................4 + 3.1. RTCP Compound Packets (Background) .........................4 + 3.2. Use Cases for Reduced-Size RTCP ............................6 + 3.3. Benefits of Reduced-Size RTCP ..............................7 + 3.4. Issues with Reduced-Size RTCP ..............................8 + 3.4.1. Middle Boxes ........................................9 + 3.4.2. Packet Validation ...................................9 + 3.4.3. Encryption/Authentication ..........................10 + 3.4.4. RTP and RTCP Multiplex on the Same Port ............10 + 3.4.5. Header Compression .................................11 + 4. Use of Reduced-Size RTCP with AVPF .............................11 + 4.1. Definition of Reduced-Size RTCP ...........................12 + 4.2. Algorithm Considerations ..................................12 + 4.2.1. Verification of Delivery ...........................12 + 4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP .....13 + 4.2.3. Enforcing Compound RTCP ............................13 + 4.2.4. Immediate Feedback Mode ............................14 + 5. Signaling ......................................................14 + 6. Security Considerations ........................................14 + 7. IANA Considerations ............................................14 + 8. Acknowledgements ...............................................15 + 9. References .....................................................15 + 9.1. Normative References ......................................15 + 9.2. Informative References ....................................16 + + + + + + + + + + + +Johansson & Westerlund Standards Track [Page 2] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + +1. Introduction + + In RTP [RFC3550] it is currently mandatory to send RTP Control + Protocol (RTCP) packets as compound packets containing at least a + sender report (SR) or receiver report (RR), followed by a source + description (SDES) packet containing at least the CNAME item. There + are good reasons for this, as discussed below (see Section 3.1); + however, it does result in the minimal RTCP packets being quite + large. + + The RTP/AVPF profile [RFC4585] specifies new RTCP packet types for + feedback messages. Some of these feedback messages would benefit + from being transmitted with minimal delay. AVPF provides some + mechanisms to support this; however, for environments with low- + bitrate links, these messages can still consume a large amount of + resources and can introduce extra delay in the time it takes to + completely send the compound packet in the network. It is therefore + desirable to send just the feedback, without the other parts of a + compound RTCP packet. This memo proposes such a mechanism for this + and other use cases, as discussed in Section 3.2. + + There are a number of benefits with Reduced-Size RTCP; these are + discussed in Section 3.3. + + The use of Reduced-Size RTCP is not without issues. This is + discussed in Section 3.4. These issues need to be considered and are + part of the motivation for this document. + + Finally, this document defines how AVPF is updated to allow for the + transmission of Reduced-Size RTCP in a way that would not + substantially affect the mechanisms that compound packets provide; + see Section 4 for more details. The connection to AVPF (or SAVPF + [RFC5124]) is motivated by the fact that Reduced-Size RTCP is mainly + beneficial for event-driven feedback purposes and that the AVPF Early + RTCP and Immediate Feedback modes make this possible. + + This document updates [RFC3550], [RFC3711], and [RFC4585]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + The naming convention for RTCP is often confusing. Below is a list + of RTCP terms and what they mean. See also Section 6.1 in [RFC3550] + and Section 3.1 in [RFC4585] for details. + + + + +Johansson & Westerlund Standards Track [Page 3] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + RTCP packet: Can be of different types, contains a fixed header part + followed by structured elements depending on RTCP packet type. + + Lower layer datagram: Can be interpreted as the UDP payload. It may + however, depending on the transport, be a TCP or Datagram + Congestion Control Protocol (DCCP) payload or something else. + Synonymous to the "underlying protocol" defined in Section 3 in + [RFC3550]. + + Compound RTCP packet: A collection of two or more RTCP packets. A + compound RTCP packet is transmitted in a lower-layer datagram. It + must contain at least an RTCP RR or SR packet and an SDES packet + with the CNAME item. Often "compound" is left out, the + interpretation of RTCP packet is therefore dependent on the + context. + + Minimal compound RTCP packet: A compound RTCP packet that contains + the RTCP RR or SR packet and the SDES packet with the CNAME item + with a specified ordering. + + (Full) compound RTCP packet: A compound RTCP packet that conforms to + the requirements on minimal compound RTCP packets and contains + more RTCP packets. + + Reduced-Size RTCP packet: May contain one or more RTCP packets but + does not follow the compound RTCP rules defined in Section 6.1 in + [RFC3550] and is thus neither a minimal nor a full compound RTCP. + See Section 4.1 for a full definition. + +3. Use Cases and Design Rationale + +3.1. RTCP Compound Packets (Background) + + Section 6.1 in [RFC3550] specifies that an RTCP packet must be sent + as a compound RTCP packet consisting of at least two individual RTCP + packets, first a sender report (SR) or receiver report (RR), followed + by additional packets including a mandatory SDES packet containing a + CNAME item for the transmitting source identifier. Below is a short + description of what these RTCP packet types are used for. + + 1. The sender and receiver reports (see Section 6.4 of [RFC3550]) + provide the RTP session participant with the synchronization + source (SSRC) identifier of all RTP session participants. Having + all participants send these packets periodically allows everyone + to determine the current number of participants. This + information is used in the transmission scheduling algorithm. + Thus, this is particularly important for new participants so that + + + + +Johansson & Westerlund Standards Track [Page 4] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + they can quickly establish a good estimate of the group size. + Failure to do this would result in RTCP senders consuming too + much bandwidth. + + 2. Before a new session participant has sent any RTP or RTCP packet, + it can also avoid SSRC collisions with all the SSRCs it sees + prior to that transmission. So the possibility to see a + substantial proportion of the participating sources minimizes the + risk of any collision when selecting SSRC. + + 3. The sender and receiver reports contain some basic statistics + usable for monitoring of the transport and thus enable + adaptation. These reports become more useful if sent regularly, + as the receiver of a report can perform analyses to find trends + between the individual reports. When used for media transmission + adaptation, the information becomes more useful the more + frequently it is received, at least until one report per round- + trip time (RTT) is achieved. Therefore, there is, in most cases, + no reason not to include the sender or receiver report in all + RTCP packets. + + 4. The CNAME SDES item (see Section 6.5.1 of [RFC3550]) exists to + allow receivers to determine which media flows should be + synchronized with each other, both within an RTP session and + between different RTP sessions carrying different media types. + Thus, it is important to quickly receive this for each media + sender in the session when joining an RTP session. + + 5. Sender reports (SR) are used in combination with the above SDES + CNAME mechanism to synchronize multiple RTP streams, such as + audio and video. After having determined which media streams + should be synchronized using the CNAME field, the receiver uses + the sender report's NTP and RTP timestamp fields to establish + synchronization. + + 6. The CNAME SDES item also allows a session participant to detect + SSRC collisions and separate them from routing loops. The 32- + bit, randomly selected SSRC has some probability of collision. + The CNAME is used as the longer canonical identifier of a + particular endpoint instance that is bound to an SSRC. If that + binding isn't received and kept current, the receiver may not + detect an SSRC collision, i.e., two different CNAMEs using the + same SSRC. It also can't detect an RTP-level routing loop, with + the result that the same SSRC and CNAME arrive from multiple + lower-layer source addresses. + + + + + + +Johansson & Westerlund Standards Track [Page 5] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + Reviewing the above, it is obvious that both SR/RR and the CNAME are + very important in order for new session participants to be able to + utilize any received media and to avoid flooding the network with + RTCP reports. In addition, the dynamic nature of the information + provided would make it less useful if not sent regularly. + + The following sections will describe the cases when Reduced-Size RTCP + is beneficial and will also show the possible issues that must be + considered. + +3.2. Use Cases for Reduced-Size RTCP + + Below are listed a few use cases for Reduced-Size RTCP. + + Control Plane Signaling: The Open Mobile Alliance (OMA) Push-to-talk + over Cellular (PoC) [OMA-PoC] makes use of Reduced-Size RTCP when + transmitting certain events. The OMA PoC service is primarily + used over cellular links capable of IP transport, such as the + Global System for Mobile Connections (GSM) General Packet Radio + Service (GPRS). + + Codec Control Signaling: An example that can be used with Reduced- + Size RTCP is, e.g., Temporary Maximum Media Stream Bitrate Request + (TMMBR) messages as specified in [RFC5104], which signal a request + for a change in codec bitrate. These messages benefit from the + usage of Reduced-Size RTCP in bad channel conditions, as Reduced- + Size RTCP are much more likely to be successfully transmitted than + larger compound RTCP. This is critical, as these messages are + likely to occur when channel conditions are poor. Other examples + of codec control usage for Reduced-Size RTCP are found in + [MTSI-3GPP]. + + Feedback: An example of a feedback scenario that would benefit from + Reduced-Size RTCP is Video streams with generic NACK. In cases + where the RTT is shorter than the receiver buffer depth, generic + NACK can be used to request retransmission of missing packets, + thus improving playout quality considerably. If the generic NACK + packets are transmitted as Reduced-Size RTCP, the bandwidth + requirement for RTCP will be minimal, enabling more frequent + feedback. As in the codec control case, it is important that + these packets can be transmitted with as little delay as possible. + Another interesting use for Reduced-Size RTCP is in cases when + regular feedback is needed, as described in Section 3.3. + + Status Reports: One proposed idea is to transmit small measurement + or status reports in Reduced-Size RTCP, and to split the minimal + compound RTCP and transmit the individual RTCP separately. The + status reports can be used either by the endpoints or by other + + + +Johansson & Westerlund Standards Track [Page 6] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + network monitoring boxes in the network. The benefit is that, + with some radio access technologies, small packets are more robust + to poor radio conditions than large packets. Additionally, with + small (report) packets, there is a smaller risk that the report + packets will affect the channel upon which they report. Another + benefit is that it is possible, with Reduced-Size RTCP, to allow, + for example, anonymous status reporting to be transmitted + unencrypted. This is something that may be beneficial, for + instance, for network monitoring purposes. + +3.3. Benefits of Reduced-Size RTCP + + As mentioned in the introduction, most advantages of using Reduced- + Size RTCP packets exist in cases when the available RTCP bitrate is + limited. This is because they can become substantially smaller than + compound packets. A compound packet is forced to contain both an RR + or an SR and the CNAME SDES item. The RR containing a report block + for a single source is 32 bytes, an SR is 52 bytes. Both may be + larger if they contain report blocks for multiple sources. The SDES + packet containing a CNAME item will be 10 bytes plus the CNAME string + length. Here, it is reasonable that the CNAME string is at least 10 + bytes to get a decent collision resistance. If the recommended form + of user@host is used, then most strings will be longer than 20 + characters. Thus, a Reduced-Size RTCP can become at least 70-80 + bytes smaller than the compound packet. + + For low bitrate links, the benefits of this reduction in size are as + follows: + + o For links where the packet-loss rate grows with the packet size, + smaller packets are less likely to be dropped. Radio links are an + example of such links. In the cellular world, there exist links + that are optimized to handle RTP packets sized for carrying + compressed speech. This increases the capacity and coverage for + voice services in a given wireless network. Minimal compound RTCP + packets are commonly 2-3 times the size of an RTP packet carrying + compressed speech. If the speech packet over such a bearer has a + packet-loss probability of p, then the RTCP packet will experience + a loss probability of 1-(1-p)^x, where x is the number of + fragments the compound packet will be split into on the link + layer, i.e., commonly into 2 or 3 fragments. + + o There is a shorter serialization time, i.e., the time it takes the + link to transmit the packet. For slower links, this time can be + substantial. For example, transmitting 120 bytes over a link + interface capable of 30 kbps takes 32 milliseconds (ms), assuming + uniform transmission rate. + + + + +Johansson & Westerlund Standards Track [Page 7] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + In cases when Reduced-Size RTCP carries important and time-sensitive + feedback, both shorter serialization time and the lower loss + probability are important to enable the best possible functionality. + Having a packet-loss rate that is much higher for the feedback + packets than the media packets hurts when trying to perform media + adaptation to, for example, handle the changed performance present at + the cell border in a cellular system. + + For high-bitrate applications, there is usually no problem to supply + RTCP with sufficient bitrates. When using AVPF, one can use the + "trr-int" parameter to restrict the regular reporting interval to + approximately once per RTT or less often. As in most cases, there is + little reason to provide regular reports of higher density than this; + any additional bandwidth can then be used for feedback messages. The + benefit of Reduced-Size RTCP in this case is limited, but exists. + One typical example is video using generic NACK in cases where the + RTT is low. Using Reduced-Size RTCP would reduce the total amount of + bits used for RTCP. This is primarily applicable if the number of + reports is large. This would also result in lower processing delay + and less complexity for the feedback packets, as they do not need to + query the RTCP database to construct the right messages. + + As message size is generally a smaller issue at higher bitrates, it + is also possible to transmit multiple RTCP in each lower-layer + datagram in these cases. The motivation behind Reduced-Size RTCP in + this case is not size, rather it is to avoid the extra overhead + caused by inclusion of the SR/RR and SDES CNAME items in each + transmitted RTCP. + + Independently of the link type, there are additional benefits with + sending feedback in small Reduced-Size RTCP. Applications that use + RTCP AVPF in Early RTCP or Immediate Feedback mode need to send + frequent event-driven feedback. Under these circumstances, the risk + is reduced that the RTCP bandwidth becomes too high during periods of + heavy feedback signaling. + + In cases when regular feedback is needed, such as the profile under + development for TCP friendly rate control (TFRC) for RTP + [TCP-FRIEND], the size of compound RTCPs can result in very high + bandwidth requirements if the round-trip time is short. For this + particular application, Reduced-Size RTCP gives a very substantial + improvement. + +3.4. Issues with Reduced-Size RTCP + + This section describes the known issues with Reduced-Size RTCP and + also provides a brief analysis of their effects and mitigation. + + + + +Johansson & Westerlund Standards Track [Page 8] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + +3.4.1. Middle Boxes + + Middle boxes in the network may discard RTCP that do not follow the + rules outlined in Section 6.1 of RFC 3550. Newer report types may be + interpreted as unknown by the middle box. For instance, if the + payload type number is 207 instead of 200 or 201, it may be treated + as unknown. The effect of this might, for instance, be that compound + RTCP would get through while the Reduced-Size RTCP would be lost. + + Verification of the delivery of Reduced-Size RTCP is discussed in + Section 4.2.1. + +3.4.2. Packet Validation + + A Reduced-Size RTCP packet will be discarded by the packet validation + code in Appendix A of [RFC3550]. This has several impacts: + + Weakened Packet Validation: The packet validation code needs to be + rewritten to accept Reduced-Size RTCP. In particular, this + affects Section 9.1 in [RFC3550] in the sense that the header + verification must take into account that the payload type numbers + for the (first) RTCP in the lower-layer datagram may differ from + 200 or 201 (SR or RR). One potential effect of this change is + much weaker validation that received packets actually are RTCP and + not packets of some other type being wrongly delivered. Thus, + some consideration should be given to ensure the best possible + validation is available, for example, restricting Reduced-Size + RTCP to contain only some specific RTCP packet types that are + preferably signalled on a per-session basis. However, the + application of a security mechanism for source authentication on + the packets will provide much stronger protection. + + Old RTP Receivers: Any RTCP receiver without an updated packet + validation code will discard the Reduced-Size RTCP, which means + that the receiver will not see e.g., the contained feedback + messages. The effect of this depends on the type of feedback + message and the role of the receiver. For example, this may cause + complete function loss in the case of attempting to send a + Reduced-Size NACK message (see Section 6.2.1 of [RFC4585]) to a + non-updated media sender in a session using the retransmission + scheme defined by [RFC4588]. This type of discarding would also + affect the feedback suppression defined in AVPF. The result would + be a partitioning of the receivers within the session, with the + old receivers only seeing the compound RTCP feedback messages and + the newer ones seeing both. In this case, the old receivers may + send feedback messages for events already reported on in Reduced- + Size RTCP. + + + + +Johansson & Westerlund Standards Track [Page 9] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + Bandwidth Considerations: The discarding of Reduced-Size RTCP would + affect the RTCP transmission calculation in that the avg_rtcp_size + value would become larger than for RTP receivers that exclude the + Reduced-Size RTCP in this calculation (assuming that Reduced-Size + RTCP are smaller than compound ones). Therefore, these senders + would under-utilize the available bitrate and send with a longer + interval than updated receivers. For most sessions, this should + not be an issue. However, for sessions with a large portion of + Reduced-Size RTCP, the updated receivers may time out non-updated + senders prematurely. This is, however, not likely to occur, as + the time between compound RTCP transmissions needs to become 5 + times that used by the Reduced-Size RTCP senders for it to happen. + + Computation of avg_rtcp_size: Long intervals between compound RTCP + with many Reduced-Size RTCP in between may lead to a computation + of a value for avg_rtcp_size that varies greatly over time. + Investigation shows that although it varies, this is not enough of + a problem to warrant further changes or complexities to the RTCP + scheduling algorithm. + +3.4.3. Encryption/Authentication + + The Secure Real-time Transport Protocol (SRTP) presents a problem for + Reduced-Size RTCP. Section 3.4 of [RFC3711] states, "SRTCP MUST be + given packets according to that requirement in the sense that the + first part MUST be a sender report or a receiver report". + + Upon examination of how SRTP processes packets, it becomes obvious + that SRTP has no real dependency on whether the first packet is an SR + or an RR packet. What is needed is the common RTCP packet header, + which is present in all the packet types, with a source SSRC. The + conclusion is therefore that it is possible to use Reduced-Size RTCP + with SRTP. Nevertheless, as this implies a change to the rules in + [RFC3711], changes in SRTP implementations MAY become necessary. + +3.4.4. RTP and RTCP Multiplex on the Same Port + + In applications in which multiplex RTP and RTCP are on the same port, + as defined in [MULTI-RTP], care must be taken to ensure that de- + multiplexing is done properly even though the RTCP packets are + reduced size. The downside of Reduced-Size RTCP is that more values + representing RTCP packets exist, reducing the available RTP payload + type space. However, Section 4 in [MULTI-RTP] already requires the + corresponding RTP payload type range not be used when performing this + multiplexing. + + + + + + +Johansson & Westerlund Standards Track [Page 10] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + +3.4.5. Header Compression + + Two issues are related to header compression. Possible changes are + left for future work: + + o Payload type number identification: The Robust Header Compression + (RoHC) algorithm [RFC3095] needs to create different compression + contexts for RTP and RTCP for optimum performance. If RTP and + RTCP are multiplexed on the same port, the classification may be + based on payload type numbers. The classification algorithm must + here acknowledge the fact that the payload type number for (the + first) RTCP may differ from 200 or 201. + + o Compression of RTCP: No IETF-defined header compression method + compress RTCP; however, if such methods are developed in the + future, these methods must take Reduced-Size RTCP in account. + +4. Use of Reduced-Size RTCP with AVPF + + Based on the above analysis, it seems feasible to allow transmission + of Reduced-Size RTCP under some restrictions: + + o First of all, it is important that compound RTCPs are transmitted + at regular intervals to ensure that the mechanisms maintained by + the compound packets, like feedback reporting, work. The tracking + of session size and number of participants warrants mentioning + again, as this ensures that the RTCP bandwidth remains bounded + independent of the number of session participants. + + o Second, as the compound RTCP packets are also used to establish + and maintain synchronization between media, any newly joining + participant in a session would need to receive compound RTCP from + the media sender(s). + + This implies that the regular transmission of compound RTCP MUST be + maintained throughout an RTP session. Reduced-Size RTCP SHOULD be + restricted to be used as extra RTCP (e.g., feedback), sent in cases + when a regular compound RTCP packet would not otherwise have been + sent. + + The usage of Reduced-Size RTCP SHALL only be done in RTP sessions + operating in AVPF [RFC4585] or SAVPF [RFC5124] Early RTCP or + Immediate Feedback mode. Reduced-Size RTCP SHALL NOT be sent until + at least one compound RTCP has been sent. In Immediate Feedback + mode, all feedback messages MAY be sent as Reduced-Size RTCP. In + Early RTCP mode, a feedback message scheduled for transmission as an + + + + + +Johansson & Westerlund Standards Track [Page 11] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + Early RTCP, i.e., not a Regular RTCP, MAY be sent as Reduced-Size + RTCP. All RTCP that are scheduled for transmission as Regular RTCP + SHALL be sent as compound RTCP as indicated by AVPF [RFC4585]. + +4.1. Definition of Reduced-Size RTCP + + A Reduced-Size RTCP packet is an RTCP packet with the following + properties that make it deviate from the compound RTCP packet + definition given in Section 6.1 in [RFC3550]: + + o contains one or more RTCP packet(s) + + o allows any RTCP packet type; however, see Section 4.2.1 + + o MUST NOT be used for Regular (scheduled) RTCP report purposes + + o MUST NOT be used with the RTP/AVP profile [RFC3551] or the + RTP/SAVP profile [RFC3711] + +4.2. Algorithm Considerations + +4.2.1. Verification of Delivery + + If an application is to use Reduced-Size RTCP, it is important to + verify that the Reduced-Size RTCP packets actually reach the session + participants. As outlined above in Section 3.4.1 and Section 3.4.2, + packets may be discarded along the path or in the endpoint. + + A few verification rules are RECOMMENDED to ensure robust RTCP + transmission and reception and to solve the identified issues when + Reduced-Size RTCP is used: + + o The endpoint issue can be solved by introducing signaling that + informs if all session participants are capable of Reduced-Size + RTCP. See Section 5. + + o The middle box issue is more difficult, and here one will be + required to use heuristics to determine whether or not the + Reduced-Size RTCP packets are delivered. The method used to + detect successful delivery of Reduced-Size RTCP packets depends on + the packet type. The RTCP packet types for which successful + delivery can be detected are: + + * Sender reports (SR): Successful transmission of a sender report + can be verified by inspection of the echoed timestamp in the + received receiver report (RR). This can also be used as a + method to verify if Reduced-Size RTCP can be used at all. + + + + +Johansson & Westerlund Standards Track [Page 12] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + * Feedback RTCP packets: In many cases, the feedback messages + sent using Reduced-Size RTCP will result in either explicit or + implicit indications that they have been received. An example + of this is the RTP retransmission [RFC4588] that results from a + NACK message [RFC4585]. Another example is the Temporary + Maximum Media Stream Bitrate Notification (TMMBN) message + resulting from a Temporary Maximum Media Stream Bitrate Request + (TMMBR) [RFC5104]. A third example is the presence of a + decoder refresh point [RFC5104] in the video media stream + resulting from the Full Intra Request that was sent. + + RTCP packet types for which it is not possible to detect + successful delivery SHOULD NOT be transmitted as Reduced-Size RTCP + packets unless they are transmitted in the same lower-layer + datagram as another RTCP packet type for which successful delivery + can be detected. + + o An algorithm to detect consistent failure of delivery of Reduced- + Size RTCP MUST be used by any application using Reduced-Size RTCP. + The details of this algorithm are application dependent and + therefore outside the scope of this document. + + If the verification fails, it is strongly RECOMMENDED that only + compound RTCP, according to the rules outlined in RFC 3550, is + transmitted. + +4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP + + The result of the definition in Section 4.1 may be that the resulting + size of Reduced-Size RTCP can become larger than a regularly + scheduled compound RTCP packet. For applications that use access + types that are sensitive to packet size (see Paragraph 2 in + Section 3.3), it is strongly RECOMMENDED that the use of Reduced-Size + RTCP is limited to the transmission of a single RTCP packet in each + lower-layer datagram. The method to determine the need for this is + outside the scope of this document. + + In general, as the benefit with large Reduced-Size RTCP packets is + very limited, it is strongly RECOMMENDED to transmit large Reduced- + Size RTCP packets as compound RTCP packets instead. + +4.2.3. Enforcing Compound RTCP + + As discussed earlier, it is important that the transmission of + compound RTCP occurs at regular intervals. However, this will occur + as long as the RTCP senders follow the AVPF scheduling algorithm + + + + + +Johansson & Westerlund Standards Track [Page 13] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + defined in Section 3.5 of [RFC4585]. This follows as all Regular + RTCP MUST be full compound RTCP. Note that there is also a + requirement on sending Regular RTCP in Immediate Feedback mode. + +4.2.4. Immediate Feedback Mode + + Section 3.3 of [RFC4585] gives the option to use AVPF Immediate + Feedback mode as long as the group size is below a certain limit. As + transmissions using Reduced-Size RTCP may reduce the bandwidth + demand, such transmissions also open up the possibility of a more + liberal use of Immediate Feedback mode. + +5. Signaling + + This document defines the "a=rtcp-rsize" Session Description Protocol + (SDP) [RFC4566] attribute to indicate if the session participant is + capable of supporting Reduced-Size RTCP for applications that use SDP + for configuration of RTP sessions. It is REQUIRED that a participant + that proposes the use of Reduced-Size RTCP shall itself support the + reception of Reduced-Size RTCP. + + An offering client that wishes to use Reduced-Size RTCP MUST include + the attribute "a=rtcp-rsize" in the SDP offer. If "a=rtcp-rsize" is + present in the offer SDP, the answerer that supports Reduced-Size + RTCP and wishes to use it SHALL include the "a=rtcp-rsize" attribute + in the answer. + + In declarative usage of SDP, such as the Real Time Streaming Protocol + (RTSP) [RFC2326] and the Session Announcement Protocol (SAP) + [RFC2974], the presence of the attribute indicates that the session + participant MAY use Reduced-Size RTCP packets in its RTCP + transmissions. + +6. Security Considerations + + The security considerations of RTP [RFC3550] and AVPF [RFC4585] will + apply also to Reduced-Size RTCP. The reduction in validation + strength for received packets on the RTCP port may result in a higher + degree of acceptance of spurious data as real RTCP. This + vulnerability can mostly be addressed by usage of any security + mechanism that provides authentication; one such mechanism is SRTP + [RFC3711]. + +7. IANA Considerations + + Following the guidelines in [RFC4566], the IANA has registered a new + SDP attribute: + + + + +Johansson & Westerlund Standards Track [Page 14] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + + o Contact name, email address, and telephone number: Authors of RFC + 5506 + + o Attribute-name: rtcp-rsize + + o Long-form attribute name: Reduced-Size RTCP + + o Type of attribute: media-level + + o Subject to charset: no + + This attribute defines the support for Reduced-Size RTCP, i.e., the + possibility to transmit RTCP that does not conform to the rules for + compound RTCP defined in RFC 3550. It is a property attribute, which + does not take a value. + +8. Acknowledgements + + The authors would like to thank all the people who gave feedback on + this document. Special thanks go to Colin Perkins. + + This document also contains some text copied from [RFC3550], + [RFC4585], and [RFC3711]. We take this opportunity to thank the + authors of said documents. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio + and Video Conferences with Minimal Control", STD 65, + RFC 3551, July 2003. + + [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. + Rey, "Extended RTP Profile for Real-time Transport + Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", + RFC 4585, July 2006. + + [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile + for Real-time Transport Control Protocol (RTCP)-Based + Feedback (RTP/SAVPF)", RFC 5124, February 2008. + + + +Johansson & Westerlund Standards Track [Page 15] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + +9.2. Informative References + + [MTSI-3GPP] 3GPP, "Specification : 3GPP TS 26.114 (v8.2.0 or + later), http://www.3gpp.org/ftp/Specs/html-info/ + 26-series.htm", March 2007. + + [MULTI-RTP] Perkins, C. and M. Westerlund, "Multiplexing RTP Data + and Control Packets on a Single Port", Work + in Progress, August 2007. + + [OMA-PoC] Open Mobile Alliance, "Specification : Push to talk + Over Cellular User Plane, http:// + member.openmobilealliance.org/ftp/public_documents/poc/ + Permanent_documents/ + OMA-TS-PoC_UserPlane-V2_0-20080507-C.zip", + November 2006. + + [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time + Streaming Protocol (RTSP)", RFC 2326, April 1998. + + [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session + Announcement Protocol", RFC 2974, October 2000. + + [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, + H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., + Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, + K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust + Header Compression (ROHC): Framework and four profiles: + RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and + K. Norrman, "The Secure Real-time Transport Protocol + (SRTP)", RFC 3711, March 2004. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: + Session Description Protocol", RFC 4566, July 2006. + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", + RFC 4588, July 2006. + + [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, + "Codec Control Messages in the RTP Audio-Visual Profile + with Feedback (AVPF)", RFC 5104, February 2008. + + [TCP-FRIEND] Gharai, L., "RTP with TCP Friendly Rate Control", Work + in Progress, July 2007. + + + + +Johansson & Westerlund Standards Track [Page 16] + +RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 + + +Authors' Addresses + + Ingemar Johansson + Ericsson AB + Laboratoriegrand 11 + SE-971 28 Lulea + SWEDEN + + Phone: +46 73 0783289 + EMail: ingemar.s.johansson@ericsson.com + + + Magnus Westerlund + Ericsson AB + Faeroegatan 6 + SE-164 80 Stockholm + SWEDEN + + Phone: +46 10 7148287 + EMail: magnus.westerlund@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johansson & Westerlund Standards Track [Page 17] + |