idnits 2.17.1 draft-even-clue-rtp-mapping-02.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 (May 27, 2012) is 4352 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) == Missing Reference: 'RFC5245' is mentioned on line 179, but not defined ** Obsolete undefined reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-05 == 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: 1 error (**), 0 flaws (~~), 4 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 May 27, 2012 5 Expires: November 28, 2012 7 Mapping RTP streams to CLUE media captures 8 draft-even-clue-rtp-mapping-02.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 November 28, 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 . . . . . . . . . . 4 52 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 53 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 57 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 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 using one of the other 82 topologies Topo-Mixer, Topo-vide-switch-MCU or Topo-RTCP-Terminating- 83 MCU. The major difference between these topologies is on how RTCP 84 and CSRC are conveyed and the issue of identifying the original 85 source of the RTP streams need to be discussed. Note that the Topo- 86 RTCP-Terminating-MCU do not convey the CSRC information and needs 87 some other means to identify the original source of the contributing 88 RTP streams. 90 The relation between the SDP and CLUE descriptions is that the CLUE 91 media capture defined adds some semantics describing the content of 92 an RTP stream and the relations between the streams that is not 93 specified in SDP like spatial relation between the media captures 94 with regards to the conference room. 96 This document discusses the relation between the CLUE media captures 97 and the RTP streams and makes recommendations on how to co-relate 98 between the two. It tries to use SDP attributes when possible in 99 order to not duplicate information. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC2119[RFC2119] and 106 indicate requirement levels for compliant RTP implementations. 108 3. Mapping CLUE Media Captures to RTP streams 110 The SDP description of the RTP streams provides among others the 111 information about the encoding and decoding capabilities of the media 112 as well as transport addresses for receiving the RTP and RTCP streams 113 and some channels capabilities like the maximum bandwidth available 114 for the data. 116 The CLUE MCs provide semantic information of the streams which may be 117 its spatial information like left camera or on its content like 118 loudest speaker. 120 An RTP stream can have different content based on the MC description. 121 For example one video capture from a camera may capture a third of 122 the room while another from the same camera may provide a zoom 123 version of the whole room. These two media captures can be mapped to 124 the same RTP stream and they are mutually exclusive using the same 125 physical device. 127 Note: In this case the same SSRC will be used for two MCs since they 128 originate from the same source. The consumer asking to switch 129 between these two MCs may not be able to identify the switch based on 130 the RTP information. This may require the provider to acknowledge 131 the request in order to let the consumer know that its request was 132 accepted. 134 Using the video capture example from the framework 135 [I-D.ietf-clue-framework] document: 137 o VC0- (the camera-left camera stream, purpose=main, switched:no 139 o VC1- (the center camera stream, purpose=main, switched:no 141 o VC2- (the camera-right camera stream), purpose=main, switched:no 143 o VC3- (the loudest panel stream), purpose=main, switched:yes 145 o VC4- (the loudest panel stream with PiPs), purpose=main, 146 composed=true; switched:yes 148 o VC5- (the zoomed out view of all people in the room), 149 purpose=main, composed=no; switched:no 151 o VC6- (presentation stream), purpose=presentation, switched:no 153 Where the physical simultaneity information is: 155 {VC0, VC1, VC2, VC3, VC4, VC6} 157 {VC0, VC2, VC5, VC6} 159 To describe the above MCs Media Captures we need 6 RTP streams based 160 on the first simultaneous entry. The RTP stream used for VC1 is also 161 the RTP stream for VC5 coming from the same camera, it may even use 162 the same RTP payload type number since the only difference between 163 the two is the view port. This will mean that the mapping from a 164 Media capture to an RTP stream is fixed. The number of RTP streams 165 defined in the SDP depends on the number of non mutually exclusive 166 captures in the capture scene. 168 The offer answer exchange should work with systems that do not 169 support CLUE protocol or multiple streams. It should also allow both 170 sides to learn if CLUE is supported. One approach is to have two 171 stage negotiation offering a single audio and maybe also a single 172 video that will allow a connection with media to be established. 173 This exchange will also enable both sides to learn if CLUE is 174 supported and start a second exchange that will list the available 175 media streams. 177 Note: If CLUE decides to mandate RTP multiplexing it will make sense 178 to negotitate in the initial offer at least all SDP media streams in 179 order allow for ICE [RFC5245] negotiation. 181 Another approach is to use the same logic specified in the 182 [I-D.ietf-mmusic-sdp-bundle-negotiation] which uses a new grouping 183 attribute and allows offering of multiple media lines in the first 184 offer. 186 The proposal bellow can be used as the initial offer if using the 187 bundle approach or for the second offer/answer exchange if using two 188 stage negotitation. It provides all the individual encoding 189 information and specify the mapping between the SDP media lines and 190 the different CLUE media captures. 192 The example bellow uses a separate UDP port for each m-line but 193 multiplexing grouping as specified in 194 [I-D.ietf-mmusic-sdp-bundle-negotiation] can be applied here. 196 This mapping can be done by defining a new [RFC5888] grouping 197 attribute CaptureId and a new CLUE MC attribute RTP-id. 199 The above example will have the following SDP 200 b=AS:10000 202 a=group:captureId 1 2 3 4 5 6 204 m=video 49170 RTP/AVP 96 206 a=rtpmap:96 H264/90000 208 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 209 3.0 211 mid=1 213 b=TIAS:2000000 215 m=video 49172 RTP/AVP 96 217 a=rtpmap:96 H264/90000 219 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 220 3.0 222 mid=2 224 b=TIAS:2000000 226 m=video 49174 RTP/AVP 96 228 a=rtpmap:96 H264/90000 230 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 231 3.0 233 mid=3 235 b=TIAS:2000000 237 m=video 49176 RTP/AVP 96 239 a=rtpmap:96 H264/90000 241 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 242 3.0 244 mid=4 246 b=TIAS:2000000 247 m=video 49178 RTP/AVP 96 249 a=rtpmap:96 H264/90000 251 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 252 3.0 254 mid=5 256 b=TIAS:2000000 258 m=video 49180 RTP/AVP 96 260 a=rtpmap:96 H264/90000 262 a=fmtp:96 profile-level-id=42A01E; //Baseline profile, Level 263 3.0 265 mid=6 267 b=TIAS:2000000 269 There is a need for a new MC attribute RTPid which will have the mid 270 of the related RTP stream 272 o VC0- (the camera-left camera stream, purpose=main, switched:no, 273 RTPid=1 275 o VC1- (the center camera stream, purpose=main, switched:no, RTPid=2 277 o VC2- (the camera-right camera stream), purpose=main, switched:no, 278 RTPid=3 280 o VC3- (the loudest panel stream), purpose=main, switched:yes, 281 RTPid=4 283 o VC4- (the loudest panel stream with PiPs), purpose=main, 284 composed=true; switched:yes, RTPid=5 286 o VC5- (the zoomed out view of all people in the room), 287 purpose=main, composed=no; switched:no, RTPid=2 289 o VC6- (presentation stream), purpose=presentation, switched:no, 290 RTPid=6 292 There was a concern about the size of SDP or CLUE messages if the MCU 293 will advertise the roster information. This is not the current 294 approach defined in IETF work. The assumption is that the MCU 295 advertises a set of virtual MCs and provide the content of the MC 296 based on the multipoint application logic. The roster information is 297 provided by other means like XCON conference event package enabling 298 the conference participants to use this information to select a new 299 source from a new participant. Still the assumption is that the MCU 300 acting will create the RTP stream using his own SSRC. 302 Note that for the video switch MCU the SDP SSRC attribute can be used 303 to provide the information about the different sources, an example is 304 in [RFC6184] section 8.3, this solution does not scale when there are 305 many participants since the SDP may grow big and it will be better in 306 this case to use the XCON conference event package that supports 307 partial updates. 309 The offer is for H.264 [RFC6184] profile level 3. The level ID 310 specifies the maximum encoding and decoding capabilities of the H.264 311 codec like the max macroblocks process rate, max frame size. The 312 max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br parameters 313 are used to signal the receiver implementation. The level ID is used 314 to convey also the maximum encoding capability. [RFC6184] does not 315 provide the means to override specific level parameters for the 316 encoder side; it only allows the decoder to ask for a specific 317 configuration. 319 [RFC6236] a generic session setup attribute that make it possible to 320 negotiate the image attributes like frame size and aspect ratio. 322 The bandwidth parameters can be used to specify the maximum session 323 bandwidth as well as the maximum bandwidth for individual streams. 325 4. Acknowledgements 327 place holder 329 5. IANA Considerations 331 TBD 333 6. Security Considerations 335 TBD. 337 7. References 338 7.1. Normative References 340 [I-D.ietf-clue-framework] 341 Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, 342 "Framework for Telepresence Multi-Streams", 343 draft-ietf-clue-framework-05 (work in progress), 344 February 2012. 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 7.2. Informative References 351 [I-D.ietf-mmusic-sdp-bundle-negotiation] 352 Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation 353 Using Session Description Protocol (SDP) Port Numbers", 354 draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in 355 progress), February 2012. 357 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 358 with Session Description Protocol (SDP)", RFC 3264, 359 June 2002. 361 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 362 Jacobson, "RTP: A Transport Protocol for Real-Time 363 Applications", STD 64, RFC 3550, July 2003. 365 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 366 Description Protocol", RFC 4566, July 2006. 368 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 369 January 2008. 371 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 372 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 374 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 375 Payload Format for H.264 Video", RFC 6184, May 2011. 377 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 378 Attributes in the Session Description Protocol (SDP)", 379 RFC 6236, May 2011. 381 Author's Address 383 Roni Even 384 Huawei Technologies 385 Tel Aviv, 386 Israel 388 Email: even.roni@huawei.com