idnits 2.17.1 draft-ietf-avtext-rid-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 03, 2016) is 2948 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) == Outdated reference: A later version (-07) exists of draft-ietf-avtext-sdes-hdr-ext-05 ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) ** Downref: Normative reference to an Informational RFC: RFC 7656 == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-msid-11 == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-rid-04 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Roach 3 Internet-Draft Mozilla 4 Intended status: Standards Track S. Nandakumar 5 Expires: September 4, 2016 Cisco Systems 6 P. Thatcher 7 Google 8 March 03, 2016 10 RTP Stream Identifier (RID) Source Description (SDES) 11 draft-ietf-avtext-rid-01 13 Abstract 15 This document defines and registers an RTCP SDES item, RID, for 16 identification of RTP streams associated with Encoded Streams and 17 Dependent Streams. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 4, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Key Words for Requirements . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Usage of RID in RTP and RTCP . . . . . . . . . . . . . . . . 4 57 4.1. RTCP 'RID' SDES Extension . . . . . . . . . . . . . . . . 4 58 4.2. RTCP 'RRID' SDES Extension . . . . . . . . . . . . . . . 4 59 4.3. RTP 'RID' and 'RRID' Header Extensions . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 5.1. New RID SDES item . . . . . . . . . . . . . . . . . . . . 5 62 5.2. New RRID SDES item . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 RTP sessions frequently consist of multiple streams, each of which is 73 identified at any given time by its SSRC; however, the SSRC 74 associated with a stream is not guaranteed to be stable over its 75 lifetime. Within a session, these streams can be tagged with a 76 number of identifiers, including CNAMEs and MSIDs 77 [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the proper 78 ordinality to refer to an individual stream; all such identifiers can 79 appear in more than one stream at a time. While approaches that use 80 unique Payload Types (PTs) per stream have been used in some 81 applications, this is a semantic overloading of that field, and one 82 for which its size is inadequate: in moderately complex systems that 83 use PT to uniquely identify every potential combination of codec 84 configuration and unique stream, it is possible to simply run out of 85 values. 87 To address this situation, we define a new RTCP SDES identifier that 88 uniquely identifies a single stream. A key motivator for defining 89 this identifier is the ability to differentiate among different 90 encodings of a single Source Stream that are sent simultaneously 91 (i.e., simulcast). This need for unique identification extends to 92 Dependent Streams (i.e., layers used by a layered codec). 94 At the same time, when Redundancy RTP Streams are in use, we also 95 need an identifier that connects such streams to the RTP stream for 96 which they are providing redundancy. To that end, when this new 97 identifier is in use, it appears (and contains the same value) in 98 both in the Redundancy RTP Stream as well as the stream it is 99 correcting. 101 For lack of a better term, we have elected to call this term "RID," 102 which loosely stands for "RTP stream IDentifier." It should be noted 103 that this isn't an overly-precise use of the term "RTP Stream," due 104 to the lack of an existing well-defined term for the construct we are 105 attempting to identify. See Section 3 for a formal definition of the 106 exact scope of a RID. 108 The use of RIDs in SDP is described in [I-D.ietf-mmusic-rid]. 110 Finally, to accommodate the potential need to identify Redundancy RTP 111 streams independently of the stream for which they are defining 112 redundancy, we specify a second identifier, RRID (Redundancy RTP 113 Stream IDentifier). 115 2. Key Words for Requirements 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119] 121 3. Terminology 123 In this document, the terms "Source Stream", "Encoded Stream," "RTP 124 Stream", "Source RTP Stream", "Dependent Stream", "Received RTP 125 Stream", and "Redundancy RTP Stream" are used as defined in 126 [RFC7656]. 128 For Encoded Streams, the RID refers to the "Source RTP Stream" as 129 defined by [RFC7656] Section 2.1.10. For Dependent Streams, it 130 refers to the RTP Stream that, like the Source RTP Stream of an 131 Encoded Stream, is the RTP Stream that is not a Redundancy RTP 132 Stream. For conciseness, we define the term "RID RTP Stream" to 133 refer to this construct. 135 For clarity, when RID is used, Redundancy RTP Streams that can be 136 used to repair Received RTP Streams will use the same RID value as 137 the Received RTP Stream they are intended to be combined with. If 138 applications want to identify individual redundancy streams, they can 139 add an RRID to them instead of or in addition to the RID. 141 4. Usage of RID in RTP and RTCP 143 The RTP fixed header includes the payload type number and the SSRC 144 values of the RTP stream. RTP defines how you de-multiplex streams 145 within an RTP session; however, in some use cases, applications need 146 further identifiers in order to effectively map the individual RID 147 RTP Streams to their equivalent payload configurations in the SDP. 149 This specification defines two new RTCP SDES items [RFC3550]. The 150 first item is 'RID', which is used to carry RID identifiers within 151 RTCP SDES packets. This makes it possible for a receiver to 152 associate received RTP packets (identifying the RID RTP Stream) with 153 a media description having the format constraint specified. The 154 second is 'RRID', which can be used to carry a unique identifier to 155 designate Redundancy RTP Streams independently of the stream for 156 which they provide redundancy. 158 This specification also uses the RTP header extension for RTCP SDES 159 items [I-D.ietf-avtext-sdes-hdr-ext] to allow carrying RID and RRID 160 information in RTP packets. This allowes correlation at stream 161 startup, or after stream changes where the use of RTCP may not be 162 sufficiently responsive. 164 4.1. RTCP 'RID' SDES Extension 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | RID=TBD | length | rid ... 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 The rid payload is UTF-8 encoded and is not null-terminated. 173 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 174 identifier value. 176 4.2. RTCP 'RRID' SDES Extension 178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | RRID=TBD | length | rrid ... 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 The rrid payload is UTF-8 encoded and is not null-terminated. 185 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 186 identifier value. 188 4.3. RTP 'RID' and 'RRID' Header Extensions 190 Because recipients of RTP packets will typically need to know which 191 streams they correspond to immediately upon receipt, this 192 specification also defines a means of carrying RID and RRID 193 identifiers in RTP extension headers, using the technique described 194 in [I-D.ietf-avtext-sdes-hdr-ext]. 196 As described in that document, the header extension element can be 197 encoded using either the one-byte or two-byte header, and the 198 identification-tag payload is UTF-8 encoded, as in SDP. 200 As the identification-tag is included in an RTP header extension, 201 there should be some consideration about the packet expansion caused 202 by the identification-tag. To avoid Maximum Transmission Unit (MTU) 203 issues for the RTP packets, the header extension's size needs to be 204 taken into account when the encoding media. Note that set of header 205 extensions included in the packet needs to be padded to the next 206 32-bit boundary [RFC5285]. 208 It is RECOMMENDED that the identification-tag is kept short. In many 209 cases, a one-byte tag will be sufficient; it is RECOMMENDED that 210 implementations use the shortest identifier that fits their purposes. 212 5. IANA Considerations 214 5.1. New RID SDES item 216 RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of 217 this document. 219 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 220 identifier value. 222 This document adds the MID SDES item to the IANA "RTCP SDES item 223 types" registry as follows: 225 Value: TBD 226 Abbrev.: RID 227 Name: RTP Stream Identifier 228 Reference: RFCXXXX 230 5.2. New RRID SDES item 232 RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of 233 this document. 235 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 236 identifier value. 238 This document adds the MID SDES item to the IANA "RTCP SDES item 239 types" registry as follows: 241 Value: TBD 242 Abbrev.: RRID 243 Name: Redundancy RTP Stream Identifier 244 Reference: RFCXXXX 246 6. Security Considerations 248 The actual identifiers used for RIDs and RRIDs are expected to be 249 opaque. As such, they are not expected to contain information that 250 would be sensitive, were it observed by third-parties. 252 7. Acknowledgements 254 Many thanks for review and input from Cullen Jennings, Magnus 255 Westerlund, Colin Perkins, Peter Thatcher, Jonathan Lennox, and Paul 256 Kyzivat. 258 8. References 260 8.1. Normative References 262 [I-D.ietf-avtext-sdes-hdr-ext] 263 Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 264 Header Extension for RTCP Source Description Items", 265 draft-ietf-avtext-sdes-hdr-ext-05 (work in progress), 266 March 2016. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 270 RFC2119, March 1997, 271 . 273 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 274 Jacobson, "RTP: A Transport Protocol for Real-Time 275 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 276 July 2003, . 278 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 279 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 280 2008, . 282 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 283 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 284 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 285 DOI 10.17487/RFC7656, November 2015, 286 . 288 8.2. Informative References 290 [I-D.ietf-mmusic-msid] 291 Alvestrand, H., "WebRTC MediaStream Identification in the 292 Session Description Protocol", draft-ietf-mmusic-msid-11 293 (work in progress), October 2015. 295 [I-D.ietf-mmusic-rid] 296 Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., 297 Roach, A., and B. Campen, "RTP Payload Format 298 Constraints", draft-ietf-mmusic-rid-04 (work in progress), 299 February 2016. 301 Authors' Addresses 303 Adam Roach 304 Mozilla 306 Email: adam@nostrum.com 308 Suhas Nandakumar 309 Cisco Systems 311 Email: snandaku@cisco.com 313 Peter Thatcher 314 Google 316 Email: pthatcher@google.com