GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5506

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5506.txt · Last modified: 2009/04/09 16:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki