Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6285

Unicast-Based Rapid Acquisition of Multicast RTP Sessions

Pages: 56
Proposed Standard
Part 3 of 3 – Pages 40 to 56
First   Prev   None

Top   ToC   RFC6285 - Page 40   prevText

8. SDP Signaling

8.1. Definitions

The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. Here we add the following syntax to the 'rtcp-fb' attribute (the feedback type and optional parameters are all case sensitive): (In the following ABNF [RFC5234], rtcp-fb-nack-param is used as defined in [RFC4585].) rtcp-fb-nack-param =/ SP "rai" The following parameter is defined in this document for use with 'nack': o 'rai' stands for Rapid Acquisition Indication and indicates the use of RAMS messages as defined in Section 7. This document also defines a new media-level SDP attribute ('rams-updates') that indicates whether or not the BRS supports updated request messages. This attribute is used in a declarative manner and no Offer/Answer Model behavior is specified. If the BRS supports updated request messages and this attribute is included in the SDP description, the RTP_Rx can send updated requests. The BRS might or might not be able to accept value changes in every field in
Top   ToC   RFC6285 - Page 41
   an updated RAMS-R message.  However, if the 'rams-updates' attribute
   is not included in the SDP description, the RTP_Rx SHALL NOT send
   updated requests.  The RTP_Rx MAY still repeat its initial request
   without changes, though.

8.2. Requirements

The use of SDP to describe the RAMS entities normatively requires support for: o The SDP grouping framework and flow identification (FID) semantics [RFC5888] o The RTP/AVPF profile [RFC4585] o The RTP retransmission payload format [RFC4588] o The RTCP extensions for SSM sessions with unicast feedback [RFC5760] o The 'multicast-rtcp' attribute [RFC6128] o Multiplexing RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761] o The 'portmapping-req' attribute [RFC6284] Support for the source-specific media attributes [RFC5576] can also be needed when the 'ssrc' attribute is to be used for the media descriptions.

8.3. Example and Discussion

This section provides a declarative SDP [RFC4566] example (for the RTP_Rx side) for enabling rapid acquisition of multicast RTP sessions. v=0 o=ali 1122334455 1122334466 IN IP4 rams.example.com s=Rapid Acquisition Example t=0 0 a=group:FID 1 2 a=rtcp-unicast:rsi m=video 41000 RTP/AVPF 98 i=Primary Multicast Stream c=IN IP4 233.252.0.2/255 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 a=rtpmap:98 MP2T/90000
Top   ToC   RFC6285 - Page 42
        a=multicast-rtcp:42000
        a=rtcp:43000 IN IP4 192.0.2.1
        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack rai
        a=ssrc:123321 cname:iptv-ch32@rams.example.com
        a=rams-updates
        a=portmapping-req:54000 IN IP4 192.0.2.1
        a=mid:1
        m=video 51000 RTP/AVPF 99
        i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
        c=IN IP4 192.0.2.1
        a=sendonly
        a=rtpmap:99 rtx/90000
        a=rtcp-mux
        a=rtcp:51500
        a=fmtp:99 apt=98;rtx-time=5000
        a=portmapping-req:55000
        a=mid:2

         Figure 10: Example SDP for a Single-Channel RAMS Scenario

   In this example SDP description, we have a primary multicast (source)
   stream and a unicast retransmission stream.  The source stream is
   multicast from a distribution source (with a source IP address of
   198.51.100.1) to the multicast destination address of 233.252.0.2 and
   port 41000.  The corresponding RTCP traffic is multicast to the same
   multicast destination address at port 42000.  Here, we are assuming
   that the multicast RTP and RTCP ports are carefully chosen so that
   different RTP and RTCP streams do not collide with each other.

   The feedback target (FT_Ap) residing on the RS (with an address of
   192.0.2.1) at port 43000 is declared with the "a=rtcp" line
   [RFC3605].  The support for the conventional retransmission is
   indicated through the "a=rtcp-fb:98 nack" line.  The RTP receiver(s)
   can report missing packets on the source stream to the feedback
   target and request retransmissions.  The SDP above includes the
   "a=sendonly" line for the media description of the retransmission
   stream since the retransmissions are sent in only one direction.

   The support for rapid acquisition is indicated through the "a=rtcp-
   fb:98 nack rai" line.  The parameter 'rtx-time' applies to both the
   conventional retransmissions and rapid acquisition.  However, when
   rapid acquisition is enabled, the standard definition for the
   parameter 'rtx-time' given in [RFC4588] is not followed.  Instead,
   when rapid acquisition support is enabled, 'rtx-time' specifies the
   time in milliseconds that the BRS keeps an RTP packet in its cache
