RFC 6285
Unicast-Based Rapid Acquisition of Multicast RTP Sessions
Pages: 56
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 40 to 56
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
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
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
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].
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.
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.
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
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
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: None11.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].
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.
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:
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]
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.
[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.
[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.
[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.
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