idnits 2.17.1 draft-begen-avt-rtcp-port-for-ssm-01.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 (April 3, 2010) is 5137 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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) April 3, 2010 5 Intended status: Standards Track 6 Expires: October 5, 2010 8 RTP Control Protocol (RTCP) Port for Multicast Sessions 9 draft-begen-avt-rtcp-port-for-ssm-01 11 Abstract 13 The Session Description Protocol (SDP) has an attribute that allows 14 RTP applications to specify an address and a port associated with the 15 RTP Control Protocol (RTCP) traffic. In RTP-based source-specific 16 multicast (SSM) sessions, the same attribute is used to designate the 17 address and the RTCP port of the Feedback Target in the SDP 18 description. However, the RTCP port associated with the SSM session 19 itself cannot be specified by the same attribute to avoid ambiguity, 20 and thus, is required to be derived from the "m=" line of the media 21 description. Similarly, in any-source multicast (ASM) sessions, 22 there is no explicit way to specify the destination RTCP port. 23 Deriving the RTCP port from the "m=" line imposes an unnecessary 24 restriction. This document removes this restriction by introducing a 25 new SDP attribute. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 5, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 63 3. The 'multicast-rtcp' Attribute . . . . . . . . . . . . . . . . 3 64 3.1. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Registration of SDP Attributes . . . . . . . . . . . . . . 6 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The Session Description Protocol (SDP) [RFC4566] has an attribute 77 that allows RTP applications [RFC3550] to specify an address and a 78 port associated with the RTP Control Protocol (RTCP) traffic 79 [RFC3605]. This attribute is called 'rtcp'. 81 Now consider a network where one or more media senders send RTP 82 packets to a distribution source, which then multicasts these RTP 83 packets to multicast receivers using a source-specific multicast 84 (SSM) arrangement [RFC5760]. The distribution source also multicasts 85 the forward RTCP traffic (i.e., RTCP Sender Reports and Receiver 86 Reports or their summaries) to the receivers in the same SSM session. 88 In RTP-based SSM sessions, the 'rtcp' attribute is used to designate 89 the address and the RTCP port of the Feedback Target in the SDP 90 description [RFC5760]. However, the RTCP port associated with the 91 SSM session itself cannot be specified by the same attribute since it 92 could potentially cause ambiguity. Thus, the multicast RTCP port is 93 required to be derived from the "m=" line of the media description 94 (See Section 10.2 of [RFC5760]) by following the +1 rule. However, 95 [RFC3550] lifted the requirement for the +1 rule since it imposed an 96 unnecessary restriction on RTCP port selection. 98 In this specification, we introduce a new SDP attribute to remove 99 this restriction. The new attribute allows the multicast sender to 100 use its desired port in the RTCP session. Similar to SSM sessions, 101 in any-source multicast (ASM) sessions, there is no explicit way to 102 specify the destination RTCP port, either, and the new SDP attribute 103 is equally applicable in ASM sessions as well. 105 If approved, this document intends to update [RFC5760]. 107 2. Requirements Notation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. The 'multicast-rtcp' Attribute 115 In RTP-based SSM sessions, the distribution source may use different 116 multicast RTP and RTCP ports to send the RTP and RTCP packets, 117 respectively. Alternatively, the distribution source may use RTP/ 118 RTCP port muxing [I-D.ietf-avt-rtp-and-rtcp-mux], in which case the 119 RTP and RTCP packets are sent to the same destination port in the SSM 120 session. For the former case, this document defines a new SDP 121 attribute, called 'multicast-rtcp'. By using this attribute, the 122 distribution source MAY use a desired port for the SSM RTCP session. 124 The formal description of the 'multicast-rtcp' attribute is defined 125 by the following ABNF [RFC5234] syntax: 127 rtcp-attribute = "a=multicast-rtcp:" port CRLF 129 Figure 1: ABNF syntax for the 'multicast-rtcp' attribute 131 Here, the 'port' token is defined as specified in Section 9 of 132 [RFC4566]. 134 The 'multicast-rtcp' attribute MAY be used as a media-level 135 attribute; it MUST NOT be used as a session-level attribute. 137 3.1. SDP Example 139 In the SDP description shown in Figure 2, a source stream is 140 multicast from a distribution source (with a source IP address of 141 198.51.100.1) to the multicast destination address of 233.252.0.2 and 142 port 41000. The forward RTCP traffic is multicast in the same 143 multicast group but to port 42000 as specified by the "a=multicast- 144 rtcp:42000" line. A feedback target with an address of 192.0.2.1 and 145 port of 43000 is specified by the 'rtcp' attribute. 147 v=0 148 o=ali 1122334455 1122334466 IN IP4 ssm.example.com 149 s='multicast-rtcp' Example 150 t=0 0 151 a=rtcp-unicast:rsi 152 m=video 41000 RTP/AVPF 98 153 i=Multicast Stream 154 c=IN IP4 233.252.0.2/255 155 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 156 a=rtpmap:98 MP2T/90000 157 a=multicast-rtcp:42000 158 a=rtcp:43000 IN IP4 192.0.2.1 159 a=mid:1 161 Figure 2: Example SDP showing the use of the 'multicast-rtcp' 162 attribute 164 4. Security Considerations 166 The 'multicast-rtcp' attribute is not believed to introduce any 167 significant security risk to multimedia applications. A malevolent 168 third party could use this attribute to redirect the RTCP traffic, 169 but this requires intercepting and rewriting the packets carrying the 170 SDP description; and if an interceptor can do that, many more attacks 171 are possible, including a wholesale change of the addresses and port 172 numbers at which the media will be sent. Therefore, as usual 173 adequate security measures are RECOMMENDED to ensure the integrity 174 and authenticity of the SDP descriptions so that transport addresses 175 of the media senders, distribution sources, feedback targets as well 176 as other session-specific information can be authenticated. 178 5. IANA Considerations 180 The following contact information shall be used for all registrations 181 in this document: 183 Ali Begen 184 abegen@cisco.com 186 170 West Tasman Drive 187 San Jose, CA 95134 USA 189 5.1. Registration of SDP Attributes 191 This document registers a new attribute name in SDP. 193 SDP Attribute ("att-field"): 194 Attribute name: multicast-rtcp 195 Long form: Port in the multicast RTCP session 196 Type of name: att-field 197 Type of attribute: Media level 198 Subject to charset: No 199 Purpose: See this document 200 Reference: This document 201 Values: See this document 203 6. Acknowledgments 205 Thanks to Colin Perkins amd Magnus Westerlund for suggesting the name 206 for the 'multicast-rtcp' attribute. Some parts of this specification 207 are based on [RFC3605] and [RFC5760]. So, thanks to those who 208 contributed to those specifications, too. 210 7. References 212 7.1. Normative References 214 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 215 Jacobson, "RTP: A Transport Protocol for Real-Time 216 Applications", STD 64, RFC 3550, July 2003. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 222 Description Protocol", RFC 4566, July 2006. 224 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 225 in Session Description Protocol (SDP)", RFC 3605, 226 October 2003. 228 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 229 Protocol (RTCP) Extensions for Single-Source Multicast 230 Sessions with Unicast Feedback", RFC 5760, February 2010. 232 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 233 Specifications: ABNF", STD 68, RFC 5234, January 2008. 235 7.2. Informative References 237 [I-D.ietf-avt-rtp-and-rtcp-mux] 238 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 239 Control Packets on a Single Port", 240 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 241 August 2007. 243 Author's Address 245 Ali Begen 246 Cisco 247 170 West Tasman Drive 248 San Jose, CA 95134 249 USA 251 Email: abegen@cisco.com