idnits 2.17.1 draft-ietf-avtext-rid-00.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 (February 18, 2016) is 2989 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-02 ** 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: August 21, 2016 Cisco Systems 6 P. Thatcher 7 Google 8 February 18, 2016 10 RTP Stream Identifier (RID) Source Description (SDES) 11 draft-ietf-avtext-rid-00 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 August 21, 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 . . . . . . . . . . . . . . . 3 57 4.1. RTCP 'RID' SDES Extension . . . . . . . . . . . . . . . . 4 58 4.2. RTP 'RID' Header Extension . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. New SDES item . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 8.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 RTP sessions frequently consist of multiple streams, each of which is 71 identified at any given time by its SSRC; however, the SSRC 72 associated with a stream is not guaranteed to be stable over its 73 lifetime. Within a session, these streams can be tagged with a 74 number of identifiers, including CNAMEs and MSIDs 75 [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the proper 76 ordinality to refer to an individual stream; all such identifiers can 77 appear in more than one stream at a time. While approaches that use 78 unique Payload Types (PTs) per stream have been used in some 79 applications, this is a semantic overloading of that field, and one 80 for which its size is inadequate: in moderately complex systems that 81 use PT to uniquely identify every potential combination of codec 82 configuration and unique stream, it is possible to simply run out of 83 values. 85 To address this situation, we define a new RTCP SDES identifier that 86 uniquely identifies a single stream. A key motivator for defining 87 this identifier is the ability to differentiate among different 88 encodings of a single Source Stream that are sent simultaneously 89 (i.e., simulcast). This need for unique identification extends to 90 Dependent Streams (i.e., layers used by a layered codec). 92 At the same time, when Redundancy RTP Streams are in use, we also 93 need an identifier that connects such streams to the RTP stream for 94 which they are providing redundancy. To that end, when this new 95 identifier is in use, it appears (and contains the same value) in 96 both in the Redundancy RTP Stream as well as the stream it is 97 correcting. 99 For lack of a better term, we have elected to call this term "RID," 100 which loosely stands for "RTP stream IDentifier." It should be noted 101 that this isn't an overly-precise use of the term "RTP Stream," due 102 to the lack of an existing well-defined term for the construct we are 103 attempting to identify. See Section 3 for a formal definition of the 104 exact scope of a RID. 106 The use of RIDs in SDP is described in [I-D.ietf-mmusic-rid]. 108 2. Key Words for Requirements 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119] 114 3. Terminology 116 In this document, the terms "Source Stream", "Encoded Stream," "RTP 117 Stream", "Source RTP Stream", "Dependent Stream", "Received RTP 118 Stream", and "Redundancy RTP Stream" are used as defined in 119 [RFC7656]. 121 For Encoded Streams, the RID refers to the "Source RTP Stream" as 122 defined by [RFC7656] Section 2.1.10. For Dependent Streams, it 123 refers to the RTP Stream that, like the Source RTP Stream of an 124 Encoded Stream, is the RTP Stream that is not a Redundancy RTP 125 Stream. For conciseness, we define the term "RID RTP Stream" to 126 refer to this construct. 128 For clarity, when RID is used, Redundancy RTP Streams that can be 129 used to repair Received RTP Streams will use the same RID value as 130 the Received RTP Stream they are intended to be combined with. 132 4. Usage of 'rid' in RTP and RTCP 134 The RTP fixed header includes the payload type number and the SSRC 135 values of the RTP stream. RTP defines how you de-multiplex streams 136 within an RTP session; however, in some use cases, applications need 137 further identifiers in order to effectively map the individual RID 138 RTP Streams to their equivalent payload configurations in the SDP. 140 This specification defines a new RTCP SDES item [RFC3550], 'RID', 141 which is used to carry these identifiers within RTCP SDES packets. 142 This makes it possible for a receiver to associate received RTP 143 packets (identifying the RID RTP Stream) with a media description 144 having the format constraint specified. 146 This specification also uses the RTP header extension for RTCP SDES 147 items [I-D.ietf-avtext-sdes-hdr-ext] to allow carrying RID 148 information in RTP packets. This allowes correlation at stream 149 startup, or after stream changes where the use of RTCP may not be 150 sufficiently responsive. 152 4.1. RTCP 'RID' SDES Extension 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | RID=TBD | length | rid ... 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 The rid payload is UTF-8 encoded and is not null-terminated. 161 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 162 identifier value. 164 4.2. RTP 'RID' Header Extension 166 Because recipients of RTP packets will typically need to know which 167 "a=rid" constraints they correspond to immediately upon receipt, this 168 specification also defines a means of carrying RID identifiers in RTP 169 extension headers, using the technique described in 170 [I-D.ietf-avtext-sdes-hdr-ext]. 172 As described in that document, the header extension element can be 173 encoded using either the one-byte or two-byte header, and the 174 identification-tag payload is UTF-8 encoded, as in SDP. 176 As the identification-tag is included in an RTP header extension, 177 there should be some consideration about the packet expansion caused 178 by the identification-tag. To avoid Maximum Transmission Unit (MTU) 179 issues for the RTP packets, the header extension's size needs to be 180 taken into account when the encoding media. Note that set of header 181 extensions included in the packet needs to be padded to the next 182 32-bit boundary [RFC5285]. 184 It is RECOMMENDED that the identification-tag is kept short. In many 185 cases, a one-byte tag will be sufficient; it is RECOMMENDED that 186 implementations use the shortest identifier that fits their purposes. 188 5. IANA Considerations 190 5.1. New SDES item 192 RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of 193 this document. 195 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 196 identifier value. 198 This document adds the MID SDES item to the IANA "RTCP SDES item 199 types" registry as follows: 201 Value: TBD 202 Abbrev.: RID 203 Name: RTP Stream Identifier 204 Reference: RFCXXXX 206 6. Security Considerations 208 The actual identifiers used for RIDs are expected to be opaque. As 209 such, they are not expected to contain information that would be 210 sensitive, were it observed by third-parties. 212 7. Acknowledgements 214 Many thanks for review and input from Cullen Jennings, Magnus 215 Westerlund, Colin Perkins, Peter Thatcher, Jonathan Lennox, and Paul 216 Kyzivat. 218 8. References 220 8.1. Normative References 222 [I-D.ietf-avtext-sdes-hdr-ext] 223 Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 224 Header Extension for RTCP Source Description Items", 225 draft-ietf-avtext-sdes-hdr-ext-02 (work in progress), July 226 2015. 228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 229 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 230 RFC2119, March 1997, 231 . 233 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 234 Jacobson, "RTP: A Transport Protocol for Real-Time 235 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 236 July 2003, . 238 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 239 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 240 2008, . 242 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 243 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 244 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 245 DOI 10.17487/RFC7656, November 2015, 246 . 248 8.2. Informative References 250 [I-D.ietf-mmusic-msid] 251 Alvestrand, H., "WebRTC MediaStream Identification in the 252 Session Description Protocol", draft-ietf-mmusic-msid-11 253 (work in progress), October 2015. 255 [I-D.ietf-mmusic-rid] 256 Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., 257 Roach, A., and B. Campen, "RTP Payload Format 258 Constraints", draft-ietf-mmusic-rid-04 (work in progress), 259 February 2016. 261 Authors' Addresses 263 Adam Roach 264 Mozilla 266 Email: adam@nostrum.com 268 Suhas Nandakumar 269 Cisco Systems 271 Email: snandaku@cisco.com 273 Peter Thatcher 274 Google 276 Email: pthatcher@google.com