idnits 2.17.1 draft-ietf-clue-rtp-mapping-04.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 8, 2015) is 3334 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: 'RFCXXXX' is mentioned on line 596, but not defined == Unused Reference: 'RFC5117' is defined on line 660, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-17 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-12 == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-topologies-update-04 == Outdated reference: A later version (-15) exists of draft-ietf-clue-signaling-03 == Outdated reference: A later version (-14) exists of draft-ietf-mmusic-sdp-simulcast-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) -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 4 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 J. Lennox 5 Expires: September 9, 2015 Vidyo 6 March 8, 2015 8 Mapping RTP streams to CLUE media captures 9 draft-ietf-clue-rtp-mapping-04.txt 11 Abstract 13 This document describes how the Real Time transport Protocol (RTP) is 14 used in the context of the CLUE protocol. It also describes the 15 mechanisms and recommended practice for mapping RTP media streams 16 defined in SDP to CLUE media captures. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 9, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. RTP topologies for CLUE . . . . . . . . . . . . . . . . . . . 3 55 4. Mapping CLUE Capture Encodings to RTP streams . . . . . . . . 5 56 4.1. Review of RTP related documents relevant to CLUE work. . 6 57 4.2. Requirements of a solution . . . . . . . . . . . . . . . 7 58 4.3. Static Mapping . . . . . . . . . . . . . . . . . . . . . 9 59 4.4. Dynamic mapping . . . . . . . . . . . . . . . . . . . . . 9 60 4.5. Recommendations . . . . . . . . . . . . . . . . . . . . . 9 61 5. Application to CLUE Media Requirements . . . . . . . . . . . 10 62 6. CaptureID definition . . . . . . . . . . . . . . . . . . . . 11 63 6.1. RTCP CaptureId SDES Item . . . . . . . . . . . . . . . . 12 64 6.2. RTP Header Extension . . . . . . . . . . . . . . . . . . 12 65 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 11.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 Telepresence systems can send and receive multiple media streams. 77 The CLUE framework [I-D.ietf-clue-framework] defines media captures 78 as a source of Media, such as from one or more Capture Devices. A 79 Media Capture may also be constructed from other Media streams. A 80 middle box can express conceptual Media Captures that it constructs 81 from Media streams it receives. A Multiple Content Capture (MCC) is 82 a special Media Capture composed of multiple Media Captures. 84 SIP offer answer [RFC3264] uses SDP [RFC4566] to describe the 85 RTP[RFC3550] media streams. Each RTP stream has a unique SSRC within 86 its RTP session. The content of the RTP stream is created by an 87 encoder in the endpoint. This may be an original content from a 88 camera or a content created by an intermediary device like an MCU. 90 This document makes recommendations, for the telepresence 91 architecture, about how RTP and RTCP streams should be encoded and 92 transmitted, and how their relation to CLUE Media Captures should be 93 communicated. The proposed solution supports multiple RTP 94 topologies. 96 With regards to the media (audio and video), systems that support 97 CLUE use RTP for the media, SDP for codec and media transport 98 negotiation (CLUE individual encodings) and the CLUE protocol for 99 media Capture description and selection. In order to associate the 100 media in the different protocols there are three mapping that need to 101 be specified: 103 1. CLUE individual encodings to SDP 105 2. RTP media streams to SDP (this is not a CLUE specific mapping) 107 3. RTP media streams to MC to map the received RTP steam to the 108 current MC in the MCC. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC2119[RFC2119] and 115 indicate requirement levels for compliant RTP implementations. 117 3. RTP topologies for CLUE 119 The typical RTP topologies used by Telepresence systems specify 120 different behaviors for RTP and RTCP distribution. A number of RTP 121 topologies are described in [I-D.ietf-avtcore-rtp-topologies-update]. 122 For telepresence, the relevant topologies include point-to-point, as 123 well as media mixers, media- switching mixers, and Selective 124 Forwarding middleboxs. 126 In the point-to-point topology, one peer communicates directly with a 127 single peer over unicast. There can be one or more RTP sessions, and 128 each RTP session can carry multiple RTP streams identified by their 129 SSRC. All SSRCs will be recognized by the peers based on the 130 information in the RTCP SDES report that will include the CNAME and 131 SSRC of the sent RTP streams. There are different point to point use 132 cases as specified in CLUE use case [RFC7205]. There may be a 133 difference between the symmetric and asymmetric use cases. While in 134 the symmetric use case the typical mapping will be from a Media 135 capture device to a render device (e.g. camera to monitor) in the 136 asymmetric case the render device may receive different capture 137 information (RTP stream from different cameras) if it has fewer 138 rendering devices (monitors). In some cases, a CLUE session which, 139 at a high-level, is point-to-point may nonetheless have RTP which is 140 best described by one of the mixer topologies. For example, a CLUE 141 endpoint can produce composite or switched captures for use by a 142 receiving system with fewer displays than the sender has cameras. 143 The Media capture may be described using MCC. 145 For the Media Mixer topology 146 [I-D.ietf-avtcore-rtp-topologies-update], the peers communicate only 147 with the mixer. The mixer provides mixed or composited media 148 streams, using its own SSRC for the sent streams. There are two 149 cases here. In the first case the mixer may have separate RTP 150 sessions with each peer (similar to the point to point topology) 151 terminating the RTCP sessions on the mixer; this is known as Topo- 152 RTCP-Terminating MCU in [I-D.ietf-avtcore-rtp-topologies-update]. In 153 the second case, the mixer can use a conference-wide RTP session 154 similar to [I-D.ietf-avtcore-rtp-topologies-update] Topo-mixer or 155 Topo-Video-switching. The major difference is that for the second 156 case, the mixer uses conference-wide RTP sessions, and distributes 157 the RTCP reports to all the RTP session participants, enabling them 158 to learn all the CNAMEs and SSRCs of the participants and know the 159 contributing source or sources (CSRCs) of the original streams from 160 the RTP header. In the first case, the Mixer terminates the RTCP and 161 the participants cannot know all the available sources based on the 162 RTCP information. The conference roster information including 163 conference participants, endpoints, media and media-id (SSRC) can be 164 available using the conference event package [RFC4575] element. 166 In the Media-Switching Mixer topology 167 [I-D.ietf-avtcore-rtp-topologies-update], the peer to mixer 168 communication is unicast with mixer RTCP feedback. It is 169 conceptually similar to a compositing mixer as described in the 170 previous paragraph, except that rather than compositing or mixing 171 multiple sources, the mixer provides one or more conceptual sources 172 selecting one source at a time from the original sources. The Mixer 173 creates a conference-wide RTP session by sharing remote SSRC values 174 as CSRCs to all conference participants. 176 In the Selective Forwarding middlebox topology, the peer to mixer 177 communication is unicast with RTCP mixer feedback. Every potential 178 sender in the conference has a source which may be "projected" by the 179 mixer into every other RTP session in the conference; thus, every 180 original source is maintained with an independent RTP identity to 181 every receiver, maintaining separate decoding state and its original 182 RTCP SDES information. However, RTCP is terminated at the mixer, 183 which might also perform reliability, repair, rate adaptation, or 184 transcoding on the stream. Senders' SSRCs may be renumbered by the 185 mixer. The sender may turn the projected sources on and off at any 186 time, depending on which sources it thinks are most relevant for the 187 receiver; this is the primary reason why this topology must act as an 188 RTP mixer rather than as a translator, as otherwise these disabled 189 sources would appear to have enormous packet loss. Source switching 190 is accomplished through this process of enabling and disabling 191 projected sources, with the higher-level semantic assignment of 192 reason for the RTP streams assigned externally. 194 The above topologies demonstrate two major RTP/RTCP behaviors: 196 1. The mixer may either use the source SSRC when forwarding RTP 197 packets, or use its own created SSRC. Still the mixer will 198 distribute all RTCP information to all participants creating 199 conference-wide RTP session/s. This allows the participants to 200 learn the available RTP sources in each RTP session. The 201 original source information will be the SSRC or in the CSRC 202 depending on the topology. The point to point case behaves like 203 this. 205 2. The mixer terminates the RTCP from the source, creating separate 206 RTP sessions with the peers. In this case the participants will 207 not receive the source SSRC in the CSRC. Since this is usually a 208 mixer topology, the source information is available from the SIP 209 conference event package [RFC4575]. Subscribing to the 210 conference event package allows each participant to know the 211 SSRCs of all sources in the conference. 213 4. Mapping CLUE Capture Encodings to RTP streams 215 The different topologies described in Section 3 create different SSRC 216 distribution models and RTP stream multiplexing points. 218 Most video conferencing systems today can separate multiple RTP 219 sources by placing them into separate RTP sessions using, the SDP 220 description. For example, main and slides video sources are 221 separated into separate RTP sessions based on the content attribute 222 [RFC4796]. This solution works straightforward if the multiplexing 223 point is at the UDP transport level, where each RTP stream uses a 224 separate RTP session. This will also be true for mapping the RTP 225 streams to Media Captures Encodings if each media capture encodings 226 uses a separate RTP session, and the consumer can identify it based 227 on the receiving RTP port. In this case, SDP only needs to label the 228 RTP session with an identifier that can be used to identify the media 229 capture in the CLUE description. The SDP label attribute serves as 230 this identifier. In this case, the mapping does not change even if 231 the RTP session is switched using same or different SSRC. (The 232 multiplexing is not at the SSRC level). 234 Even though Session multiplexing is supported by CLUE, for scaling 235 reasons, CLUE recommends using SSRC multiplexing in a single or 236 multiple sessions using [I-D.ietf-mmusic-sdp-bundle-negotiation]. So 237 we need to look at how to map RTP streams to Captures Encodings when 238 SSRC multiplexing is used. 240 When looking at SSRC multiplexing we can see that in various 241 topologies, the SSRC behavior may be different: 243 1. The SSRCs are static (assigned by the MCU/Mixer), and there is an 244 SSRC for each media capture encoding defined in the CLUE 245 protocol. Source information may be conveyed using CSRC, or, in 246 the case of topo-RTCP-Terminating MCU, is not conveyed. 248 2. The SSRCs are dynamic, representing the original source and are 249 relayed by the Mixer/MCU to the participants. 251 In the above two cases the MCU/Mixer may create an advertisement, 252 with a virtual room capture scene. 254 Another case we can envision is that the MCU / Mixer relays all the 255 capture scenes from all advertisements to all consumers. This means 256 that the advertisement will include multiple capture scenes, each 257 representing a separate TelePresence room with its own coordinate 258 system. 260 MCCs bring another mapping issue, in that an MCC represents multiple 261 Media Captures that can be sent as part of this MCC if configured by 262 the consumer. When receiving an RTP stream which is mapped to the 263 MCC, the consumer needs to know which original MC it is in order to 264 get the MC parameters from the advertisement. If a consumer 265 requested a MCC, the original MC does not have a capture encoding, so 266 it cannot be associated with an m-line using a label as described in 267 CLUE signaling [I-D.ietf-clue-signaling]. This is important, for 268 example, to get correct scaling information for the original MC, 269 which may be different for the various MCs that are contributing to 270 the MCC. 272 4.1. Review of RTP related documents relevant to CLUE work. 274 Editor's note: This section provides an overview of the RFCs and 275 drafts that are can be used in a CLUE system and as a base for a 276 mapping solution. This section is for information only; the 277 normative behavior is given in the cited documents. Tools for SSRC 278 multiplexing support are defined for general conferencing 279 applications; CLUE systems use the same tools. 281 The solution needs to also support the simulcast case where more than 282 one RTP session may be advertised for a Media Capture. Support of 283 such simulcast is out of scope for CLUE but a solution is needed. 285 When looking at the available tools based on current work in MMUSIC, 286 AVTcore and AVText for supporting SSRC multiplexing the following 287 documents are considered to be relevant. 289 Negotiating Media Multiplexing Using the Session Description Protocol 290 in [I-D.ietf-mmusic-sdp-bundle-negotiation] defines a "bundle" SDP 291 grouping extension that can be used with SDP Offer/Answer mechanism 292 to negotiate the usage of a single 5-tuple for sending and receiving 293 media associated with multiple SDP media descriptions ("m="). 294 [bundle] specifies how to associate a received RTP stream with the 295 m-line describing it. The assumption in the work is that each SDP 296 m-line represents a single media source. 297 [I-D.ietf-mmusic-sdp-bundle-negotiation] specifies using the SDP mid 298 value and sending it as RTCP SDES and an RTP header extension in 299 order to be able to map the RTP stream to the SDP m-line. This is 300 relevant when there are multiple RTP streams with the same payload 301 subtype number. 303 SDP Source attribute [RFC5576] mechanisms to describe specific 304 attributes of RTP sources based on their SSRC. 306 Negotiation of generic image attributes in SDP [RFC6236] provides the 307 means to negotiate the image size. The image attribute can be used 308 to offer different image parameters like size but in order to offer 309 multiple RTP streams with different resolutions it does it using 310 separate RTP session for each image option 311 ([I-D.ietf-mmusic-sdp-bundle-negotiation] provides the support of a 312 single RTP session but each image option will need a separate SDP 313 m-line). 315 The recommended support of the simulcast case is to use 316 [I-D.ietf-mmusic-sdp-simulcast] 318 In the next sections, the document will propose mechanisms to map the 319 RTP streams to media captures addressing. 321 4.2. Requirements of a solution 323 This section lists, more briefly, the requirements a media 324 architecture for Clue telepresence needs to achieve, summarizing the 325 discussion of previous sections. In this section, RFC 2119 [RFC2119] 326 language refers to requirements on a solution, not an implementation; 327 thus, requirements keywords are not written in capital letters. 329 Media-1: It must not be necessary for a Clue session to use more than 330 a single transport flow for transport of a given media type (video or 331 audio). 333 Media-2: It must, however, be possible for a Clue session to use 334 multiple transport flows for a given media type where it is 335 considered valuable (for example, for distributed media, or 336 differential quality-of-service). 338 Media-3: It must be possible for a Clue endpoint or MCU to 339 simultaneously send sources corresponding to static captures and to 340 both composited and switched multi-content captures in the same 341 transport flow. (Any given device might not necessarily be able send 342 all of these source types; but for those that can, it must be 343 possible for them to be sent simultaneously.) 345 Media-4: It must be possible for an original source to move among 346 multi-content captures (i.e. at one time be sent for one MCC, and at 347 a later time be sent for another one). 349 Media-5: It must be possible for a source to be placed into a MCC 350 even if the source is a "late joiner", i.e. was added to the 351 conference after the receiver requested the MCC. 353 Media-6: Whenever a given source is assigned to a switched capture, 354 it must be immediately possible for a receiver to determine the MCC 355 it corresponds to, and thus that any previous source is no longer 356 being mapped to that switched capture. 358 Media-7: It must be possible for a receiver to identify the original 359 capture(s) that are currently being mapped to an MCC, and correlate 360 it with both the Clue advertisement and out-of-band (non-Clue) 361 information such as rosters. 363 Media-8: It must be possible for a source to move among MCCs without 364 requiring a refresh of decoder state (e.g., for video, a fresh 365 I-frame), when this is unnecessary. However, it must also be 366 possible for a receiver to indicate when a refresh of decoder state 367 is in fact necessary. 369 Media-9: If a given source is being sent on the same transport flow 370 for more than one reason (e.g. if it corresponds to more than one 371 switched capture at once, or to a static capture), it should be 372 possible for a sender to send only one copy of the source. 374 Media-10: On the network, media flows should, as much as possible, 375 look and behave like currently-defined usages of existing protocols; 376 established semantics of existing protocols must not be redefined. 378 Media-11: The solution should seek to minimize the processing burden 379 for boxes that distribute media to decoding hardware. 381 Media-12: If multiple sources from a single synchronization context 382 are being sent simultaneously, it must be possible for a receiver to 383 associate and synchronize them properly, even for sources that are 384 are mapped to switched captures. 386 4.3. Static Mapping 388 Static mapping is widely used in current MCU implementations. It is 389 also common for a point to point symmetric use case when both 390 endpoints have the same capabilities. For capture encodings with 391 static SSRCs, it is most straightforward to indicate this mapping 392 outside the media stream, in the CLUE or SDP signaling. When using 393 SSRC multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation] defines 394 the use of the SDP mid attribute value to associate between the 395 received RTP stream and the SDP m-line. The mid is carried as an RTP 396 header extension and RTCP SDES message defined in 397 [I-D.ietf-mmusic-sdp-bundle-negotiation] . 399 4.4. Dynamic mapping 401 Dynamic mapping by tagging each media packet with the SDP mid value. 402 This means that a receiver immediately knows how to interpret 403 received media, even when an unknown SSRC is seen. As long as the 404 media carries a known mid, it can be assumed that this media stream 405 will replace the stream currently being received with that mid. 407 This gives significant advantages to switching latency, as a switch 408 between sources can be achieved without any form of negotiation with 409 the receiver. 411 However, the disadvantage in using a mid in the stream that it 412 introduces additional processing costs for every media packet, as mid 413 are scoped only within one hop (i.e., within a cascaded conference a 414 mid that is used from the source to the first MCU is not meaningful 415 between two MCUs, or between an MCU and a receiver), and so they may 416 need to be added or modified at every stage. 418 An additional issue with putting mid in the RTP packets comes from 419 cases where a non-bundle aware endpoint is being switched by an MCU 420 to a bundle endpoint. In this case, we may require up to an 421 additional 12 bytes in the RTP header, which may push a media packet 422 over the MTU. However, as the MTU on either side of the switch may 423 not match, it is possible that this could happen even without adding 424 extra data into the RTP packet. The 12 additional bytes per packet 425 could also be a significant bandwidth increase in the case of very 426 low bandwidth audio codecs. 428 4.5. Recommendations 430 The recommendation is that CLUE endpoint using SSRC multiplexing MUST 431 support [[I-D.ietf-mmusic-sdp-bundle-negotiation] and use the SDP mid 432 attribute for mapping. 434 5. Application to CLUE Media Requirements 436 The requirement section Section 4.2 offers a number of requirements 437 that are believed to be necessary for a CLUE RTP mapping. The 438 solutions described in this document are believed to meet these 439 requirements, though some of them are only possible for some of the 440 topologies. (Since the requirements are generally of the form "it 441 must be possible for a sender to do something", this is adequate; a 442 sender which wishes to perform that action needs to choose a topology 443 which allows the behavior it wants. 445 In this section we address only those requirements where the 446 topologies or the association mechanisms treat the requirements 447 differently. 449 Media-4: It must be possible for an original source to move among 450 switched captures (i.e. at one time be sent for one switched capture, 451 and at a later time be sent for another one). 453 This applies naturally for static sources with a Switched Mixer. For 454 dynamic sources with a Selective Forwarding middlebox, this just 455 requires the mid in the header extension element to be updated 456 appropriately. 458 Media-6: Whenever a given source is transmitted for a switched 459 capture, it must be immediately possible for a receiver to determine 460 the switched capture it corresponds to, and thus that any previous 461 source is no longer being mapped to that switched capture. 463 For a Switched Mixer, this applies naturally. For a Selective 464 Forwarding middlebox, this is done based on the mid. 466 Media-7: It must be possible for a receiver to identify the original 467 source that is currently being mapped to a switched capture, and 468 correlate it with out-of-band (non-Clue) information such as rosters. 470 For a Switched Mixer, this is done based on the CSRC, if the mixer is 471 providing CSRCs; For a Selective Forwarding middlebox, this is done 472 based on the SSRC. 474 For MCC which can represent multiple switched MCs there is a need to 475 know which MC represents the current RTP stream, requires a mapping 476 from an RTP stream to an MC. In order to address this mapping this 477 document defines an RTP header extension that includes the CaptureID 478 in order to map to the original MC allowing the consumer to use the 479 MC attributes like the spatial information. 481 Media-8: It must be possible for a source to move among switched 482 captures without requiring a refresh of decoder state (e.g., for 483 video, a fresh I-frame), when this is unnecessary. However, it must 484 also be possible for a receiver to indicate when a refresh of decoder 485 state is in fact necessary. 487 This can be done by a Selective Forwarding middlebox, but not by a 488 Switching Mixer. The last requirement can be accomplished through an 489 FIR message [RFC5104], though potentially a faster mechanism (not 490 requiring a round-trip time from the receiver) would be preferable. 492 Media-9: If a given source is being sent on the same transport flow 493 to satisfy more than one capture (e.g. if it corresponds to more than 494 one switched capture at once, or to a static capture as well as a 495 switched capture), it should be possible for a sender to send only 496 one copy of the source. 498 For a Selective Forwarding middlebox, this may be a problem since an 499 encoding can be used by a single MC, it will require using the same 500 SDP label for multiple MC (example middle camera and active speaker 501 MC) this can also be done for an environment with a hybrid of mixer 502 topologies and static and dynamic captures. It is not possible for 503 static captures from a Switched Mixer. 505 Media-12: If multiple sources from a single synchronization context 506 are being sent simultaneously, it must be possible for a receiver to 507 associate and synchronize them properly, even for sources that are 508 mapped to switched captures. 510 For a Mixed or Switched Mixer topology, receivers will see only a 511 single synchronization context (CNAME), corresponding to the mixer. 512 For a Selective Forwarding middlebox, separate projecting sources 513 keep separate synchronization contexts based on their original 514 CNAMEs, thus allowing independent synchronization of sources from 515 independent rooms without needing global synchronization. In hybrid 516 cases, however (e.g. if audio is mixed), all sources which need to be 517 synchronized with the mixed audio must get the same CNAME (and thus a 518 mixer-provided timebase) as the mixed audio. 520 6. CaptureID definition 522 For mapping an RTP stream to a specific MC in the MCC the CLUE 523 captureId is used. The media sender MUST send for MCC the captureID 524 in the RTP header and as a RTCP SDES message. 526 6.1. RTCP CaptureId SDES Item 528 This document specifies a new RTCP SDES message 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | CaptureId = XXX | length |CaptureId 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | .... 537 This CaptureID is the same as in the CLUE MC and is also used in the 538 RTP header extension. 540 This SDES message MAY be sent in a compound RTCP packet based on the 541 application need. 543 6.2. RTP Header Extension 545 The CaptureId is carried within the RTP header extension field, using 546 [RFC5285] two bytes header extension. 548 Support is negotiated within the SDP, i.e. 550 a=extmap:1 urn:ietf:params:rtp-hdrext:CaptureId 552 Packets tagged by the sender with the CapturId then contain a header 553 extension as shown below 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | ID | Len-1 | CaptureId 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | CaptureId .. | 561 +-+-+-+-+-+-+-+-+ 563 There is no need to send the CaptureId header extension with all RTP 564 packets. Senders MAY choose to send it only when a new MC is sent. 565 If such a mode is being used, the header extension SHOULD be sent in 566 the first few RTP packets to reduce the risk of losing it due to 567 packet loss. 569 7. Examples 571 TBD 573 8. Acknowledgements 575 The authors would like to thanks Allyn Romanow and Paul Witty for 576 contributing text to this work. 578 9. IANA Considerations 580 This document defines a new extension URI in the RTP Compact Header 581 Extensions subregistry of the Real-Time Transport Protocol (RTP) 582 Parameters registry, according to the following data: 584 Extension URI: urn:ietf:params:rtp-hdrext:CaptureId 586 Description: CLUE CaptureId 588 Contact: roni.even@mail01.huawei.com 590 Reference: RFC XXXX 592 The IANA is requested to register one new RTCP SDES items in the 593 "RTCP SDES Item Types" registry, as follows: 595 Value Abbrev Name Reference 596 TBA CCID CLUE CaptureId [RFCXXXX] 598 10. Security Considerations 600 TBD. 602 11. References 604 11.1. Normative References 606 [I-D.ietf-clue-framework] 607 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 608 for Telepresence Multi-Streams", draft-ietf-clue- 609 framework-17 (work in progress), September 2014. 611 [I-D.ietf-mmusic-sdp-bundle-negotiation] 612 Holmberg, C., Alvestrand, H., and C. Jennings, 613 "Negotiating Media Multiplexing Using the Session 614 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 615 negotiation-12 (work in progress), October 2014. 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 11.2. Informative References 622 [I-D.ietf-avtcore-rtp-topologies-update] 623 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 624 ietf-avtcore-rtp-topologies-update-04 (work in progress), 625 August 2014. 627 [I-D.ietf-clue-signaling] 628 Kyzivat, P., Xiao, L., Groves, C., and R. Hansen, "CLUE 629 Signaling", draft-ietf-clue-signaling-03 (work in 630 progress), August 2014. 632 [I-D.ietf-mmusic-sdp-simulcast] 633 Westerlund, M., Nandakumar, S., and M. Zanaty, "Using 634 Simulcast in SDP and RTP Sessions", draft-ietf-mmusic-sdp- 635 simulcast-00 (work in progress), January 2015. 637 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 638 with Session Description Protocol (SDP)", RFC 3264, June 639 2002. 641 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 642 Jacobson, "RTP: A Transport Protocol for Real-Time 643 Applications", STD 64, RFC 3550, July 2003. 645 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 646 Description Protocol", RFC 4566, July 2006. 648 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 649 Initiation Protocol (SIP) Event Package for Conference 650 State", RFC 4575, August 2006. 652 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 653 Protocol (SDP) Content Attribute", RFC 4796, February 654 2007. 656 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 657 "Codec Control Messages in the RTP Audio-Visual Profile 658 with Feedback (AVPF)", RFC 5104, February 2008. 660 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 661 January 2008. 663 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 664 Header Extensions", RFC 5285, July 2008. 666 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 667 Media Attributes in the Session Description Protocol 668 (SDP)", RFC 5576, June 2009. 670 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 671 Attributes in the Session Description Protocol (SDP)", RFC 672 6236, May 2011. 674 [RFC7205] Romanow, A., Botzko, S., Duckworth, M., and R. Even, "Use 675 Cases for Telepresence Multistreams", RFC 7205, April 676 2014. 678 Authors' Addresses 680 Roni Even 681 Huawei Technologies 682 Tel Aviv 683 Israel 685 Email: roni.even@mail01.huawei.com 687 Jonathan Lennox 688 Vidyo, Inc. 689 433 Hackensack Avenue 690 Seventh Floor 691 Hackensack, NJ 07601 692 US 694 Email: jonathan@vidyo.com