idnits 2.17.1 draft-ietf-clue-signaling-15.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 (December 9, 2019) is 1600 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) ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel') ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-protocol (ref. 'I-D.ietf-clue-protocol') -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hanton 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track P. Kyzivat 5 Expires: June 11, 2020 6 L. Xiao 7 Huawei 8 C. Groves 9 December 9, 2019 11 Session Signaling for Controlling Multiple Streams for Telepresence 12 (CLUE) 13 draft-ietf-clue-signaling-15 15 Abstract 17 This document specifies how CLUE-specific signaling such as the CLUE 18 protocol and the CLUE data channel are used in conjunction with each 19 other and with existing signaling mechanisms such as SIP and SDP to 20 produce a telepresence call. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 11, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Media Feature Tag Definition . . . . . . . . . . . . . . . . 4 59 4. SDP Grouping Framework CLUE Extension Semantics . . . . . . . 4 60 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. The CLUE data channel and the CLUE grouping semantic . . 5 62 4.3. CLUE-controlled media and the CLUE grouping semantic . . 5 63 4.4. SDP semantics for CLUE-controlled media . . . . . . . . . 5 64 4.4.1. Signaling CLUE Encodings . . . . . . . . . . . . . . 6 65 4.4.1.1. Referencing Encodings in the CLUE protocol . . . 6 66 4.4.2. Negotiating receipt of CLUE Capture Encodings in SDP 7 67 4.5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 7 68 4.5.1. Generating the Initial Offer . . . . . . . . . . . . 7 69 4.5.2. Generating the Answer . . . . . . . . . . . . . . . . 8 70 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 8 71 4.5.2.2. Negotiating CLUE-controlled media . . . . . . . . 8 72 4.5.2.3. Negotiating non-CLUE controlled media . . . . . . 9 73 4.5.3. Processing the initial Offer/Answer negotiation . . . 9 74 4.5.3.1. Successful CLUE negotiation . . . . . . . . . . . 9 75 4.5.3.2. CLUE negotiation failure . . . . . . . . . . . . 10 76 4.5.4. Modifying the session . . . . . . . . . . . . . . . . 10 77 4.5.4.1. Adding and removing CLUE-controlled media . . . . 10 78 4.5.4.2. Enabling CLUE mid-call . . . . . . . . . . . . . 10 79 4.5.4.3. Disabling CLUE mid-call . . . . . . . . . . . . . 10 80 4.5.4.4. CLUE protocol failure mid-call . . . . . . . . . 11 81 5. Interaction of CLUE protocol and SDP negotiations . . . . . . 11 82 5.1. Independence of SDP and CLUE negotiation . . . . . . . . 12 83 5.2. Constraints on sending media . . . . . . . . . . . . . . 13 84 5.3. Recommendations for operating with non-atomic operations 13 85 6. Interaction of CLUE protocol and RTP/RTCP CaptureID . . . . . 14 86 6.1. CaptureID reception during MCC redefinition . . . . . . . 14 87 7. Multiplexing of CLUE-controlled media using BUNDLE . . . . . 15 88 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 89 7.2. Usage of BUNDLE with CLUE . . . . . . . . . . . . . . . . 15 90 7.2.1. Generating the Initial Offer . . . . . . . . . . . . 16 91 7.2.2. Multiplexing of the data channel and RTP media . . . 16 92 8. Example: A call between two CLUE-capable Endpoints . . . . . 16 93 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 26 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 11.1. New SDP Grouping Framework Attribute . . . . . . . . . . 27 97 11.2. New SIP Media Feature Tag . . . . . . . . . . . . . . . 28 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 99 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 29 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 39 102 14.2. Informative References . . . . . . . . . . . . . . . . . 41 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 105 1. Introduction 107 To enable devices to participate in a telepresence call, selecting 108 the sources they wish to view, receiving those media sources and 109 displaying them in an optimal fashion, CLUE (ControLling mUltiple 110 streams for tElepresence) employs two principal and inter-related 111 protocol negotiations. SDP [RFC4566], conveyed via SIP [RFC3261], is 112 used to negotiate the specific media capabilities that can be 113 delivered to specific addresses on a device. Meanwhile, CLUE 114 protocol [I-D.ietf-clue-protocol] messages, transported via a CLUE 115 data channel [I-D.ietf-clue-datachannel], are used to negotiate the 116 Capture Sources available, their attributes and any constraints in 117 their use. They also allow the far end device to specify which 118 Captures they wish to receive. It is recommended that those 119 documents be read prior to this one as this document assumes 120 familiarity with those protocols and hence uses terminology from each 121 with limited introduction. 123 Beyond negotiating the CLUE channel, SDP is also used to negotiate 124 the details of supported media streams and the maximum capability of 125 each of those streams. As the CLUE Framework 126 [I-D.ietf-clue-framework] defines a manner in which the Media 127 Provider expresses their maximum encoding group capabilities, SDP is 128 also used to express the encoding limits for each potential Encoding. 130 Backwards-compatibility is an important consideration of the 131 protocol: it is vital that a CLUE-capable device contacting a device 132 that does not support CLUE is able to fall back to a fully functional 133 non-CLUE call. The document also defines how a non-CLUE call may be 134 upgraded to CLUE in mid-call, and similarly how CLUE functionality 135 can be removed mid-call to return to a standard non-CLUE call. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 This document uses terminology defined in the CLUE Framework 146 [I-D.ietf-clue-framework]. 148 A few additional terms specific to this document are defined as 149 follows: 151 non-CLUE device: A device that supports standard SIP and SDP, but 152 either does not support CLUE, or that does but does not currently 153 wish to invoke CLUE capabilities. 155 CLUE-controlled media: A media "m=" line that is under CLUE control; 156 the Capture Source that provides the media on this "m=" line is 157 negotiated in CLUE. See Section 4 for details of how this control 158 is signaled in SDP. There is a corresponding "non-CLUE- 159 controlled" media term. 161 3. Media Feature Tag Definition 163 The "sip.clue" media feature tag [RFC3840] indicates support for CLUE 164 in SIP [RFC3261] calls. A CLUE-capable device SHOULD include this 165 media feature tag in its REGISTER requests and OPTION responses. It 166 SHOULD also include the media feature tag in INVITE and UPDATE 167 [RFC3311] requests and responses. 169 Presence of the media feature tag in the contact field of a request 170 or response can be used to determine that the far end supports CLUE. 172 4. SDP Grouping Framework CLUE Extension Semantics 174 4.1. General 176 This section defines a new SDP Grouping Framework [RFC5888] extension 177 called 'CLUE'. 179 The CLUE extension can be indicated using an SDP session-level 180 'group' attribute. Each SDP media "m=" line that is included in this 181 group, using SDP media-level mid attributes, is CLUE-controlled, by a 182 CLUE data channel also included in this CLUE group. 184 Currently only support for a single CLUE group is specified; support 185 for multiple CLUE groups in a single session is outside the scope of 186 this document. A device MUST NOT include more than one CLUE group in 187 its SDP message unless it is following a specification that defines 188 how multiple CLUE channels are signaled, and is either able to 189 determine that the other side of the SDP exchange supports multiple 190 CLUE channels, or is able to fail gracefully in the event it does 191 not. 193 4.2. The CLUE data channel and the CLUE grouping semantic 195 The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional 196 data channel [I-D.ietf-rtcweb-data-channel] used for the transport of 197 CLUE messages, conveyed within an SCTP over DTLS connection. This 198 channel must be established before CLUE protocol messages can be 199 exchanged and CLUE-controlled media can be sent. 201 The data channel is negotiated over SDP as described in 202 [I-D.ietf-mmusic-data-channel-sdpneg]. A CLUE-capable device wishing 203 to negotiate CLUE MUST also include a CLUE group in their SDP offer 204 or answer and include the "mid" of the "m=" line for the data channel 205 in that group. The CLUE group MUST include the "mid" of the "m=" 206 line for one (and only one) data channel. 208 Presence of the data channel in the CLUE group in an SDP offer or 209 answer also serves, along with the "sip.clue" media feature tag, as 210 an indication that the device supports CLUE and wishes to upgrade the 211 call to include CLUE-controlled media. A CLUE-capable device SHOULD 212 include a data channel "m=" line in offers and, when allowed by 213 [RFC3264], answers. 215 4.3. CLUE-controlled media and the CLUE grouping semantic 217 CLUE-controlled media lines in an SDP are "m=" lines in which the 218 content of the media streams to be sent is negotiated via the CLUE 219 protocol [I-D.ietf-clue-protocol]. For an "m=" line to be CLUE- 220 controlled, its "mid" value MUST be included in the CLUE group. 221 CLUE-controlled media is controlled by the CLUE protocol as 222 negotiated on the CLUE data channel with an "mid" included in the 223 CLUE group. 225 "m=" lines not specified as under CLUE control follow normal rules 226 for media streams negotiated in SDP as defined in documents such as 227 [RFC3264]. 229 The restrictions on CLUE-controlled media that are defined below 230 always apply to "m=" lines in an SDP offer or answer, even if 231 negotiation of the data channel in SDP failed due to lack of CLUE 232 support by the remote device or for any other reason, or in an offer 233 if the recipient does not include the "mid" of the corresponding "m=" 234 line in their CLUE group. 236 4.4. SDP semantics for CLUE-controlled media 237 4.4.1. Signaling CLUE Encodings 239 The CLUE Framework [I-D.ietf-clue-framework] defines the concept of 240 "Encodings", which represent the sender's encode ability. Each 241 Encoding the Media Provider wishes to signal is signaled via an "m=" 242 line of the appropriate media type, which MUST be marked as sendonly 243 with the "a=sendonly" attribute or as inactive with the "a=inactive" 244 attribute. 246 The encoder limits of active (eg, "a=sendonly") Encodings can then be 247 expressed using existing SDP syntax. For instance, for H.264 see 248 Table 6 in [RFC6184] for a list of valid parameters for representing 249 encoder sender stream limits. 251 These Encodings are CLUE-controlled and hence MUST include an "mid" 252 in the CLUE group as defined above. 254 As well as the normal restrictions defined in [RFC3264] the stream 255 MUST be treated as if the "m=" line direction attribute had been set 256 to "a=inactive" until the Media Provider has received a valid CLUE 257 'configure' message specifying the Capture to be used for this 258 stream. This means that RTP packets MUST NOT be sent until 259 configuration is complete, while non-media packets such as STUN, RTCP 260 and DTLS MUST be sent as per their relevant specifications if 261 negotiated. 263 Every "m=" line representing a CLUE Encoding MUST contain a "label" 264 attribute as defined in [RFC4574]. This label is used to identify 265 the Encoding by the sender in CLUE 'advertisement' messages and by 266 the receiver in CLUE 'configure' messages. Each label used for a 267 CLUE-controlled "m=" line MUST be different from the label on all 268 other "m=" lines in the CLUE group, unless an "m=" line represents a 269 dependent stream related to another "m=" line (such as an FEC 270 stream), in which case it MUST have the same label value as the "m=" 271 line on which it depends. 273 4.4.1.1. Referencing Encodings in the CLUE protocol 275 CLUE Encodings are defined in SDP, but can be referenced from CLUE 276 protocol messages - this is how the protocol defines which Encodings 277 are part of an Encoding Group (in 'advertisement' messages) and which 278 Encoding with which to encode a specific Capture (in 'configure' 279 messages). The labels on the CLUE-controlled "m=" lines are the 280 references that are used in the CLUE protocol. 282 Each (in encodingIDList) in a CLUE 'advertisement' message 283 SHOULD represent an Encoding defined in SDP; the specific Encoding 284 referenced is a CLUE-controlled "m=" line in the most recent SDP 285 Offer/Answer message sent by the sender of the 'advertisement' 286 message with a label value corresponding to the text content of the 287 . If the is not defined in SDP it MUST be one it 288 anticipates sending in a subsequent SDP Offer/Answer exchange. 290 Each (in captureEncodingType) in a CLUE 'configure' 291 message MUST represent an Encoding defined in SDP; the specific 292 Encoding referenced is a CLUE-controlled "m=" line in the most recent 293 SDP Offer/Answer message received by the sender of the 'configure' 294 message with a label value corresponding to the text content of the 295 . 297 Note that the non-atomic nature of SDP/CLUE protocol interaction may 298 mean that there are temporary periods where an / 299 in a CLUE message does not reference an SDP "m=" line, or where an 300 Encoding represented in SDP is not referenced in a CLUE protocol 301 message. See Section 5 for specifics. 303 4.4.2. Negotiating receipt of CLUE Capture Encodings in SDP 305 A receiver who wishes to receive a CLUE stream via a specific 306 Encoding requires an "a=recvonly" "m=" line that matches the 307 "a=sendonly" Encoding. 309 These "m=" lines are CLUE-controlled and hence MUST include their 310 "mid" in the CLUE group. They MAY include a "label" attribute, but 311 this is not required by CLUE, as only label values associated with 312 "a=sendonly" Encodings are referenced by CLUE protocol messages. 314 4.5. SDP Offer/Answer Procedures 316 4.5.1. Generating the Initial Offer 318 A CLUE-capable device sending an initial SDP offer of a SIP session 319 and wishing to negotiate CLUE will include an "m=" line for the data 320 channel to convey the CLUE protocol, along with a CLUE group 321 containing the "mid" of the data channel "m=" line. 323 For interoperability with non-CLUE devices a CLUE-capable device 324 sending an initial SDP offer SHOULD NOT include any "m=" line for 325 CLUE-controlled media beyond the "m=" line for the CLUE data channel, 326 and SHOULD include at least one non-CLUE-controlled media "m=" line. 328 If the device has evidence that the receiver is also CLUE-capable, 329 for instance due to receiving an initial INVITE with no SDP but 330 including a "sip.clue" media feature tag, the above recommendation is 331 waived, and the initial offer MAY contain "m=" lines for CLUE- 332 controlled media. 334 With the same interoperability recommendations as for Encodings, the 335 sender of the initial SDP offer MAY also include "a=recvonly" media 336 lines to preallocate "m=" lines to receive media. Alternatively, it 337 MAY wait until CLUE protocol negotiation has completed before 338 including these lines in a new offer/answer exchange - see Section 5 339 for recommendations. 341 4.5.2. Generating the Answer 343 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 345 If the recipient of an initial offer is CLUE-capable, and the offer 346 contains both an "m=" line for a data channel and a CLUE group 347 containing the "mid" for that "m=" line, they SHOULD negotiate data 348 channel support for an "m=" line, and include the "mid" of that "m=" 349 line in a corresponding CLUE group. 351 A CLUE-capable recipient that receives an "m=" line for a data 352 channel but no corresponding CLUE group containing the "mid" of that 353 "m=" line MAY still include a corresponding data channel "m=" line if 354 there are any other non-CLUE protocols it can convey over that 355 channel, but MUST NOT negotiate use of the CLUE protocol on this 356 channel. 358 4.5.2.2. Negotiating CLUE-controlled media 360 If the initial offer contained "a=recvonly" CLUE-controlled media 361 lines the recipient SHOULD include corresponding "a=sendonly" CLUE- 362 controlled media lines for accepted Encodings, up to the maximum 363 number of Encodings it wishes to advertise. As CLUE-controlled 364 media, the "mid" of these "m=" lines MUST be included in the 365 corresponding CLUE group. The recipient MUST set the direction of 366 the corresponding "m=" lines of any remaining "a=recvonly" CLUE- 367 controlled media lines received in the offer to "a=inactive". 369 If the initial offer contained "a=sendonly" CLUE-controlled media 370 lines the recipient MAY include corresponding "a=recvonly" CLUE- 371 controlled media lines, up to the maximum number of Capture Encodings 372 it wishes to receive. Alternatively, it MAY wait until CLUE protocol 373 negotiation has completed before including these lines in a new 374 offer/answer exchange - see Section 5 for recommendations. The 375 recipient MUST set the direction of the corresponding "m=" lines of 376 any remaining "a=sendonly" CLUE-controlled media lines received in 377 the offer to "a=inactive" 379 4.5.2.3. Negotiating non-CLUE controlled media 381 A CLUE-controlled device implementation MAY prefer to render initial, 382 single-stream audio and/or video for the user as rapidly as possible, 383 transitioning to CLUE-controlled media once that has been negotiated. 384 Alternatively, an implementation MAY wish to suppress initial media, 385 only providing media once the final, CLUE-controlled streams have 386 been negotiated. 388 The receiver of the initial offer, if making the call CLUE-enabled 389 with their SDP answer, can make their preference clear by their 390 action in accepting or rejecting non-CLUE-controlled media lines. 391 Rejecting these "m=" lines will ensure that no non-CLUE-controlled 392 media flows before the CLUE-controlled media is negotiated. In 393 contrast, accepting one or more non-CLUE-controlled "m=" lines in 394 this initial answer will enable initial media to flow. 396 If the answerer chooses to send initial non-CLUE-controlled media in 397 a CLUE-enabled call, Section 4.5.4.1 addresses the need to disable it 398 once CLUE-controlled media is fully negotiated. 400 4.5.3. Processing the initial Offer/Answer negotiation 402 In the event that both offer and answer include a data channel "m=" 403 line with a mid value included in corresponding CLUE groups, CLUE has 404 been successfully negotiated and the call is now CLUE-enabled. If 405 not then the call is not CLUE-enabled. 407 4.5.3.1. Successful CLUE negotiation 409 In the event of successful CLUE-enablement of the call, devices MUST 410 now begin negotiation of the CLUE channel, see 411 [I-D.ietf-clue-datachannel] for negotiation details. If negotiation 412 is successful, sending of CLUE protocol [I-D.ietf-clue-protocol] 413 messages can begin. 415 A CLUE-capable device MAY choose not to send RTP on the non-CLUE- 416 controlled channels during the period in which control of the CLUE- 417 controlled media lines is being negotiated (though RTCP MUST still be 418 sent and received as normal). However, a CLUE-capable device MUST 419 still be prepared to receive media on non-CLUE-controlled media lines 420 that have been successfully negotiated as defined in [RFC3264]. 422 If either side of the call wishes to add additional CLUE-controlled 423 "m=" lines to send or receive CLUE-controlled media they MAY now send 424 a SIP request with a new SDP offer following the normal rules of SDP 425 offer/answer and any negotiated extensions. 427 4.5.3.2. CLUE negotiation failure 429 In the event that the negotiation of CLUE fails and the call is not 430 CLUE-enabled once the initial offer/answer negotiation completes then 431 CLUE is not in use in the call. The CLUE-capable devices MUST either 432 revert to non-CLUE behaviour or terminate the call. 434 4.5.4. Modifying the session 436 4.5.4.1. Adding and removing CLUE-controlled media 438 Subsequent offer/answer exchanges MAY add additional "m=" lines for 439 CLUE-controlled media, or activate or deactivate existing "m=" lines 440 per the standard SDP mechanisms. 442 In most cases at least one additional exchange after the initial 443 offer/answer exchange will be required before both sides have added 444 all the Encodings and ability to receive Encodings that they desire. 445 Devices MAY delay adding "a=recvonly" CLUE-controlled "m=" lines 446 until after CLUE protocol negotiation completes - see Section 5 for 447 recommendations. 449 Once CLUE media has been successfully negotiated devices SHOULD 450 ensure that non-CLUE-controlled media is deactivated by setting their 451 ports to 0 in cases where it corresponds to the media type of CLUE- 452 controlled media that has been successfully negotiated. This 453 deactivation may require an additional SDP exchange, or may be 454 incorporated into one that is part of the CLUE negotiation. 456 4.5.4.2. Enabling CLUE mid-call 458 A CLUE-capable device that receives an initial SDP offer from a non- 459 CLUE device SHOULD include a new data channel "m=" line and 460 corresponding CLUE group in any subsequent offers it sends, to 461 indicate that it is CLUE-capable. 463 If, in an ongoing non-CLUE call, an SDP offer/answer exchange 464 completes with both sides having included a data channel "m=" line in 465 their SDP and with the "mid" for that channel in a corresponding CLUE 466 group then the call is now CLUE-enabled; negotiation of the data 467 channel and subsequently the CLUE protocol begins. 469 4.5.4.3. Disabling CLUE mid-call 471 If, during an ongoing CLUE-enabled call a device wishes to disable 472 CLUE, it can do so by following the procedures for closing a data 473 channel defined in Section 5.2.4 of 474 [I-D.ietf-mmusic-data-channel-sdpneg]: sending a new SDP offer/answer 475 exchange and subsequent SCTP SSN reset for the CLUE channel. It MUST 476 also remove the CLUE group. Without the CLUE group any "m=" lines 477 that were previously CLUE-controlled no longer are; implementations 478 MAY disable them by setting their ports to 0 or MAY continue to use 479 them - in the latter case how they are used is outside the scope of 480 this document. 482 If a device follows the procedure above, or an SDP offer-answer 483 negotiation completes in a fashion in which either the "m=" CLUE data 484 channel line was not successfully negotiated, and/or one side did not 485 include the data channel in the CLUE group then CLUE for this call is 486 disabled. In the event that this occurs, CLUE is no longer enabled. 487 Any active "m=" lines still included in the CLUE group are no longer 488 CLUE-controlled and the implementation MAY either disable them in a 489 subsequent negotiation or continue to use them in some other fashion. 490 If the data channel is still present but not included in the CLUE 491 group semantic CLUE protocol messages MUST no longer be sent. 493 4.5.4.4. CLUE protocol failure mid-call 495 In contrast to the specific disablement of the use of CLUE described 496 above, the CLUE channel may fail unexpectedly. Two circumstances 497 where this can occur are: 499 o The CLUE data channel terminates, either gracefully or 500 ungracefully, without any corresponding SDP renegotiation. 502 o A channel error of the CLUE protocol causes it to return to the 503 IDLE state as defined in Section 6. of [I-D.ietf-clue-protocol]. 505 In this circumstance implementations SHOULD continue to transmit and 506 receive CLUE-controlled media on the basis of the last negotiated 507 CLUE messages, until the CLUE protocol is re-established (in the 508 event of a channel error) or disabled mid-call by an SDP exchange as 509 defined in Section 4.5.4.3. Implementations MAY choose to send such 510 an SDP request to disable CLUE immediately or MAY continue on in a 511 call-preservation mode. 513 5. Interaction of CLUE protocol and SDP negotiations 515 Information about media streams in CLUE is split between two message 516 types: SDP, which defines media addresses and limits, and the CLUE 517 channel, which defines properties of Capture Devices available, scene 518 information and additional constraints. As a result certain 519 operations, such as advertising support for a new transmissible 520 Capture with associated stream, cannot be performed atomically, as 521 they require changes to both SDP and CLUE messaging. 523 This section defines how the negotiation of the two protocols 524 interact, provides some recommendations on dealing with intermediate 525 stages in non-atomic operations, and mandates additional constraints 526 on when CLUE-configured media can be sent. 528 5.1. Independence of SDP and CLUE negotiation 530 To avoid the need to implement interlocking state machines with the 531 potential to reach invalid states if messages were to be lost, or be 532 rewritten en-route by middle boxes, the state machines in SDP and 533 CLUE operate independently. The state of the CLUE channel does not 534 restrict when an implementation may send a new SDP offer or answer, 535 and likewise the implementation's ability to send a new CLUE 536 'advertisement' or 'configure' message is not restricted by the 537 results of or the state of the most recent SDP negotiation (unless 538 the SDP negotiation has removed the CLUE channel). 540 The primary implication of this is that a device may receive an SDP 541 Offer/Answer message with a CLUE Encoding for which it does not yet 542 have Capture information, or receive a CLUE 'configure' message 543 specifying a Capture Encoding for which the far end has not 544 negotiated a media stream in SDP. 546 CLUE messages contain an (in encodingIDList) or 547 (in captureEncodingType), which is used to identify a specific 548 encoding or captureEncoding in SDP; see 549 [I-D.ietf-clue-data-model-schema] for specifics. The non-atomic 550 nature of CLUE negotiation means that a sender may wish to send a new 551 CLUE 'advertisement' message before the corresponding SDP message. 552 As such the sender of the CLUE message MAY include an which 553 does not currently match a CLUE-controlled "m=" line label in SDP; A 554 CLUE-capable implementation MUST NOT reject a CLUE protocol message 555 solely because it contains elements that do not match a label 556 in SDP. 558 The current state of the CLUE participant or Media Provider/Consumer 559 state machines do not affect compliance with any of the normative 560 language of [RFC3264]. That is, they MUST NOT delay an ongoing SDP 561 exchange as part of a SIP server or client transaction; an 562 implementation MUST NOT delay an SDP exchange while waiting for CLUE 563 negotiation to complete or for a 'configure' message to arrive. 565 Similarly, a device in a CLUE-enabled call MUST NOT delay any 566 mandatory state transitions in the CLUE Participant or Media 567 Provider/Consumer state machines due to the presence or absence of an 568 ongoing SDP exchange. 570 A device with the CLUE Participant state machine in the ACTIVE state 571 MAY choose to delay moving from ESTABLISHED to ADV (Media Provider 572 state machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media 573 Consumer state machine) based on the SDP state. See 574 [I-D.ietf-clue-protocol] for CLUE state machine specifics. 575 Similarly, a device MAY choose to delay initiating a new SDP exchange 576 based on the state of their CLUE state machines. 578 5.2. Constraints on sending media 580 While SDP and CLUE message states do not impose constraints on each 581 other, both impose constraints on the sending of media - CLUE- 582 controlled media MUST NOT be sent unless it has been negotiated in 583 both CLUE and SDP: an implementation MUST NOT send a specific CLUE 584 Capture Encoding unless its most recent SDP exchange contains an 585 active media channel for that Encoding AND it has received a CLUE 586 'configure' message specifying a valid Capture for that Encoding. 588 5.3. Recommendations for operating with non-atomic operations 590 CLUE-capable devices MUST be able to handle states in which CLUE 591 messages make reference to EncodingIDs that do not match the most 592 recently received SDP, irrespective of the order in which SDP and 593 CLUE messages are received. While these mismatches will usually be 594 transitory a device MUST be able to cope with such mismatches 595 remaining indefinitely. However, this document makes some 596 recommendations on message ordering for these non-atomic transitions. 598 CLUE-capable devices MUST ensure that any inconsistencies between SDP 599 and CLUE signaling are temporary by sending updated SDP or CLUE 600 messages as soon as the relevant state machines and other constraints 601 permit. 603 Generally, implementations that receive messages for which they have 604 incomplete information will be most efficient if they wait until they 605 have the corresponding information they lack before sending messages 606 to make changes related to that information. For example, an 607 answerer that receives a new SDP offer with three new "a=sendonly" 608 CLUE "m=" lines for which it has received no CLUE 'advertisement' 609 message providing the corresponding capture information would 610 typically inclue corresponding "a=inactive" lines in its answer, and 611 only make a new SDP offer with "a=recvonly" when and if a new 612 'advertisement' message arrives with Captures relevant to those 613 Encodings. 615 Because of the constraints of SDP offer/answer and because new SDP 616 negotiations are generally more 'costly' than sending a new CLUE 617 message, implementations needing to make changes to both channels 618 SHOULD prioritize sending the updated CLUE message over sending the 619 new SDP message. The aim is for the recipient to receive the CLUE 620 changes before the SDP changes, allowing the recipient to send their 621 SDP answers without incomplete information, reducing the number of 622 new SDP offers required. 624 6. Interaction of CLUE protocol and RTP/RTCP CaptureID 626 The CLUE Framework [I-D.ietf-clue-framework] allows for Multiple 627 Content Captures (MCCs): Captures which contain multiple source 628 Captures, whether composited into a single stream or switched based 629 on some metric. 631 The Captures that contribute to these MCCs may or may not be defined 632 in the 'advertisement' message. If they are defined and the MCC is 633 providing them in a switched format the recipient may wish to 634 determine which originating source Capture is currently being 635 provided, so that they can apply geometric corrections based on that 636 Capture's geometry, or take some other action based on the original 637 Capture information. 639 To do this, [I-D.ietf-clue-rtp-mapping] allows for the CaptureID of 640 the originating Capture to be conveyed via RTP or RTCP. A Media 641 Provider sending switched media for an MCC with defined originating 642 sources MUST send the CaptureID in both RTP and RTCP, as described in 643 the mapping document. 645 6.1. CaptureID reception during MCC redefinition 647 Because the RTP/RTCP CaptureID is delivered via a different channel 648 to the 'advertisement' message in which in the contents of the MCC 649 are defined there is an intrinsic race condition in cases in which 650 the contents of an MCC are redefined. 652 When a Media Provider redefines an MCC which involves CaptureIDs, the 653 reception of the relevant CaptureIDs by the recipient will either 654 lead or lag reception and processing of the new 'advertisement' 655 message by the recipient. As such, a Media Consumer MUST NOT be 656 disrupted by any of the following in any CLUE-controlled media stream 657 it is receiving, whether that stream is for a static Capture or for 658 an MCC (as any static Capture may be redefined to an MCC in a later 659 'advertisement' message): 661 o Receiving RTP or RTCP containing a CaptureID when the most 662 recently processed 'advertisement' message means that none are 663 expected. 665 o Receiving RTP or RTCP without CaptureIDs when the most recently 666 processed 'advertisement' message means that media CaptureIDs are 667 expected. 669 o Receiving a CaptureID in RTP or RTCP for a Capture defined in the 670 most recently processed 'advertisement' message, but which the 671 same 'advertisement' message does not include in the MCC. 673 o Receiving a CaptureID in RTP or RTCP for a Capture not defined in 674 the most recently processed 'advertisement' message. 676 7. Multiplexing of CLUE-controlled media using BUNDLE 678 7.1. Overview 680 A CLUE call may involve sending and/or receiving significant numbers 681 of media streams. Conventionally, media streams are sent and 682 received on unique ports. However, each separate port used for this 683 purpose may impose costs that a device wishes to avoid, such as the 684 need to open that port on firewalls and NATs, the need to collect ICE 685 candidates [RFC8445], etc. 687 The BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] extension can be 688 used to negotiate the multiplexing of multiple media lines onto a 689 single 5-tuple for sending and receiving media, allowing devices in 690 calls to another BUNDLE-supporting device to potentially avoid some 691 of the above costs. 693 While CLUE-capable devices MAY support the BUNDLE extension for this 694 purpose supporting the extension is not mandatory for a device to be 695 CLUE-compliant. 697 A CLUE-capable device that supports BUNDLE SHOULD also support rtcp- 698 mux [RFC5761]. However, a CLUE-capable device that supports rtcp-mux 699 may or may not support BUNDLE. 701 7.2. Usage of BUNDLE with CLUE 703 This specification imposes no additional requirements or restrictions 704 on the usage of BUNDLE when used with CLUE. There is no restriction 705 on combining CLUE-controlled media lines and non-CLUE-controlled 706 media lines in the same BUNDLE group or in multiple such groups. 707 However, there are several steps an implementation may wish to take 708 to ameliorate the cost and time requirements of extra SDP offer/ 709 answer exchanges between CLUE and BUNDLE. 711 7.2.1. Generating the Initial Offer 713 BUNDLE mandates that the initial SDP offer MUST use a unique address 714 for each "m=" line with a non-zero port. Because CLUE 715 implementations generally will not include CLUE-controlled media 716 lines with the exception of the data channel in the initial SDP 717 offer, CLUE devices that support large numbers of streams can avoid 718 ever having to open large numbers of ports if they successfully 719 negotiate BUNDLE. 721 An implementation that does include CLUE-controlled media lines in 722 its initial SDP offer while also using BUNDLE must take care to avoid 723 renderings its CLUE-controlled media lines unusable in the event the 724 far end does not negotiate BUNDLE if it wishes to avoid the risk of 725 additional SDP exchanges to resolve this issue. This is best 726 achieved by not sending any CLUE-controlled media lines in an initial 727 offer with the 'bundle-only' attribute unless it has been established 728 via some other channel that the recipient supports and is able to use 729 BUNDLE. 731 7.2.2. Multiplexing of the data channel and RTP media 733 BUNDLE-supporting CLUE-capable devices MAY include the data channel 734 in the same BUNDLE group as RTP media. In this case the device MUST 735 be able to demultiplex the various transports - see section 9.2 of 736 the BUNDLE draft [I-D.ietf-mmusic-sdp-bundle-negotiation]. If the 737 BUNDLE group includes other protocols than the data channel 738 transported via DTLS the device MUST also be able to differentiate 739 the various protocols. 741 8. Example: A call between two CLUE-capable Endpoints 743 This example illustrates a call between two CLUE-capable Endpoints. 744 Alice, initiating the call, is a system with three cameras and three 745 screens. Bob, receiving the call, is a system with two cameras and 746 two screens. A call-flow diagram is presented, followed by a summary 747 of each message. 749 To manage the size of this section the SDP snippets only illustrate 750 video "m=" lines. SIP ACKs are not always discussed. Note that 751 BUNDLE is not in use. 753 +----------+ +-----------+ 754 | Alice | | Bob | 755 | | | | 756 +----+-----+ +-----+-----+ 757 | | 758 | | 759 | SIP INVITE 1 | 760 |--------------------------------->| 761 | | 762 | | 763 | SIP 200 OK 1 | 764 |<---------------------------------| 765 | | 766 | | 767 | SIP ACK 1 | 768 |--------------------------------->| 769 | | 770 | | 771 | | 772 |<########### MEDIA 1 ############>| 773 | 1 video A->B, 1 video B->A | 774 |<################################>| 775 | | 776 | | 777 | | 778 |<================================>| 779 | CLUE DATA CHANNEL ESTABLISHED | 780 |<================================>| 781 | | 782 | | 783 | CLUE OPTIONS | 784 |<*********************************| 785 | | 786 | | 787 | CLUE OPTIONS RESPONSE | 788 |*********************************>| 789 | | 790 | | 791 | CLUE ADVERTISEMENT 1 | 792 |*********************************>| 793 | | 794 | | 795 | CLUE ADVERTISEMENT 2 | 796 |<*********************************| 797 | | 798 | | 799 | CLUE ACK 1 | 800 |<*********************************| 801 | | 802 | | 803 | CLUE ACK 2 | 804 |*********************************>| 805 | | 806 | | 807 | SIP INVITE 2 (+3 sendonly) | 808 |--------------------------------->| 809 | | 810 | | 811 | CLUE CONFIGURE 1 | 812 |<*********************************| 813 | | 814 | | 815 | SIP 200 OK 2 (+2 recvonly) | 816 |<---------------------------------| 817 | | 818 | | 819 | CLUE CONFIGURE RESPONSE 1 | 820 |*********************************>| 821 | | 822 | | 823 | SIP ACK 2 | 824 |--------------------------------->| 825 | | 826 | | 827 | | 828 |<########### MEDIA 2 ############>| 829 | 2 video A->B, 1 video B->A | 830 |<################################>| 831 | | 832 | | 833 | SIP INVITE 3 (+2 sendonly) | 834 |<---------------------------------| 835 | | 836 | | 837 | CLUE CONFIGURE 2 | 838 |*********************************>| 839 | | 840 | | 841 | SIP 200 OK 3 (+2 recvonly) | 842 |--------------------------------->| 843 | | 844 | | 845 | CLUE CONFIGURE RESPONSE 2 | 846 |<*********************************| 847 | | 848 | | 849 | SIP ACK 3 | 850 |<---------------------------------| 851 | | 852 | | 853 | | 854 |<########### MEDIA 3 ############>| 855 | 2 video A->B, 2 video B->A | 856 |<################################>| 857 | | 858 | | 859 | | 860 v v 862 In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP 863 body the basic audio and video capabilities and the data channel as 864 per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" 865 media feature tag in the INVITE. A snippet of the SDP showing the 866 grouping attribute and the video "m=" line are shown below. Alice 867 has included a "CLUE" group, and included the mid corresponding to a 868 data channel in the group (3). Note that Alice has chosen not to 869 include any CLUE-controlled media in the initial offer - the mid 870 value of the video line is not included in the "CLUE" group. 872 ... 873 a=group:CLUE 3 874 ... 875 m=video 6002 RTP/AVP 96 876 a=rtpmap:96 H264/90000 877 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 878 a=sendrecv 879 a=mid:2 880 ... 881 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 882 a=setup:actpass 883 a=sctp-port: 5000 884 a=dcmap:2 subprotocol="CLUE";ordered=true 885 a=mid:3 887 Bob responds with a similar SDP in SIP 200 OK 1, which also has a 888 "CLUE" group including the mid value of a data channel; due to their 889 similarity no SDP snippet is shown here. Bob wishes to receive 890 initial media, and so includes corresponding non-CLUE-controlled 891 audio and video lines. Bob also includes the "sip.clue" media 892 feature tag in the 200 OK. Alice and Bob are each now able to send a 893 single audio and video stream. This is illustrated as MEDIA 1. 895 With the successful initial SDP Offer/Answer exchange complete Alice 896 and Bob are also free to negotiate the CLUE data channel. This is 897 illustrated as CLUE DATA CHANNEL ESTABLISHED. 899 Once the data channel is established CLUE protocol negotiation 900 begins. In this case Bob was the DTLS client (sending a=active in 901 his SDP answer) and hence is the CLUE Channel Initiator and sends a 902 CLUE OPTIONS message describing his version support. On receiving 903 that message Alice sends her corresponding CLUE OPTIONS RESPONSE. 905 With the OPTIONS phase complete Alice now sends her CLUE 906 'advertisement' message (CLUE ADVERTISEMENT 1). She advertises three 907 static Captures representing her three cameras. She also includes 908 switched Captures suitable for two- and one-screen systems. All of 909 these Captures are in a single Capture Scene, with suitable Capture 910 Scene Views to tell Bob that he should either subscribe to the three 911 static Captures, the two switched Captures or the one switched 912 Capture. Alice has no simultaneity constraints, so includes all six 913 Captures in one simultaneous set. Finally, Alice includes an 914 Encoding Group with three Encoding IDs: "enc1", "enc2" and "enc3". 915 These Encoding IDs aren't currently valid, but will match the next 916 SDP offer she sends. 918 Bob received CLUE ADVERTISEMENT 1 but does not yet send a 'configure' 919 message, because he has not yet received Alice's Encoding 920 information, so as yet he does not know if she will have sufficient 921 resources to send him the two streams he ideally wants at a quality 922 he is happy with. Because Bob is not sending an immediate 923 'configure' message with the "ack" element set he must send an 924 explicit 'ack' message (CLUE ACK 1) to signal receipt of CLUE 925 ADVERTISEMENT 1. 927 Bob also sends his CLUE 'advertisement' message (CLUE ADVERTISEMENT 928 2) - though the diagram shows that this occurs after Alice sends CLUE 929 ADVERTISEMENT 1 Bob sends his 'advertisement' message independently 930 and does not wait for CLUE ADVERTISEMENT 1 to arrive. He advertises 931 two static Captures representing his cameras. He also includes a 932 single composed Capture for single-screen systems, in which he will 933 composite the two camera views into a single video stream. All three 934 Captures are in a single Capture Scene, with suitable Capture Scene 935 Views to tell Alice that she should either subscribe to the two 936 static Captures, or the single composed Capture. Bob also has no 937 simultaneity constraints, so includes all three Captures in one 938 simultaneous set. Bob also includes a single Encoding Group with two 939 Encoding IDs: "foo" and "bar". 941 Similarly, Alice receives CLUE ADVERTISEMENT 2 but does not yet send 942 a 'configure' message, because she has not yet received Bob's 943 Encoding information, sending instead an 'ack' message (CLUE ACK 2). 945 Both sides have now sent their CLUE 'advertisement' messages and an 946 SDP exchange is required to negotiate Encodings. For simplicity, in 947 this case Alice is shown sending an INVITE with a new offer; in many 948 implementations both sides might send an INVITE, which would be 949 resolved by use of the 491 Request Pending resolution mechanism from 950 [RFC3261]. 952 Alice now sends SIP INVITE 2. She maintains the sendrecv audio, 953 video and CLUE "m=" lines, and she adds three new sendonly "m=" lines 954 to represent the three CLUE-controlled Encodings she can send. Each 955 of these "m=" lines has a label corresponding to one of the Encoding 956 IDs from CLUE ADVERTISEMENT 1. Each also has its mid added to the 957 grouping attribute to show they are controlled by the CLUE data 958 channel. A snippet of the SDP showing the grouping attribute, data 959 channel and the video "m=" lines are shown below: 961 ... 962 a=group:CLUE 3 4 5 6 963 ... 964 m=video 6002 RTP/AVP 96 965 a=rtpmap:96 H264/90000 966 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 967 a=sendrecv 968 a=mid:2 969 ... 970 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 971 a=sctp-port: 5000 972 a=dcmap:2 subprotocol="CLUE";ordered=true 973 a=mid:3 974 ... 975 m=video 6004 RTP/AVP 96 976 a=rtpmap:96 H264/90000 977 a=fmtp:96 profile-level-id=42e016 978 a=sendonly 979 a=mid:4 980 a=label:enc1 981 m=video 6006 RTP/AVP 96 982 a=rtpmap:96 H264/90000 983 a=fmtp:96 profile-level-id=42e016 984 a=sendonly 985 a=mid:5 986 a=label:enc2 987 m=video 6008 RTP/AVP 96 988 a=rtpmap:96 H264/90000 989 a=fmtp:96 profile-level-id=42e016 990 a=sendonly 991 a=mid:6 992 a=label:enc3 994 Bob now has all the information he needs to decide which streams to 995 configure, allowing him to send both a CLUE 'configure' message and 996 his SDP answer. As such he now sends CLUE CONFIGURE 1. This 997 requests the pair of switched Captures that represent Alice's scene, 998 and he configures them with encoder ids "enc1" and "enc2". 1000 Bob also sends his SDP answer as part of SIP 200 OK 2. Alongside his 1001 original audio, video and CLUE "m=" lines he includes three 1002 additional "m=" lines corresponding to the three added by Alice; two 1003 active recvonly "m= "lines and an inactive "m=" line for the third. 1004 He adds their mid values to the grouping attribute to show they are 1005 controlled by the CLUE data channel. A snippet of the SDP showing 1006 the grouping attribute and the video "m=" lines are shown below (mid 1007 100 represents the CLUE data channel, not shown): 1009 ... 1010 a=group:CLUE 11 12 13 100 1011 ... 1012 m=video 58722 RTP/AVP 96 1013 a=rtpmap:96 H264/90000 1014 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1015 a=sendrecv 1016 a=mid:10 1017 ... 1018 m=video 58724 RTP/AVP 96 1019 a=rtpmap:96 H264/90000 1020 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1021 a=recvonly 1022 a=mid:11 1023 m=video 58726 RTP/AVP 96 1024 a=rtpmap:96 H264/90000 1025 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1026 a=recvonly 1027 a=mid:12 1028 m=video 58728 RTP/AVP 96 1029 a=rtpmap:96 H264/90000 1030 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1031 a=inactive 1032 a=mid:13 1034 Alice receives Bob's message CLUE CONFIGURE 1 and sends CLUE 1035 CONFIGURE RESPONSE 1 to ack its reception. She does not yet send the 1036 Capture Encodings specified, because at this stage she hasn't 1037 processed Bob's answer SDP and so hasn't negotiated the ability for 1038 Bob to receive these streams. 1040 On receiving SIP 200 OK 2 from Bob Alice sends her SIP ACK (SIP ACK 1041 2). She is now able to send the two streams of video Bob requested - 1042 this is illustrated as MEDIA 2. 1044 The constraints of offer/answer meant that Bob could not include his 1045 encoding information as new "m=" lines in SIP 200 OK 2. As such Bob 1046 now sends SIP INVITE 3 to generate a new offer. Along with all the 1047 streams from SIP 200 OK 2 Bob also includes two new sendonly streams. 1048 Each stream has a label corresponding to the Encoding IDs in his CLUE 1049 ADVERTISEMENT 2 message. He also adds their mid values to the 1050 grouping attribute to show they are controlled by the CLUE data 1051 channel. A snippet of the SDP showing the grouping attribute and the 1052 video "m=" lines are shown below (mid 100 represents the CLUE data 1053 channel, not shown): 1055 ... 1056 a=group:CLUE 11 12 14 15 100 1057 ... 1058 m=video 58722 RTP/AVP 96 1059 a=rtpmap:96 H264/90000 1060 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1061 a=sendrecv 1062 a=mid:10 1063 ... 1064 m=video 58724 RTP/AVP 96 1065 a=rtpmap:96 H264/90000 1066 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1067 a=recvonly 1068 a=mid:11 1069 m=video 58726 RTP/AVP 96 1070 a=rtpmap:96 H264/90000 1071 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1072 a=recvonly 1073 a=mid:12 1074 m=video 0 RTP/AVP 96 1075 a=mid:13 1076 m=video 58728 RTP/AVP 96 1077 a=rtpmap:96 H264/90000 1078 a=fmtp:96 profile-level-id=42e016 1079 a=sendonly 1080 a=label:foo 1081 a=mid:14 1082 m=video 58730 RTP/AVP 96 1083 a=rtpmap:96 H264/90000 1084 a=fmtp:96 profile-level-id=42e016 1085 a=sendonly 1086 a=label:bar 1087 a=mid:15 1089 Having received this, Alice now has all the information she needs to 1090 send her CLUE 'configure' message and her SDP answer. In CLUE 1091 CONFIGURE 2 she requests the two static Captures from Bob, to be sent 1092 on Encodings "foo" and "bar". 1094 Alice also sends SIP 200 OK 3, matching two recvonly "m=" lines to 1095 Bob's new sendonly lines. She includes their mid values in the 1096 grouping attribute to show they are controlled by the CLUE cdata 1097 hannel. Alice also now deactivates the initial non-CLUE-controlled 1098 media, as bidirectional CLUE-controlled media is now available. A 1099 snippet of the SDP showing the grouping attribute and the video "m=" 1100 lines are shown below (mid 3 represents the data channel, not shown): 1102 ... 1103 a=group:CLUE 3 4 5 7 8 1104 ... 1105 m=video 0 RTP/AVP 96 1106 a=mid:2 1107 ... 1108 m=video 6004 RTP/AVP 96 1109 a=rtpmap:96 H264/90000 1110 a=fmtp:96 profile-level-id=42e016 1111 a=sendonly 1112 a=mid:4 1113 a=label:enc1 1114 m=video 6006 RTP/AVP 96 1115 a=rtpmap:96 H264/90000 1116 a=fmtp:96 profile-level-id=42e016 1117 a=sendonly 1118 a=mid:5 1119 a=label:enc2 1120 m=video 0 RTP/AVP 96 1121 a=mid:6 1122 m=video 6010 RTP/AVP 96 1123 a=rtpmap:96 H264/90000 1124 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1125 a=recvonly 1126 a=mid:7 1127 m=video 6012 RTP/AVP 96 1128 a=rtpmap:96 H264/90000 1129 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1130 a=recvonly 1131 a=mid:8 1133 Bob receives Alice's message CLUE CONFIGURE 2 and sends CLUE 1134 CONFIGURE RESPONSE 2 to ack its reception. Bob does not yet send the 1135 Capture Encodings specified, because he hasn't yet received and 1136 processed Alice's SDP answer and negotiated the ability to send these 1137 streams. 1139 Finally, on receiving SIP 200 OK 3 Bob is now able to send the two 1140 streams of video Alice requested - this is illustrated as MEDIA 3. 1142 Both sides of the call are now sending multiple video streams with 1143 their sources defined via CLUE negotiation. As the call progresses 1144 either side can send new 'advertisement' or 'configure' message or 1145 new SDP offer/answers to add, remove or change what they have 1146 available or want to receive. 1148 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 1150 In this brief example Alice is a CLUE-capable Endpoint making a call 1151 to Bob, who is not CLUE-capable (i.e. is not able to use the CLUE 1152 protocol). 1154 +----------+ +-----------+ 1155 | Alice | | Bob | 1156 | | | | 1157 +----+-----+ +-----+-----+ 1158 | | 1159 | | 1160 | SIP INVITE 1 | 1161 |--------------------------------->| 1162 | | 1163 | | 1164 | 200 0K 1 | 1165 |<---------------------------------| 1166 | | 1167 | | 1168 | SIP ACK 1 | 1169 |--------------------------------->| 1170 | | 1171 | | 1172 | | 1173 |<########### MEDIA 1 ############>| 1174 | 1 video A->B, 1 video B->A | 1175 |<################################>| 1176 | | 1177 | | 1178 | | 1179 | | 1180 v v 1182 In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP 1183 body the basic audio and video capabilities and the data channel as 1184 per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" 1185 media feature tag in the INVITE. A snippet of the SDP showing the 1186 grouping attribute and the video "m=" line are shown below. Alice 1187 has included a "CLUE" group, and included the mid corresponding to a 1188 data channel in the group (3). Note that Alice has chosen not to 1189 include any CLUE-controlled media in the initial offer - the mid 1190 value of the video line is not included in the "CLUE" group. 1192 ... 1193 a=group:CLUE 3 1194 ... 1195 m=video 6002 RTP/AVP 96 1196 a=rtpmap:96 H264/90000 1197 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1198 a=sendrecv 1199 a=mid:2 1200 ... 1201 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 1202 a=sctp-port: 5000 1203 a=dcmap:2 subprotocol="CLUE";ordered=true 1204 a=mid:3 1206 Bob is not CLUE-capable, and hence does not recognize the "CLUE" 1207 semantic for grouping attribute, nor does he support the data 1208 channel. IN SIP 200 OK 1 he responds with an answer with audio and 1209 video, but with the data channel zeroed. 1211 From the lack of a CLUE group Alice understands that Bob does not 1212 support CLUE, or does not wish to use it. Both sides are now able to 1213 send a single audio and video stream to each other. Alice at this 1214 point begins to send her fallback video: in this case likely a 1215 switched view from whichever camera shows the current loudest 1216 participant on her side. 1218 10. Acknowledgements 1220 Besides the authors, the team focusing on this draft consists of: 1221 Roni Even, Simon Pietro-Romano, Roberta Presta. 1223 Christian Groves, Jonathan Lennox and Adam Roach have contributed 1224 detailed comments and suggestions. 1226 11. IANA Considerations 1228 11.1. New SDP Grouping Framework Attribute 1230 This document registers the following semantics with IANA in the 1231 "Semantics for the "group" SDP Attribute" subregistry (under the 1232 "Session Description Protocol (SDP) Parameters" registry per 1233 [RFC5888]: 1235 Semantics Token Reference 1236 ------------------------------------- ------ --------- 1237 CLUE-controlled m-line CLUE [this draft] 1239 11.2. New SIP Media Feature Tag 1241 This specification registers a new media feature tag in the SIP 1242 [RFC3261] tree per the procedures defined in [RFC2506] and [RFC3840]. 1244 Media feature tag name: sip.clue 1246 ASN.1 Identifier: [to be assigned] 1248 Summary of the media feature indicated by this tag: This feature tag 1249 indicates that the device supports CLUE-controlled media. 1251 Values appropriate for use with this feature tag: Boolean. 1253 The feature tag is intended primarily for use in the following 1254 applications, protocols, services, or negotiation mechanisms: 1256 This feature tag is most useful in a communications application for 1257 describing the capabilities of a device to use the CLUE control 1258 protocol to negotiate the use of multiple media streams. 1260 Related standards or documents: [this draft] 1262 Security Considerations: Security considerations for this media 1263 feature tag are discussed in Section 12 of [this draft]. 1265 Name(s) & email address(es) of person(s) to contact for further 1266 information: 1268 o Internet Engineering Steering Group: iesg@ietf.org 1270 Intended usage: COMMON 1272 12. Security Considerations 1274 CLUE makes use of a number of protocols and mechanisms, either 1275 defined by CLUE or long-standing. The security considerations 1276 section of the CLUE Framework [I-D.ietf-clue-framework] addresses the 1277 need to secure these mechanisms by following the recommendations of 1278 the individual protocols. 1280 Beyond the need to secure the constituent protocols, the use of CLUE 1281 does impose additional security concerns. One area of increased risk 1282 involves the potential for a malicious party to subvert a CLUE- 1283 capable device to attack a third party by driving large volumes of 1284 media (particularly video) traffic at them by establishing a 1285 connection to the CLUE-capable device and directing the media to the 1286 victim. While this is a risk for all media devices, a CLUE-capable 1287 device may allow the attacker to configure multiple media streams to 1288 be sent, significantly increasing the volume of traffic directed at 1289 the victim. 1291 This attack can be prevented by ensuring that the media recipient 1292 intends to receive the media packets. As such all CLUE-capable 1293 devices MUST support key negotiation and receiver intent assurance 1294 via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines, and MUST 1295 use it or some other mechanism that provides receiver intent 1296 assurance. All CLUE-controlled RTP "m" lines must be secured and 1297 implemented using mechanisms such as SRTP [RFC3711]. CLUE 1298 implementations MAY choose not to require the use of SRTP to secure 1299 legacy (non-CLUE-controlled) media for backwards compatibility with 1300 older SIP clients that are incapable of supporting it. 1302 CLUE also defines a new media feature tag that indicates CLUE 1303 support. This tag may be present even in non-CLUE calls, which 1304 increases the metadata available about the sending device, which can 1305 help an attacker differentiate between multiple devices and help them 1306 identify otherwise anonymised users via the fingerprint of features 1307 their device supports. To prevent this, SIP signaling used to set up 1308 CLUE sessions SHOULD always be encrypted using TLS [RFC5630]. 1310 The CLUE protocol also carries additional information that could be 1311 used to help fingerprint a particular user or to identify the 1312 specific version of software being used. CLUE Framework 1313 [I-D.ietf-clue-protocol] provides details of these issues and how to 1314 mitigate them. 1316 13. Change History 1318 Note to RFC Editor: please remove this section prior to publication 1320 -15: Revision by Rob Hanton 1322 * Clarified that using an 'EncID' defined in SDP in an CLUE 1323 ADVERTISEMENT message is only a SHOULD because of the inherent 1324 race conditions about the ordering of the SDP and CLUE message. 1325 In contrast, changed the use of 'EncID' in a CLUE CONFIGURE 1326 message to a MUST as that is defined by the far end and so 1327 there is no way for the sending of the CONFIGURE to anticipate 1328 it. 1330 * Updated the description of handling the failure of the CLUE 1331 channel to reflect the fact that the protocol state machine now 1332 returns to the IDLE state on failure rather than a specific 1333 termination state, which also means defining an allowance for 1334 the CLUE channel being recovered. 1336 * Updated all instances of advertisment, configure and ack 1337 messages throughout to match the styling of the protocol 1338 document 1340 * Security section updated to make DTLs-SRTP mandatory to use as 1341 well as support unless intent assurance is provided by some 1342 other mechanism per mailing list proposal (to resolve the 1343 concern from a previous IETF session of those wanting to use 1344 CLUE in a closed environment where intent assurance was 1345 provided by other prorietary mechanisms). 1347 * Removed OID value for "sip.clue" media feature tag pending its 1348 actual assignment on registration, leaving a placeholder 1350 * All lower-case uses of 'must', 'should' and 'may' reviewed and 1351 a few made normative 1353 * Fixed various spelling mistakes, clarified grammar, and fixed a 1354 copy/paste error. 1356 * Updated boilerplate to RFC 8174 1358 * Some informative references moved to normative. 1360 -14: Revision by Rob Hanton 1362 * Reference to RFC5245 updated to RFC8445 1364 * Updated my name to reflect surname change (Hansen to Hanton). 1366 * Reviewed recent changes to clue protocol document and concluded 1367 that none affected this document 1369 * Added recommendation that the SDP O/A spec and clue protocol be 1370 read prior to this document 1372 * Several acronyms expanded at the point of initial use 1374 * Some unnecessary normative language replaced with prose 1376 -13: Revision by Rob Hansen 1377 * Added a section on handling failures of the protocol channel or 1378 data channel mid-call - instructions are that media must 1379 continue as if the clue channel were still established and 1380 unchanged until CLUE is disabled by either side via SDP 1381 exchange. 1383 * Example in section on efficient operation with non-atomic 1384 transactions has had all normative language removed and is now 1385 entirely descriptive (normative language retained in the non- 1386 example portion). 1388 * draft-ietf-clue-protocol-14 reviewed for relevant changes, and 1389 use of CLUE ACK and RESPONSE messages made consistent with that 1390 document (ADVERTISEMENT ACKNOWLEDGEMENT and CONFIGURE RESPONSE 1391 respectively). 1393 * Order of authors revised to reflect updates since Jan 2014. 1395 -12: Revision by Rob Hansen 1397 * Title change to expand and elucidate our totally-not-contrived 1398 acronym 1400 * Explicit reference to RFC3840 added when first mentioning media 1401 feature tags 1403 * Have standardised references to Clue protocol messages to 1404 ADVERTISEMENT, CONFIGURE and ACK, in line with section 12.4.1. 1405 of the protocol document (though the protocol document also 1406 uses ADV and CONF). 1408 * 'MUST' in opening paragraph of 4.2 changed from normative 1409 'MUST' to logical 'must' 1411 * Per his request, removed Cristian's company affiliation and 1412 changed his email address 1414 * Clarified that an implementation that chooses not to send media 1415 during the initial negotiation process must still send RTCP as 1416 normal 1418 * Rewrote the section on adding/remove clue m-lines after the 1419 initial exchange to make clear that this is just standard SDP. 1420 For non-clue controlled lines, recommended they are deactivated 1421 by zeroing the port when turning them off after clue is 1422 successfully negotiated. 1424 * Added guidance that an initial offer containing clue-controlled 1425 m-lines MUST NOT set them bundle-only unless they somehow know 1426 the far end actually supports BUNDLE 1428 * Added section saying that CLUE devices that do BUNDLE SHOULD do 1429 rtcp-mux, but that the requirement doesn't exist in the other 1430 direction (eg, supporting rtcp-mux does not require or imply 1431 the need to implement BUNDLE) 1433 * For clue-controlled m-lines where the sender included more 1434 encodings than the recipient wants, have standardised on using 1435 "a=inactive" to not receive RTP on them (previously had a mix 1436 of "a=inactive" or port 0, or in some cases did not specify). 1438 * Page break added before the big ladder diagram in the example 1440 * Have added a direction attribute to the SDP example in the data 1441 channel, and made explicit that Bob is the DTLS client and 1442 hence the CLUE Channel Initiator. 1444 * Have removed all language that referenced the possibility of 1445 having multiple CLUE groups 1447 * Removed names appearing in the authors list from the 1448 acknowledgements 1450 * Changed the contact for the IANA registration to iesg@ietf.org 1452 * Security section updated to clarify that DTLS-SRTP must be 1453 supported (as opposed to DTLS) and removed the reference to 1454 RFC7202. 1456 * Other syntactic tweaks based on Paul and Adam's feedback 1458 -11: Revision by Rob Hansen 1460 * Some informative references added for SIP and SDP. 1462 * 'a=mid' lines added to example m-lines with port 0, per RFC5888 1463 section 6. 1465 * Instace of 'must' changed to normative 'MUST', along with 1466 various minor clarifications and corrections. 1468 * Abstract made standalone without citations, per RFC7322 section 1469 4.3. 1471 * RFC editor note added to remove this section. 1473 -10: Revision by Rob Hansen 1475 * Changes to draft-ietf-clue-protocol between 07 and 11 reviewed 1476 to ensure compatibility between documents has been maintained. 1478 * Expanded the portion of the document related to fingerprinting 1479 with info on the CLUE channel as well as SIP. 1481 -09: Revision by Rob Hansen 1483 * A few minor spelling tweaks 1485 * Made removing the CLUE group mandatory when disabling CLUE mid- 1486 call. Made clear that any CLUE-controlled m-lines should be 1487 disabled or else how they're used is up to the implementation. 1489 -08: Revision by Rob Hansen 1491 * Spelling and grammar fixes from Paul and Christian gratefully 1492 adopted 1494 * Expanded the section on disabling CLUE mid-call to make 1495 explicit the actions required to disable the CLUE channel 1496 gracefully, or to handle someone else doing the same. 1498 * Made a number of fixes to the example call flow to better 1499 reflect the recommendations in the document. 1501 -07: Revision by Rob Hansen 1503 * Removed the entire 'Media line directionality' section as a 1504 discussion of the pros/cons of using bidirectional vs 1505 unidirectional schemes wasn't suitable for a finalised version. 1506 The unidirectionality requirement is covered normatively in an 1507 earlier section. 1509 * BUNDLE no longer includes an address synchronisation step so 1510 the suggestion to wait until that done has been replaced with 1511 some general language about following any negotiated 1512 extensions. 1514 * Added OPTIONS negotiation to the example flow, and revised the 1515 flow to ensure it matched protocol document. 1517 * Section on not sending CLUE control media until CLUE 1518 negotiation completes narrowed to notify that only RTP should 1519 not be sent until negotiation completes and add RTCP to the 1520 list of things that should be sent as normal, in line with 1521 a=inactive. 1523 * Make explicit that m=recvonly lines don't need to have a label, 1524 as only m=sendonly lines are referenced by CLUE protocol 1525 messages. 1527 * Fix formatting of IANA sections. Improve syntax of feature tag 1528 section in line with Paul's suggestions. Definition of feature 1529 tag narrowed to be multiple media lines *negotiated via CLUE 1530 protocol* rather than more generic 'multiple media lines'. 1532 * General corrections to grammar, spelling and readability based 1533 on Christian, Paul and Mark; in many cases suggested text was 1534 gratefully accepted. 1536 -06: Revision by Rob Hansen 1538 * State machine interactions updated to match versions in -04 of 1539 protocol doc. 1541 * Section on encoding updated to specify both encID and 1542 encodingID from data model doc. 1544 * Removed the limitations on describing H264 encoding limits 1545 using SDP syntax as an open issue. 1547 * Previous draft had SRTP and DTLS mandatory to implement and to 1548 use on CLUE- controlled m lines. Current version has DTLS 1549 mandatory to implement, and 'security' mandatory to use but 1550 does not define what that security is. 1552 * Terminology reference to framework doc reinforced. All 1553 terminology that duplicates framework removed. All text 1554 updated with capitalisation that matches framework document's 1555 terminology. 1557 * SDP example syntax updated to match that of ietf-clue- 1558 datachannel and hence ietf-mmusic-data-channel-sdpneg. 1560 -05: Revision by Rob Hansen 1562 * SRTP/DTLS made mandatory for CLUE-controlled media lines. 1564 * IANA consideration section added (text as proposed by Christian 1565 Groves). 1567 * Includes provision for dependent streams on seperate "m" lines 1568 having the same encID as their parent "m" line. 1570 * References to putting CLUE-controlled media and data channels 1571 in more than one CLUE group removed, since the document no 1572 longer supports using more than one CLUE group. 1574 * Section on CLUE controlled media restrictions still applying 1575 even if the call does not end up being CLUE enabled being 1576 rewritten to hopefully be clearer. 1578 * Other minor syntax improvements. 1580 -04: Revision by Rob Hansen 1582 * Updated DTLS/SCTP channel syntax in examples to fix errors and 1583 match latest format defined in draft-ietf-mmusic-sctp-sdp-07. 1585 * Clarified the behaviour if an SDP offer includes a CLUE- 1586 controlled "m" line and the answer accepts that "m" line but 1587 without CLUE control of that line. 1589 * Added a new section on the sending and receiving of CaptureIDs 1590 in RTP and RTCP. Includes a section on the necessity of the 1591 receiver coping with unexpected CaptureIDs (or the lack 1592 thereof) due to MCCs being redefined in new Advertisement 1593 messages. 1595 * Added reminder on IANA section on registering grouping semantic 1596 and media feature tag, removed the less formal sections that 1597 did the same job. 1599 * Fixed and clarified issues raised by Christian's document 1600 review. 1602 * Added a number of security considerations. 1604 -03: Revision by Rob Hansen 1606 * Clarified text on not rejecting messages because they contain 1607 unknown encIDs. 1609 * Removed normative language in section on accepting/rejecting 1610 non-CLUE-controlled media in the initial answer. 1612 * Example SDP updated to include the data channel "m" lines. 1614 * Example call flow updated to show disablement of non-CLUE- 1615 controlled media once CLUE-controlled media is flowing. 1617 -02: Revision by Rob Hansen 1619 * Added section on not accepting non-CLUE-controlled "m" lines in 1620 the initial answer when CLUE is to be negotiated. 1622 * Removed previous language attempting to describe media 1623 restrictions for CLUE-controlled "m" lines that had not been 1624 configured, and replaced it with much more accurate 'treat as 1625 "a=inactive" was set'. 1627 * Made label element mandatory for CLUE-controlled media (was 1628 previously "SHOULD include", but there didn't seem a good 1629 reason for this - anyone wishing to include the "m" line but 1630 not immediately use it in CLUE can simply leave it out of the 1631 .) 1633 * Added a section on the specifics of relating encodings in SDP 1634 to elements in the CLUE protocol, including the fact 1635 that both Advertisement and Configure messages reference the 1636 *encoding* (eg, in the Configure case the sender of the 1637 Configure message includes the labels of the recipient's "m" 1638 lines as their contents). 1640 * Minor revisions to the section on complying with normative SDP/ 1641 CLUEstate machine language to clarify that these were not new 1642 normative language, merely that existing normative language 1643 still applies. 1645 * Removed appendices which previously contained information to be 1646 transferred to the protocol and data channel drafts. Removed 1647 other text that discussed alternatives to the current approach. 1649 * Cleaned up some 'todo' text. 1651 -01: Revision by Rob Hansen 1653 * Revised terminology - removed the term 'CLUE-enabled' device as 1654 insufficiently distinct from 'CLUE-capable' and instead added a 1655 term for 'CLUE-enabled' calls. 1657 * Removed text forbidding RTCP and instead added text that ICE/ 1658 DTLS negotiation for CLUE controlled media must be done as 1659 normal irrespective of CLUE negotiation. 1661 * Changed 'sip.telepresence' to 'sip.clue' and 'TELEPRESENCE' 1662 grouping semantic back to CLUE. 1664 * Made it mandatory to have exactly one mid corresponding to a 1665 data channel in a CLUE group 1667 * Forbade having multiple CLUE groups unless a specification for 1668 doing so is published. 1670 * Refactored SDP-related text; previously the encoding 1671 information had been in the "initial offer" section despite the 1672 fact that we recommend that the initial offer doesn't actually 1673 include any encodings. I moved the specifications of encodings 1674 and how they're received to an earlier, seperate section. 1676 * Added text on how the state machines in CLUE and SDP are 1677 allowed to affect one another, and further recommendations on 1678 how a device should handle the sending of CLUE and SDP changes. 1680 -00: Revision by Rob Hansen 1682 * Submitted as -00 working group document 1684 draft-kyzivat-08: Revisions by Rob Hansen 1686 * Added media feature tag for CLUE support ('sip.telepresence') 1688 * Changed grouping semantic from 'CLUE' to 'TELEPRESENCE' 1690 * Restructured document to be more centred on the grouping 1691 semantic and its use with O/A 1693 * Lots of additional text on usage of the grouping semantic 1695 * Stricter definition of CLUE-controlled m lines and how they 1696 work 1698 * Some additional text on defining what happens when CLUE 1699 supports is added or removed 1701 * Added details on when to not send RTCP for CLUE-controlled "m" 1702 lines. 1704 * Added a section on using BUNDLE with CLUE 1706 * Updated data channel references to point at new WG document 1707 rather than indivual draft 1709 draft-kyzivat-07: Revisions by Rob Hansen 1711 * Removed the text providing arguments for encoding limits being 1712 in SDP and Encoding Groups in the CLUE protocol in favor of the 1713 specifics of how to negotiate encodings in SDP 1715 * Added normative language on the setting up of a CLUE call, and 1716 added sections on mid-call changes to the CLUE status. 1718 * Added references to [I-D.ietf-clue-datachannel] where 1719 appropriate. 1721 * Added some terminology for various types of CLUE and non-CLUE 1722 states of operation. 1724 * Moved language related to topics that should be in 1725 [I-D.ietf-clue-datachannel] and [I-D.ietf-clue-protocol], but 1726 that has not yet been resolved in those documents, into an 1727 appendix. 1729 draft-kyzivat-06: Revisions by Rob Hansen 1731 * Removed CLUE message XML schema and details that are now in 1732 draft-presta-clue-protocol 1734 * Encoding limits in SDP section updated to note that this has 1735 been investigated and discussed and is the current working 1736 assumption of the WG, though consensus has not been fully 1737 achieved. 1739 * A section has also been added on the current mandation of 1740 unidirectional "m" lines. 1742 * Updated CLUE messaging in example call flow to match draft- 1743 presta-clue-protocol-03 1745 draft-kyzivat-05: Revisions by pkyzivat: 1747 * Specified versioning model and mechanism. 1749 * Added explicit response to all messages. 1751 * Rearranged text to work with the above changes. (Which 1752 rendered diff almost useless.) 1754 draft-kyzivat-04: Revisions by Rob Hansen: ??? 1756 draft-kyzivat-03: Revisions by pkyzivat: 1758 * Added a syntax section with an XML schema for CLUE messages. 1759 This is a strawhorse, and is very incomplete, but it 1760 establishes a template for doing this based on elements defined 1761 in the data model. (Thanks to Roberta for help with this!) 1763 * Did some rewording to fit the syntax section in and reference 1764 it. 1766 * Did some relatively minor restructuring of the document to make 1767 it flow better in a logical way. 1769 draft-kyzivat-02: A bunch of revisions by pkyzivat: 1771 * Moved roberta's call flows to a more appropriate place in the 1772 document. 1774 * New section on versioning. 1776 * New section on NAK. 1778 * A couple of possible alternatives for message acknowledgment. 1780 * Some discussion of when/how to signal changes in provider 1781 state. 1783 * Some discussion about the handling of transport errors. 1785 * Added a change history section. 1787 These were developed by Lennard Xiao, Christian Groves and Paul, 1788 so added Lennard and Christian as authors. 1790 draft-kyzivat-01: Updated by roberta to include some sample call 1791 flows. 1793 draft-kyzivat-00: Initial version by pkyzivat. Established general 1794 outline for the document, and specified a few things thought to 1795 represent wg consensus. 1797 14. References 1799 14.1. Normative References 1801 [I-D.ietf-clue-data-model-schema] 1802 Presta, R. and S. Romano, "An XML Schema for the CLUE data 1803 model", draft-ietf-clue-data-model-schema-17 (work in 1804 progress), August 2016. 1806 [I-D.ietf-clue-datachannel] 1807 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1808 clue-datachannel-18 (work in progress), April 2019. 1810 [I-D.ietf-clue-framework] 1811 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 1812 for Telepresence Multi-Streams", draft-ietf-clue- 1813 framework-25 (work in progress), January 2016. 1815 [I-D.ietf-clue-protocol] 1816 Presta, R. and S. Romano, "Protocol for Controlling 1817 Multiple Streams for Telepresence (CLUE)", draft-ietf- 1818 clue-protocol-19 (work in progress), July 2019. 1820 [I-D.ietf-clue-rtp-mapping] 1821 Even, R. and J. Lennox, "Mapping RTP streams to CLUE Media 1822 Captures", draft-ietf-clue-rtp-mapping-14 (work in 1823 progress), February 2017. 1825 [I-D.ietf-mmusic-data-channel-sdpneg] 1826 Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. 1827 Even, "SDP-based Data Channel Negotiation", draft-ietf- 1828 mmusic-data-channel-sdpneg-28 (work in progress), May 1829 2019. 1831 [I-D.ietf-mmusic-sctp-sdp] 1832 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1833 "Session Description Protocol (SDP) Offer/Answer 1834 Procedures For Stream Control Transmission Protocol (SCTP) 1835 over Datagram Transport Layer Security (DTLS) Transport.", 1836 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1837 2017. 1839 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1840 Holmberg, C., Alvestrand, H., and C. Jennings, 1841 "Negotiating Media Multiplexing Using the Session 1842 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1843 negotiation-54 (work in progress), December 2018. 1845 [I-D.ietf-rtcweb-data-channel] 1846 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1847 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1848 progress), January 2015. 1850 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1851 Requirement Levels", BCP 14, RFC 2119, 1852 DOI 10.17487/RFC2119, March 1997, 1853 . 1855 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1856 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1857 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1858 . 1860 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1861 "Indicating User Agent Capabilities in the Session 1862 Initiation Protocol (SIP)", RFC 3840, 1863 DOI 10.17487/RFC3840, August 2004, 1864 . 1866 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1867 Protocol (SDP) Label Attribute", RFC 4574, 1868 DOI 10.17487/RFC4574, August 2006, 1869 . 1871 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1872 for Establishing a Secure Real-time Transport Protocol 1873 (SRTP) Security Context Using Datagram Transport Layer 1874 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1875 2010, . 1877 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1878 Protocol (SDP) Grouping Framework", RFC 5888, 1879 DOI 10.17487/RFC5888, June 2010, 1880 . 1882 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1883 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1884 May 2017, . 1886 14.2. Informative References 1888 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1889 Registration Procedure", BCP 31, RFC 2506, 1890 DOI 10.17487/RFC2506, March 1999, 1891 . 1893 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1894 A., Peterson, J., Sparks, R., Handley, M., and E. 1895 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1896 DOI 10.17487/RFC3261, June 2002, 1897 . 1899 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1900 with Session Description Protocol (SDP)", RFC 3264, 1901 DOI 10.17487/RFC3264, June 2002, 1902 . 1904 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1905 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1906 2002, . 1908 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1909 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1910 July 2006, . 1912 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1913 Initiation Protocol (SIP)", RFC 5630, 1914 DOI 10.17487/RFC5630, October 2009, 1915 . 1917 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1918 Control Packets on a Single Port", RFC 5761, 1919 DOI 10.17487/RFC5761, April 2010, 1920 . 1922 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1923 Payload Format for H.264 Video", RFC 6184, 1924 DOI 10.17487/RFC6184, May 2011, 1925 . 1927 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1928 Connectivity Establishment (ICE): A Protocol for Network 1929 Address Translator (NAT) Traversal", RFC 8445, 1930 DOI 10.17487/RFC8445, July 2018, 1931 . 1933 Authors' Addresses 1935 Robert Hanton 1936 Cisco Systems 1938 Email: rohanse2@cisco.com 1940 Paul Kyzivat 1942 Email: pkyzivat@alum.mit.edu 1944 Lennard Xiao 1945 Huawei 1947 Email: lennard.xiao@huawei.com 1948 Christian Groves 1950 Email: cngroves.std@gmail.com