tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6285

 
 
 

Unicast-Based Rapid Acquisition of Multicast RTP Sessions

Part 3 of 3, p. 40 to 56
Prev RFC Part

 


prevText      Top      Up      ToC       Page 40 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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