idnits 2.17.1 draft-cazeaux-clue-sip-signaling-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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 27, 2012) is 4410 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cazeaux 3 Internet-Draft E. Bertin 4 Intended status: Informational B. Chatras 5 Expires: September 28, 2012 France Telecom Orange 6 March 27, 2012 8 Requirements for ControLling mUltiple streams for tElepresence (CLUE) 9 signaling. 10 draft-cazeaux-clue-sip-signaling-01 12 Abstract 14 This document defines requirements relating to the design of CLUE 15 signaling. This document also proposes two alternative design 16 approaches to CLUE signaling. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF 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 28, 2012. 35 Copyright Notice 37 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. CLUE signaling options . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Option A: CLUE signaling based on SIP-SDP signaling 57 only . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1.2. Use of SDP fields . . . . . . . . . . . . . . . . . . 6 60 4.1.3. Examples of SDP . . . . . . . . . . . . . . . . . . . 7 61 4.1.4. Transport and format . . . . . . . . . . . . . . . . . 9 62 4.2. Option B1: media capture selection in a separate 63 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2.2. Use of SDP fields . . . . . . . . . . . . . . . . . . 11 66 4.2.3. Examples of SDP . . . . . . . . . . . . . . . . . . . 11 67 4.2.4. Transport and format . . . . . . . . . . . . . . . . . 15 68 4.3. Option B2: media capture selection in a separate 69 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 16 71 4.3.2. Use of SDP fields . . . . . . . . . . . . . . . . . . 17 72 4.3.3. Examples of SDP . . . . . . . . . . . . . . . . . . . 18 73 4.3.4. Transport and format . . . . . . . . . . . . . . . . . 22 74 4.4. Interoperability with legacy endpoints . . . . . . . . . . 22 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 8.1. Normative references . . . . . . . . . . . . . . . . . . . 23 80 8.2. Informative references . . . . . . . . . . . . . . . . . . 24 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 83 1. Introduction 85 The framework defined for Telepresence Multi-Streams 86 [I-D.ietf-clue-framework] in the context of CLUE introduces the need 87 to have CLUE messages, conveying CLUE data, exchanged between 88 telepresence endpoints. It is necessary to agree upon a signaling 89 protocol enabling these CLUE messages to be exchanged, taking into 90 account the existing SIP-SDP ecosystem. 92 This document first outlines signaling requirements to be met by the 93 CLUE protocol. Then the document proposes two approaches for the 94 design of this protocol. 96 2. Terminology 98 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 99 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 100 and "OPTIONAL" are to be interpreted as described in RFC 2119 101 [RFC2119]. 103 3. Requirements 105 The term of "solution" designates here the set of mechanisms that 106 allows endpoints to exchange CLUE-related information. 108 REQ-1 The solution MUST enable the implementation of the CLUE 109 framework described in [I-D.ietf-clue-framework], in 110 particular : CLUE data model, provider/consumer exchange. 112 REQ-2 The solution MUST allow session establishment between two 113 Telepresence endpoints, and between a Telepresence endpoint 114 and a Multipoint Control Unit (MCU). The solution MUST 115 support the establishment of symmetrical or asymmetrical 116 media streams between the Telepresence endpoints (or MCU). 118 REQ-3 The solution MUST enable interoperability with SIP legacy 119 endpoints, without requiring intermediary protocol 120 translation systems. At a minimum, the solution MUST enable 121 interoperability with legacy SIP audio endpoints (one audio 122 media stream) and SIP video endpoints (one audio media 123 stream, zero or one main video media stream, zero or one 124 presentation video media stream, zero or one BFCP stream). 126 REQ-4 The solution MUST enable interoperability with SIP legacy 127 endpoints, with a minimum number of offer-answer cycles. 129 REQ-5 The solution MUST NOT make any assumptions on the SIP 130 implementation level (besides [RFC3261]) of intermediary 131 systems that could be in the signaling path of a Telepresence 132 session (e.g. a Session Border Controller, SBC). 134 REQ-6 The solution MUST enable to discover whether a remote party 135 is CLUE-enabled or not. 137 REQ-7 The solution MUST rely on the SDP offer/answer model for any 138 CLUE data related to the definition of media streams. This 139 requirement in particular aims to enable intermediaries (such 140 as SBCs) to apply appropriate policies (e.g. QoS marking, 141 Bandwidth control ...), which require that SDP offers and 142 answers provide and accurate description of the actual media 143 streams. 145 REQ-8 The solution MUST take into account that a media capture 146 selection could result from the interaction with an end-user, 147 at any time during a session. The user interaction can 148 indeed occur between the provider capability advertisement 149 and the consumer selection, but also at any moment during the 150 established session. 152 REQ-9 The solution MUST NOT add new requirements regarding NAT 153 traversal compared to legacy video systems (NOTE : lesson 154 learned from BFCP over TCP). 156 REQ-10 The solution MUST be extensible in order to support future 157 evolution in a backward compatible manner. 159 Note that no requirement is placed regarding to the latency of the 160 CLUE messages exchanged between the provider and the consumer. 162 4. CLUE signaling options 164 4.1. Option A: CLUE signaling based on SIP-SDP signaling only 166 This option proposes an approach where the exchange of CLUE messages 167 (including all CLUE parameters) between the provider and the consumer 168 is solely based on the SDP O/A model as specified in [RFC3264]. The 169 SDP is used for the exchange of media stream descriptions and media 170 capture descriptions and selection. 172 4.1.1. Overview 174 An example message flow for CLUE session establishment is illustrated 175 below. 177 A B 178 | | 179 {A as provider} {B as consumer} 180 | | 181 |INVITE (SDP-O1:A-adv) | 182 |----------------------------------->| 183 | 200 OK (SDP-A1:B-conf)| 184 |<-----------------------------------| 185 |ACK | 186 |----------------------------------->| 187 | | 188 | | 189 {A as consumer} {B as provider} 190 | | 191 | INVITE (SDP-O2:B-adv+B-conf)| 192 |<-----------------------------------| 193 |200 OK (SDP-A2:A-conf+B-conf) | 194 |----------------------------------->| 195 | ACK| 196 |<-----------------------------------| 198 Figure 1 200 A-adv: A as a Provider advertises available media captures and 201 supported encoding options. 203 B-conf: B as a Consumer selects the media captures it wants to 204 receive from A and configure the encoding options to be applied by A 205 to the media streams 207 B-adv: B as a Provider advertises available media captures and 208 supported encoding options. 210 A-conf: A as a Consumer selects the media captures it wants to 211 receive from B and configure the encoding options to be applied by B 212 to the media streams 214 SDP is used for provider advertisement of available media captures 215 and supported encoding options. SDP is also used for consumer 216 selection of the media captures it wants to receive from the provider 217 and configure the encoding options to be applied by the provider to 218 the media streams. A change in media capture selection requires a 219 new SDP Offer/Answer cycle 221 The first SDP offer/answer cycle enables the CLUE exchange between A 222 as provider and B as consumer. The second SDP offer/answer cycle 223 enables the CLUE exchange between A as consumer and B as provider. 224 This second SDP offer/answer cycle completes the first one, so that 225 it can safely replace it. 227 It is worth noting that this option will not satisfy the following 228 requirements: 230 REQ-8: this option requires a complete SDP offer/answer cycle to 231 change media capture selection, thus requires to re-negotiate 232 (even if not actually required) the media streams. 233 REQ-9: the transmission of a SDP answer conveying a capture 234 selection cannot wait for a user action more than what a SIP 235 transaction timer allows. 237 4.1.2. Use of SDP fields 239 Media descriptions in a Provider announcement include the a=sendonly 240 attribute. Encoding options are represented by the sub-fields 241 of the m= line and associated SDP attributes. 243 Media descriptions associated to selected media captures have the 244 a=recvonly attribute. Media descriptions associated to other media 245 captures are either omitted or included with the a=inactive 246 attribute. Encoding options are selected using regular SDP Offer/ 247 Answer procedures. 249 There are two variants regarding media capture description and 250 selection: 252 1) Media capture of the same media type representing alternative 253 captures of the same CLUE type are represented by an m= line and 254 associated attributes (regular SDP attributes and CLUE-specific 255 attributes). One specific CLUE attribute tentatively called "clue- 256 capture" provides the list of media captures. Media capture 257 selection is performed by the Consumer through updating the value of 258 this specific CLUE attribute. 260 2) A media capture is represented by an m= line and associated 261 attributes (regular SDP attributes and CLUE-specific attributes). 262 Because of the one-to-one mapping between media captures and media 263 streams, the presence of the a=recvonly attribute is sufficient to 264 imply selection of the media capture. 266 4.1.3. Examples of SDP 268 The examples below show a negotiation between a typical 3-camera/ 269 screen/microphone telepresence endpoint (acting as Provider below), 270 and a typical 1-camera/screen/microphone telepresence endpoint 271 (acting as Consumer below), based on the option 1) described in the 272 Section 4.1.2 274 An example of SDP for a Provider announcement illustrated below. 276 a=group:LS 1 6 277 a=group:LS 2 7 278 a=group:LS 3 8 280 m=video 10002 RTP/AVP 96 97 281 a=sendonly 282 a=rtpmap:96 H264 283 a=rtpmap:97 H265 284 a=content: main 285 a=mid:1 286 a=clue-attributes: 287 a=clue-capture{1:camera-left,2:full-scene, 288 3:composed-scene,4:speaker} 290 m=video 10003 RTP/AVP 96 97 291 a=sendonly 292 a=rtpmap:96 H264 293 a=rtpmap:97 H265 294 a=content: main 295 a=mid:2 296 a=clue-attributes: 297 a=clue-capture{1:camera-center,2:full-scene, 298 3:composed-scene,4:speaker} 300 m=video 10004 RTP/AVP 96 97 301 a=sendonly 302 a=rtpmap:96 H264 303 a=rtpmap:97 H265 304 a=content: main 305 a=mid:3 306 a=clue-attributes: 307 a=clue-capture{1:camera-right,2:full-scene, 308 3:composed-scene,4:speaker} 310 m=video 10006 RTP/AVP 96 311 a=sendonly 312 a=rtpmap:96 H264 313 a=content: slides 314 a=mid:5 315 a=clue-attributes 317 m=audio 10000 RTP/AVP 96 318 a=sendonly 319 a=rtpmap:96 PCMU 320 a=mid:6 321 a=clue-attributes: 322 a=clue-capture{1:mic-left,2:speaker} 324 m=audio 10001 RTP/AVP 96 325 a=sendonly 326 a=rtpmap:96 PCMU 327 a=mid:7 328 a=clue-attributes: 329 a=clue-capture{1:mic-center,2:speaker} 331 m=audio 10002 RTP/AVP 96 332 a=sendonly 333 a=rtpmap:96 PCMU 334 a=mid:8 335 a=clue-attributes: 336 a=clue-capture{1:mic-right,2:speaker} 337 An example of SDP for a Consumer configuration is illustrated below. 339 a=group:LS 1 6 341 m=video 10002 RTP/AVP 96 342 a=recvonly 343 a=rtpmap:96 H264 344 a=content: main 345 a=mid:1 346 a=clue-attributes: 347 a=clue-capture{1:full-scene} 349 m=video 10006 RTP/AVP 96 350 a=inactive 351 a=rtpmap:96 H264 352 a=content: slides 353 a=mid:5 354 a=clue-attributes 356 m=audio 10000 RTP/AVP 96 357 a=recvonly 358 a=rtpmap:96 PCMU 359 a=mid:6 360 a=clue-attributes: 361 a=clue-capture{1:speaker} 363 4.1.4. Transport and format 365 In this option, the CLUE protocol is entirely based on the SDP offer/ 366 answer model as described in [RFC3264]. Thus the transport protocol 367 for CLUE messages is SIP, and the format of CLUE messages follows SDP 368 specifications. 370 4.2. Option B1: media capture selection in a separate protocol 372 This option proposes an approach where the exchange of CLUE messages 373 between the provider and the consumer related to media stream is 374 based on the SDP offer/answer model as described in [RFC3264], and 375 the exchange of CLUE messages related to media captures is based on a 376 dedicated channel (futher referred to as the CLUE channel). 378 4.2.1. Overview 380 An example message flow for a CLUE session establishment is 381 illustrated below. 383 A B 384 | | 385 {A as provider} {B as consumer} 386 | | 387 |INVITE (SDP-O1:A-adv) | 388 |----------------------------------->| 389 | 200 OK (SDP-A1:B-conf)| 390 |<-----------------------------------| 391 |ACK | 392 |----------------------------------->| 393 | | 394 | | 395 {A as consumer} {B as provider} 396 | | 397 | INVITE (SDP-O2:B-adv+B-conf)| 398 |<-----------------------------------| 399 |200 OK (SDP-A2:A-conf+B-conf) | 400 |----------------------------------->| 401 | ACK| 402 |<-----------------------------------| 403 | CLUE channel | 404 |<==================================>| 405 | | 407 Figure 4 409 A-adv: A as a Provider advertises available media captures and 410 supported encoding options. 412 B-conf: B as a Consumer configures the encoding options to be applied 413 by A to the media streams 415 B-adv: B as a Provider advertises available media captures and 416 supported encoding options. 418 A-conf: A as a Consumer configures the encoding options to be applied 419 by B to the media streams 421 The model of multiple SDP O/A cycles is the same than in option B. 422 The difference resides in the fact that the SDP B-conf and A-conf 423 don't enable media captures selection, they are just used for 424 encoding configuration . The media capture selection is performed 425 through a dedicated CLUE channel. 427 The CLUE channel enables each consumer to select what media capture 428 will be sent by the remote provider. A media capture selection does 429 not require making a SDP O/A cycle, unless a consumer whishes to 430 change an encoding option. 432 This option should satisfy all requirements. 434 4.2.2. Use of SDP fields 436 As for option A, media descriptions in a Provider announcement 437 include the a=sendonly attribute. Encoding options are represented 438 by the sub-fields of the m= line and associated SDP attributes. 439 Media capture of the same media type representing alternative 440 captures of the same CLUE type are represented by an m= line and 441 associated attributes (regular SDP attributes and CLUE-specific 442 attributes). One specific CLUE attribute provides the list of media 443 captures. 445 This option B1 relies on the media capture identifier provided by the 446 specific CLUE attribute of the m= line and the media id provided by 447 the sub-field of the same m= line to perform the media capture 448 selection by the Consumer through the CLUE channel. 450 Media descriptions associated to selected media streams (selected by 451 a Consumer) have the a=recvonly attribute. Media descriptions 452 associated to other media captures are either omitted or included 453 with the a=inactive attribute. Encoding options are selected using 454 regular SDP Offer/Answer procedures. 456 4.2.3. Examples of SDP 458 The examples below show a negotiation between a typical 3-camera/ 459 screen/microphone telepresence endpoint (acting as Provider below), 460 and a typical 1-camera/screen/microphone telepresence endpoint 461 (acting as Consumer below). 463 An example of SDP for a Provider announcement illustrated below. 465 m=video 10002 RTP/AVP 96 97 466 a=sendonly 467 a=rtpmap:96 H264 468 a=rtpmap:97 H265 469 a=content: main 470 a=mid:1 471 a=clue-attributes: 472 a=clue-capture{1:camera-left,2:full-scene, 473 3:composed-scene,4:speaker} 475 m=video 10003 RTP/AVP 96 97 476 a=sendonly 477 a=rtpmap:96 H264 478 a=rtpmap:97 H265 479 a=content: main 480 a=mid:2 481 a=clue-attributes: 482 a=clue-capture{1:camera-center,2:full-scene, 483 3:composed-scene,4:speaker} 485 m=video 10004 RTP/AVP 96 97 486 a=sendonly 487 a=rtpmap:96 H264 488 a=rtpmap:97 H265 489 a=content: main 490 a=mid:3 491 a=clue-attributes: 492 a=clue-capture{1:camera-right,2:full-scene, 493 3:composed-scene,4:speaker} 495 m=video 10006 RTP/AVP 96 496 a=sendonly 497 a=rtpmap:96 H264 498 a=content: slides 499 a=mid:5 500 a=clue-attributes 502 m=audio 10000 RTP/AVP 96 503 a=sendonly 504 a=rtpmap:96 PCMU 505 a=mid:6 506 a=clue-attributes: 507 a=clue-capture{1:mic-left,2:speaker} 509 m=audio 10001 RTP/AVP 96 510 a=sendonly 511 a=rtpmap:96 PCMU 512 a=mid:7 513 a=clue-attributes: 514 a=clue-capture{1:mic-center,2:speaker} 516 m=audio 10002 RTP/AVP 96 517 a=sendonly 518 a=rtpmap:96 PCMU 519 a=mid:8 520 a=clue-attributes: 521 a=clue-capture{1:mic-right,2:speaker} 523 An example of SDP for a Consumer configuration is illustrated below. 525 m=video 10002 RTP/AVP 96 526 a=recvonly 527 a=rtpmap:96 H264 528 a=content: main 529 a=mid:1 530 a=clue-attributes: 532 m=video 10003 RTP/AVP 96 533 a=recvonly 534 a=rtpmap:96 H264 535 a=content: main 536 a=mid:2 537 a=clue-attributes: 539 m=video 10004 RTP/AVP 96 540 a=recvonly 541 a=rtpmap:96 H264 542 a=content: main 543 a=mid:3 544 a=clue-attributes: 546 m=video 10006 RTP/AVP 96 547 a=inactive 548 a=rtpmap:96 H264 549 a=content: slides 550 a=mid:5 551 a=clue-attributes 553 m=audio 10000 RTP/AVP 96 554 a=recvonly 555 a=rtpmap:96 PCMU 556 a=mid:6 557 a=clue-attributes: 559 m=audio 10001 RTP/AVP 96 560 a=recvonly 561 a=rtpmap:96 PCMU 562 a=mid:7 563 a=clue-attributes: 565 m=audio 10002 RTP/AVP 96 566 a=recvonly 567 a=rtpmap:96 PCMU 568 a=mid:8 569 a=clue-attributes: 571 4.2.4. Transport and format 573 In this option, the solution uses at least two protocol elements. 575 The first protocol element aims at handling the CLUE media streams 576 and the advertisement of the CLUE media captures. For this part, the 577 transport protocol of CLUE messages is SIP, and the format follows 578 SDP specifications. 580 The second protocol element (named hereafter the CLUE channel), aims 581 to handle the CLUE media capture configuration and selection. The 582 CLUE channel most likely relies on a separate protocol. 584 A possible design of the CLUE channel is to rely on the BFCP protocol 585 ([RFC4582]) extended as defined in 586 [I-D.westerlund-dispatch-stream-selection]. 588 4.3. Option B2: media capture selection in a separate protocol 590 This option is a variant of the previous one. With the use of a CLUE 591 channel to enable each consumer to make the media capture selection, 592 it is possible to consider a solution where a single SDP O/A cyle is 593 used for the initial negotiation of the media streams between the 594 parties. It enables to be again closer to regular SDP O/A cycle, 595 where the answerer will make the final choice of the encoding 596 options. This is also the main drawback of this solution, since 597 subsequent SDP O/A cycles will be necessary to enable the initial 598 offerer to make its own configuration of the encoding. However, the 599 usage of a single SDP O/A cycle may be sufficient for simple 600 configuration, for instance where only one encoding option is 601 advertised by a provider. 603 4.3.1. Signaling 605 An example message flow for a CLUE session establishment is 606 illustrated below. 608 A B 609 | | 610 | | 611 |INVITE (SDP-O1:A-adv + A-cap) | 612 |---------------------------------------->| 613 |200 OK (SDP-A1:{B-adv + A-conf} + B-conf)| 614 |<----------------------------------------| 615 |ACK | 616 |---------------------------------------->| 617 | | 618 | CLUE channel | 619 |<=======================================>| 620 | | 622 Figure 7 624 SDP-O1: This SDP provides the capabilities of A acting as a consumer 625 (A-cap, what A can receive) under the form of the number and 626 characteristics of media streams that A is able to receive. This 627 SDP also advertises the capabilities of A acting as a provider 628 (A-adv, what A can send). At this stage: A can receive and can 629 send. 631 SDP-A1: This SDP provides the configuration of A's capabilities, 632 corresponding to what B acting as consumer wants to receive from 633 A (B-conf, what B will receive). This SDP also provides the 634 configuration of B's capabilities acting as provider, on behalf 635 of A (A-conf, what A will receive). The A-conf is completed with 636 information that provide hints to A about B's capabilities as 637 providers (represented as {B-adv + A-conf} in the figure above). 638 More precisely, {B-adv + A-conf} is built as the configuration B 639 according to A's capabilities, and completed (under the form of 640 sdp attributes) with information about B's capabilities as 641 Provider (such as list of media capture B can send, for 642 instance). 643 At this stage : B will receive and send, A will receive and send. 644 After this SDP offer/answer cycle, A and B are able to send and 645 receive media through the media streams that have been 646 negotiated. Additionally, each entity (as consumer) know what 647 media captures can be sent by the remote provider (A-adv and 648 B-adv have been exchanged). However, no media capture selection 649 has been yet performed. 651 CLUE channel: The CLUE channel enables each consumer to perform 652 media content selection according to provider capabilities. The 653 use of this channel may be defined as optional. Indeed, without 654 exchange on CLUE channel, a provider will select a default media 655 capture for each negotiated media stream. 657 Subsequent SDP O/A cycles are not required, but may occur to enable A 658 or B wishes to update their respective capabilities (add or remove a 659 media stream for instance) or change their respective configuration. 660 In the sample below, A initiates a new SDP O/A cycle by sending a SDP 661 offer (SDP-O2) which repeats or updates its capabilities as provider 662 (A-adv) and provides its configuration of B's capabilities (based on 663 the B's provider capabilities advertised in SDP-A1) corresponding to 664 what A wants to receive from B. B responds with with a SDP answer 665 which repeats the configuration sent by A (A-conf) and repeats or 666 updates its configuration of what A will send based (B-conf) on the 667 advertisement provided by A (A-adv) 669 An example message flow to update an established session is 670 illustrated below. 672 A B 673 | ... | 674 | {established session} | 675 | | 676 |re-INVITE (SDP-O2:A-adv + A-conf) | 677 |---------------------------------------->| 678 |200 OK (SDP-A2:{B-adv + A-conf} + A-conf)| 679 |<----------------------------------------| 680 |ACK | 681 |---------------------------------------->| 682 | | 684 Figure 8 686 4.3.2. Use of SDP fields 688 Media descriptions in a Provider announcement include the a=sendonly 689 attribute. Encoding options are represented by the sub-fields 690 of the m= line and associated SDP attributes. Media capture of the 691 same media type representing alternative captures of the same CLUE 692 type are represented by an m= line and associated attributes (regular 693 SDP attributes and CLUE-specific attributes). One specific CLUE 694 attribute provides the list of media captures. The media capture 695 identifier provided by the specific CLUE attribute of the m= line and 696 the media id provided by the sub-field of the same m= line are 697 used to perform the media capture selection by the Consumer through 698 the CLUE channel. 700 Media descriptions in a Consumer capability announcement include the 701 a=recvonly attribute. Encoding options are represented by the 702 sub-fields of the m= line and associated SDP attributes. These media 703 descriptions don't include descriptions of media captures 705 Media descriptions associated to selected media streams (selected by 706 a Consumer) have the a=recvonly attribute. Media descriptions 707 associated to other media captures are either omitted or included 708 with the a=inactive attribute. Encoding options are selected using 709 regular SDP Offer/Answer procedures. 711 4.3.3. Examples of SDP 713 The examples below show a negotiation between a typical 3-camera/ 714 screen/microphone telepresence endpoint (acting as Offerer below), 715 and a typical 1-camera/1-screen/1-microphone telepresence endpoint 716 (acting as Answerer below). The answerer is actually equipped with 717 two cameras (main and secondary cameras), but is able to use only one 718 simultaneously. 720 An example of initial SDP offer including Provider announcement and 721 Consumer capability is illustrated below. 723 ; Provider announcement 725 m=video 10002 RTP/AVP 96 97 726 a=sendonly 727 a=rtpmap:96 H264 728 a=rtpmap:97 H265 729 a=content: main 730 a=mid:1 731 a=clue-attributes 732 a=clue-capture{1:camera-left,2:full-scene, 733 3:composed-scene,4:speaker} 735 m=video 10003 RTP/AVP 96 97 736 a=sendonly 737 a=rtpmap:96 H264 738 a=rtpmap:97 H265 739 a=content: main 740 a=mid:2 741 a=clue-attributes: 742 a=clue-capture{1:camera-center,2:full-scene, 743 3:composed-scene,4:speaker} 745 m=video 10004 RTP/AVP 96 97 746 a=sendonly 747 a=rtpmap:96 H264 748 a=rtpmap:97 H265 749 a=content: main 750 a=mid:3 751 a=clue-attributes: 752 a=clue-capture{1:camera-right,2:full-scene, 753 3:composed-scene,4:speaker} 755 m=video 10006 RTP/AVP 96 756 a=sendonly 757 a=rtpmap:96 H264 758 a=content: slides 759 a=mid:4 760 a=clue-attributes 761 a=clue-capture{1:slides,2:presentation-camera, 762 3:dvd} 764 m=audio 10000 RTP/AVP 96 765 a=sendonly 766 a=rtpmap:96 PCMU 767 a=mid:5 768 a=clue-attributes: 769 a=clue-capture{1:mic-left,2:speaker} 771 m=audio 10001 RTP/AVP 96 772 a=sendonly 773 a=rtpmap:96 PCMU 774 a=mid:6 775 a=clue-attributes: 776 a=clue-capture{1:mic-center,2:speaker} 778 m=audio 10002 RTP/AVP 96 779 a=sendonly 780 a=rtpmap:96 PCMU 781 a=mid:7 782 a=clue-attributes: 783 a=clue-capture{1:mic-right,2:speaker} 785 ; Consumer capability 787 m=video 20002 RTP/AVP 96 97 788 a=recvonly 789 a=rtpmap:96 H264 790 a=rtpmap:97 H265 791 a=content: main 792 a=mid:8 793 a=clue-attributes: 795 m=video 20003 RTP/AVP 96 97 796 a=recvonly 797 a=rtpmap:96 H264 798 a=rtpmap:97 H265 799 a=content: main 800 a=mid:9 801 a=clue-attributes: 803 m=video 20004 RTP/AVP 96 97 804 a=recvonly 805 a=rtpmap:96 H264 806 a=rtpmap:97 H265 807 a=content: main 808 a=mid:10 809 a=clue-attributes: 811 m=video 20006 RTP/AVP 96 812 a=recvonly 813 a=rtpmap:96 H264 814 a=content: slides 815 a=mid:11 816 a=clue-attributes 818 m=audio 20000 RTP/AVP 96 819 a=recvonly 820 a=rtpmap:96 PCMU 821 a=mid:12 822 a=clue-attributes: 824 m=audio 20001 RTP/AVP 96 825 a=recvonly 826 a=rtpmap:96 PCMU 827 a=mid:13 828 a=clue-attributes: 830 m=audio 20002 RTP/AVP 96 831 a=recvonly 832 a=rtpmap:96 PCMU 833 a=mid:14 834 a=clue-attributes: 836 ; CLUE Channel 837 m=application 30000 CLUE 838 a=sendrcv 840 An example of initial SDP answer including Provider announcement and 841 Consumer configuration is illustrated below. 843 ; Consumer configuration 845 m=video 10002 RTP/AVP 96 846 a=recvonly 847 a=rtpmap:96 H264 848 a=content: main 849 a=mid:1 850 a=clue-attributes: 852 m=video 10003 RTP/AVP 96 853 a=recvonly 854 a=rtpmap:96 H264 855 a=content: main 856 a=mid:2 857 a=clue-attributes: 859 m=video 10006 RTP/AVP 96 860 a=recvonly 861 a=rtpmap:96 H264 862 a=content: slides 863 a=mid:4 864 a=clue-attributes 866 m=audio 10000 RTP/AVP 96 867 a=recvonly 868 a=rtpmap:96 PCMU 869 a=mid:6 870 a=clue-attributes: 872 ; Remote consumer configuration and 873 Provider announcement 875 m=video 20002 RTP/AVP 96 876 a=sendonly 877 a=rtpmap:96 H264 878 a=content: main 879 a=mid:8 880 a=clue-attributes: 881 a=clue-capture{1:main-camera,2:secondary-camera} 882 m=video 20006 RTP/AVP 96 883 a=sendonly 884 a=rtpmap:96 H264 885 a=content: slides 886 a=mid:11 887 a=clue-attributes 888 a=clue-capture{1:slides,2:presentation-camera} 890 m=audio 20000 RTP/AVP 96 891 a=sendonly 892 a=rtpmap:96 PCMU 893 a=mid:12 894 a=clue-attributes: 895 a=clue-capture{1:main-mic} 897 ; CLUE Channel 898 m=application 30000 CLUE 899 a=sendrcv 901 4.3.4. Transport and format 903 Same as option B1. 905 4.4. Interoperability with legacy endpoints 907 To enable the interoperability with legacy endpoints, a CLUE-enabled 908 endpoint must be able to discover whether the remote endpoint is 909 CLUE-enabled or not. When the remote endpoint is not CLUE-enabled, 910 the telepresence endpoints must establish a session without using 911 CLUE extensions. 913 Two solutions are possible: 915 Solution 1: OPTIONS procedures are invoked before the first offer/ 916 answer cycle between a consumer and a provider. The OPTIONS 917 procedure enables the provider to retrieve consumer capabilities 918 so as to be able to build an SDP Offer that is meaningful for the 919 consumer. This procedure is particularly useful to enable the 920 provider to determine whether the consumer is CLUE-enabled or 921 not. 923 Solution 2: RFC5939 ([RFC5939]) is used. The SDP Offer sent by the 924 provider includes an "Actual Configuration" and one or more 925 "Potential Configurations". The "Actual Configuration" 926 corresponds to a basic mono-stream video call and can be 927 understood by any endpoint. One of the "Potential 928 Configurations" corresponds to a fully CLUE-compliant endpoint. 929 Other "Potential Configurations" may correspond to partially 930 compliant endpoint (e.g. multistream video without clue-specific 931 data). 933 These solutions are intended to fulfil requirements 3,4 and 6. 935 The options A, B1 and B2 described previously in the document do not 936 include the usage of any of these solutions. But they may rely on 937 any of these solutions to enable the interoperability with legacy 938 endpoints. 940 5. Security Considerations 942 6. IANA Considerations 944 None. 946 7. Acknowledgements 948 8. References 950 8.1. Normative references 952 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 953 Requirement Levels", BCP 14, RFC 2119, March 1997. 955 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 956 A., Peterson, J., Sparks, R., Handley, M., and E. 957 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 958 June 2002. 960 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 961 with Session Description Protocol (SDP)", RFC 3264, 962 June 2002. 964 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 965 Control Protocol (BFCP)", RFC 4582, November 2006. 967 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 968 Capability Negotiation", RFC 5939, September 2010. 970 8.2. Informative references 972 [I-D.ietf-clue-framework] 973 Romanow, A., Pepperell, A., Baldino, B., and M. Duckworth, 974 "Framework for Telepresence Multi-Streams", 975 draft-ietf-clue-framework-03 (work in progress), 976 February 2012. 978 [I-D.westerlund-dispatch-stream-selection] 979 Grondal, D., Burman, B., and M. Westerlund, "Media Stream 980 Selection (MESS)", 981 draft-westerlund-dispatch-stream-selection-00 (work in 982 progress), October 2011. 984 Authors' Addresses 986 Stephane Cazeaux 987 France Telecom Orange 988 42 rue des Coutures 989 Caen 14000 990 France 992 Email: stephane.cazeaux@orange.com 994 Emmanuel Bertin 995 France Telecom Orange 996 42 rue des Coutures 997 Caen 14000 998 France 1000 Email: emmanuel.bertin@orange.com 1002 Bruno Chatras 1003 France Telecom Orange 1004 38 rue du General Leclerc 1005 Issy-Les-Moulineaux 92794 1006 France 1008 Email: bruno.chatras@orange.com