idnits 2.17.1 draft-avtext-berger-framemarking-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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 21, 2013) is 3840 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) == Unused Reference: 'KEYWORDS' is defined on line 228, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 239, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Berger 3 Internet-Draft S. Nandakumar 4 Intended status: Standards Track Cisco Systems 5 Expires: April 24, 2014 October 21, 2013 7 Frame marking for RTP packets 8 draft-avtext-berger-framemarking-00 10 Abstract 12 This document describes a mechanisms to provide frame markings to 13 allow RTP switches to perform stream operations on encrypted payload. 14 The mechanisms support extensions to allow for codec specific 15 information. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 24, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. RTP header extension . . . . . . . . . . . . . . . . . . . 4 54 2.2. Signaling information . . . . . . . . . . . . . . . . . . . 5 55 2.3. Considerations on use . . . . . . . . . . . . . . . . . . . 5 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 60 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 It is common practice in modern voice and video conferencing systems 66 to implement a centralized component that acts as a RTP switch. It 67 receives voice and video streams from each participant, which may be 68 encrypted using SRTP [RFC3711]. The goal is to provide a set of 69 streams back to the participants which enable them to render the 70 right media content. In a simple video configuration, for example, 71 the goal will be that each participant sees and hears just the active 72 speaker. In that case, the goal of the switch is to receive the 73 voice and video streams from each participant, determine the active 74 speaker based on energy in the voice packets, and select the 75 corresponding video stream for transmission to participants, see 76 Figure 1 78 In this document, an "RTP switch" is used as a common short term for 79 the terms switching RTP mixer", "source projecting middlebox", and 80 "video switching MCU" as discussed in 81 [I-D.ietf-avtcore-rtp-topologies-update]. 83 +---+ +------------+ +---+ 84 | A |<---->| |<---->| B | 85 +---+ | | +---+ 86 | RTP | 87 +---+ | Switch | +---+ 88 | C |<---->| |<---->| D | 89 +---+ +------------+ +---+ 91 Figure 1: RTP switch 93 In order to properly support switching of video streams, the RTP 94 switch typically needs information in order to do a proper job: 95 o Because of inter-frame dependencies, it should ideally switch 96 video streams at a point where the first frame from the new 97 speaker can be decoded by recipients without prior frames, e.g 98 switch on an intra-frame. 99 o In many cases, the switch may need to drop frames in order to 100 realize congestion control techniques, and needs to know which 101 frames can be dropped with minimal impact to video quality 102 o Furthermore, it is highly desirable to do this in a way which is 103 not specific to the video codec. Nearly all modern video codecs 104 share common concepts around I, P, B frames. 105 o It is also desirable to be able to do this for SRTP without 106 requiring the video switch to decrypt the packets. SRTP will 107 encrypt the RTP payload format contents and consequently this data 108 is not usable for the switching function. 110 By providing meta-information about the RTP streams outside the 111 encrypted media payload a RTP switch can do selective forwarding 112 without decrypting the payload. This document provides a solution to 113 this problem. 115 2. Solution 117 The solution uses RTP header extensions as defined in [RFC5285]. A 118 subset of meta-information from the video stream is provided as an 119 header extension to allow a RTP switch to do generic video switching 120 handling of video streams encoded with different video codecs. 122 The following information are extracted from the media payload. 123 o Discardable - The flag must be true for packets that can be 124 dropped, and still provide a decodable media stream. 125 o Switching point (1 bit) - The flag must be true for RTP packets in 126 a frame that can be used as a switcing point. A switching point 127 is the first packet where a new receiver can start decoding a 128 video stream without prior frames, e.g an IDR frame from 129 [RFC6184]. 130 o Temporal ID (3 bits) - The base temporal quality starts with 0, 131 and increases with 1 for each temporal layer. 132 o frame Type (3 bits) - Abstract frame type; P-frame=0, IDR=1, 133 GDR=2. The abstracted frame types are: 134 * P-frame - a frame depending on a previous frame 135 * IDR - a frame without references to other frames 136 * GDR - a Gradual Decoder Refresh (GDR) packet includes both 137 p-frame and frame information to allow a receiver to build of a 138 IDR frame over a short period. 140 Video codec specific information can be provided as an extension. 142 2.1. RTP header extension 144 The values of frame information can be carried as RTP header 145 extensions encoded using the one-byte header as described in 146 [RFC5285]. Only the one-byte header version is listed with examples 147 in the document. 149 0 1 150 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | ID=2 | L=0 |D|S|TID |Type | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 The frame marking can be extended with codec specific information 156 using a longer length value in the one-byte header. The codec 157 specific information included in the header extension MUST match the 158 SDP negotiated payload format for the RTP stream. 160 0 1 2 3 161 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 2 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | ID=2 | L=2 |D|S|TID |Type | video codec specific information | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 In the following example the H265 LayerID is included as video codec 167 specific information. The length field is 1 to add another 1 byte of 168 data, the H265 LayerId is a 6-bit field and a 2-bit PADding at the 169 end. 171 0 1 2 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | ID=2 | L=1 |D|S|TID |Type | H265-LayerId|PAD| 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 2.2. Signaling information 179 The URI for declaring this header extension in an extmap attribute is 180 "urn:ietf:params:rtp-hdrext:framemarkinginfo". It does not contain 181 any extension attributes. 183 An example attribute line in SDP: 185 a=extmap:3 urn:ietf:params:rtp-hdrext:framemarkinginfo 187 2.3. Considerations on use 189 The header extension values MUST represent what is already in the RTP 190 payload. 192 When a RTP switch needs to discard a received video frame due to 193 congestion control considerations, it is RECOMMENDED that it 194 preferably drop frames marked with the "discardable" bit. 196 When a RTP switch want to forward a new video stream to a receiver, 197 its RECOMMENDED to forward the new video stream from the first 198 switching point and forward. A RTP switch can request a media source 199 to generate a switching point for H264 by sending Full Intra Request 200 (RTCP FIR) as defined in [RFC5104]. 202 3. Security Considerations 204 In the Secure Real-Time Transport Protocol (SRTP) [RFC3711], RTP 205 header extensions are authenticated but not encrypted. When header 206 extensions are used some of the payload type information are exposed 207 and is visible to middle boxes. The encrypted media data is not 208 exposed, so this is not seen as a high risk exposure. 210 4. IANA Considerations 212 This document defines a new extension URI to the RTP Compact 213 HeaderExtensions sub-registry of the Real-Time Transport Protocol 214 (RTP) Parameters registry, according to the following data: 216 Extension URI: urn:ietf:params:rtp-hdrext:framemarkinginfo 217 Description: Frame marking information for video streams 218 Contact: espeberg@cisco.com 219 Reference: RFC XXXX 221 Note to RFC Editor: please replace RFC XXXX with the number of this 222 RFC. 224 5. References 226 5.1. Normative References 228 [KEYWORDS] 229 Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 5.2. Informative References 234 [I-D.ietf-avtcore-rtp-topologies-update] 235 Westerlund, M. and S. Wenger, "RTP Topologies", 236 draft-ietf-avtcore-rtp-topologies-update (work in 237 progress), April 2013. 239 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 240 Jacobson, "RTP: A Transport Protocol for Real-Time 241 Applications", STD 64, RFC 3550, July 2003. 243 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 244 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 245 RFC 3711, March 2004. 247 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 248 "Codec Control Messages in the RTP Audio-Visual Profile 249 with Feedback (AVPF)", RFC 5104, February 2008. 251 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 252 Header Extensions", RFC 5285, July 2008. 254 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 255 Payload Format for H.264 Video", RFC 6184, May 2011. 257 Authors' Addresses 259 Espen Berger 260 Cisco Systems 262 Phone: +47 98228179 263 Email: espeberg@cisco.com 265 Suhas Nandakumar 266 Cisco Systems 267 170 West Tasman Drive 268 San Jose, CA 95134 269 US 271 Email: snandaku@cisco.com