doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc6642.txt b/doc/rfc/rfc6642.txt
new file mode 100644
index 0000000..59cf9a4
--- /dev/null
+++ b/doc/rfc/rfc6642.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        Q. Wu, Ed.
+Request for Comments: 6642                                        F. Xia
+Category: Standards Track                                        R. Even
+ISSN: 2070-1721                                                   Huawei
+                                                               June 2012
+
+
+  RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report
+
+Abstract
+
+   In a large RTP session using the RTP Control Protocol (RTCP) feedback
+   mechanism defined in RFC 4585, a feedback target may experience
+   transient overload if some event causes a large number of receivers
+   to send feedback at once.  This overload is usually avoided by
+   ensuring that feedback reports are forwarded to all receivers,
+   allowing them to avoid sending duplicate feedback reports.  However,
+   there are cases where it is not recommended to forward feedback
+   reports, and this may allow feedback implosion.  This memo discusses
+   these cases and defines a new RTCP Third-Party Loss Report that can
+   be used to inform receivers that the feedback target is aware of some
+   loss event, allowing them to suppress feedback.  Associated Session
+   Description Protocol (SDP) signaling is also defined.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6642.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                   Standards Track                    [Page 1]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+      2.1. Requirements Notation ......................................3
+      2.2. Glossary ...................................................4
+   3. Example Use Cases ...............................................4
+      3.1. Source-Specific Multicast (SSM) Use Case ...................4
+      3.2. Unicast-Based Rapid Acquisition of Multicast Stream
+           (RAMS) Use Case ............................................5
+      3.3. RTP Transport Translator Use Case ..........................5
+      3.4. Multipoint Control Unit (MCU) Use Case .....................6
+      3.5. Mixer Use Case .............................................6
+   4. Protocol Overview ...............................................6
+   5. Format of RTCP Feedback Messages ................................7
+      5.1. Transport-Layer Feedback: Third-Party Loss Report (TPLR) ...8
+      5.2. Payload-Specific Feedback:  Third-Party Loss Report (TPLR) .8
+   6. SDP Signaling ...................................................9
+   7. Security Considerations ........................................10
+   8. IANA Considerations ............................................11
+   9. Acknowledgments ................................................11
+   10. References ....................................................12
+      10.1. Normative References .....................................12
+      10.2. Informative References ...................................12
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                   Standards Track                    [Page 2]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+1.  Introduction
+
+   The RTP Control Protocol (RTCP) feedback messages [RFC4585] allow the
+   receivers in an RTP session to report events and ask for action from
+   the media source (or a delegated feedback target when using unicast
+   RTCP feedback with Source-Specific Multicast (SSM) [RFC5760]).  There
+   are cases where multiple receivers may initiate the same, or an
+   equivalent, message towards the same media source or the same
+   feedback target.  When the receiver count is large, this behavior may
+   cause transient overload of the media source, the network, or both.
+   This is known as a "feedback storm" or a "NACK storm".
+
+   One scenario that can cause such feedback storms involves video Fast
+   Update requests.  A storm of these feedback messages can occur in
+   conversational multimedia scenarios like multipoint video switching
+   conference [RFC4587], where many receivers may simultaneously lose
+   synchronization with the video stream when the speaker is changed in
+   the middle of a session.  Receivers that issue Fast Update requests
+   (i.e., Full Intra Request (FIR) described in RFC 5104 [RFC5104]), can
+   cause an implosion of FIR requests from receivers to the same media
+   source since these requests must currently be made blind, without
+   knowledge of requests made by other receivers.
+
+   RTCP feedback storms may cause short-term overload and, in extreme
+   cases, pose a possible risk of increasing network congestion on the
+   control channel (e.g., RTCP feedback), the data channel, or both.  It
+   is therefore desirable to provide a way of suppressing unneeded
+   feedback.  This document specifies a new Third-Party Loss Report for
+   this function.  It supplements the existing use of RTCP NACK packets
+   and is also more precise in the uses where the network is active to
+   suppress feedback.  It tells receivers explicitly that feedback for a
+   particular packet or frame loss is not needed and can provide an
+   early indication before the receiver reacts to the loss and invokes
+   its packet loss repair machinery.  Section 3 provides some example
+   use cases of when to send the Third-Party Loss Report message.
+
+2.  Terminology
+
+2.1.  Requirements Notation
+
+   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 RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+Wu, et al.                   Standards Track                    [Page 3]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+2.2.  Glossary
+
+   TPLR  - Third-Party Loss Report
+
+   TLLEI - Transport-Layer Third-Party Loss Early Indication
+
+   PSLEI - Payload-Specific Third-Party Loss Early Indication
+
+   PT    - Payload Type
+
+   FMT   - Feedback Message Type
+
+   FCI   - Feedback Control Information [RFC4585]
+
+   AVPF  - Audio-Visual Profile with RTCP-based feedback [RFC4585]
+
+   SSRC  - Synchronization Source
+
+   BRS   - Burst/Retransmission Source [RFC6285]
+
+   FIR   - Full Intra Request [RFC5104]
+
+   PLI   - Picture Loss Indication [RFC4585]
+
+   SSM   - Source-Specific Multicast [RFC5760]
+
+   RAMS  - Unicast-based Rapid Acquisition of Multicast Stream [RFC6285]
+
+   MCU   - Multipoint Control Unit [RFC5117]
+
+3.  Example Use Cases
+
+   The operation of feedback suppression is similar for all types of RTP
+   sessions and topologies [RFC5117]; however, the exact messages used
+   and the scenarios in which suppression is employed differ for various
+   use cases.  The following sections outline some of the intended use
+   cases for using the Third-Party Loss Report for feedback suppression
+   and give an overview of each.
+
+3.1.  Source-Specific Multicast (SSM) Use Case
+
+   In SSM RTP sessions as described in "RTP Control Protocol (RTCP)
+   Extensions for Single-Source Multicast Sessions with Unicast
+   Feedback" [RFC5760], one or more media sources send RTP packets to a
+   distribution source.  The distribution source relays the RTP packets
+   to the receivers using a source-specific multicast group.
+
+
+
+
+
+Wu, et al.                   Standards Track                    [Page 4]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+   As outlined in RFC 5760 [RFC5760], there are two Unicast Feedback
+   models that may be used for reporting: the Simple Feedback Model and
+   the Distribution Source Feedback Summary Model.  In the Simple
+   Feedback Model, there's no need for the distribution source to create
+   the RTCP TPLRs; instead, RTCP NACKs are reflected by the distribution
+   source to the other receivers.  However, in the Distribution Source
+   Feedback Summary Model, the distribution source will not redistribute
+   the NACK for some reason (e.g., to prevent revealing the identity or
+   existence of a system sending NACK) and may send an RTCP TPLR message
+   to the systems that were unable to receive the NACK and won't receive
+   the NACK via other means.  The RTCP TPLR can be generated at the
+   distribution source when downstream loss is reported (e.g.,
+   downstream loss report is received), which indicates to the receivers
+   that they should not transmit feedback messages for the same loss
+   event for a certain time.  Therefore, the distribution source in the
+   Distribution Source Feedback Summary Model can be reasonably certain
+   that it will help the situation (i.e., the distribution source is
+   unable receive the NACK) by sending this RTCP TPLR message to all the
+   relevant receivers impacted by the packet loss.
+
+3.2.  Unicast-Based Rapid Acquisition of Multicast Stream (RAMS) Use
+      Case
+
+   The typical RAMS architecture [RFC6285] may have several Burst/
+   Retransmission Sources (BRSs) behind the multicast source placed at
+   the same level.  These BRSs will receive the primary multicast RTP
+   stream from the media source and cache the most recent packets after
+   joining the multicast session.  If packet loss happens at the
+   upstream of all the BRSs or the downstream of BRSs, one or all of the
+   BRSs may send an RTCP NACK or RTCP TPLR message to the distribution
+   source, where the SSRC in this RTCP NACK or RTCP TPLR message is the
+   BRS that is sending the message.  The distribution source forwards/
+   reflects this message down on the primary SSM.  The details on how
+   the distribution source deals with this message are specified in
+   [RETRANS-FOR-SSM].
+
+3.3.  RTP Transport Translator Use Case
+
+   A Transport Translator (Topo-Trn-Translator), as defined in RFC 5117
+   [RFC5117], is typically forwarding the RTP and RTCP traffic between
+   RTP clients, for example, converting from multicast to unicast for
+   domains that do not support multicast.  The translator may suffer a
+   loss of important video packets.  In this case, the translator may
+   forward an RTCP TPLR message received from upstream in the same way
+   it forwards other RTCP traffic.  If the translator acting as the
+   monitor [MONARCH] is aware of packet loss, it may use the SSRC of the
+   monitor as the SSRC of the packet sender to create a NACK message and
+   send it to the receivers that are not aware of packet loss.
+
+
+
+Wu, et al.                   Standards Track                    [Page 5]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+3.4.  Multipoint Control Unit (MCU) Use Case
+
+   When the speaker is changed in a voice-activated multipoint video
+   switching conference [RFC4587], an RTP mixer can be used to select
+   the available input streams and forward them to each participant.  If
+   the MCU is doing a blind switch without waiting for a synchronization
+   point on the new stream, it can send a FIR to the new video source.
+   In this case, the MCU should send a FIR suppression message to the
+   new receivers.  For example, when the RTP mixer starts to receive FIR
+   from some participants, it can suppress the remaining session
+   participants from sending FIR by sending out an RTCP TPLR message.
+
+3.5.  Mixer Use Case
+
+   A mixer, in accordance with RFC 5117 [RFC5117], aggregates multiple
+   RTP streams from other session participants and generates a new RTP
+   stream sent to the session participants.  In some cases, the delivery
+   of video frames delivery may get damaged, for example, due to packet
+   loss or delayed delivery, between the media source and the mixer.  In
+   such cases, the mixer needs to check if the packet loss will result
+   in PLI or FIR transmissions from most of the group by analyzing the
+   received video.  If so, the mixer may initiate FIR or PLI towards the
+   media source on behalf of all the session participants and send out
+   an RTCP TPLR message to the session participants that may or are
+   expected to send a PLI or FIR.  Alternatively, when the mixer starts
+   to receive FIR or PLI from some participants and would like to
+   suppress the remaining session participants from sending FIR or PLI,
+   it can just forward the FIR/PLI from one session participant to
+   others.
+
+4.  Protocol Overview
+
+   This document extends the RTCP feedback messages defined in the RTP/
+   AVPF [RFC4585] by defining an RTCP Third-Party Loss Report (TPLR)
+   message.  The RTCP TPLR message can be used by the intermediaries to
+   inform the receiver that the sender of the RTCP TPLR has received
+   reports that the indicated packets were lost and ask the receiver not
+   to send feedback to it regarding these packets.  Intermediaries are
+   variously referred to as distribution sources, Burst/Retransmission
+   Sources, MCUs, RTP translators, or RTP mixers, depending on the
+   precise use case described Section 3.
+
+   RTCP TPLR follows a similar message type format as RTCP NACK or Full
+   Intra Request Command.  However, RTCP TPLR is defined as an
+   indication that the sender of the feedback has received reports that
+   the indicated packets were lost, while NACK [RFC4585] just indicates
+   that the sender of the NACK observed that these packets were lost.
+   The RTCP TPLR message is generated by an intermediary that may not
+
+
+
+Wu, et al.                   Standards Track                    [Page 6]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+   have seen the actual packet loss.  It is sent following the same
+   timing rule as sending NACK, defined in RFC 4585 [RFC4585].  The RTCP
+   TPLR message may be sent in a regular full compound RTCP packet or in
+   an early RTCP packet, as per the RTP/AVPF rules.  Intermediaries in
+   the network that receive an RTCP TPLR MUST NOT send their own
+   additional Third-Party Loss Report messages for the same packet
+   sequence numbers.  They SHOULD simply forward the RTCP TPLR message
+   received from upstream to the receiver(s).  Additionally, they may
+   generate their own RTCP TPLR that reports a set of the losses they
+   see, which are different from ones reported in the RTCP TPLR they
+   received.  The RTCP TPLR does not have retransmission request
+   [RFC4588] semantics.
+
+   When a receiver gets an RTCP TPLR message, it MUST follow the rules
+   for NACK suppression in RFC 4585 [RFC4585] and refrain from sending a
+   feedback request (e.g., NACK or FIR) for the missing packets reported
+   in the message, which is dealt with in the same way as receiving a
+   NACK.
+
+   To increase the robustness to the loss of a TPLR, the RTCP TPLR may
+   be retransmitted.  If the additional TPLR arrives at the receiver,
+   the receiver SHOULD deal with the additional TPLR in the same way as
+   receiving the first TPLR for the same packet, and no additional
+   behavior for receiver is required.
+
+   A receiver may have sent a feedback message according to the RTP/AVPF
+   scheduling algorithm of RFC 4585 [RFC4585] before receiving an RTCP
+   TPLR message, but further feedback messages for those sequence
+   numbers SHOULD be suppressed after receiving the RTCP TPLR.  Nodes
+   that do not understand the RTCP TPLR message will ignore it and might
+   therefore still send feedback according to the AVPF scheduling
+   algorithm of RFC 4585 [RFC4585].  The media source or intermediate
+   nodes cannot be certain that the use of an RTCP TPLR message actually
+   reduces the amount of feedback they receive.
+
+5.  Format of RTCP Feedback Messages
+
+   This document introduces two new RTCP feedback messages for Third-
+   Party Loss Report.  Applications that are employing one or more loss-
+   repair methods MAY use the RTCP TPLR together with their existing
+   loss-repair methods either for every packet they expect to receive or
+   for an application-specific subset of the RTP packets in a session.
+
+   The following two sections each define an RTCP TPLR message.  Both
+   messages are feedback messages as defined in Section 6.1 of RFC 4585
+   [RFC4585] and use the header format defined there.  Each section
+   defines how to populate the PT, FMT, length, SSRC of packet sender,
+   SSRC of media source, and FCI fields in that header.
+
+
+
+Wu, et al.                   Standards Track                    [Page 7]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+5.1.  Transport-Layer Feedback: Third-Party Loss Report (TPLR)
+
+   This TPLR message is identified by RTCP packet type values PT=RTPFB
+   and FMT=7.
+
+   Within the common packet header for feedback messages (as defined in
+   Section 6.1 of RFC 4585 [RFC4585]), the "SSRC of packet sender" field
+   indicates the source of the request, and the "SSRC of media source"
+   field denotes the media sender of the flow for which the indicated
+   losses are being suppressed.
+
+   The FCI field MUST contain one or more entries of Transport-Layer
+   Third-Party Loss Early Indication (TLLEI).  Each entry applies to the
+   same media source identified by the SSRC contained in the "SSRC of
+   media source" field of the Feedback header.  The length field in the
+   TLLEI feedback message MUST be set to N+2, where N is the number of
+   FCI entries.
+
+   The FCI field for TLLEI uses a similar message type format to that
+   defined in the Section 6.2.1 of RFC 4585 [RFC4585].  The format is
+   shown in Figure 1.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            PID                |             BLP               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Figure 1: Syntax of an FCI Entry in the TLLEI Feedback Message
+
+   Packet ID (PID): 16 bits
+
+      The PID field is used to specify a lost packet.  The PID field
+      refers to the RTP sequence number of the lost packet.
+
+   bitmask of lost packets (BLP): 16 bits
+
+      The BLP allows for reporting losses of any of the 16 RTP packets
+      immediately following the RTP packet indicated by the PID.  The
+      BLP's definition is identical to that given in Section 6.2.1 of
+      [RFC4585].
+
+5.2.  Payload-Specific Feedback:  Third-Party Loss Report (TPLR)
+
+   This TPLR message is identified by RTCP packet type values PT=PSFB
+   and FMT=8, which are used to suppress FIR [RFC5104] and PLI
+   [RFC4585].
+
+
+
+
+Wu, et al.                   Standards Track                    [Page 8]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+   Within the common packet header for feedback messages (as defined in
+   Section 6.1 of RFC 4585 [RFC4585]), the "SSRC of packet sender" field
+   indicates the source of the request, and the "SSRC of media source"
+   is not used and SHALL be set to 0.  The SSRCs of the media senders to
+   which this message apply are in the corresponding FCI entries.
+
+   The FCI field for a Payload-Specific Third-Party Loss Early
+   Indication (PSLEI) consists one or more FCI entries.  Each entry
+   applies to a different media source, identified by its SSRC, the
+   content of which is depicted in Figure 2.  The length field in the
+   PSLEI feedback message MUST be set to N+2, where N is the number of
+   FCI entries.
+
+   The format is shown in Figure 2.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                              SSRC                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Figure 2: Syntax of an FCI Entry in the PSLEI Feedback Message
+
+   Synchronization source (SSRC): 32 bits
+
+      The SSRC value of the media source that is already aware, or in
+      the process of being made aware, that some receiver lost
+      synchronization with the media stream and for which the PSLEI
+      receiver's own response to any such error is suppressed.
+
+6.  SDP Signaling
+
+   The Session Description Protocol (SDP) [RFC4566] attribute, rtcp-fb,
+   is defined in Section 4 of RFC 4585 [RFC4585] and may be used to
+   negotiate the capability to handle specific AVPF commands and
+   indications.  The ABNF for rtcp-fb is described in Section 4.2 of RFC
+   4585 [RFC4585].  In this section, we extend the rtcp-fb attribute to
+   include the commands and indications that are described for Third-
+   Party Loss Reports in the present document.
+
+   In the ABNF [RFC5234] for rtcp-fb-val defined in RFC 4585 [RFC4585],
+   the feedback type "nack", without parameters, indicates use of the
+   Generic NACK feedback format as defined in Section 6.2.1 of RFC 4585
+   [RFC4585].  In this document, we define two parameters that indicate
+   the third-party loss supported for use with "nack", namely:
+
+   o  "tllei" denotes support of Transport-Layer Third-Party Loss Early
+      Indication.
+
+
+
+Wu, et al.                   Standards Track                    [Page 9]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+   o  "pslei" denotes support of Payload-Specific Third-Party Loss Early
+      Indication.
+
+   The ABNF for these two parameters for use with "nack" is defined here
+   (please refer to Section 4.2 of RFC4585 [RFC4585] for complete ABNF
+   syntax).
+
+           rtcp-fb-val        =/ "nack" rtcp-fb-nack-param
+           rtcp-fb-nack-param = SP "tllei"
+                                   ;Transport-Layer Third-Party
+                                   ; Loss Early Indication
+                               / SP "pslei"
+                                   ;Payload-Specific Third-Party
+                                   ; Loss Early Indication
+                               / SP token [SP byte-string]
+                                   ; for future commands/indications
+           token =     <as defined in Section 9 of [RFC4566]>
+           byte-string = <as defined in Section 9 of [RFC4566]>
+
+7.  Security Considerations
+
+   The security considerations documented in [RFC4585] are also
+   applicable for the TPLR messages defined in this document.
+
+   More specifically, spoofed or maliciously created TPLR feedback
+   messages cause missing RTP packets to not be repaired in a timely
+   fashion and add risk of (undesired) feedback suppression at RTCP
+   receivers that accept such TPLR messages.  Any packet loss detected
+   by a receiver that also receives a TPLR message for the same missing
+   packet(s) will negatively impact the application that relies on the
+   (timely) RTP retransmission capabilities.
+
+   A solution to prevent such attack with maliciously sent TPLR messages
+   is to apply an authentication and integrity protection framework for
+   the feedback messages.  This can be accomplished using the RTP
+   profile that combines Secure RTP [RFC3711] and AVPF into SAVPF
+   [RFC5124].
+
+   Note that intermediaries that are not visible at the RTP layer that
+   wish to send the Third-Party Loss Reports on behalf of the media
+   source can only do so if they spoof the SSRC of the media source.
+   This is difficult if SRTP is in use.  If the intermediary is visible
+   at the RTP layer, this is not an issue, provided the intermediary is
+   part of the security context for the session.
+
+
+
+
+
+
+
+Wu, et al.                   Standards Track                   [Page 10]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+8.  IANA Considerations
+
+   Per this document, IANA has added two values to the '"ack" and "nack"
+   Attribute Values' sub-registry [RFC4585] of the 'Session Description
+   Protocol (SDP) Parameters' registry.
+
+   The value registration for the attribute value "nack":
+
+      Value name:     tllei
+      Long name:      Transport-Layer Third-Party Loss Early Indication
+      Usable with:    nack
+      Reference:      RFC 6642
+
+      Value name:     pslei
+      Long name:      Payload-Specific Third-Party Loss Early Indication
+      Usable with:    nack
+      Reference:      RFC 6642
+
+   The following value has been registered as one FMT value in the "FMT
+   Values for RTPFB Payload Types" registry
+   (http://www.iana.org/assignments/rtp-parameters).
+
+     RTPFB range
+     Name           Long Name                         Value  Reference
+     -------------- --------------------------------- -----  ---------
+     TLLEI          Transport-Layer Third-Party         7    [RFC6642]
+                    Loss Early Indication
+
+   The following value has been registered as one FMT value in the "FMT
+   Values for PSFB Payload Types" registry
+   (http://www.iana.org/assignments/rtp-parameters).
+
+     PSFB range
+     Name            Long Name                        Value  Reference
+     -------------- --------------------------------- -----  ---------
+     PSLEI          Payload-Specific Third-Party        8    [RFC6642]
+                    Loss Early Indication
+
+9.  Acknowledgments
+
+   The authors would like to thank David R. Oran, Magnus Westerlund,
+   Colin Perkins, Ali C. Begen, Tom Van Caenegem, Francis Dupont,
+   Ingemar Johansson, Bill Ver Steeg, Jonathan Lennox, and WeeSan Lee
+   for their valuable comments and suggestions on this document.
+
+
+
+
+
+
+
+Wu, et al.                   Standards Track                   [Page 11]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
+              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
+              July 2006.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [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.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [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.
+
+10.2.  Informative References
+
+   [RFC6285]  Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
+              "Unicast-Based Rapid Acquisition of Multicast RTP
+              Sessions", RFC 6285, June 2011.
+
+   [MONARCH]  Wu, Q., Hunt, G., and P. Arden, "Monitoring Architectures
+              for RTP", Work in Progress, May 2012.
+
+   [RETRANS-FOR-SSM]
+              Van Caenegem, T., Ver Steeg, B., and A. Begen,
+              "Retransmission for Source-Specific Multicast (SSM)
+              Sessions", Work in Progress, May 2011.
+
+
+
+
+Wu, et al.                   Standards Track                   [Page 12]
+
+RFC 6642                 Third-Party Loss Report               June 2012
+
+
+   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
+              January 2008.
+
+   [RFC4587]  Even, R., "RTP Payload Format for H.261 Video Streams",
+              RFC 4587, August 2006.
+
+   [RFC5760]  Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
+              Protocol (RTCP) Extensions for Single-Source Multicast
+              Sessions with Unicast Feedback", RFC 5760, February 2010.
+
+Authors' Addresses
+
+   Qin Wu (editor)
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: sunseawq@huawei.com
+
+
+   Frank Xia
+   Huawei
+   1700 Alma Dr., Suite 500
+   Plano, TX 75075
+   USA
+
+   Phone: +1 972-509-5599
+   EMail: xiayangsong@huawei.com
+
+
+   Roni Even
+   Huawei
+   14 David Hamelech
+   Tel Aviv 64953
+   Israel
+
+   EMail: even.roni@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                   Standards Track                   [Page 13]
+