Top   ToC   RFC6285 - Page 43
   available for retransmission (measured from the time the packet was
   received by the BRS, not from the time indicated in the packet
   timestamp).

   Once an RTP_Rx has acquired an SDP description, it can ask for rapid
   acquisition before it joins a primary multicast RTP session.  To do
   so, it sends a RAMS-R message to the feedback target of that primary
   multicast RTP session.  If the FT_Ap is associated with only one RTP
   stream, the RTP_Rx does not need to learn the SSRC of that stream via
   an out-of-band method.  If the BRS accepts the rapid acquisition
   request, it will send a RAMS-I message with the correct SSRC
   identifier.  If the FT_Ap is associated with a multi-stream RTP
   session and the RTP_Rx is willing to request rapid acquisition for
   the entire session, the RTP_Rx again does not need to learn the SSRCs
   via an out-of-band method.  However, if the RTP_Rx intends to request
   a particular subset of the primary multicast streams, it must learn
   their SSRC identifiers and list them in the RAMS-R message.  Since
   this RTP_Rx has not yet received any RTP packets for the primary
   multicast stream(s), the RTP_Rx must in this case learn the SSRC
   value(s) from the 'ssrc' attribute of the media description
   [RFC5576].  In addition to the SSRC value, the 'cname' source
   attribute must also be present in the SDP description [RFC5576].

   Listing the SSRC values for the primary multicast streams in the SDP
   file does not create a problem in SSM sessions when an SSRC collision
   occurs.  This is because in SSM sessions, an RTP_Rx that observed an
   SSRC collision with a media sender must change its own SSRC [RFC5760]
   by following the rules defined in [RFC3550].

   A feedback target that receives a RAMS-R message becomes aware that
   the RTP_Rx wants to rapidly catch up with a primary multicast RTP
   session.  If the necessary conditions are satisfied (as outlined in
   Section 7 of [RFC4585]) and available resources exist, the BRS can
   react to the RAMS-R message by sending any transport-layer (and
   optional payload-specific, when allowed) feedback message(s) and
   starting the unicast burst.

   In this section, we considered the simplest scenario where the
   primary multicast RTP session carried only one stream and the RTP_Rx
   wanted to rapidly acquire this stream only.  Best practices for
   scenarios where the primary multicast RTP session carries two or more
   streams or the RTP_Rx wants to acquire one or more streams from
   multiple primary multicast RTP sessions at the same time are
   presented in [RAMS-SCENARIOS].
Top   ToC   RFC6285 - Page 44

9. NAT Considerations

For a variety of reasons, one or more Network Address Port Translators (NAPT, hereafter simply called NAT) can exist between the RTP_Rx and RS. NATs have a variety of operating characteristics for UDP traffic [RFC4787]. For a NAT to permit traffic from the BRS to arrive at the RTP_Rx, the NAT(s) must first either: a. See UDP (or DCCP) traffic sent from the RTP_Rx (which is on the 'inside' of the NAT) to the BRS (which is on the 'outside' of the NAT). This traffic has the same transport address as the subsequent response traffic, or b. Be configured to forward certain ports (e.g., using HTML configuration or Universal Plug and Play (UPnP) Internet Gateway Device (IGD) [UPnP-IGD]). Details of this are out of the scope of this document. For both (a) and (b), the RTP_Rx is responsible for maintaining the NAT's state if it wants to receive traffic from the BRS on that port. For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at least every 30 seconds [RFC4787]. While (a) is more like an automatic/dynamic configuration, (b) is more like a manual/static configuration. When the RTP_Rx sends a request (RAMS-R) message to the FT as unicast feedback in the primary multicast RTP session and the request is received by the FT, a new unicast burst RTP session will be established between the BRS and RTP_Rx. While the FT and BRS ports on the RS are already signaled via out-of- band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP ports it wants to use on its side for the new session. Since there are two RTP sessions (one multicast and one unicast) involved during this process and one of them is established upon a feedback message sent in the other one, this requires an explicit port mapping method. Applications using RAMS MUST support the method presented in [RFC6284] both on the RS and RTP_Rx side to allow RTP receivers to use their desired ports and to support RAMS behind NAT devices. The port mapping message exchange needs to take place whenever the RTP_Rx intends to make use of the RAMS protocol for rapidly acquiring a specific multicast RTP session prior to joining the associated SSM session.
Top   ToC   RFC6285 - Page 45

