idnits 2.17.1 draft-ietf-clue-signaling-07.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-clue-protocol], [I-D.ietf-clue-datachannel]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When a Media Provider redefines an MCC which involves CaptureIDs, the reception of the relevant CaptureIDs by the recipient will either lead or lag reception and processing of the new Advertisement by the recipient. As such, a Media Consumer MUST not be disrupted by any of the following in any CLUE- controlled media stream it is receiving, whether that stream is for a static Capture or for an MCC (as any static Capture may be redefined to an MCC in a later Advertisement): -- The document date (January 21, 2016) is 3016 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-clue-data-model-schema-11 == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-protocol (ref. 'I-D.ietf-clue-protocol') == Outdated reference: A later version (-18) exists of draft-ietf-clue-datachannel-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel') == Outdated reference: A later version (-14) exists of draft-ietf-clue-rtp-mapping-06 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-15 == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-07 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-25 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Kyzivat 3 Internet-Draft 4 Intended status: Standards Track L. Xiao 5 Expires: July 24, 2016 C. Groves 6 Huawei 7 R. Hansen 8 Cisco Systems 9 January 21, 2016 11 CLUE Signaling 12 draft-ietf-clue-signaling-07 14 Abstract 16 This document specifies how CLUE-specific signaling such as the CLUE 17 protocol [I-D.ietf-clue-protocol] and the CLUE data channel 18 [I-D.ietf-clue-datachannel] are used with each other and with 19 existing signaling mechanisms such as SIP and SDP to produce a 20 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 http://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 July 24, 2016. 39 Copyright Notice 41 Copyright (c) 2016 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 (http://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 . . 4 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 . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 7 70 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 7 71 4.5.2.2. Negotiating CLUE-controlled media . . . . . . . . 8 72 4.5.2.3. Negotiating non-CLUE controlled media . . . . . . 8 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 . . . . . . . . . . . . 9 76 4.5.4. Modifying the session . . . . . . . . . . . . . . . . 9 77 4.5.4.1. Adding and removing CLUE-controlled media . . . . 9 78 4.5.4.2. Enabling CLUE mid-call . . . . . . . . . . . . . 10 79 4.5.4.3. Disabling CLUE mid-call . . . . . . . . . . . . . 10 80 5. Interaction of CLUE protocol and SDP negotiations . . . . . . 10 81 5.1. Independence of SDP and CLUE negotiation . . . . . . . . 11 82 5.2. Constraints on sending media . . . . . . . . . . . . . . 12 83 5.3. Recommendations for operating with non-atomic operations 12 84 6. Interaction of CLUE protocol and RTP/RTCP CaptureID . . . . . 13 85 6.1. CaptureID reception during MCC redefinition . . . . . . . 13 86 7. Multiplexing of CLUE-controlled media using BUNDLE . . . . . 14 87 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 88 7.2. Usage of BUNDLE with CLUE . . . . . . . . . . . . . . . . 14 89 7.2.1. Generating the Initial Offer . . . . . . . . . . . . 14 90 7.2.2. Multiplexing of the data channel and RTP media . . . 15 91 8. Example: A call between two CLUE-capable Endpoints . . . . . 15 92 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 24 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 11.1. New SDP Grouping Framework Attribute . . . . . . . . . . 25 96 11.2. New SIP Media Feature Tag . . . . . . . . . . . . . . . 26 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 99 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 27 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 33 102 14.2. Informative References . . . . . . . . . . . . . . . . . 35 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 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 employs two principal and 110 inter-related protocol negotiations. SDP, conveyed via SIP, is used 111 to negotiate the specific media capabilities that can be delivered to 112 specific addresses on a device. Meanwhile, CLUE protocol 113 [I-D.ietf-clue-protocol] messages, transported via a CLUE data 114 channel [I-D.ietf-clue-datachannel], are used to negotiate the 115 Capture Sources available, their attributes and any constraints in 116 their use. They also allow the far end device to specify which 117 Captures they wish to receive. 119 Beyond negotiating the CLUE channel, SDP is also used to negotiate 120 the details of supported media streams and the maximum capability of 121 each of those streams. As the CLUE Framework 122 [I-D.ietf-clue-framework] defines a manner in which the Media 123 Provider expresses their maximum encoding group capabilities, SDP is 124 also used to express the encoding limits for each potential Encoding. 126 Backwards-compatibility is an important consideration of the 127 protocol: it is vital that a CLUE-capable device contacting a device 128 that does not support CLUE is able to fall back to a fully functional 129 non-CLUE call. The document also defines how a non-CLUE call may be 130 upgraded to CLUE in mid-call, and similarly how CLUE functionality 131 can be removed mid-call to return to a standard non-CLUE call. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 This document uses terminology defined in the CLUE Framework 140 [I-D.ietf-clue-framework]. 142 A few additional terms specific to this document are defined as 143 follows: 145 non-CLUE device: A device that supports standard SIP and SDP, but 146 either does not support CLUE, or that does but does not currently 147 wish to invoke CLUE capabilities. 149 CLUE-controlled media: A media "m=" line that is under CLUE control; 150 the Capture Source that provides the media on this "m=" line is 151 negotiated in CLUE. See Section 4 for details of how this control 152 is signaled in SDP. There is a corresponding "non-CLUE- 153 controlled" media term. 155 3. Media Feature Tag Definition 157 The "sip.clue" media feature tag indicates support for CLUE. A CLUE- 158 capable device SHOULD include this media feature tag in its REGISTER 159 requests and OPTION responses. It SHOULD also include the media 160 feature tag in INVITE and UPDATE [RFC3311] requests and responses. 162 Presence of the media feature tag in the contact field of a request 163 or response can be used to determine that the far end supports CLUE. 165 4. SDP Grouping Framework CLUE Extension Semantics 167 4.1. General 169 This section defines a new SDP Grouping Framework [RFC5888] extension 170 called 'CLUE'. 172 The CLUE extension can be indicated using an SDP session-level 173 'group' attribute. Each SDP media "m=" line that is included in this 174 group, using SDP media-level mid attributes, is CLUE-controlled, by a 175 CLUE data channel also included in this CLUE group. 177 Currently only support for a single CLUE group is specified; support 178 for multiple CLUE groups in a single session is beyond the scope of 179 this document. A device MUST NOT include more than one CLUE group in 180 its SDP unless it is following a specification that defines how 181 multiple CLUE channels are signaled, and is either able to determine 182 that the other side of the SDP exchange supports multiple CLUE 183 channels, or is able to fail gracefully in the event it does not. 185 4.2. The CLUE data channel and the CLUE grouping semantic 187 The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional 188 data channel [I-D.ietf-rtcweb-data-channel] used for the transport of 189 CLUE messages, conveyed within an SCTP over DTLS connection. This 190 channel must be established before CLUE protocol messages can be 191 exchanged and CLUE-controlled media can be sent. 193 The data channel is negotiated over SDP as described in 194 [I-D.ietf-mmusic-data-channel-sdpneg]. A CLUE-capable device wishing 195 to negotiate CLUE MUST also include a CLUE group in the SDP and 196 include the "mid" of the "m=" line for the data channel in that 197 group. A CLUE group MUST include the "mid" of the "m=" line for one 198 (and only one) data channel. 200 Presence of the data channel in a CLUE group in an SDP offer or 201 answer also serves, along with the "sip.clue" media feature tag, as 202 an indication that the device supports CLUE and wishes to upgrade the 203 call to include CLUE-controlled media. A CLUE-capable device SHOULD 204 include a data channel "m=" line in offers and, when allowed by 205 [RFC3264], answers. 207 4.3. CLUE-controlled media and the CLUE grouping semantic 209 CLUE-controlled media lines in an SDP are "m=" lines in which the 210 content of the media streams to be sent is negotiated via the CLUE 211 protocol [I-D.ietf-clue-protocol]. For an "m=" line to be CLUE- 212 controlled, its "mid" value MUST be included in a CLUE group. CLUE- 213 controlled media is controlled by the CLUE protocol as negotiated on 214 the CLUE data channel with an "mid" included in the CLUE group. 216 "m=" lines not specified as under CLUE control follow normal rules 217 for media streams negotiated in SDP as defined in documents such as 218 [RFC3264]. 220 The restrictions on CLUE-controlled media always apply to "m=" lines 221 in an SDP offer or answer, even if negotiation of the data channel in 222 SDP failed due to lack of CLUE support by the remote device or for 223 any other reason, or in an offer if the recipient does not include 224 the "mid" of the corresponding "m=" line in their CLUE group. 226 4.4. SDP semantics for CLUE-controlled media 228 4.4.1. Signaling CLUE Encodings 230 The CLUE Framework [I-D.ietf-clue-framework] defines the concept of 231 "Encodings", which represent the sender's encode ability. Each 232 Encoding the Media Provider wishes to signal is signaled via an "m=" 233 line of the appropriate media type, which MUST be marked as sendonly 234 with the "a=sendonly" attribute or as inactive with the "a=inactive" 235 attribute. 237 The encoder limits of active (eg, "a=sendonly") Encodings can then be 238 expressed using existing SDP syntax. For instance, for H.264 see 239 Table 6 in [RFC6184] for a list of valid parameters for representing 240 encoder sender stream limits. 242 These Encodings are CLUE-controlled and hence MUST include an "mid" 243 in a CLUE group as defined above. 245 As well as the normal restrictions defined in [RFC3264] the stream 246 MUST be treated as if the "m=" line direction attribute had been set 247 to "a=inactive" until the Media Provider has received a valid CLUE 248 Configure message specifying the Capture to be used for this stream. 249 This means that RTP packets MUST NOT be sent until configuration is 250 complete, while non-media packets such as STUN, RTCP and DTLS MUST be 251 sent as per their relevant specifications if negotiated. 253 Every "m=" line representing a CLUE Encoding MUST contain a "label" 254 attribute as defined in [RFC4574]. This label is used to identify 255 the Encoding by the sender in CLUE Advertisement messages and by the 256 receiver in CLUE Configure messages. Each label used for a CLUE- 257 controlled "m=" line MUST be different from the label on all other 258 "m=" lines in the same CLUE group in the SDP message, unless an "m=" 259 line represents a dependent stream related to another "m=" line (such 260 as a FEC stream), in which case it MUST have the same label value as 261 the "m=" line on which it depends. 263 4.4.1.1. Referencing Encodings in the CLUE protocol 265 CLUE Encodings are defined in SDP, but can be referenced from CLUE 266 protocol messages - this is how the protocol defines which Encodings 267 are part of an Encoding group (in Advertisement messages) and which 268 Encoding with which to encode a specific Capture (in Configure 269 messages). The labels on the CLUE-controlled "m=" lines are the 270 references that are used in the CLUE protocol. 272 Each (in encodingIDList) in a CLUE Advertisement message 273 SHOULD represent an Encoding defined in SDP; the specific Encoding 274 referenced is a CLUE-controlled "m=" line in the most recent SDP sent 275 by the sender of the Advertisement message with a label value 276 corresponding to the text content of the . 278 Similarly, each (in captureEncodingType) in a CLUE 279 Configure message SHOULD represent an Encoding defined in SDP; the 280 specific Encoding referenced is a CLUE-controlled "m=" line in the 281 most recent SDP received by the sender of the Configure message with 282 a label value corresponding to the text content of the . 284 Note that the non-atomic nature of SDP/CLUE protocol interaction may 285 mean that there are temporary periods where an / 286 in a CLUE message does not reference an SDP "m=" line, or where an 287 Encoding represented in SDP is not referenced in a CLUE protocol 288 message. See Section 5 for specifics. 290 4.4.2. Negotiating receipt of CLUE Capture Encodings in SDP 292 A receiver who wishes to receive a CLUE stream via a specific 293 Encoding requires an "a=recvonly" "m=" line that matches the 294 "a=sendonly" Encoding. 296 These "m=" lines are CLUE-controlled and hence MUST include their 297 "mid" in the CLUE group corresponding to the CLUE group of the 298 Encoding they wish to receive. They MAY include a "label" attribute, 299 but this is not required by CLUE, as only label values associated 300 with "a=sendonly" Encodings are referenced by CLUE protocol messages. 302 4.5. SDP Offer/Answer Procedures 304 4.5.1. Generating the Initial Offer 306 A CLUE-capable device sending an initial SDP offer of a SIP session 307 SHOULD include an "m=" line for the data channel to convey the CLUE 308 protocol, along with a CLUE group containing the "mid" of the data 309 channel "m=" line. 311 For interoperability with non-CLUE devices a CLUE-capable device 312 sending an initial SDP offer SHOULD NOT include any "m=" line for 313 CLUE-controlled media beyond the "m=" line for the CLUE data channel, 314 and SHOULD include at least one non-CLUE-controlled media "m=" line. 316 If the device has evidence that the receiver is also CLUE-capable, 317 for instance due to receiving an initial INVITE with no SDP but 318 including a "sip.clue" media feature tag, the above recommendation is 319 waived, and the initial offer MAY contain "m=" lines for CLUE- 320 controlled media. 322 With the same interoperability recommendations as for Encodings, the 323 sender of the initial SDP offer MAY also include "a=recvonly" media 324 lines to preallocate "m=" lines to receive media. Alternatively, it 325 MAY wait until CLUE protocol negotiation has completed before 326 including these lines in a new offer/answer exchange - see Section 5 327 for recommendations. 329 4.5.2. Generating the Answer 331 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 333 If the recipient is CLUE-capable and the initial offer contains both 334 an "m=" line for a data channel and a CLUE group containing the "mid" 335 for that "m=" line, they SHOULD negotiate data channel support for an 336 "m=" line, and include the "mid" of that "m=" line in a corresponding 337 CLUE group. 339 A CLUE-capable recipient that receives an "m=" line for a data 340 channel but no corresponding CLUE group containing the "mid" of that 341 "m=" line MAY still include a corresponding data channel "m=" line if 342 there are any other non-CLUE protocols it can convey over that 343 channel, but MUST NOT negotiate use of the CLUE protocol on this 344 channel. 346 4.5.2.2. Negotiating CLUE-controlled media 348 If the initial offer contained "a=recvonly" CLUE-controlled media 349 lines the recipient SHOULD include corresponding "a=sendonly" CLUE- 350 controlled media lines for compatible Encodings, up to the maximum 351 number of Encodings it wishes to advertise. As CLUE-controlled 352 media, the "mid" of these "m=" lines must be included in the 353 corresponding CLUE group. 355 If the initial offer contained "a=sendonly" CLUE-controlled media 356 lines the recipient MAY include corresponding "a=recvonly" CLUE- 357 controlled media lines, up to the maximum number of Capture Encodings 358 it wishes to receive. Alternatively, it MAY wait until CLUE protocol 359 negotiation has completed before including these lines in a new 360 offer/answer exchange - see Section 5 for recommendations. 362 4.5.2.3. Negotiating non-CLUE controlled media 364 A CLUE-controlled device implementation may prefer to render initial, 365 single-stream audio and/or video for the user as rapidly as possible, 366 transitioning to CLUE-controlled media once that has been negotiated. 367 Alternatively, an implementation may wish to suppress initial media, 368 only providing media once the final, CLUE-controlled streams have 369 been negotiated. 371 The receiver of the initial offer, if making the call CLUE-enabled 372 with their SDP answer, can make their preference clear by their 373 action in accepting or rejecting non-CLUE-controlled media lines. 374 Rejecting these "m=" lines will ensure that no non-CLUE-controlled 375 media flows before the CLUE-controlled media is negotiated. In 376 contrast, accepting one or more non-CLUE-controlled "m=" lines in 377 this initial answer will enable initial media to flow. 379 If the answerer chooses to send initial non-CLUE-controlled media in 380 a CLUE-enabled call, Section 4.5.4.1 addresses the need to disable it 381 once CLUE-controlled media is fully negotiated. 383 4.5.3. Processing the initial Offer/Answer negotiation 385 In the event that both offer and answer include a data channel "m=" 386 line with a mid value included in corresponding CLUE groups, CLUE has 387 been successfully negotiated and the call is now CLUE-enabled. If 388 not then the call is not CLUE-enabled. 390 4.5.3.1. Successful CLUE negotiation 392 In the event of successful CLUE-enablement of the call, devices MUST 393 now begin negotiation of the CLUE channel, see 394 [I-D.ietf-clue-datachannel] for negotiation details. If negotiation 395 is successful, sending of CLUE protocol [I-D.ietf-clue-protocol] 396 messages can begin. 398 A CLUE-capable device MAY choose not to send media on the non-CLUE- 399 controlled channels during the period in which control of the CLUE- 400 controlled media lines is being negotiated. However, a CLUE-capable 401 device MUST still be prepared to receive media on non-CLUE-controlled 402 media lines that have been successfully negotiated as defined in 403 [RFC3264]. 405 If either side of the call wishes to add additional CLUE-controlled 406 "m=" line to send or receive CLUE-controlled media they MAY now send 407 a SIP request with a new SDP offer following the normal rules of SDP 408 offer/answer and any negotiated extensions. 410 4.5.3.2. CLUE negotiation failure 412 In the event that the negotiation of CLUE fails and the call is not 413 CLUE-enabled once the initial offer/answer negotiation completes then 414 CLUE is not in use in the call. The CLUE-capable devices MUST either 415 revert to non-CLUE behaviour or terminate the call. 417 4.5.4. Modifying the session 419 4.5.4.1. Adding and removing CLUE-controlled media 421 Subsequent offer/answer exchanges MAY add additional "m=" lines for 422 CLUE-controlled media; in most cases at least one additional exchange 423 will be required before both sides have added all the Encodings and 424 ability to receive Encodings that they desire. Devices MAY delay 425 adding "a=recvonly" CLUE-controlled "m=" lines until after CLUE 426 protocol negotiation completes - see Section 5 for recommendations. 428 Subsequent offer/answer exchanges MAY also deactivate "m=" lines for 429 CLUE-controlled media. 431 Once CLUE media has been successfully negotiated devices SHOULD 432 ensure that non-CLUE-controlled media is deactivated in cases where 433 it corresponds to the media type of CLUE-controlled media that has 434 been successfully negotiated. This deactivation may require an 435 additional SDP exchange, or may be incorporated into one that is part 436 of the CLUE negotiation. 438 4.5.4.2. Enabling CLUE mid-call 440 A CLUE-capable device that receives an initial SDP offer from a non- 441 CLUE device SHOULD include a new data channel "m=" line and 442 corresponding CLUE group in any subsequent offers it sends, to 443 indicate that it is CLUE-capable. 445 If, in an ongoing non-CLUE call, an SDP offer/answer exchange 446 completes with both sides having included a data channel "m=" line in 447 their SDP and with the "mid" for that channel in corresponding CLUE 448 groups then the call is now CLUE-enabled; negotiation of the data 449 channel and subsequently the CLUE protocol begin. 451 4.5.4.3. Disabling CLUE mid-call 453 If, in an ongoing CLUE-enabled call, an SDP offer-answer negotiation 454 completes in a fashion in which either the CLUE data channel was not 455 successfully negotiated or one side did not include the data channel 456 in a matching CLUE group then CLUE for this call is disabled. In the 457 event that this occurs, CLUE is no longer enabled and sending of all 458 CLUE-controlled media associated with the corresponding CLUE group 459 MUST stop. If the data channel is still present but not included in 460 the CLUE group semantic CLUE protocol messages MUST no longer be 461 sent. 463 Note that this is distinct to cases where the CLUE protocol 464 negotiation fails or an error occurs in the CLUE protocol; see 465 [I-D.ietf-clue-protocol] for details of media and state preservation 466 in this circumstance. 468 5. Interaction of CLUE protocol and SDP negotiations 470 Information about media streams in CLUE is split between two message 471 types: SDP, which defines media addresses and limits, and the CLUE 472 channel, which defines properties of Capture Devices available, scene 473 information and additional constraints. As a result certain 474 operations, such as advertising support for a new transmissible 475 Capture with associated stream, cannot be performed atomically, as 476 they require changes to both SDP and CLUE messaging. 478 This section defines how the negotiation of the two protocols 479 interact, provides some recommendations on dealing with intermediate 480 stages in non-atomic operations, and mandates additional constraints 481 on when CLUE-configured media can be sent. 483 5.1. Independence of SDP and CLUE negotiation 485 To avoid the need to implement interlocking state machines with the 486 potential to reach invalid states if messages were to be lost, or be 487 rewritten en-route by middle boxes, the state machines in SDP and 488 CLUE operate independently. The state of the CLUE channel does not 489 restrict when an implementation may send a new SDP offer or answer, 490 and likewise the implementation's ability to send a new CLUE 491 Advertisement or Configure message is not restricted by the results 492 of or the state of the most recent SDP negotiation (unless the SDP 493 negotiation has removed the CLUE channel). 495 The primary implication of this is that a device may receive an SDP 496 with a CLUE Encoding for which it does not yet have Capture 497 information, or receive a CLUE Configure message specifying a Capture 498 Encoding for which the far end has not negotiated a media stream in 499 SDP. 501 CLUE messages contain an (in encodingIDList) or 502 (in captureEncodingType), which is used to identify a specific 503 encoding or captureEncoding in SDP; see 504 [I-D.ietf-clue-data-model-schema] for specifics. The non-atomic 505 nature of CLUE negotiation means that a sender may wish to send a new 506 Advertisement before the corresponding SDP message. As such the 507 sender of the CLUE message MAY include an which does not 508 currently match a CLUE-controlled "m=" line label in SDP; A CLUE- 509 capable implementation MUST NOT reject a CLUE protocol message solely 510 because it contains elements that do not match a label in 511 SDP. 513 The current state of the CLUE participant or Media Provider/Consumer 514 state machines do not affect compliance with any of the normative 515 language of [RFC3264]. That is, they MUST NOT delay an ongoing SDP 516 exchange as part of a SIP server or client transaction; an 517 implementation MUST NOT delay an SDP exchange while waiting for CLUE 518 negotiation to complete or for a Configure message to arrive. 520 Similarly, a device in a CLUE-enabled call MUST NOT delay any 521 mandatory state transitions in the CLUE Participant or Media 522 Provider/Consumer state machines due to the presence or absence of an 523 ongoing SDP exchange. 525 A device with the CLUE Participant state machine in the ACTIVE state 526 MAY choose not to move from ESTABLISHED to ADV (Media Provider state 527 machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media 528 Consumer state machine) based on the SDP state. See 529 [I-D.ietf-clue-protocol] for CLUE state machine specifics. 530 Similarly, a device MAY choose to delay initiating a new SDP exchange 531 based on the state of their CLUE state machines. 533 5.2. Constraints on sending media 535 While SDP and CLUE message states do not impose constraints on each 536 other, both impose constraints on the sending of media - CLUE- 537 controlled media MUST NOT be sent unless it has been negotiated in 538 both CLUE and SDP: an implementation MUST NOT send a specific CLUE 539 Capture Encoding unless its most recent SDP exchange contains an 540 active media channel for that Encoding AND the far end has sent a 541 CLUE Configure message specifying a valid Capture for that Encoding. 543 5.3. Recommendations for operating with non-atomic operations 545 CLUE-capable devices MUST be able to handle states in which CLUE 546 messages make reference to EncodingIDs that do not match the most 547 recently received SDP, irrespective of the order in which SDP and 548 CLUE messages are received. While these mismatches will usually be 549 transitory a device MUST be able to cope with such mismatches 550 remaining indefinitely. However, this document makes some 551 recommendations on message ordering for these non-atomic transitions. 553 CLUE-capable devices SHOULD ensure that any inconsistencies between 554 SDP and CLUE signaling are temporary by sending updated SDP or CLUE 555 messages as soon as the relevant state machines and other constraints 556 permit. 558 Generally, implementations that receive messages for which they have 559 incomplete information SHOULD wait until they have the corresponding 560 information they lack before sending messages to make changes related 561 to that information. For example, an answerer that receives a new 562 SDP offer with three new "a=sendonly" CLUE "m=" lines for which it 563 has received no CLUE Advertisement providing the corresponding 564 capture information SHOULD include corresponding "a=inactive" lines 565 in its answer, and SHOULD make a new SDP offer with "a=recvonly" when 566 and if a new Advertisement arrives with Captures relevant to those 567 Encodings. 569 Because of the constraints of SDP offer/answer and because new SDP 570 negotiations are generally more 'costly' than sending a new CLUE 571 message, implementations needing to make changes to both channels 572 SHOULD prioritize sending the updated CLUE message over sending the 573 new SDP message. The aim is for the recipient to receive the CLUE 574 changes before the SDP changes, allowing the recipient to send their 575 SDP answers without incomplete information, reducing the number of 576 new SDP offers required. 578 6. Interaction of CLUE protocol and RTP/RTCP CaptureID 580 [I-D.ietf-clue-framework] allows for Multiple Content Captures MCCs): 581 Captures which contain multiple source Captures, whether composited 582 into a single stream or switched based on some metric. 584 The Captures that contribute to these MCCs may or may not be defined 585 in the Advertisement message. If they are defined and the MCC is 586 providing them in a switched format the recipient may wish to 587 determine which originating source Capture is currently being 588 provided, so that they can apply geometric corrections based on that 589 Capture's geometry, or take some other action based on the original 590 Capture information. 592 To do this, [I-D.ietf-clue-rtp-mapping] allows for the CaptureID of 593 the originating Capture to be conveyed via RTP or RTCP. A Media 594 Provider sending switched media for an MCC with defined originating 595 sources MUST send the CaptureID in both RTP and RTCP, as described in 596 the mapping document. 598 6.1. CaptureID reception during MCC redefinition 600 Because the RTP/RTCP CaptureID is delivered via a different channel 601 to the Advertisement in which in the contents of the MCC are defined 602 there is an intrinsic race condition in cases in which the contents 603 of an MCC are redefined. 605 When a Media Provider redefines an MCC which involves CaptureIDs, the 606 reception of the relevant CaptureIDs by the recipient will either 607 lead or lag reception and processing of the new Advertisement by the 608 recipient. As such, a Media Consumer MUST not be disrupted by any of 609 the following in any CLUE- controlled media stream it is receiving, 610 whether that stream is for a static Capture or for an MCC (as any 611 static Capture may be redefined to an MCC in a later Advertisement): 613 o Receiving RTP or RTCP containing a CaptureID when the most 614 recently processed Advertisement means that none are expected. 616 o Receiving RTP or RTCP without CaptureIDs when the most recently 617 processed Advertisement means that media CaptureIDs are expected. 619 o Receiving a CaptureID in RTP or RTCP for a Capture defined in the 620 most recently processed Advertisement, but which the same 621 Advertisement does not include in the MCC. 623 o Receiving a CaptureID in RTP or RTCP for a Capture not defined in 624 the most recently processed Advertisement. 626 7. Multiplexing of CLUE-controlled media using BUNDLE 628 7.1. Overview 630 A CLUE call may involve sending and/or receiving significant numbers 631 of media streams. Conventionally, media streams are sent and 632 received on unique ports. However, each separate port used for this 633 purpose may impose costs that a device wishes to avoid, such as the 634 need to open that port on firewalls and NATs, the need to collect ICE 635 candidates [RFC5245], etc. 637 The BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] extension can be 638 used to negotiate the multiplexing of multiple media lines onto a 639 single 5-tuple for sending and receiving media, allowing devices in 640 calls to another BUNDLE-supporting device to potentially avoid some 641 of the above costs. 643 While CLUE-capable devices MAY support the BUNDLE extension for this 644 purpose supporting the extension is not mandatory for a device to be 645 CLUE-compliant. 647 7.2. Usage of BUNDLE with CLUE 649 This specification imposes no additional requirements or restrictions 650 on the usage of BUNDLE when used with CLUE. There is no restriction 651 on combining CLUE-controlled media lines and non-CLUE-controlled 652 media lines in the same BUNDLE group or in multiple such groups. 653 However, there are several steps an implementation may wish to take 654 to ameliorate the cost and time requirements of extra SDP offer/ 655 answer exchanges between CLUE and BUNDLE. 657 7.2.1. Generating the Initial Offer 659 BUNDLE mandates that the initial SDP offer MUST use a unique address 660 for each "m=" line with a non-zero port. Because CLUE 661 implementations generally will not include CLUE-controlled media 662 lines with the exception of the data channel in the initial SDP 663 offer, CLUE devices that support large numbers of streams can avoid 664 ever having to open large numbers of ports if they successfully 665 negotiate BUNDLE. 667 7.2.2. Multiplexing of the data channel and RTP media 669 BUNDLE-supporting CLUE-capable devices MAY include the data channel 670 in the same BUNDLE group as RTP media. In this case the device MUST 671 be able to demultiplex the various transports - see section 9.2 of 672 the BUNDLE draft [I-D.ietf-mmusic-sdp-bundle-negotiation]. If the 673 BUNDLE group includes other protocols than the data channel 674 transported via DTLS the device MUST also be able to differentiate 675 the various protocols. 677 8. Example: A call between two CLUE-capable Endpoints 679 This example illustrates a call between two CLUE-capable Endpoints. 680 Alice, initiating the call, is a system with three cameras and three 681 screens. Bob, receiving the call, is a system with two cameras and 682 two screens. A call-flow diagram is presented, followed by a summary 683 of each message. 685 To manage the size of this section the SDP snippet only illustrate 686 video "m=" lines. SIP ACKs are not discussed. Note that BUNDLE is 687 not in use. 689 +----------+ +-----------+ 690 | Alice | | Bob | 691 | | | | 692 +----+-----+ +-----+-----+ 693 | | 694 | | 695 | SIP INVITE 1 | 696 |--------------------------------->| 697 | | 698 | | 699 | SIP 200 OK 1 | 700 |<---------------------------------| 701 | | 702 | | 703 | SIP ACK 1 | 704 |--------------------------------->| 705 | | 706 | | 707 | | 708 |<########### MEDIA 1 ############>| 709 | 1 video A->B, 1 video B->A | 710 |<################################>| 711 | | 712 | | 713 | | 714 |<================================>| 715 | CLUE DATA CHANNEL ESTABLISHED | 716 |<================================>| 717 | | 718 | | 719 | CLUE OPTIONS | 720 |<*********************************| 721 | | 722 | | 723 | CLUE OPTIONS RESPONSE | 724 |*********************************>| 725 | | 726 | | 727 | CLUE ADVERTISEMENT 1 | 728 |*********************************>| 729 | | 730 | | 731 | CLUE ADVERTISEMENT 2 | 732 |<*********************************| 733 | | 734 | | 735 | SIP INVITE 2 (+3 sendonly) | 736 |--------------------------------->| 737 | | 738 | | 739 | CLUE CONFIGURE 1 | 740 |<*********************************| 741 | | 742 | | 743 | CLUE RESPONSE 1 | 744 |*********************************>| 745 | | 746 | | 747 | SIP 200 OK 2 (+2 recvonly) | 748 |<---------------------------------| 749 | | 750 | | 751 | SIP ACK 2 | 752 |--------------------------------->| 753 | | 754 | | 755 | | 756 |<########### MEDIA 2 ############>| 757 | 2 video A->B, 1 video B->A | 758 |<################################>| 759 | | 760 | | 761 | SIP INVITE 3 (+2 sendonly) | 762 |<---------------------------------| 763 | | 764 | | 765 | CLUE CONFIGURE 2 | 766 |*********************************>| 767 | | 768 | | 769 | CLUE RESPONSE 2 | 770 |<*********************************| 771 | | 772 | | 773 | SIP 200 OK 3 (+2 recvonly) | 774 |--------------------------------->| 775 | | 776 | | 777 | | 778 | SIP ACK 3 | 779 |<---------------------------------| 780 | | 781 | | 782 | | 783 |<########### MEDIA 3 ############>| 784 | 2 video A->B, 2 video B->A | 785 |<################################>| 786 | | 787 | | 788 | | 789 v v 791 In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP 792 body the basic audio and video capabilities and the data channel as 793 per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" 794 media feature tag in the INVITE. A snippet of the SDP showing the 795 grouping attribute and the video "m=" line are shown below. Alice 796 has included a "CLUE" group, and included the mid corresponding to a 797 data channel in the group (3). Note that Alice has chosen not to 798 include any CLUE-controlled media in the initial offer - the mid 799 value of the video line is not included in the "CLUE" group. 801 ... 802 a=group:CLUE 3 803 ... 804 m=video 6002 RTP/AVP 96 805 a=rtpmap:96 H264/90000 806 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 807 a=sendrecv 808 a=mid:2 809 ... 810 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 811 a=sctp-port: 5000 812 a=dcmap:2 subprotocol="CLUE";ordered=true 813 a=mid:3 815 Bob responds with a similar SDP in SIP 200 OK 1, which also has a 816 "CLUE" group including the mid value of a data channel; due to their 817 similarity no SDP snippet is shown here. Bob wishes to receive 818 initial media, and so includes corresponding non-CLUE-controlled 819 audio and video lines. Bob also includes the "sip.clue" media 820 feature tag in the 200 OK. Alice and Bob are each now able to send a 821 single audio and video stream. This is illustrated as MEDIA 1. 823 With the successful initial SDP O/A Alice and Bob are also free to 824 negotiate the CLUE data channel. This is illustrated as CLUE DATA 825 CHANNEL ESTABLISHED. 827 Once the data channel is established CLUE protocol negotiation 828 begins. In this case Bob is the Channel Initiator and sends a CLUE 829 OPTIONS message describing his version support. On receiving that 830 message Alice sends her corresponding CLUE OPTIONS RESPONSE. 832 With the OPTIONS phase complete Alice now sends her CLUE 833 Advertisement (CLUE ADVERTISEMENT 1). She advertises three static 834 Captures representing her three cameras. She also includes switched 835 Captures suitable for two- and one-screen systems. All of these 836 Captures are in a single Capture Scene, with suitable Capture Scene 837 Views to tell Bob that he should either subscribe to the three static 838 Captures, the two switched Captures or the one switched Capture. 839 Alice has no simultaneity constraints, so includes all six Captures 840 in one simultaneous set. Finally, Alice includes an Encoding Group 841 with three Encoding IDs: "enc1", "enc2" and "enc3". These Encoding 842 IDs aren't currently valid, but will match the next SDP offer she 843 sends. 845 Bob received CLUE ADVERTISEMENT 1 but does not yet send a Configure 846 message, because he has not yet received Alice's Encoding 847 information, so as yet he does not know if she will have sufficient 848 resources to send him the two streams he ideally wants at a quality 849 he is happy with. 851 Bob also sends his CLUE Advertisement (CLUE ADVERTISEMENT 2). He 852 advertises two static Captures representing his cameras. He also 853 includes a single composed Capture for single-screen systems, in 854 which he will composite the two camera views into a single video 855 stream. All three Captures are in a single Capture Scene, with 856 suitable Capture Scene Views to tell Alice that she should either 857 subscribe to the two static Captures, or the single composed Capture. 858 Bob also has no simultaneity constraints, so includes all three 859 Captures in one simultaneous set. Bob also includes a single 860 Encoding Group with two Encoding IDs: "foo" and "bar". 862 Similarly, Alice receives CLUE ADVERTISEMENT 2 but does not yet send 863 a Configure message, because she has not yet received Bob's Encoding 864 information. 866 Alice now sends SIP INVITE 2. She maintains the sendrecv audio, 867 video and CLUE "m=" lines, and she adds three new sendonly "m=" lines 868 to represent the three CLUE-controlled Encodings she can send. Each 869 of these "m=" lines has a label corresponding to one of the Encoding 870 IDs from CLUE ADVERTISEMENT 1. Each also has its mid added to the 871 grouping attribute to show they are controlled by the CLUE channel. 872 A snippet of the SDP showing the grouping attribute, data channel and 873 the video "m=" lines are shown below: 875 ... 876 a=group:CLUE 3 4 5 6 877 ... 878 m=video 6002 RTP/AVP 96 879 a=rtpmap:96 H264/90000 880 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 881 a=sendrecv 882 a=mid:2 883 ... 884 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 885 a=sctp-port: 5000 886 a=dcmap:2 subprotocol="CLUE";ordered=true 887 a=mid:3 888 ... 889 m=video 6004 RTP/AVP 96 890 a=rtpmap:96 H264/90000 891 a=fmtp:96 profile-level-id=42e016 892 a=sendonly 893 a=mid:4 894 a=label:enc1 895 m=video 6006 RTP/AVP 96 896 a=rtpmap:96 H264/90000 897 a=fmtp:96 profile-level-id=42e016 898 a=sendonly 899 a=mid:5 900 a=label:enc2 901 m=video 6008 RTP/AVP 96 902 a=rtpmap:96 H264/90000 903 a=fmtp:96 profile-level-id=42e016 904 a=sendonly 905 a=mid:6 906 a=label:enc3 908 Bob now has all the information he needs to decide which streams to 909 configure. As such he now sends CLUE CONFIGURE 1. This requests the 910 pair of switched Captures that represent Alice's scene, and he 911 configures them with encoder ids "enc1" and "enc2". This also serves 912 as an ack for Alice's CLUE ADVERTISEMENT 1. 914 Alice receives Bob's message CLUE CONFIGURE 1 and sends CLUE RESPONSE 915 1 to ack its reception. She does not yet send the Capture Encodings 916 specified, because at this stage Bob hasn't negotiated the ability to 917 receive these streams in SDP. 919 Bob now sends his SDP answer as part of SIP 200 OK 2. Alongside his 920 original audio, video and CLUE "m=" lines he includes two active 921 recvonly "m= "lines and a zeroed "m=" line for the third. He adds 922 their mid values to the grouping attribute to show they are 923 controlled by the CLUE channel. A snippet of the SDP showing the 924 grouping attribute and the video "m=" lines are shown below (mid 100 925 represents the CLUE channel, not shown): 927 ... 928 a=group:CLUE 11 12 100 929 ... 930 m=video 58722 RTP/AVP 96 931 a=rtpmap:96 H264/90000 932 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 933 a=sendrecv 934 a=mid:10 935 ... 936 m=video 58724 RTP/AVP 96 937 a=rtpmap:96 H264/90000 938 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 939 a=recvonly 940 a=mid:11 941 m=video 58726 RTP/AVP 96 942 a=rtpmap:96 H264/90000 943 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 944 a=recvonly 945 a=mid:12 946 m=video 0 RTP/AVP 96 948 On receiving SIP 200 OK 2 from Bob Alice is now able to send the two 949 streams of video Bob requested - this is illustrated as MEDIA 2. 951 The constraints of offer/answer meant that Bob could not include his 952 encoding information as new "m=" lines in SIP 200 OK 2. As such Bob 953 now sends SIP INVITE 3 to generate a new offer. Along with all the 954 streams from SIP 200 OK 2 Bob also includes two new sendonly streams. 955 Each stream has a label corresponding to the Encoding IDs in his CLUE 956 ADVERTISEMENT 2 message. He also adds their mid values to the 957 grouping attribute to show they are controlled by the CLUE channel. 958 A snippet of the SDP showing the grouping attribute and the video 959 "m=" lines are shown below (mid 100 represents the CLUE channel, not 960 shown): 962 ... 963 a=group:CLUE 11 12 13 14 100 964 ... 965 m=video 58722 RTP/AVP 96 966 a=rtpmap:96 H264/90000 967 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 968 a=sendrecv 969 a=mid:10 970 ... 971 m=video 58724 RTP/AVP 96 972 a=rtpmap:96 H264/90000 973 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 974 a=recvonly 975 a=mid:11 976 m=video 58726 RTP/AVP 96 977 a=rtpmap:96 H264/90000 978 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 979 a=recvonly 980 a=mid:12 981 m=video 0 RTP/AVP 96 982 m=video 58728 RTP/AVP 96 983 a=rtpmap:96 H264/90000 984 a=fmtp:96 profile-level-id=42e016 985 a=sendonly 986 a=label:foo 987 a=mid:13 988 m=video 58730 RTP/AVP 96 989 a=rtpmap:96 H264/90000 990 a=fmtp:96 profile-level-id=42e016 991 a=sendonly 992 a=label:bar 993 a=mid:14 995 Having received this Alice now has all the information she needs to 996 send CLUE CONFIGURE 2. She requests the two static Captures from 997 Bob, to be sent on Encodings "foo" and "bar". 999 Bob receives Alice's message CLUE CONFIGURE 2 and sends CLUE RESPONSE 1000 2 to ack its reception. Bob does not yet send the Capture Encodings 1001 specified, because Alice hasn't yet negotiated the ability to receive 1002 these streams in SDP. 1004 Alice now sends SIP 200 OK 3, matching two recvonly "m=" lines to 1005 Bob's new sendonly lines. She includes their mid values in the 1006 grouping attribute to show they are controlled by the CLUE channel. 1007 Alice also now deactivates the initial non-CLUE-controlled media, as 1008 bidirectional CLUE-controlled media is now available. A snippet of 1009 the SDP showing the grouping attribute and the video "m=" lines are 1010 shown below (mid 3 represents the data channel, not shown): 1012 ... 1013 a=group:CLUE 3 4 5 7 8 1014 ... 1015 m=video 0 RTP/AVP 96 1016 a=mid:2 1017 ... 1018 m=video 6004 RTP/AVP 96 1019 a=rtpmap:96 H264/90000 1020 a=fmtp:96 profile-level-id=42e016 1021 a=sendonly 1022 a=mid:4 1023 a=label:enc1 1024 m=video 6006 RTP/AVP 96 1025 a=rtpmap:96 H264/90000 1026 a=fmtp:96 profile-level-id=42e016 1027 a=sendonly 1028 a=mid:5 1029 a=label:enc2 1030 m=video 0 RTP/AVP 96 1031 m=video 6010 RTP/AVP 96 1032 a=rtpmap:96 H264/90000 1033 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1034 a=recvonly 1035 a=mid:7 1036 m=video 6012 RTP/AVP 96 1037 a=rtpmap:96 H264/90000 1038 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1039 a=recvonly 1040 a=mid:8 1042 Finally, on receiving SIP 200 OK 3 Bob is now able to send the two 1043 streams of video Alice requested - this is illustrated as MEDIA 3. 1045 Both sides of the call are now sending multiple video streams with 1046 their sources defined via CLUE negotiation. As the call progresses 1047 either side can send new Advertisement or Configure message or new 1048 SDP offer/answers to add, remove or change what they have available 1049 or want to receive. 1051 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 1053 In this brief example Alice is a CLUE-capable Endpoint making a call 1054 to Bob, who is not CLUE-capable (i.e. is not able to use the CLUE 1055 protocol). 1057 +----------+ +-----------+ 1058 | EP1 | | EP2 | 1059 | | | | 1060 +----+-----+ +-----+-----+ 1061 | | 1062 | | 1063 | SIP INVITE 1 | 1064 |--------------------------------->| 1065 | | 1066 | | 1067 | 200 0K 1 | 1068 |<---------------------------------| 1069 | | 1070 | | 1071 | ACK 1 | 1072 |--------------------------------->| 1073 | | 1074 | | 1075 | | 1076 |<########### MEDIA 1 ############>| 1077 | 1 video A->B, 1 video B->A | 1078 |<################################>| 1079 | | 1080 | | 1081 | | 1082 | | 1083 v v 1085 In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP 1086 body the basic audio and video capabilities and the data channel as 1087 per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" 1088 media feature tag in the INVITE. A snippet of the SDP showing the 1089 grouping attribute and the video "m=" line are shown below. Alice 1090 has included a "CLUE" group, and included the mid corresponding to a 1091 data channel in the group (3). Note that Alice has chosen not to 1092 include any CLUE-controlled media in the initial offer - the mid 1093 value of the video line is not included in the "CLUE" group. 1095 ... 1096 a=group:CLUE 3 1097 ... 1098 m=video 6002 RTP/AVP 96 1099 a=rtpmap:96 H264/90000 1100 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1101 a=sendrecv 1102 a=mid:2 1103 ... 1104 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 1105 a=sctp-port: 5000 1106 a=dcmap:2 subprotocol="CLUE";ordered=true 1107 a=mid:3 1109 Bob is not CLUE-capable, and hence does not recognize the "CLUE" 1110 semantic for grouping attribute, nor does he support the data 1111 channel. IN SIP 200 OK 1 he responds with an answer with audio and 1112 video, but with the data channel zeroed. 1114 From the lack of the data channel and grouping framework Alice 1115 understands that Bob does not support CLUE, or does not wish to use 1116 it. Both sides are now able to send a single audio and video stream 1117 to each other. Alice at this point begins to send her fallback 1118 video: in this case likely a switched view from whichever camera 1119 shows the current loudest participant on her side. 1121 10. Acknowledgements 1123 The team focusing on this draft consists of: Roni Even, Rob Hansen, 1124 Christer Holmberg, Paul Kyzivat, Simon Pietro-Romano, Roberta Presta. 1126 Christian Groves and Jonathan Lennox have contributed detailed 1127 comments and suggestions. 1129 11. IANA Considerations 1131 11.1. New SDP Grouping Framework Attribute 1133 This document registers the following semantics with IANA in the 1134 "Semantics for the "group" SDP Attribute" subregistry (under the 1135 "Session Description Protocol (SDP) Parameters" registry per 1136 [RFC5888]: 1138 Semantics Token Reference 1139 ------------------------------------- ------ --------- 1140 CLUE-controlled m-line CLUE [this draft] 1142 11.2. New SIP Media Feature Tag 1144 This specification registers a new media feature tag in the SIP 1145 [RFC3264] tree per the procedures defined in [RFC2506] and [RFC3840]. 1147 Media feature tag name: sip.clue 1149 ASN.1 Identifier: 1.3.6.1.8.4.29 1151 Summary of the media feature indicated by this tag: This feature tag 1152 indicates that the device supports CLUE-controlled media. 1154 Values appropriate for use with this feature tag: Boolean. 1156 The feature tag is intended primarily for use in the following 1157 applications, protocols, services, or negotiation mechanisms: 1159 This feature tag is most useful in a communications application for 1160 describing the capabilities of a device to use the CLUE control 1161 protocol to negotiate the use of multiple media streams. 1163 Related standards or documents: [this draft] 1165 Security Considerations: Security considerations for this media 1166 feature tag are discussed in Section 12 of [this draft]. 1168 Name(s) & email address(es) of person(s) to contact for further 1169 information: 1171 o CLUE workgroup: clue@ietf.org 1173 o CLUE chairs: clue-chairs@ietf.org 1175 Intended usage: COMMON 1177 12. Security Considerations 1179 CLUE makes use of a number of protocols and mechanisms, either 1180 defined by CLUE or long-standing. The security considerations 1181 section of the CLUE Framework [I-D.ietf-clue-framework] addresses the 1182 need to secure these mechanisms by following the recommendations of 1183 the individual protocols. 1185 Beyond the need to secure the constituent protocols, the use of CLUE 1186 does impose additional security concerns. One area of increased risk 1187 involves the potential for a malicious party to subvert a CLUE- 1188 capable device to attack a third party by driving large volumes of 1189 media (particularly video) traffic at them by establishing a 1190 connection to the CLUE-capable device and directing the media to the 1191 victim. While this is a risk for all media devices, a CLUE-capable 1192 device may allow the attacker to configure multiple media streams to 1193 be sent, significantly increasing the volume of traffic directed at 1194 the victim. 1196 This attack can be prevented by ensuring that the media recipient 1197 intends to receive the media packets. As such all CLUE-capable 1198 devices MUST support key negotiation and receiver intent assurance 1199 via DTLS [RFC5763] on CLUE-controlled RTP "m=" lines. All CLUE- 1200 controlled RTP "m" lines must be secured and implemented using 1201 mechanisms such as SRTP [RFC3711]; no specific security mechanisms 1202 are made mandatory to use due to the issues addressed in [RFC7202]. 1203 Due to the requirements of backwards compatibility, this is not a 1204 mandatory requirement for non-CLUE-controlled "m=" lines. 1206 CLUE also defines a new media feature tag that indicates CLUE 1207 support. This tag may be present even in non-CLUE calls, which 1208 increases the metadata available about the sending device, which can 1209 help an attacker differentiate between multiple devices and help them 1210 identify otherwise anonymised users via the fingerprint of features 1211 their device supports. To prevent this, SIP signaling SHOULD always 1212 be encrypted using TLS [RFC5630]. 1214 13. Change History 1216 -07: Revision by Rob Hansen 1218 * Removed the entire 'Media line directionality' section as a 1219 discussion of the pros/cons of using bidirectional vs 1220 unidirectional schemes wasn't suitable for a finalised version. 1221 The unidirectionality requirement is covered normatively in an 1222 earlier section. 1224 * BUNDLE no longer includes an address synchronisation step so 1225 the suggestion to wait until that done has been replaced with 1226 some general language about following any negotiated 1227 extensions. 1229 * Added OPTIONS negotiation to the example flow, and revised the 1230 flow to ensure it matched protocol document. 1232 * Section on not sending CLUE control media until CLUE 1233 negotiation completes narrowed to notify that only RTP should 1234 not be sent until negotiation completes and add RTCP to the 1235 list of things that should be sent as normal, in line with 1236 a=inactive. 1238 * Make explicit that m=recvonly lines don't need to have a label, 1239 as only m=sendonly lines are referenced by CLUE protocol 1240 messages. 1242 * Fix formatting of IANA sections. Improve syntax of feature tag 1243 section in line with Paul's suggestions. Definition of feature 1244 tag narrowed to be multiple media lines *negotiated via CLUE 1245 protocol* rather than more generic 'multiple media lines'. 1247 * General corrections to grammar, spelling and readability based 1248 on Christian, Paul and Mark; in many cases suggested text was 1249 gratefully accepted. 1251 -06: Revision by Rob Hansen 1253 * State machine interactions updated to match versions in -04 of 1254 protocol doc. 1256 * Section on encoding updated to specify both encID and 1257 encodingID from data model doc. 1259 * Removed the limitations on describing H264 encoding limits 1260 using SDP syntax as an open issue. 1262 * Previous draft had SRTP and DTLS mandatory to implement and to 1263 use on CLUE- controlled m lines. Current version has DTLS 1264 mandatory to implement, and 'security' mandatory to use but 1265 does not define what that security is. 1267 * Terminology reference to framework doc reinforced. All 1268 terminology that duplicates framework removed. All text 1269 updated with capitalisation that matches framework document's 1270 terminology. 1272 * SDP example syntax updated to match that of ietf-clue- 1273 datachannel and hence ietf-mmusic-data-channel-sdpneg. 1275 -05: Revision by Rob Hansen 1277 * SRTP/DTLS made mandatory for CLUE-controlled media lines. 1279 * IANA consideration section added (text as proposed by Christian 1280 Groves). 1282 * Includes provision for dependent streams on seperate "m" lines 1283 having the same encID as their parent "m" line. 1285 * References to putting CLUE-controlled media and data channels 1286 in more than one CLUE group removed, since the document no 1287 longer supports using more than one CLUE group. 1289 * Section on CLUE controlled media restrictions still applying 1290 even if the call does not end up being CLUE enabled being 1291 rewritten to hopefully be clearer. 1293 * Other minor syntax improvements. 1295 -04: Revision by Rob Hansen 1297 * Updated DTLS/SCTP channel syntax in examples to fix errors and 1298 match latest format defined in draft-ietf-mmusic-sctp-sdp-07. 1300 * Clarified the behaviour if an SDP offer includes a CLUE- 1301 controlled "m" line and the answer accepts that "m" line but 1302 without CLUE control of that line. 1304 * Added a new section on the sending and receiving of CaptureIDs 1305 in RTP and RTCP. Includes a section on the necessity of the 1306 receiver coping with unexpected CaptureIDs (or the lack 1307 thereof) due to MCCs being redefined in new Advertisement 1308 messages. 1310 * Added reminder on IANA section on registering grouping semantic 1311 and media feature tag, removed the less formal sections that 1312 did the same job. 1314 * Fixed and clarified issues raised by Christian's document 1315 review. 1317 * Added a number of security considerations. 1319 -03: Revision by Rob Hansen 1321 * Clarified text on not rejecting messages because they contain 1322 unknown encIDs. 1324 * Removed normative language in section on accepting/rejecting 1325 non-CLUE-controlled media in the initial answer. 1327 * Example SDP updated to include the data channel "m" lines. 1329 * Example call flow updated to show disablement of non-CLUE- 1330 controlled media once CLUE-controlled media is flowing. 1332 -02: Revision by Rob Hansen 1334 * Added section on not accepting non-CLUE-controlled "m" lines in 1335 the initial answer when CLUE is to be negotiated. 1337 * Removed previous language attempting to describe media 1338 restrictions for CLUE-controlled "m" lines that had not been 1339 configured, and replaced it with much more accurate 'treat as 1340 "a=inactive" was set'. 1342 * Made label element mandatory for CLUE-controlled media (was 1343 previously "SHOULD include", but there didn't seem a good 1344 reason for this - anyone wishing to include the "m" line but 1345 not immediately use it in CLUE can simply leave it out of the 1346 .) 1348 * Added a section on the specifics of relating encodings in SDP 1349 to elements in the CLUE protocol, including the fact 1350 that both Advertisement and Configure messages reference the 1351 *encoding* (eg, in the Configure case the sender of the 1352 Configure message includes the labels of the recipient's "m" 1353 lines as their contents). 1355 * Minor revisions to the section on complying with normative SDP/ 1356 CLUEstate machine language to clarify that these were not new 1357 normative language, merely that existing normative language 1358 still applies. 1360 * Removed appendices which previously contained information to be 1361 transferred to the protocol and data channel drafts. Removed 1362 other text that discussed alternatives to the current approach. 1364 * Cleaned up some 'todo' text. 1366 -01: Revision by Rob Hansen 1368 * Revised terminology - removed the term 'CLUE-enabled' device as 1369 insufficiently distinct from 'CLUE-capable' and instead added a 1370 term for 'CLUE-enabled' calls. 1372 * Removed text forbidding RTCP and instead added text that ICE/ 1373 DTLS negotiation for CLUE controlled media must be done as 1374 normal irrespective of CLUE negotiation. 1376 * Changed 'sip.telepresence' to 'sip.clue' and 'TELEPRESENCE' 1377 grouping semantic back to CLUE. 1379 * Made it mandatory to have exactly one mid corresponding to a 1380 data channel in a CLUE group 1382 * Forbade having multiple CLUE groups unless a specification for 1383 doing so is published. 1385 * Refactored SDP-related text; previously the encoding 1386 information had been in the "initial offer" section despite the 1387 fact that we recommend that the initial offer doesn't actually 1388 include any encodings. I moved the specifications of encodings 1389 and how they're received to an earlier, seperate section. 1391 * Added text on how the state machines in CLUE and SDP are 1392 allowed to affect one another, and further recommendations on 1393 how a device should handle the sending of CLUE and SDP changes. 1395 -00: Revision by Rob Hansen 1397 * Submitted as -00 working group document 1399 draft-kyzivat-08: Revisions by Rob Hansen 1401 * Added media feature tag for CLUE support ('sip.telepresence') 1403 * Changed grouping semantic from 'CLUE' to 'TELEPRESENCE' 1405 * Restructured document to be more centred on the grouping 1406 semantic and its use with O/A 1408 * Lots of additional text on usage of the grouping semantic 1410 * Stricter definition of CLUE-controlled m lines and how they 1411 work 1413 * Some additional text on defining what happens when CLUE 1414 supports is added or removed 1416 * Added details on when to not send RTCP for CLUE-controlled "m" 1417 lines. 1419 * Added a section on using BUNDLE with CLUE 1421 * Updated data channel references to point at new WG document 1422 rather than indivual draft 1424 draft-kyzivat-07: Revisions by Rob Hansen 1426 * Removed the text providing arguments for encoding limits being 1427 in SDP and encoding groups in the CLUE protocol in favor of the 1428 specifics of how to negotiate encodings in SDP 1430 * Added normative language on the setting up of a CLUE call, and 1431 added sections on mid-call changes to the CLUE status. 1433 * Added references to [I-D.ietf-clue-datachannel] where 1434 appropriate. 1436 * Added some terminology for various types of CLUE and non-CLUE 1437 states of operation. 1439 * Moved language related to topics that should be in 1440 [I-D.ietf-clue-datachannel] and [I-D.ietf-clue-protocol], but 1441 that has not yet been resolved in those documents, into an 1442 appendix. 1444 draft-kyzivat-06: Revisions by Rob Hansen 1446 * Removed CLUE message XML schema and details that are now in 1447 draft-presta-clue-protocol 1449 * Encoding limits in SDP section updated to note that this has 1450 been investigated and discussed and is the current working 1451 assumption of the WG, though consensus has not been fully 1452 achieved. 1454 * A section has also been added on the current mandation of 1455 unidirectional "m" lines. 1457 * Updated CLUE messaging in example call flow to match draft- 1458 presta-clue-protocol-03 1460 draft-kyzivat-05: Revisions by pkyzivat: 1462 * Specified versioning model and mechanism. 1464 * Added explicit response to all messages. 1466 * Rearranged text to work with the above changes. (Which 1467 rendered diff almost useless.) 1469 draft-kyzivat-04: Revisions by Rob Hansen: ??? 1471 draft-kyzivat-03: Revisions by pkyzivat: 1473 * Added a syntax section with an XML schema for CLUE messages. 1474 This is a strawhorse, and is very incomplete, but it 1475 establishes a template for doing this based on elements defined 1476 in the data model. (Thanks to Roberta for help with this!) 1478 * Did some rewording to fit the syntax section in and reference 1479 it. 1481 * Did some relatively minor restructuring of the document to make 1482 it flow better in a logical way. 1484 draft-kyzivat-02: A bunch of revisions by pkyzivat: 1486 * Moved roberta's call flows to a more appropriate place in the 1487 document. 1489 * New section on versioning. 1491 * New section on NAK. 1493 * A couple of possible alternatives for message acknowledgment. 1495 * Some discussion of when/how to signal changes in provider 1496 state. 1498 * Some discussion about the handling of transport errors. 1500 * Added a change history section. 1502 These were developed by Lennard Xiao, Christian Groves and Paul, 1503 so added Lennard and Christian as authors. 1505 draft-kyzivat-01: Updated by roberta to include some sample call 1506 flows. 1508 draft-kyzivat-00: Initial version by pkyzivat. Established general 1509 outline for the document, and specified a few things thought to 1510 represent wg consensus. 1512 14. References 1514 14.1. Normative References 1516 [I-D.ietf-clue-framework] 1517 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 1518 for Telepresence Multi-Streams", draft-ietf-clue- 1519 framework-25 (work in progress), January 2016. 1521 [I-D.ietf-clue-data-model-schema] 1522 Presta, R. and S. Romano, "An XML Schema for the CLUE data 1523 model", draft-ietf-clue-data-model-schema-11 (work in 1524 progress), October 2015. 1526 [I-D.ietf-clue-protocol] 1527 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 1528 clue-protocol-06 (work in progress), October 2015. 1530 [I-D.ietf-clue-datachannel] 1531 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1532 clue-datachannel-11 (work in progress), November 2015. 1534 [I-D.ietf-clue-rtp-mapping] 1535 Even, R. and J. Lennox, "Mapping RTP streams to CLUE media 1536 captures", draft-ietf-clue-rtp-mapping-06 (work in 1537 progress), January 2016. 1539 [I-D.ietf-mmusic-sctp-sdp] 1540 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 1541 Control Transmission Protocol (SCTP)-Based Media Transport 1542 in the Session Description Protocol (SDP)", draft-ietf- 1543 mmusic-sctp-sdp-15 (work in progress), September 2015. 1545 [I-D.ietf-mmusic-data-channel-sdpneg] 1546 Drage, K., Makaraju, R., Stoetzer-Bradler, J., Ejzak, R., 1547 and J. Marcon, "SDP-based Data Channel Negotiation", 1548 draft-ietf-mmusic-data-channel-sdpneg-07 (work in 1549 progress), November 2015. 1551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1552 Requirement Levels", BCP 14, RFC 2119, 1553 DOI 10.17487/RFC2119, March 1997, 1554 . 1556 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1557 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1558 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1559 . 1561 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1562 Protocol (SDP) Label Attribute", RFC 4574, 1563 DOI 10.17487/RFC4574, August 2006, 1564 . 1566 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1567 for Establishing a Secure Real-time Transport Protocol 1568 (SRTP) Security Context Using Datagram Transport Layer 1569 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1570 2010, . 1572 14.2. Informative References 1574 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1575 Registration Procedure", BCP 31, RFC 2506, 1576 DOI 10.17487/RFC2506, March 1999, 1577 . 1579 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1580 with Session Description Protocol (SDP)", RFC 3264, 1581 DOI 10.17487/RFC3264, June 2002, 1582 . 1584 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1585 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1586 2002, . 1588 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1589 "Indicating User Agent Capabilities in the Session 1590 Initiation Protocol (SIP)", RFC 3840, 1591 DOI 10.17487/RFC3840, August 2004, 1592 . 1594 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1595 (ICE): A Protocol for Network Address Translator (NAT) 1596 Traversal for Offer/Answer Protocols", RFC 5245, 1597 DOI 10.17487/RFC5245, April 2010, 1598 . 1600 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1601 Initiation Protocol (SIP)", RFC 5630, 1602 DOI 10.17487/RFC5630, October 2009, 1603 . 1605 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1606 Protocol (SDP) Grouping Framework", RFC 5888, 1607 DOI 10.17487/RFC5888, June 2010, 1608 . 1610 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1611 Payload Format for H.264 Video", RFC 6184, 1612 DOI 10.17487/RFC6184, May 2011, 1613 . 1615 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 1616 Framework: Why RTP Does Not Mandate a Single Media 1617 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 1618 2014, . 1620 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1621 Holmberg, C., Alvestrand, H., and C. Jennings, 1622 "Negotiating Media Multiplexing Using the Session 1623 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1624 negotiation-25 (work in progress), January 2016. 1626 [I-D.ietf-rtcweb-data-channel] 1627 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1628 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1629 progress), January 2015. 1631 Authors' Addresses 1633 Paul Kyzivat 1635 Email: pkyzivat@alum.mit.edu 1637 Lennard Xiao 1638 Huawei 1640 Email: lennard.xiao@huawei.com 1642 Christian Groves 1643 Huawei 1645 Email: Christian.Groves@nteczone.com 1647 Robert Hansen 1648 Cisco Systems 1650 Email: rohanse2@cisco.com