idnits 2.17.1 draft-even-clue-rtp-mapping-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 date (March 12, 2012) is 4421 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 (-25) exists of draft-ietf-clue-framework-03 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-00 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE WG R. Even 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track March 12, 2012 5 Expires: September 13, 2012 7 Mapping RTP streams to CLUE media captures 8 draft-even-clue-rtp-mapping-01.txt 10 Abstract 12 This document describes mechanisms and recommended practice for 13 mapping RTP media streams defined in SDP to CLUE media captures. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 13, 2012. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Mapping CLUE Media Captures to RTP streams . . . . . . . . . . 3 52 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 53 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 57 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 1. Introduction 62 Telepresence systems can send and receive multiple media streams. 63 The CLUE framework [I-D.ietf-clue-framework] defines media captures 64 as a source of Media, such as from one or more Capture Devices. A 65 Media Capture (MC) may be the source of one or more Media streams. A 66 Media Capture may also be constructed from other Media streams. A 67 middle box can express Media Captures that it constructs from Media 68 streams it receives. 70 SIP offer answer [RFC3264] uses SDP [RFC4566] to describe the 71 RTP[RFC3550] media streams. Each RTP stream has a payload type 72 number and SSRC. The content of the RTP stream is created by the 73 encoder in the endpoint. This may be an original content from a 74 camera or a content created by an intermediary device like an MCU. 76 The Telepresence systems MUST work in point to point calls and 77 multipoint calls when there is a central multipoint Control unit 78 (MCU). They should work in the RTP topologies defined in [RFC5117]. 79 There may be some topologies that do not scale well with SIP offer 80 answer like Topo-Translator. The assumption here is that when 81 handling the RTP streams the MCU works as an RTP mixer. 83 The relation between the two SDP and CLUE descriptions is that the 84 CLUE media capture defines adds some semantics that describing the 85 content of an RTP stream and the relations between the streams not 86 specified in SDP like spatial relation with regards to the conference 87 room. 89 This document discusses the relation between the CLUE media captures 90 and the RTP streams and makes recommendations on how to co-relate 91 between the two. It tries to use SDP attribute when possible in 92 order to not duplicate information. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC2119[RFC2119] and 99 indicate requirement levels for compliant RTP implementations. 101 3. Mapping CLUE Media Captures to RTP streams 103 The SDP description of the RTP streams provides among others the 104 information about the encoding and decoding capabilities of the media 105 as well as transport addresses for receiving the RTP streams and some 106 channels capabilities like the maximum bandwidth available for the 107 data. 109 The CLUE MCs provide semantic information of the streams which may be 110 its spatial information like left camera or on its content like 111 loudest speaker. 113 An RTP stream can have different content based on the MC description. 114 For example one video capture from a camera may capture a third of 115 the room while another from the same camera may provide a zoom 116 version of the whole room. These two media captures can be mapped to 117 the same RTP stream and they are mutually exclusive using the same 118 physical device. 120 Using the video capture example from the framework document: 122 o VC0- (the camera-left camera stream, purpose=main, switched:no 124 o VC1- (the center camera stream, purpose=main, switched:no 126 o VC2- (the camera-right camera stream), purpose=main, switched:no 128 o VC3- (the loudest panel stream), purpose=main, switched:yes 130 o VC4- (the loudest panel stream with PiPs), purpose=main, 131 composed=true; switched:yes 133 o VC5- (the zoomed out view of all people in the room), 134 purpose=main, composed=no; switched:no 136 o VC6- (presentation stream), purpose=presentation, switched:no 138 Note that the actual content of a mix or switched stream is define by 139 the provider and the description in the parenthesis is an example. 141 Where the physical simultaneity information is: 143 {VC0, VC1, VC2, VC3, VC4, VC6} 145 {VC0, VC2, VC5, VC6} 147 To describe the MCs Media Captures we need 6 RTP streams since the 148 first simultaneous entry defines 6 streams. The RTP stream used for 149 VC1 is also the RTP stream for VC5 coming from the same camera, it 150 may even use the same RTP payload type number since the only 151 difference between the two is the view port. This will mean that the 152 mapping from a Media capture to an RTP stream is fixed. The number 153 of RTP streams defined in the SDP depends on the maximum number of 154 captures in one capture set entry from the capture set. 156 The offer answer exchange should work with systems that do not 157 support CLUE protocol or multiple streams. It should also allow both 158 sides to learn if CLUE is supported. One approach is to have two 159 stage negotiation offering a single audio and maybe also a single 160 video that will allow a connection with media to be established. 161 This exchange will also enable both sides to learn if CLUE is 162 supported and start a second exchange that will list the available 163 media streams. 165 Another approach is to use the same logic specified in the 166 [I-D.ietf-mmusic-sdp-bundle-negotiation] which uses a new grouping 167 attribute and allows offering of multiple media lines in the first 168 offer. 170 The proposal bellow can be used as the initial offer if using the 171 bundle approach or for the second exchange. It provides all the 172 individual encoding information and specify the mapping between the 173 SDP media lines and the different CLUE media captures. 175 The example bellow uses a separate UDP port for each m-line but 176 multiplexing grouping as specified in 177 [I-D.ietf-mmusic-sdp-bundle-negotiation] can be applied here. 179 This mapping can be done by defining a new [RFC5888] grouping 180 attribute CaptureId and a new CLUE MC attribute RTP-id. 182 The above example will have the following SDP 184 b=AS:10000 186 a=group:captureId 1 2 3 4 5 6 188 m=video 49170 RTP/AVP 96 190 a=rtpmap:96 H264/90000 192 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 193 3.0 195 mid=1 197 b=TIAS:2000000 199 m=video 49172 RTP/AVP 96 200 a=rtpmap:96 H264/90000 202 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 203 3.0 205 mid=2 207 b=TIAS:2000000 209 m=video 49174 RTP/AVP 96 211 a=rtpmap:96 H264/90000 213 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 214 3.0 216 mid=3 218 b=TIAS:2000000 220 m=video 49176 RTP/AVP 96 222 a=rtpmap:96 H264/90000 224 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 225 3.0 227 mid=4 229 b=TIAS:2000000 231 m=video 49178 RTP/AVP 96 233 a=rtpmap:96 H264/90000 235 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 236 3.0 238 mid=5 240 b=TIAS:2000000 242 m=video 49180 RTP/AVP 96 244 a=rtpmap:96 H264/90000 246 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 247 3.0 248 mid=6 250 b=TIAS:2000000 252 There is a need for a new MC attribute RTPid which will have the mid 253 of the related RTP stream 255 o VC0- (the camera-left camera stream, purpose=main, switched:no, 256 RTPid=1 258 o VC1- (the center camera stream, purpose=main, switched:no, RTPid=2 260 o VC2- (the camera-right camera stream), purpose=main, switched:no, 261 RTPid=3 263 o VC3- (the loudest panel stream), purpose=main, switched:yes, 264 RTPid=4 266 o VC4- (the loudest panel stream with PiPs), purpose=main, 267 composed=true; switched:yes, RTPid=5 269 o VC5- (the zoomed out view of all people in the room), 270 purpose=main, composed=no; switched:no, RTPid=2 272 o VC6- (presentation stream), purpose=presentation, switched:no, 273 RTPid=6 275 There was a concern about the size of SDP or CLUE messages if the MCU 276 will advertise the roster information. This is not the current 277 approach defined in IETF work. The assumption is that the MCU decide 278 what to advertise and the roster information is provided by other 279 means like XCON conference event package enabling the conference 280 participants to use this information to select a new source. Still 281 the assumption is that the MCU acting as an RTP mixer will create the 282 RTP stream using his own SSRC. Note that for the video switch MCU 283 the SDP SSRC attribute can be used to provide the information about 284 the different sources, an example is in [RFC6184] section 8.3, this 285 solution does not scale when there are many participants since the 286 SDP may grow big and it will be better in this case to use the XCON 287 conference event package that supports partial updates. 289 The offer is for H.264 [RFC6184] profile level 3. The level ID 290 specifies the maximum encoding and decoding capabilities of the H.264 291 codec like the max macroblocks process rate, max frame size. The 292 max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br parameters 293 are used to signal the receiver implementation. The level ID is used 294 to convey also the maximum encoding capability. [RFC6184] does not 295 provide the means to override specific level parameters for the 296 encoder side; it only allows the decoder to ask for a specific 297 configuration. 299 [RFC6236] a generic session setup attribute that make it possible to 300 negotiate the image attributes like frame size and aspect ratio. 302 The bandwidth parameters can be used to specify the maximum session 303 bandwidth as well as the maximum bandwidth for individual streams. 305 4. Acknowledgements 307 place holder 309 5. IANA Considerations 311 TBD 313 6. Security Considerations 315 TBD. 317 7. References 319 7.1. Normative References 321 [I-D.ietf-clue-framework] 322 Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, 323 "Framework for Telepresence Multi-Streams", 324 draft-ietf-clue-framework-03 (work in progress), 325 February 2012. 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 7.2. Informative References 332 [I-D.ietf-mmusic-sdp-bundle-negotiation] 333 Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation 334 Using Session Description Protocol (SDP) Port Numbers", 335 draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in 336 progress), February 2012. 338 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 339 with Session Description Protocol (SDP)", RFC 3264, 340 June 2002. 342 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 343 Jacobson, "RTP: A Transport Protocol for Real-Time 344 Applications", STD 64, RFC 3550, July 2003. 346 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 347 Description Protocol", RFC 4566, July 2006. 349 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 350 January 2008. 352 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 353 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 355 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 356 Payload Format for H.264 Video", RFC 6184, May 2011. 358 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 359 Attributes in the Session Description Protocol (SDP)", 360 RFC 6236, May 2011. 362 Author's Address 364 Roni Even 365 Huawei Technologies 366 Tel Aviv, 367 Israel 369 Email: even.roni@huawei.com