10. Security Considerations

Applications that are using RAMS make heavy use of the unicast feedback mechanism described in [RFC5760], the payload format defined in [RFC4588], and the port mapping solution specified in [RFC6284]. Thus, these applications are subject to the general security considerations discussed in those documents. In particular, the threats and risks discussed in [RFC5760] need to be considered carefully. In this section, we give an overview of the guidelines and suggestions described in these specifications from a RAMS perspective. We also discuss the security considerations that explicitly apply to applications using RAMS. First of all, much of the session description information is available in the SDP descriptions that are distributed to the media senders, retransmission servers, and RTP receivers. Adequate security measures are RECOMMENDED to ensure the integrity and authenticity of the SDP descriptions so that transport addresses of the media senders, distribution sources, feedback targets, and other session-specific information can be protected. See [RFC4566] for details. Compared to an RTCP NACK message that triggers one or more retransmissions, a RAMS Request (RAMS-R) message can trigger a new burst stream to be sent by the retransmission server. Depending on the application-specific requirements and conditions existing at the time of the RAMS-R reception by the retransmission server, the resulting burst stream can potentially contain a large number of retransmission packets. Since these packets are sent faster than the nominal rate, RAMS consumes more resources on the retransmission servers, RTP receivers, and the network. In particular, this can make denial-of-service (DoS) attacks more intense and hence more harmful than attacks that target ordinary retransmission sessions. As RAMS messages are sent as RTCP messages, counter-measures SHOULD be taken to prevent tampered or spoofed RTCP packets, following the suggestions given in [RFC4588]. Tampered RAMS-R messages can trigger inappropriate burst streams or alter the existing burst streams in an inappropriate way. For example, if the Max Receive Bitrate field is altered by a tampered RAMS-R message, the updated burst can overflow the buffer at the receiver side or, oppositely, can slow down the burst to the point that it becomes useless. Tampered RAMS Termination (RAMS-T) messages can terminate valid burst streams prematurely resulting in gaps in the received RTP packets. RAMS Information (RAMS-I) messages contain fields that are critical for a successful rapid acquisition. Any tampered information in the RAMS-I message can easily cause an RTP receiver to make wrong decisions. Consequently, the RAMS operation can fail.
Top   ToC   RFC6285 - Page 46
   RTCP BYE messages are similar to RAMS-T messages in the sense that
   they can be used to stop an existing burst.  The CNAME of an RTP
   receiver is used to bind the RTCP BYE message to an existing burst.
   Thus, one should be careful if the CNAMEs are reasonably easy to
   guess and off-path attacks can be performed.  Also note that the
   CNAMEs might be redistributed to all participants in the multicast
   group (as in ASM or the simple feedback model of [RFC5760]).

   The retransmission server has to consider if values indicated in a
   RAMS-R message are reasonable.  For example, a request demanding a
   large value of many seconds in the Min RAMS Buffer Fill Requirement
   element should, unless special use cases exist, likely be rejected
   since it is likely to be an attempt to prolong a DoS attack on the
   retransmission server, RTP receiver, and/or the network.  The Max
   Receive Bitrate could also be set to a very large value to try to get
   the retransmission server to cause massive congestion by bursting at
   a bitrate that will not be supported by the network.  An RTP_Rx
   should also consider if the values for the Earliest Multicast Join
   Time and Burst Duration indicated by the retransmission server in a
   RAMS-I message are reasonable.  For example, if the burst packets
   stop arriving and the join time is still significantly far into the
   future, this could be a sign of a man-in-the-middle attack where the
   RAMS-I message has been manipulated by an attacker.

   A basic mitigation against DoS attacks introduced by an attacker
   injecting tampered RAMS messages is source address validation
   [RFC2827].  Also, most of the DoS attacks can be prevented by the
   integrity and authenticity checks enabled by Secure RTP (SRTP)
   [RFC3711].  However, an attack can still be started by legitimate
   endpoints that send several valid RAMS-R messages to a particular
   feedback target in a synchronized fashion and in a very short amount
   of time.  Since a RAMS operation can temporarily consume a large
   amount of resources, a series of the RAMS-R messages can temporarily
   overload the retransmission server.  In these circumstances, the
   retransmission server can, for example, reject incoming RAMS requests
   until its resources become available again.  One means to ameliorate
   this threat is to apply a per-endpoint policing mechanism on the
   incoming RAMS requests.  A reasonable policing mechanism should
   consider application-specific requirements and minimize false
   negatives.

   In addition to the DoS attacks, man-in-the-middle and replay attacks
   will also be harmful.  RAMS-R messages do not carry any information
   that allows the retransmission server to detect duplication or replay
   attacks.  Thus, the possibility of a replay attack using a captured
   valid RAMS-R message exists unless a mitigation method such as Secure
   RTCP (SRTCP) is used.  Similarly, RAMS-T messages can be replayed.
   The RAMS-I has a sequence number that makes replay attacks less
