idnits 2.17.1 draft-roach-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 (February 01, 2016) is 2978 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-00 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 4, 2016 Cisco Systems 6 P. Thatcher 7 Google 8 February 01, 2016 10 RTP Payload Format Constraints 11 draft-roach-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 August 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 . . . . . . . . . . . . . . . 3 57 4.1. RTCP 'RID' SDES Extension . . . . . . . . . . . . . . . . 4 58 4.2. RTP 'RID' Header Extension . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 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. 127 For clarity, when RID is used, Redundancy RTP Streams that can be 128 used to repair Received RTP Streams will use the same RID value as 129 the Received RTP Stream they are intended to be combined with. 131 4. Usage of 'rid' in RTP and RTCP 133 The RTP fixed header includes the payload type number and the SSRC 134 values of the RTP stream. RTP defines how you de-multiplex streams 135 within an RTP session; however, in some use cases, applications need 136 further identifiers in order to effectively map the individual RTP 137 Streams to their equivalent payload configurations in the SDP. 139 This specification defines a new RTCP SDES item [RFC3550], 'RID', 140 which is used to carry these identifiers within RTCP SDES packets. 141 This makes it possible for a receiver to associate received RTP 142 packets (identifying the Source RTP Stream) with a media description 143 having the format constraint specified. 145 This specification also uses the RTP header extension for RTCP SDES 146 items [I-D.ietf-avtext-sdes-hdr-ext] to allow carrying RID 147 information in RTP packets. This allowes correlation at stream 148 startup, or after stream changes where the use of RTCP may not be 149 sufficiently responsive. 151 4.1. RTCP 'RID' SDES Extension 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | RID=TBD | length | rid ... 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 The rid payload is UTF-8 encoded and is not null-terminated. 160 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 161 identifier value. 163 4.2. RTP 'RID' Header Extension 165 Because recipients of RTP packets will typically need to know which 166 "a=rid" constraints they correspond to immediately upon receipt, this 167 specification also defines a means of carrying RID identifiers in RTP 168 extension headers, using the technique described in 169 [I-D.ietf-avtext-sdes-hdr-ext]. 171 As described in that document, the header extension element can be 172 encoded using either the one-byte or two-byte header, and the 173 identification-tag payload is UTF-8 encoded, as in SDP. 175 As the identification-tag is included in an RTP header extension, 176 there should be some consideration about the packet expansion caused 177 by the identification-tag. To avoid Maximum Transmission Unit (MTU) 178 issues for the RTP packets, the header extension's size needs to be 179 taken into account when the encoding media. Note that set of header 180 extensions included in the packet needs to be padded to the next 181 32-bit boundary [RFC5285]. 183 It is RECOMMENDED that the identification-tag is kept short. In many 184 cases, a one-byte tag will be sufficient; it is RECOMMENDED that 185 implementations use the shortest identifier that fits their purposes. 187 5. IANA Considerations 188 5.1. New SDES item 190 RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of 191 this document. 193 RFC EDITOR NOTE: Please replace TBD with the assigned SDES 194 identifier value. 196 This document adds the MID SDES item to the IANA "RTCP SDES item 197 types" registry as follows: 199 Value: TBD 200 Abbrev.: RID 201 Name: Restriction Identification 202 Reference: RFCXXXX 204 6. Security Considerations 206 The actual identifiers used for RIDs are expected to be opaque. As 207 such, they are not expected to contain information that would be 208 sensitive, were it observed by third-parties. 210 7. Acknowledgements 212 Many thanks for review and input from Cullen Jennings, Magnus 213 Westerlund, Colin Perkins, Peter Thatcher, Jonathan Lennox, and Paul 214 Kyzivat. 216 8. References 218 8.1. Normative References 220 [I-D.ietf-avtext-sdes-hdr-ext] 221 Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 222 Header Extension for RTCP Source Description Items", 223 draft-ietf-avtext-sdes-hdr-ext-02 (work in progress), July 224 2015. 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 228 RFC2119, March 1997, 229 . 231 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 232 Jacobson, "RTP: A Transport Protocol for Real-Time 233 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 234 July 2003, . 236 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 237 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 238 2008, . 240 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 241 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 242 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 243 DOI 10.17487/RFC7656, November 2015, 244 . 246 8.2. Informative References 248 [I-D.ietf-mmusic-msid] 249 Alvestrand, H., "WebRTC MediaStream Identification in the 250 Session Description Protocol", draft-ietf-mmusic-msid-11 251 (work in progress), October 2015. 253 [I-D.ietf-mmusic-rid] 254 Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., 255 Roach, A., and B. Campen, "RTP Payload Format 256 Constraints", draft-ietf-mmusic-rid-00 (work in progress), 257 November 2015. 259 Authors' Addresses 261 Adam Roach 262 Mozilla 264 Email: adam@nostrum.com 266 Suhas Nandakumar 267 Cisco Systems 269 Email: snandaku@cisco.com 271 Peter Thatcher 272 Google 274 Email: pthatcher@google.com