idnits 2.17.1 draft-ietf-avt-rtcp-port-for-ssm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC5760, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5760, updated by this document, for RFC5378 checks: 2002-02-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 25, 2010) is 4993 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 200, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft Cisco 4 Updates: 5760 (if approved) August 25, 2010 5 Intended status: Standards Track 6 Expires: February 26, 2011 8 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) 9 Sessions 10 draft-ietf-avt-rtcp-port-for-ssm-02 12 Abstract 14 The Session Description Protocol (SDP) has an attribute that allows 15 RTP applications to specify an address and a port associated with the 16 RTP Control Protocol (RTCP) traffic. In RTP-based source-specific 17 multicast (SSM) sessions, the same attribute is used to designate the 18 address and the RTCP port of the Feedback Target in the SDP 19 description. However, the RTCP port associated with the SSM session 20 itself cannot be specified by the same attribute to avoid ambiguity, 21 and thus, is required to be derived from the "m=" line of the media 22 description. Deriving the RTCP port from the "m=" line imposes an 23 unnecessary restriction. This document removes this restriction by 24 introducing a new SDP attribute. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 26, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 62 3. The 'multicast-rtcp' Attribute . . . . . . . . . . . . . . . . 3 63 4. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Registration of SDP Attributes . . . . . . . . . . . . . . 6 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The Session Description Protocol (SDP) [RFC4566] has an attribute 76 that allows RTP applications [RFC3550] to specify an address and a 77 port associated with the RTP Control Protocol (RTCP) traffic 78 [RFC3605]. This attribute is called 'rtcp'. 80 Now consider a network where one or more media senders send RTP 81 packets to a distribution source, which then multicasts these RTP 82 packets to multicast receivers using a source-specific multicast 83 (SSM) arrangement [RFC5760]. The distribution source also multicasts 84 the forward RTCP traffic (i.e., RTCP sender reports and receiver 85 reports or their summaries) to the receivers in the same SSM session. 87 In RTP-based SSM sessions, the 'rtcp' attribute is used to designate 88 the address and the RTCP port of the Feedback Target in the SDP 89 description [RFC5760]. However, the RTCP port associated with the 90 SSM session itself cannot be specified by the same attribute since it 91 could potentially cause ambiguity. Thus, the multicast RTCP port is 92 required to be derived from the "m=" line of the media description 93 (See Section 10.2 of [RFC5760]) by following the +1 rule. However, 94 [RFC3550] lifted the requirement for the +1 rule since it imposed an 95 unnecessary restriction on RTCP port selection. 97 In this specification, we introduce a new SDP attribute to remove 98 this restriction. The new attribute allows the multicast sender to 99 use its desired port in the RTCP session. This document updates 100 [RFC5760]. 102 2. Requirements Notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. The 'multicast-rtcp' Attribute 110 In RTP-based SSM sessions, the distribution source can use different 111 multicast RTP and RTCP ports to send the RTP and RTCP packets, 112 respectively. Alternatively, the distribution source can use RTP/ 113 RTCP port muxing [RFC5761], in which case the RTP and RTCP packets 114 are sent to the same destination port in the SSM session. 116 For the cases when the distribution source does not want to use the 117 one higher port for the RTCP traffic, this document defines a new SDP 118 attribute, called 'multicast-rtcp'. By using this attribute, the 119 distribution source uses a desired port for the SSM RTCP session. In 120 the absence of the 'multicast-rtcp' attribute, the +1 rule applies 121 following [RFC5760]. 123 The formal description of the 'multicast-rtcp' attribute is defined 124 by the following ABNF [RFC5234] syntax: 126 rtcp-attribute = "a=multicast-rtcp:" port CRLF 128 Figure 1: ABNF syntax for the 'multicast-rtcp' attribute 130 Here, the 'port' token is defined as specified in Section 9 of 131 [RFC4566]. 133 The 'multicast-rtcp' attribute is defined as both a media-level and 134 session-level attribute. 136 4. SDP Example 138 In the session description shown in Figure 2, a source stream is 139 multicast from a distribution source (with a source IP address of 140 198.51.100.1) to the multicast destination address of 233.252.0.2 and 141 port 41000. The forward RTCP traffic is multicast in the same 142 multicast group but to port 42000 as specified by the "a=multicast- 143 rtcp:42000" line. A feedback target with an address of 192.0.2.1 and 144 port of 43000 is specified by the 'rtcp' attribute. 146 v=0 147 o=ali 1122334455 1122334466 IN IP4 ssm.example.com 148 s='multicast-rtcp' Example 149 t=0 0 150 a=rtcp-unicast:rsi 151 m=video 41000 RTP/AVPF 98 152 i=Multicast Stream 153 c=IN IP4 233.252.0.2/255 154 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 155 a=rtpmap:98 MP2T/90000 156 a=multicast-rtcp:42000 157 a=rtcp:43000 IN IP4 192.0.2.1 158 a=mid:1 160 Figure 2: Example SDP showing the use of the 'multicast-rtcp' 161 attribute 163 5. Security Considerations 165 The 'multicast-rtcp' attribute is not believed to introduce any 166 significant security risk to multimedia applications. A malevolent 167 third party could use this attribute to redirect the RTCP traffic, 168 but this requires intercepting and rewriting the packets carrying the 169 SDP description; and if an interceptor can do that, many more attacks 170 are possible, including a wholesale change of the addresses and port 171 numbers at which the media will be sent. Therefore, as usual 172 adequate security measures are RECOMMENDED to ensure the integrity 173 and authenticity of the SDP descriptions so that transport addresses 174 of the media senders, distribution sources, feedback targets as well 175 as other session-specific information can be authenticated. 177 6. IANA Considerations 179 The following contact information shall be used for all registrations 180 in this document: 182 Ali Begen 183 abegen@cisco.com 185 Note to the RFC Editor: In the following, replace "XXXX" with the 186 number of this document prior to publication as an RFC. 188 6.1. Registration of SDP Attributes 190 This document registers a new attribute name in SDP. 192 SDP Attribute ("att-field"): 193 Attribute name: multicast-rtcp 194 Long form: Port in the multicast RTCP session 195 Type of name: att-field 196 Type of attribute: Media or session level 197 Subject to charset: No 198 Purpose: Specifies the port for the SSM RTCP session 199 Reference: [RFCXXXX] 200 Values: See [RFCXXXX] 202 7. Acknowledgments 204 Thanks to Colin Perkins amd Magnus Westerlund for suggesting the name 205 for the 'multicast-rtcp' attribute. Some parts of this specification 206 are based on [RFC3605] and [RFC5760]. So, also thanks to those who 207 contributed to those specifications. 209 8. References 211 8.1. Normative References 213 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 214 Jacobson, "RTP: A Transport Protocol for Real-Time 215 Applications", STD 64, RFC 3550, July 2003. 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 221 Description Protocol", RFC 4566, July 2006. 223 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 224 in Session Description Protocol (SDP)", RFC 3605, 225 October 2003. 227 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 228 Protocol (RTCP) Extensions for Single-Source Multicast 229 Sessions with Unicast Feedback", RFC 5760, February 2010. 231 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 232 Specifications: ABNF", STD 68, RFC 5234, January 2008. 234 8.2. Informative References 236 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 237 Control Packets on a Single Port", RFC 5761, April 2010. 239 Author's Address 241 Ali Begen 242 Cisco 243 181 Bay Street 244 Toronto, ON M5J 2T3 245 Canada 247 Email: abegen@cisco.com