Top   ToC   RFC6285 - Page 47
   likely but not impossible.  Man-in-the-middle attacks that are
   capable of capturing, injecting, or modifying the RAMS messages can
   easily accomplish the attacks described above.  Thus, cryptographic
   integrity and authentication is the only reliable protection.  To
   protect the RTCP messages from man-in-the-middle and replay attacks,
   the RTP receivers and retransmission server SHOULD perform a Datagram
   Transport Layer Security (DTLS)-SRTP handshake [RFC5764] over the
   RTCP channel.  Because there is no integrity-protected signaling
   channel between an RTP receiver and the retransmission server, the
   retransmission server MUST maintain a list of certificates owned by
   legitimate RTP receivers, or their certificates MUST be signed by a
   trusted Certificate Authority.  Once the DTLS-SRTP security is
   established, non-SRTCP-protected messages received from a particular
   RTP receiver are ignored by the retransmission server.  To reduce the
   impact of DTLS-SRTP overhead when communicating with different
   feedback targets on the same retransmission server, it is RECOMMENDED
   that RTP receivers and the retransmission server both support TLS
   Session Resumption without Server-side State [RFC5077].  To help
   scale SRTP to handle many RTP receivers asking for retransmissions of
   identical data, implementors may consider using the same SRTP key for
   SRTP data sent to the receivers [SRTP-EKT] and be aware that such key
   sharing allows those receivers to impersonate the sender.  Thus,
   source address validation remains important.

   [RFC4588] RECOMMENDS that cryptography mechanisms be used for the
   retransmission payload format to provide protection against known
   plain-text attacks.  As discussed in [RFC4588], the retransmission
   payload format sets the timestamp field in the RTP header to the
   media timestamp of the original packet, and this does not compromise
   the confidentiality.  Furthermore, if cryptography is used to provide
   security services on the original stream, then the same services,
   with equivalent cryptographic strength, MUST be provided on the
   retransmission stream per [RFC4588].

   Finally, a retransmission server that has become subverted by an
   attacker is almost impossible to protect against as such a server can
   perform a large number of different actions to deny service to
   receivers.

11. IANA Considerations

The following contact information is used for all registrations in this document: Ali Begen abegen@cisco.com
Top   ToC   RFC6285 - Page 48
   Note that the "RAMS" (value 2) in the Multicast Acquisition Method
   Registry refers to the method described in Section 6 of this
   document.

11.1. Registration of SDP Attributes

This document registers a new attribute name in SDP. SDP Attribute ("att-field"): Attribute name: rams-updates Long form: Support for Updated RAMS Request Messages Type of name: att-field Type of attribute: Media level Subject to charset: No Purpose: See this document Reference: [RFC6285] Values: None

11.2. Registration of SDP Attribute Values

This document registers a new value for the 'nack' attribute to be used with the 'rtcp-fb' attribute in SDP. For more information about the 'rtcp-fb' attribute, refer to Section 4.2 of [RFC4585]. Value name: rai Long name: Rapid Acquisition Indication Usable with: nack Reference: [RFC6285]

11.3. Registration of FMT Values

Within the RTPFB range, the following format (FMT) value is registered: Name: RAMS Long name: Rapid Acquisition of Multicast Sessions Value: 6 Reference: [RFC6285]

11.4. SFMT Values for RAMS Messages Registry

This document creates a new sub-registry for the sub-feedback message type (SFMT) values to be used with the FMT value registered for RAMS messages. The registry is called the SFMT Values for RAMS Messages Registry. This registry is managed by the IANA according to the Specification Required policy of [RFC5226].
Top   ToC   RFC6285 - Page 49
   The length of the SFMT field in the RAMS messages is a single octet,
   allowing 256 values.  The registry is initialized with the following
   entries:

   Value Name                                               Reference
   ----- -------------------------------------------------- ------------
   0     Reserved                                           [RFC6285]
   1     RAMS Request                                       [RFC6285]
   2     RAMS Information                                   [RFC6285]
   3     RAMS Termination                                   [RFC6285]
   4-254 Unassigned - Specification Required
   255   Reserved                                           [RFC6285]

   The SFMT values 0 and 255 are reserved for future use.

   Any registration for an unassigned SFMT value needs to contain the
   following information:

   o  Contact information of the one doing the registration, including
      at least name, address, and email.

   o  A detailed description of what the new SFMT represents and how it
      shall be interpreted.

   New RAMS functionality is intended to be introduced by using the
   extension mechanism within the existing RAMS message types not by
   introducing new message types unless it is absolutely necessary.

11.5. RAMS TLV Space Registry

This document creates a new IANA TLV space registry for the RAMS extensions. The registry is called the RAMS TLV Space Registry. This registry is managed by the IANA according to the Specification Required policy of [RFC5226]. The length of the Type field in the TLV elements is a single octet, allowing 256 values. The Type values 0 and 255 are reserved for future use. The Type values between (and including) 128 and 254 are reserved for private extensions.
Top   ToC   RFC6285 - Page 50
   The registry is initialized with the following entries:

   Type    Description                                     Reference
   ----    ----------------------------------------------- -------------
   0       Reserved                                        [RFC6285]
   1       Requested Media Sender SSRC(s)                  [RFC6285]
   2       Min RAMS Buffer Fill Requirement                [RFC6285]
   3       Max RAMS Buffer Fill Requirement                [RFC6285]
   4       Max Receive Bitrate                             [RFC6285]
   5       Request for Preamble Only                       [RFC6285]
   6       Supported Enterprise Number(s)                  [RFC6285]
   7-30    Unassigned - Specification Required
   31      Media Sender SSRC                               [RFC6285]
   32      RTP Seqnum of the First Packet                  [RFC6285]
   33      Earliest Multicast Join Time                    [RFC6285]
   34      Burst Duration                                  [RFC6285]
   35      Max Transmit Bitrate                            [RFC6285]
   36-60   Unassigned - Specification Required
   61      Extended RTP Seqnum of First Multicast Packet   [RFC6285]
   62-127  Unassigned - Specification Required
   128-254 Reserved for Private Use
   255     Reserved                                        [RFC6285]

   Any registration for an unassigned Type value needs to contain the
   following information:

   o  Contact information of the one doing the registration, including
      at least name, address, and email.

   o  A detailed description of what the new TLV element represents and
      how it shall be interpreted.

11.6. RAMS Response Code Space Registry

This document creates a new IANA TLV space registry for the RAMS response codes. The registry is called the RAMS Response Code Space Registry. This registry is managed by the IANA according to the Specification Required policy of [RFC5226]. The length of the Response field is two octets, allowing 65536 codes. However, in this document, the response codes have been classified and registered following an HTTP-style code numbering. New response codes should be classified following the guidelines below:
Top   ToC   RFC6285 - Page 51
   Code Level Purpose
   ---------- ---------------
   1xx        Informational
   2xx        Success
   3xx        Redirection
   4xx        RTP Receiver (RTP_Rx) Error
   5xx        Burst/Retransmission Source (BRS) Error

   The Response code 65535 is reserved for future use.

   The registry is initialized with the following entries:

   Code  Description                                        Reference
   ----- -------------------------------------------------- ------------
   0     A private response code is included in the message [RFC6285]

   100   Parameter update for RAMS session                  [RFC6285]

   200   RAMS request has been accepted                     [RFC6285]
   201   Unicast burst has been completed                   [RFC6285]

   400   Invalid RAMS-R message syntax                      [RFC6285]
   401   Invalid min buffer requirement in RAMS-R message   [RFC6285]
   402   Invalid max buffer requirement in RAMS-R message   [RFC6285]
   403   Insufficient max bitrate requirement in RAMS-R
         message                                            [RFC6285]
   404   Invalid RAMS-T message syntax                      [RFC6285]

   500   An unspecified BRS internal error has occurred     [RFC6285]
   501   BRS has insufficient bandwidth to start RAMS
         session                                            [RFC6285]
   502   Burst is terminated due to network congestion      [RFC6285]
   503   BRS has insufficient CPU cycles to start RAMS
         session                                            [RFC6285]
   504   RAMS functionality is not available on BRS         [RFC6285]
   505   RAMS functionality is not available for RTP_Rx     [RFC6285]
   506   RAMS functionality is not available for
         the requested multicast stream                     [RFC6285]
   507   BRS has no valid starting point available for
         the requested multicast stream                     [RFC6285]
   508   BRS has no reference information available for
         the requested multicast stream                     [RFC6285]
   509   BRS has no RTP stream matching the requested SSRC  [RFC6285]
   510   RAMS request to acquire the entire session
         has been denied                                    [RFC6285]
   511   Only the preamble information is sent              [RFC6285]
   512   RAMS request has been denied due to a policy       [RFC6285]
Top   ToC   RFC6285 - Page 52
   Any registration for an unassigned Response code needs to contain the
   following information:

   o  Contact information of the one doing the registration, including
      at least name, address, and email.

   o  A detailed description of what the new Response code describes and
      how it shall be interpreted.

12. Contributors

Dave Oran, Magnus Westerlund, and Colin Perkins have contributed significantly to this specification by providing text and solutions to some of the issues raised during the development of this specification.

13. Acknowledgments

The following individuals reviewed earlier versions of this specification and provided helpful comments: Joerg Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox, Jose Rey, Sean Sheedy, and Keith Drage.

14. References

14.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
Top   ToC   RFC6285 - Page 53
   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [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.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, January 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, July 2008.

   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
              Real-Time Transport Control Protocol (RTCP): Opportunities
              and Consequences", RFC 5506, April 2009.

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

   [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.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010.
Top   ToC   RFC6285 - Page 54
   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
              Flows", RFC 6051, November 2010.

   [RFC6128]  Begen, A., "RTP Control Protocol (RTCP) Port for Source-
              Specific Multicast (SSM) Sessions", RFC 6128,
              February 2011.

   [RFC6284]  Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping
              Between Unicast and Multicast RTP Sessions", RFC 6284,
              June 2011.

14.2. Informative References

[ECN-FOR-RTP] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", Work in Progress, May 2011. [IC2009] Begen, A., Glazebrook, N., and W. Ver Steeg, "Reducing Channel Change Times in IPTV with Real-Time Transport Protocol (IEEE Internet Computing)", May 2009. [MULTICAST-ACQ] Begen, A. and E. Friedrich, "Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", Work in Progress, May 2011. [RAMS-SCENARIOS] Begen, A., "Considerations and Guidelines for Deploying the Rapid Acquisition of Multicast Sessions (RAMS) Method", Work in Progress, June 2011. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
Top   ToC   RFC6285 - Page 55
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5762]  Perkins, C., "RTP and the Datagram Congestion Control
              Protocol (DCCP)", RFC 5762, April 2010.

   [RFC6015]  Begen, A., "RTP Payload Format for 1-D Interleaved Parity
              Forward Error Correction (FEC)", RFC 6015, October 2010.

   [RFC6222]  Begen, A., Perkins, C., and D. Wing, "Guidelines for
              Choosing RTP Control Protocol (RTCP) Canonical Names
              (CNAMEs)", RFC 6222, April 2011.

   [SRTP-EKT] McGrew, D., Andreasen, F., Wing, D., and K. Fischer,
              "Encrypted Key Transport for Secure RTP", Work
              in Progress, March 2011.

   [UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet
              Gateway Device (IGD)", December 2010.
Top   ToC   RFC6285 - Page 56

Authors' Addresses

Bill Ver Steeg Cisco 5030 Sugarloaf Parkway Lawrenceville, GA 30044 USA EMail: billvs@cisco.com Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada EMail: abegen@cisco.com Tom Van Caenegem Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium EMail: Tom.Van_Caenegem@alcatel-lucent.be Zeev Vax Magnum Semiconductor, Inc. 591 Yosemite Drive Milpitas, CA 95035 USA EMail: zeev.vax@magnumsemi.com