idnits 2.17.1 draft-ietf-clue-signaling-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 recipient 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 (October 27, 2014) is 3467 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) == Unused Reference: 'I-D.ietf-clue-data-model-schema' is defined on line 1446, but no explicit reference was found in the text == Unused Reference: 'I-D.groves-clue-latent-config' is defined on line 1464, but no explicit reference was found in the text == Unused Reference: 'I-D.tuexen-tsvwg-sctp-dtls-encaps' is defined on line 1475, but no explicit reference was found in the text == Unused Reference: 'RFC5888' is defined on line 1483, but no explicit reference was found in the text == Unused Reference: 'RFC4353' is defined on line 1500, but no explicit reference was found in the text == Unused Reference: 'RFC6120' is defined on line 1512, but no explicit reference was found in the text == Unused Reference: 'I-D.even-clue-sdp-clue-relation' is defined on line 1518, but no explicit reference was found in the text == Unused Reference: 'I-D.even-clue-rtp-mapping' is defined on line 1523, but no explicit reference was found in the text == Unused Reference: 'I-D.hansen-clue-sdp-interaction' is defined on line 1528, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-18 == Outdated reference: A later version (-17) exists of draft-ietf-clue-data-model-schema-07 == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-02 ** 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-01 ** 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-03 ** Downref: Normative reference to an Informational draft: draft-groves-clue-latent-config (ref. 'I-D.groves-clue-latent-config') == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-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-12 Summary: 4 errors (**), 0 flaws (~~), 18 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 L. Xiao 4 Intended status: Standards Track C. Groves 5 Expires: April 30, 2015 Huawei 6 R. Hansen 7 Cisco Systems 8 October 27, 2014 10 CLUE Signaling 11 draft-ietf-clue-signaling-04 13 Abstract 15 This document specifies how CLUE-specific signaling such as the CLUE 16 protocol [I-D.ietf-clue-protocol] and the CLUE data channel 17 [I-D.ietf-clue-datachannel] are used with each other and with 18 existing signaling mechanisms such as SIP and SDP to produce a 19 telepresence call. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 30, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Media Feature Tag Definition . . . . . . . . . . . . . . . . 4 58 4. SDP Grouping Framework CLUE Extension Semantics . . . . . . . 4 59 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. The CLUE data channel and the CLUE grouping semantic . . 5 61 4.3. CLUE-controlled media and the CLUE grouping semantic . . 5 62 4.4. SDP semantics for CLUE-controlled media . . . . . . . . . 6 63 4.4.1. Signalling CLUE Encodings . . . . . . . . . . . . . . 6 64 4.4.1.1. Referencing encodings in the CLUE protocol . . . 7 65 4.4.1.2. Media line directionality . . . . . . . . . . . . 7 66 4.4.2. Negotiating receipt of CLUE capture encodings in SDP 8 67 4.5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 8 68 4.5.1. Generating the Initial Offer . . . . . . . . . . . . 8 69 4.5.2. Generating the Answer . . . . . . . . . . . . . . . . 9 70 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 9 71 4.5.2.2. Negotiating CLUE-controlled media . . . . . . . . 9 72 4.5.2.3. Negotiating non-CLUE controlled media . . . . . . 9 73 4.5.3. Processing the initial Offer/Answer negotiation . . . 10 74 4.5.3.1. Successful CLUE negotiation . . . . . . . . . . . 10 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 . . . . . . . . . . . . . 11 79 4.5.4.3. Disabling CLUE mid-call . . . . . . . . . . . . . 11 80 5. Interaction of CLUE protocol and SDP negotiations . . . . . . 11 81 5.1. Independence of SDP and CLUE negotiation . . . . . . . . 12 82 5.2. Constraints on sending media . . . . . . . . . . . . . . 13 83 5.3. Recommendations for operating with non-atomic operations 13 84 6. Interaction of CLUE protocol and RTP/RTCP CaptureID . . . . . 14 85 6.1. CaptureId reception during MCC redefinition . . . . . . . 14 86 7. Multiplexing of CLUE-controlled media using BUNDLE . . . . . 15 87 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7.2. Usage of BUNDLE with CLUE . . . . . . . . . . . . . . . . 15 89 7.2.1. Generating the Initial Offer . . . . . . . . . . . . 15 90 7.2.2. Bundle Address Synchronization . . . . . . . . . . . 16 91 7.2.3. 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 25 94 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 96 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 97 13. Security Considerations . . . . . . . . . . . . . . . . . . . 27 98 14. Change History . . . . . . . . . . . . . . . . . . . . . . . 27 99 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 15.1. Normative References . . . . . . . . . . . . . . . . . . 32 101 15.2. Informative References . . . . . . . . . . . . . . . . . 33 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 104 1. Introduction 106 To enable devices to participate in a telepresence call, selecting 107 the sources they wish to view, receiving those media sources and 108 displaying them in an optimal fashion, CLUE involves two principal 109 and inter-related protocol negotiations. SDP, conveyed via SIP, is 110 used to negotiate the specific media capabilities that can be 111 delivered to specific addresses on a device. Meanwhile, a CLUE 112 protocol [I-D.ietf-clue-protocol], transported via a CLUE data 113 channel [I-D.ietf-clue-datachannel], is used to negotiate the capture 114 sources available, their attributes and any constraints in their use, 115 along which which captures the far end provides a device wishes to 116 receive. 118 Beyond negotiating the CLUE channel, SDP is also used to negotiate 119 the details of supported media streams and the maximum capability of 120 each of those streams. As the CLUE Framework 121 [I-D.ietf-clue-framework] defines a manner in which the media 122 provider expresses their maximum encoding capabilities, SDP is also 123 used to express the encoding limits for each potential encoding. 125 Backwards-compatibility is an important consideration of the 126 document: it is vital that a CLUE-capable device contacting a device 127 that does not support CLUE is able to fall back to a fully functional 128 non-CLUE call. The document also defines how a non-CLUE call may be 129 upgraded to CLUE in mid-call, and similarly how CLUE functionality 130 can be removed mid-call to return to a standard non-CLUE call. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 This document draws liberally from the terminology defined in the 139 CLUE Framework [I-D.ietf-clue-framework]. 141 Other terms introduced here: 143 CLUE data channel: A reliable, bidirectional, transport mechanism 144 used to convey CLUE messages. See [I-D.ietf-clue-datachannel] for 145 more details. 147 CLUE-capable device: A device that supports the CLUE data channel 148 [I-D.ietf-clue-datachannel], the CLUE protocol 149 [I-D.ietf-clue-protocol] and the principles of CLUE negotiation, 150 and wishes to upgrade the call to CLUE-enabled status. 152 CLUE-enabled call: A call in which two CLUE-capable devices have 153 successfully negotiated support for a CLUE data channel in SDP. A 154 CLUE-enabled call is not necessarily immediately able to send 155 CLUE-controlled media; negotiation of the data channel and of the 156 CLUE protocol must complete first. Calls between two CLUE-capable 157 devices which have not yet successfully completed negotiation of 158 support for the CLUE data channel in SDP are not considered CLUE- 159 enabled. 161 Non-CLUE device: A device that supports standard SIP and SDP, but 162 either does not support CLUE, or that does but does not currently 163 wish to invoke CLUE capabilities. 165 CLUE-controlled media: A media "m" line that is under CLUE control; 166 the capture source that provides the media on this "m" line is 167 negotiated in CLUE. See Section 4 for details of how this control 168 is signalled in SDP. There is a corresponding "non-CLUE- 169 controlled" media term. 171 3. Media Feature Tag Definition 173 The "sip.clue" media feature tag indicates support for CLUE. A CLUE- 174 capable device SHOULD include this media feature tag in its REGISTER 175 requests and OPTION responses. It SHOULD also include the media 176 feature tag in INVITE and UPDATE [RFC3311] requests and responses. 178 Presence of the media feature tag in the contact field of a request 179 or response can be used to determine that the far end supports CLUE. 181 4. SDP Grouping Framework CLUE Extension Semantics 183 4.1. General 185 This section defines a new SDP Grouping Framework extension, CLUE. 187 The CLUE extension can be indicated using an SDP session-level 188 'group' attribute. Each SDP media "m" line that is included in this 189 group, using SDP media-level mid attributes, is CLUE-controlled, by a 190 CLUE data channel also included in this CLUE group. 192 Currently only support for a single CLUE group is specified. A 193 device MUST NOT include more than one CLUE group in its SDP unless it 194 is following a specification that defines how multiple CLUE channels 195 are defined, and is either able to determine that the other side of 196 the SDP exchange supports multiple CLUE channels, or is able to fail 197 gracefully in the event it does not. 199 4.2. The CLUE data channel and the CLUE grouping semantic 201 The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional 202 SCTP over DTLS channel used for the transport of CLUE messages. This 203 channel must be established before CLUE protocol messages can be 204 exchanged and CLUE-controlled media can be sent. 206 The data channel is a generic transport that is not specific to CLUE 207 - if a device wishes to use the CLUE protocol on the data channel it 208 MUST include a CLUE group in the SDP and include the "mid" of the "m" 209 line for the data channel in that group. A CLUE group MUST include 210 the "mid" of the "m" line for one (and only one) data channel, and 211 the "mid" of the "m" line of a data channel "mid" MUST NOT be 212 included in more than one CLUE group. 214 Presence of the data channel in a CLUE group in an SDP offer or 215 answer also serves, along with the "sip.clue" media feature tag, as 216 an indication that the device supports CLUE and wishes to upgrade the 217 call to include CLUE-controlled media. A CLUE-capable device SHOULD 218 include a data channel "m" line in offers and, when allowed by 219 [RFC3264], answers. 221 4.3. CLUE-controlled media and the CLUE grouping semantic 223 CLUE-controlled media lines in an SDP are "m" lines in which the 224 content of the media streams to be sent is negotiated via the CLUE 225 protocol [I-D.ietf-clue-protocol]. For an "m" line to be CLUE- 226 controlled, its "mid" value MUST be included in a CLUE group. CLUE- 227 controlled media line "mid"s MUST NOT be included in more than one 228 CLUE group. 230 CLUE-controlled media is controlled by the CLUE protocol as 231 negotiated on the CLUE data channel with an "mid" included in the 232 CLUE group. If negotiation of the data channel in SDP failed due to 233 lack of CLUE support by the remote device or for any other reason the 234 other "m" lines in the group are still considered CLUE-controlled and 235 under all the restrictions of CLUE-controlled media specified in this 236 document. 238 "m" lines not specified as under CLUE control follow normal rules for 239 media streams negotiated in SDP as defined in documents such as 240 [RFC3264]. 242 If an SDP offer includes a CLUE-controlled "m" line and the recipient 243 accepts the "m" line but does not include the "mid" in the CLUE group 244 then for the sender of the SDP offer the sending of media on that "m" 245 line is still CLUE- controlled and under all the restrictions of 246 CLUE-controlled media specified in this document, but recipient of 247 media is not CLUE- controlled and they MUST be ready to receive media 248 as defined in documents such as [RFC3264] 250 4.4. SDP semantics for CLUE-controlled media 252 4.4.1. Signalling CLUE Encodings 254 The CLUE Framework [I-D.ietf-clue-framework] defines the concept of 255 "encodings", which represent the sender's encode ability. Each 256 encoding the media provider wishes to signal is signalled via an "m" 257 line of the appropriate media type, which MUST be marked as sendonly 258 with the "a=sendonly" attribute or as inactive with the "a=inactive" 259 attribute. 261 The encoder limits of active (eg, "a=sendonly") encodings can then be 262 expressed using existing SDP syntax. For instance, for H.264 see 263 Table 6 in [RFC6184] for a list of valid parameters for representing 264 encoder sender stream limits. 266 These encodings are CLUE-controlled and hence MUST include an "mid" 267 in a CLUE group as defined above. 269 As well as the normal restrictions defined in [RFC3264] the stream 270 MUST be treated as if the "m" line direction attribute had been set 271 to "a=inactive" until the media provider has received a valid CLUE 272 CONFIGURE message specifying the capture to be used for this stream. 273 This means that media packets MUST NOT be sent until configuration is 274 complete, while non-media packets such as STUN and DTLS MUST be sent 275 as normal if negotiated. 277 Every "m" line representing a CLUE encoding MUST contain a "label" 278 attribute as defined in [RFC4574]. This label is used to identify 279 the encoding by the sender in CLUE ADVERTISEMENT messages and by the 280 receiver in CLUE CONFIGURE messages. Each label used for a CLUE- 281 controlled "m" line MUST be different from the label on all other "m" 282 lines in the same CLUE group in the SDP message. 284 4.4.1.1. Referencing encodings in the CLUE protocol 286 CLUE encodings are defined in SDP, but can be referenced from CLUE 287 protocol messages - this is how the protocol defines which encodings 288 are part of an encoding group (in ADVERTISEMENT messages) and which 289 encoding with which to encode a specific capture (in CONFIGURE 290 messages). The labels on the CLUE-controlled "m" lines are the 291 references that are used in the CLUE protocol. 293 Each element in a CLUE ADVERTISEMENT message SHOULD represent 294 an encoding defined in SDP; the specific encoding referenced is a 295 CLUE-controlled "m" line in the most recent SDP sent by the sender of 296 the ADVERTISMENT message with a label value corresponding to the text 297 content of the . 299 Similarly, each element in a CLUE CONFIGURE message SHOULD 300 represent an encoding defined in SDP; the specific encoding 301 referenced is a CLUE-controlled "m" line in the most recent SDP 302 received by the sender of the CONFIGURE message with a label value 303 corresponding to the text content of the . 305 Note that the non-atomic nature of SDP/CLUE protocol interaction may 306 mean that there are temporary periods where an in a CLUE 307 message does not reference an SDP "m" line, or where an encoding 308 represented in SDP is not referenced in a CLUE protocol message. See 309 Section 5 for specifics. 311 4.4.1.2. Media line directionality 313 Presently, this specification mandates that CLUE-controlled "m"-lines 314 must be unidirectional. This is because setting "m"-lines to 315 "a=sendonly" allows the encoder limits to be expressed, whereas in 316 other cases codec attributes express the receive capabilities of a 317 media line. 319 It is possible that in future versions of this draft or its successor 320 this restriction will be relaxed. If a device does not feel there is 321 a benefit to expressing encode limitations, or if there are no 322 meaningful codec-specific limitations to express (such as with many 323 audio codecs) there are benefits to allowing bidirectional "m"-lines. 324 With bidirectional media lines recipients do not always need to 325 create a new offer to add their own "m"-lines to express their send 326 capabilities; if they can produce an equal or lesser number of 327 streams to send then they may not need additional "m"-lines. 329 However, at present the need to express encode limitations and the 330 wish to simplify the offer/answer procedure means that for the time 331 being only unidirectional media lines are allowed for CLUE-controlled 332 media. The highly asymmetric nature of CLUE means that the 333 probability of the recipient of the initial offer needing to make 334 their own offer to add additional "m"-lines is significantly higher 335 than it is for most other SIP call scenarios, in which there is a 336 tendancy for both sides to have similar numbers of potential audio 337 and video streams they can send. 339 4.4.2. Negotiating receipt of CLUE capture encodings in SDP 341 A receiver who wishes to receive a CLUE stream via a specific 342 encoding requires an "a=recvonly" "m" line that matches the 343 "a=sendonly" encoding. 345 These "m" lines are CLUE-controlled and hence MUST include their 346 "mid" in the CLUE group corresponding to the CLUE group of encoding 347 they wish to receive. 349 4.5. SDP Offer/Answer Procedures 351 4.5.1. Generating the Initial Offer 353 A CLUE-capable device sending an initial SDP offer of a SIP session 354 SHOULD include an "m" line for the data channel to convey the CLUE 355 protocol, along with a CLUE group containing the "mid" of the data 356 channel "m" line. 358 For interoperability with non-CLUE devices a CLUE-capable device 359 sending an initial SDP offer SHOULD NOT include any "m" line for 360 CLUE-controlled media beyond the "m" line for the CLUE data channel, 361 and SHOULD include at least one non-CLUE-controlled media "m" line. 363 If the device has evidence that the receiver is also CLUE-capable, 364 for instance due to receiving an initial INVITE with no SDP but 365 including a "sip.clue" media feature tag, the above recommendation is 366 waived, and the initial offer MAY contain "m" lines for CLUE- 367 controlled media. 369 With the same interoperability recommendations as for encodings, the 370 sender of the initial SDP offer MAY also include "a=recvonly" media 371 lines to preallocate "m" lines to receive media. Alternatively, it 372 MAY wait until CLUE protocol negotiation has completed before 373 including these lines in a new offer/answer exchange - see Section 5 374 for recommendations. 376 4.5.2. Generating the Answer 378 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 380 If the recipient is CLUE-capable and the initial offer contains both 381 an "m" line for a data channel and a CLUE group containing the "mid" 382 for that "m" line, they SHOULD negotiate data channel support for an 383 "m" line, and include the "mid" of that "m" line in a corresponding 384 CLUE group. 386 A CLUE-capable recipient that receives an "m" line for a data channel 387 but no corresponding CLUE group containing the "mid" of that "m" line 388 SHOULD include a corresponding data channel "m" line if there are any 389 other non-CLUE protocols it can convey over that channel, otherwise 390 it SHOULD NOT negotiate the data channel. 392 4.5.2.2. Negotiating CLUE-controlled media 394 If the initial offer contained "a=recvonly" CLUE-controlled media 395 lines the recipient SHOULD include corresponding "a=sendonly" CLUE- 396 controlled media lines, up to the maximum number of encodings it 397 wishes to advertise. As CLUE-controlled media, the "mid" of these 398 "m" lines must be included in the corresponding CLUE group. 400 If the initial offer contained "a=sendonly" CLUE-controlled media 401 lines the recipient MAY include corresponding "a=recvonly" CLUE- 402 controlled media lines, up to the maximum number of capture encodings 403 it wishes to receive. Alternatively, it MAY wait until CLUE protocol 404 negotiation has completed before including these lines in a new 405 offer/answer exchange - see Section 5 for recommendations. 407 4.5.2.3. Negotiating non-CLUE controlled media 409 A CLUE-controlled device implementation may prefer to render initial, 410 single-stream audio and/or video for the user as rapidly as possible, 411 transitioning to CLUE-controlled media once that has been negotiated. 412 Alternatively, an implementation may wish to suppress initial media, 413 only providing media once the final, CLUE-controlled streams have 414 been negotiated. 416 The receiver of the initial offer, if making the call CLUE-enabled 417 with their SDP answer, can make their preference clear by their 418 action in accepting or rejecting non-CLUE-controlled media lines. 419 Rejecting these "m" lines will ensure that no non-CLUE-controlled 420 media flows before the CLUe-controlled media is negotiated. In 421 contrast, accepting one or more non-CLUE-controlled "m" lines in this 422 initial answer will enable initial media to flow. 424 If the answerer chooses to send initial non-CLUE-controlled media in 425 a CLUE-enabled call, Section 4.5.4.1 addresses the need to disable it 426 once CLUE-controlled media is fully negotiated. 428 4.5.3. Processing the initial Offer/Answer negotiation 430 In the event that both offer and answer include a data channel "m" 431 line with a mid value included in corresponding CLUE groups CLUE has 432 been successfully negotiated and the call is now CLUE-enabled, 433 otherwise the call is not CLUE-enabled. 435 4.5.3.1. Successful CLUE negotiation 437 In the event of successful CLUE-enablement of the call, devices MUST 438 now begin negotiation of the CLUE channel, see 439 [I-D.ietf-clue-datachannel] for negotiation details. If negotiation 440 is successful, sending of CLUE protocol [I-D.ietf-clue-protocol] 441 messages can begin. 443 A CLUE-capable device MAY choose not to send media on the non-CLUE- 444 controlled channels during the period in which control of the CLUE- 445 controlled media lines is being negotiated. However, a CLUE-capable 446 device MUST still be prepared to receive media on non-CLUE-controlled 447 media lines that have been successfully negotiated as defined in 448 [RFC3264]. 450 If either side of the call wishes to add additional CLUE-controlled 451 "m" line to send or receive CLUE-controlled media they MAY now send a 452 SIP request with a new SDP offer. Note that if BUNDLE has been 453 successfully negotiated and a Bundle Address Synchronization offer is 454 required, the device to receive that offer SHOULD NOT generate a new 455 SDP offer until it has received that BAS offer. 457 4.5.3.2. CLUE negotiation failure 459 In the event that the negotiation of CLUE fails and the call is not 460 CLUE-enabled in the initial offer/answer then CLUE is not in use in 461 the call, and the CLUE-capable devices MUST either revert to non-CLUE 462 behaviour or terminate the call. 464 4.5.4. Modifying the session 466 4.5.4.1. Adding and removing CLUE-controlled media 468 Subsequent offer/answer exchanges MAY add additional "m" lines for 469 CLUE-controlled media; in most cases at least one additional exchange 470 will be required before both sides have added all the encodings and 471 ability to receive encodings that they desire. Devices MAY delay 472 adding "a=recvonly" CLUE-controlled m-lines until after CLUE protocol 473 negotiation completes - see Section 5 for recommendations. 475 Subsequent offer/answer exchanges MAY also deactive "m" lines for 476 CLUE-controlled media. 478 Once CLUE media has been successfully negotiated devices SHOULD 479 ensure that non-CLUE-controlled media is deactived in cases where it 480 corresponds to the media type of CLUE-controlled media that has been 481 successfully negotiated. This deactivate may require an additional 482 SDP exchange, or may be incorporated into one that is part of the 483 CLUE negotiation. 485 4.5.4.2. Enabling CLUE mid-call 487 A CLUE-capable device that receives an initial SDP offer from a non- 488 CLUE device SHOULD include a new data channel "m" line and 489 corresponding CLUE group in any subsequent offers it sends, to 490 indicate that it is CLUE-capable. 492 If, in an ongoing non-CLUE call, one or both sides of the call add 493 the CLUE data channel "m" line to their SDP and places the "mid" for 494 that channel in corresponding CLUE groups then the call is now CLUE- 495 enabled; negotiation of the data channel and subsequently the CLUE 496 protocol begin. 498 4.5.4.3. Disabling CLUE mid-call 500 If, in an ongoing CLUE-enabled call, an SDP offer-answer negotiation 501 completes in a fashion in which either the CLUE data channel was not 502 successfully negotiated or one side did not include the data channel 503 in a matching CLUE group then CLUE for this channel is disabled. In 504 the event that this occurs, CLUE is no longer enabled and sending of 505 all CLUE-controlled media associated with the corresponding CLUE 506 group MUST stop. If the SCTP channel is still present but not 507 included in the CLUE group semantic the CLUE protocol MUST be closed. 509 Note that this is distinct to cases where the CLUE data channel fails 510 or an error occurs on the CLUE protocol; see [I-D.ietf-clue-protocol] 511 for details of media and state preservation in this circumstance. 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 intermediary 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 results 537 of or the state of the most recent SDP negotiation (unless the SDP 538 negotiation has removed the CLUE channel). 540 The primary implication of this is that a device may receive an SDP 541 with a CLUE encoding it does not yet have capture information for, or 542 receive a CLUE CONFIGURE message specifying a capture encoding for 543 which the far end has not negotiated a media stream in SDP. 545 CLUE messages contain an which is used to identify a specific 546 encoding or captureEncoding in SDP. The non-atomic nature of CLUE 547 negotiation means that a sender may wish to send a new ADVERTISEMENT 548 before the corresponding SDP message. As such the sender of the CLUE 549 message MAY include an which does not currently match a CLUE- 550 controlled "m" line label in SDP; A CLUE-capable implementation MUST 551 NOT reject a CLUE protocol messages solely because it contains 552 elements that do not match an id in SDP. 554 The current state of the CLUE participant or CLUE media provider/ 555 consumer state machines do not affect compliance with any of the 556 normative language of [RFC3264]. That is, they MUST NOT delay an 557 ongoing SDP exchange as part of a SIP server or client transaction; 558 an implementation MUST NOT delay an SDP exchange while waiting for 559 CLUE negotiation to complete or for a CONFIGURE message to arrive. 561 Similarly, a device in a CLUE-enabled call MUST NOT delay any 562 mandatory state transitions in the CLUE participant or media 563 provider/consumer state machines due to the presence or absence of an 564 ongoing SDP exchange. 566 A device with the CLUE participant state machine in the ACTIVE state 567 MAY choose not to move from CONF COMPLETED to PREPARING ADV (media 568 provider state machine) or from READY TO CONF to TRYING (media 569 consumer state machine) based on the SDP state. See 570 [I-D.ietf-clue-protocol] for CLUE state machine specifics. 571 Similarly, a device MAY choose to delay initiating a new SDP exchange 572 based on the state of their CLUE state machines. 574 5.2. Constraints on sending media 576 While SDP and CLUE message states do not impose constraints on each 577 other, both impose constraints on the sending of media - CLUE- 578 controlled media MUST NOT be sent unless it has been negotiated in 579 both CLUE and SDP: an implementation MUST NOT send a specific CLUE 580 capture encoding unless its most recent SDP exchange contains an 581 active media channel for that encoding AND the far end has sent a 582 CLUE CONFIGURE message specifying a valid capture for that encoding. 584 5.3. Recommendations for operating with non-atomic operations 586 CLUE-capable devices MUST be able to handle states in which CLUE 587 messages make reference to EncodingIDs that do not match the most 588 recently received SDP, irrespective of the order in which SDP and 589 CLUE messages are received. While these mis-matches will usually be 590 transitory a device MUST be able to cope with such mismatches 591 remaining indefinitely. However, this document makes some 592 recommendations on message ordering for these non-atomic transitions. 594 CLUE-capable devices SHOULD ensure that any inconsistencies between 595 SDP and CLUE signalling are temporary by sending updated SDP or CLUE 596 messages as soon as the relevant state machines and other constraints 597 permit. 599 Generally, implementations that receive messages for which they have 600 incomplete information SHOULD wait until they have the corresponding 601 information they lack before sending messages to make changes related 602 to that information. For instance, an implementation that receives a 603 new SDP offer with three new "a=sendonly" CLUE "m" lines that has not 604 received the corresponding CLUE ADVERTISEMENT providing the capture 605 information for those streams SHOULD NOT include corresponding 606 "a=recvonly" lines in its answer, but instead should make a new SDP 607 offer when and if a new ADVERTISEMENT arrives with captures relevant 608 to those encodings. 610 Because of the constraints of offer/answer and because new SDP 611 negotiations are generally more 'costly' than sending a new CLUE 612 message, implementations needing to make changes to both channels 613 SHOULD prioritize sending the updated CLUE message over sending the 614 new SDP message. The aim is for the recipient to receive the CLUE 615 changes before the SDP changes, allowing the recipient to send their 616 SDP answers without incomplete information, reducing the number of 617 new SDP offers required. 619 6. Interaction of CLUE protocol and RTP/RTCP CaptureID 621 The CLUE Framework [I-D.ietf-clue-framework] allows for Multiple 622 Content Captures (MCCs): captures which contain multiple source 623 captures, whether composited into a single stream or switched based 624 on some metric. 626 The captures that constitute these MCCs may or may not be defined in 627 the ADVERTISEMENT message. If they are defined and the MCC is 628 providing them in a switched format the recipient may wish to 629 determine which originating source capture is currently being 630 provided, so that they can apply geometric corrections based on that 631 capture's geometry, or take some other action based on the original 632 capture information. 634 To do this, the RTP mapping draft [I-D.ietf-clue-rtp-mapping] allows 635 for the CaptureId of the originating capture to be conveyed via RTP 636 or RTCP. A media provider sending switched media from an MCC with 637 defined originating sources MUST send the CaptureId in both RTP and 638 RTCP, as described in [I-D.ietf-clue-rtp-mapping]. 640 6.1. CaptureId reception during MCC redefinition 642 Because the RTP/RTCP CaptureId is delivered via a different channel 643 to the ADVERTISEMENT in which in the contents of the MCC are defined 644 there is an intrinsic race condition in cases in which the contents 645 of an MCC are redefined. 647 When a media provider redefines an MCC which involves CaptureIds, the 648 reception of the relevant CaptureIds by the recipient will either 649 lead or lag reception and processing of the new ADVERTISEMENT by the 650 recipient. As such, a media recipient MUST not be disrupted by any 651 of the following in any CLUE- controlled media stream it is 652 receiving, whether that stream is for a static capture or for an MCC 653 (as any static capture may be redefined to an MCC in a later 654 ADVERTISEMENT): 656 o Receiving RTP or RTCP containing a CaptureId when the most 657 recently processed ADVERTISEMENT means that none are expected. 659 o Receiving RTP or RTCP without CaptureIds when the most recently 660 processed ADVERTISEMENT means that media CaptureIds are expected. 662 o Receiving a CaptureId in RTP or RTCP for a capture defined in the 663 most recently processed ADVERTISEMENT, but which the same 664 ADVERTISEMENT does not include in the MCC. 666 o Receiving a CaptureId in RTP or RTCP for a capture not defined in 667 the most recently processed ADVERTISEMENT. 669 7. Multiplexing of CLUE-controlled media using BUNDLE 671 7.1. Overview 673 A CLUE call may involve sending and/or receiving significant numbers 674 of media streams. Conventionally, media streams are sent and 675 received on unique ports. However, each seperate port used for this 676 purpose may impose costs that a device wishes to avoid, such as the 677 need to open that port on firewalls and NATs, the need to collect ICE 678 candidates [RFC5245], etc. 680 The BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] extension can be 681 used to negotiate the multiplexing of multiple media lines onto a 682 single 5-tuple for sending and receiving media, allowing devices in 683 calls to another BUNDLE-supporting device to potentially avoid some 684 of the above costs. 686 While CLUE-capable devices MAY support the BUNDLE extension for this 687 purpose supporting the extension is not mandatory for a device to be 688 CLUE-compliant. 690 7.2. Usage of BUNDLE with CLUE 692 This specification imposes no additional requirements or restrictions 693 on the usage of BUNDLE when used with CLUE. There is no restriction 694 on combining CLUE-controlled media lines and non-CLUE-controlled 695 media lines in the same BUNDLE group or in multiple such groups. 696 However, there are several steps an implementation may wish to 697 ameliorate the cost and time requirements of extra SDP offer/answer 698 exchanges between CLUE and BUNDLE. 700 7.2.1. Generating the Initial Offer 702 BUNDLE mandates that the initial SDP offer MUST use a unique address 703 for each m-line with a non-zero port. Because CLUE implementations 704 generarlly will not include CLUE-controlled media lines with the 705 exception of the data channel CLUE devices that support large numbers 706 of streams can avoid ever having to open large numbers of ports if 707 they successfully negotiate BUNDLE. 709 7.2.2. Bundle Address Synchronization 711 When using BUNDLE the initial offerer may be mandated to send a 712 Bundle Address Synchronisation offer. If the initial offerer also 713 followed the recommendation of not including CLUE-controlled media 714 lines in their offer, they MAY choose to include them in this 715 subsequent offer. In this circumstance the BUNDLE specification 716 recommends that the offerer does not "modify SDP parameters that 717 could get the answerer to reject the BAS offer". Including new CLUE- 718 controlled media lines using codecs and other attributes used in 719 existing media lines should not increase the chance of the answerer 720 rejecting the BAS offer; implementations should consider carefully 721 before including new codecs or other new SDP attributes in these 722 CLUE-controlled media lines. 724 7.2.3. Multiplexing of the data channel and RTP media 726 BUNDLE-supporting CLUE-capable devices MAY include the data channel 727 in the same BUNDLE group as RTP media. In this case the device MUST 728 be able to demultiplex the various transports - see section 7.2 of 729 the BUNDLE draft [I-D.ietf-mmusic-sdp-bundle-negotiation]. If the 730 BUNDLE group includes other protocols than the data channel 731 transported via DTLS the device MUST also be able to differentiate 732 the various protocols. 734 8. Example: A call between two CLUE-capable endpoints 736 This example illustrates a call between two CLUE-capable endpoints. 737 Alice, initiating the call, is a system with three cameras and three 738 screens. Bob, receiving the call, is a system with two cameras and 739 two screens. A call-flow diagram is presented, followed by an 740 summary of each message. 742 To manage the size of this section SDP snippet only illustrate video 743 'm' lines. ACKs are not discussed. Note that BUNDLE is not in use. 745 +----------+ +-----------+ 746 | Alice | | Bob | 747 | | | | 748 +----+-----+ +-----+-----+ 749 | | 750 | | 751 | SIP INVITE 1 | 752 |--------------------------------->| 753 | | 754 | | 755 | SIP 200 OK 1 | 756 |<---------------------------------| 757 | | 758 | | 759 | SIP ACK 1 | 760 |--------------------------------->| 761 | | 762 | | 763 | | 764 |<########### MEDIA 1 ############>| 765 | 1 video A->B, 1 video B->A | 766 |<################################>| 767 | | 768 | | 769 | | 770 |<================================>| 771 | CLUE CTRL CHANNEL ESTABLISHED | 772 |<================================>| 773 | | 774 | | 775 | CLUE ADVERTISEMENT 1 | 776 |*********************************>| 777 | | 778 | | 779 | CLUE ADVERTISEMENT 2 | 780 |<*********************************| 781 | | 782 | | 783 | SIP INVITE 2 (+3 sendonly) | 784 |--------------------------------->| 785 | | 786 | | 787 | CLUE CONFIGURE 1 | 788 |<*********************************| 789 | | 790 | | 791 | CLUE RESPONSE 1 | 792 |*********************************>| 793 | | 794 | | 795 | SIP 200 OK 2 (+2 recvonly) | 796 |<---------------------------------| 797 | | 798 | | 799 | SIP ACK 2 | 800 |--------------------------------->| 801 | | 802 | | 803 | | 804 |<########### MEDIA 2 ############>| 805 | 2 video A->B, 1 video B->A | 806 |<################################>| 807 | | 808 | | 809 | SIP INVITE 3 (+2 sendonly) | 810 |<---------------------------------| 811 | | 812 | | 813 | CLUE CONFIGURE 2 | 814 |*********************************>| 815 | | 816 | | 817 | CLUE RESPONSE 2 | 818 |<*********************************| 819 | | 820 | | 821 | SIP 200 OK 3 (+2 recvonly) | 822 |--------------------------------->| 823 | | 824 | | 825 | | 826 | SIP ACK 3 | 827 |<---------------------------------| 828 | | 829 | | 830 | | 831 |<########### MEDIA 3 ############>| 832 | 2 video A->B, 2 video B->A | 833 |<################################>| 834 | | 835 | | 836 | | 837 v v 839 In INVITE 1, Alice sends Bob a SIP INVITE including in the SDP body 840 the basilar audio and video capabilities and the information needed 841 for opening a control channel to be used for CLUE protocol messages 842 exchange, according to what is envisioned in the COMEDIA approach for 843 DTLS/SCTP channel [I-D.ietf-mmusic-sctp-sdp]. A snippet of the SDP 844 showing the grouping attribute and the video m-line are shown below. 845 Alice has included a "CLUE" group, and included the mid corresponding 846 to a data channel in the group (3). Note that Alice has chosen not 847 to include any CLUE-controlled media in the initial offer - the mid 848 value of the video line is not included in the "CLUE" group. 850 ... 851 a=group:CLUE 3 852 ... 853 m=video 6002 RTP/AVP 96 854 a=rtpmap:96 H264/90000 855 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 856 a=sendrecv 857 a=mid:2 858 ... 859 m=application 6100 DTLS/SCTP webrtc-datachannel 860 a=fmtp:webrtc-datachannel max-message-size=100000 861 a=sctp-port 5000 862 a=mid:3 864 Bob responds with a similar SDP (200 OK 1), which also has a "CLUE" 865 group including the mid value of a data channel; due to their 866 similiarity no SDP snippet is shown here. Bob wishes to receive 867 initial media, and so includes corresponding non-CLUE-controlled 868 audio and video lines. Alice and Bob are each now able to send a 869 single audio and video stream. This is illustrated as MEDIA 1. 871 With the successful initial O/A Alice and Bob are also free to 872 negotiate the CLUE channel. Once this is successfully established 873 CLUE negotiation can begin. This is illustrated as CLUE CTRL CHANNEL 874 ESTABLISHED. 876 Alice now sends her CLUE Advertisement (ADVERTISEMENT 1). She 877 advertises three static captures representing her three cameras. She 878 also includes switched captures suitable for two- and one-screen 879 systems. All of these captures are in a single capture scene, with 880 suitable capture scene entries to tell Bob that he should either 881 subscribe to the three static captures, the two switched capture view 882 or the one switched capture view. Alice has no simultaneity 883 constraints, so includes all six captures in one simultaneous set. 884 Finally, Alice includes an encoding group with three encoding IDs: 885 "enc1", "enc2" and "enc3". These encoding ids aren't currently 886 valid, but will match the next SDP offer she sends. 888 Bob received ADVERTISEMENT 1 but does not yet send a Configure 889 message, because he has not yet received Alice's encoding 890 information, so as yet he does not know if she will have sufficient 891 resources to send him the two streams he ideally wants at a quality 892 he is happy with. 894 Bob also sends his CLUE ADVERTISEMENT (ADVERTISEMENT 2). He 895 advertises two static captures representing his cameras. He also 896 includes a single composed capture for single-screen systems, in 897 which he will composite the two camera views into a single video 898 stream. All three captures are in a single capture scene, with 899 suitable capture scene entries to tell Alice that she should either 900 subscribe to the two static captures, or the single composed capture. 901 Bob also has no simultaneity constraints, so includes all three 902 captures in one simultaneous set. Bob also includes a single 903 encoding group with two encoding IDs: "foo" and "bar". 905 Similarly, Alices receives ADVERTISEMENT 2 but does not yet send a 906 CONFIGURE message, because she has not yet received Bob's encoding 907 information. 909 Alice now sends INVITE 2. She maintains the sendrecv audio, video 910 and CLUE m-lines, and she adds three new sendonly m-lines to 911 represents the maximum three encodings she can send. Each of these 912 m-lines has a label corresponding to one of the encoding ids from 913 ADVERTISEMENT 1. Each also has its mid added to the grouping 914 attribute to show they are controlled by the CLUE channel. A snippet 915 of the SDP showing the grouping attribute, data channel and the video 916 m-lines are shown below: 918 ... 919 a=group:CLUE 3 4 5 6 920 ... 921 m=video 6002 RTP/AVP 96 922 a=rtpmap:96 H264/90000 923 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 924 a=sendrecv 925 a=mid:2 926 ... 927 m=application 6100 DTLS/SCTP webrtc-datachannel 928 a=fmtp:webrtc-datachannel max-message-size=100000 929 a=sctp-port 5000 930 a=mid:3 931 ... 932 m=video 6004 RTP/AVP 96 933 a=rtpmap:96 H264/90000 934 a=fmtp:96 profile-level-id=42e016 935 a=sendonly 936 a=mid:4 937 a=label:enc1 938 m=video 6006 RTP/AVP 96 939 a=rtpmap:96 H264/90000 940 a=fmtp:96 profile-level-id=42e016 941 a=sendonly 942 a=mid:5 943 a=label:enc2 944 m=video 6008 RTP/AVP 96 945 a=rtpmap:96 H264/90000 946 a=fmtp:96 profile-level-id=42e016 947 a=sendonly 948 a=mid:6 949 a=label:enc3 951 Bob now has all the information he needs to decide which streams to 952 configure. As such he now sends CONFIGURE 1. This requests the pair 953 of switched captures that represent Alice's scene, and he configures 954 them with encoder ids "enc1" and "enc2". This also serves as an ack 955 for Alice's ADVERTISMENT 1. 957 Alice receives Bob's message CONFIGURE 1 and sends RESPONSE 1 to ack 958 its receptions. She does not yet send the capture encodings 959 specified, because at this stage Bob hasn't negotiated the ability to 960 receive these streams in SDP. 962 Bob now sends his SDP answer as part of 200 OK 2. Alongside his 963 original audio, video and CLUE m-lines he includes two active 964 recvonly m-lines and a zeroed m-line for the third. He adds their 965 mid values to the grouping attribute to show they are controlled by 966 the CLUE channel. A snippet of the SDP showing the grouping 967 attribute and the video m-lines are shown below (mid 100 represents 968 the CLUE channel, not shown): 970 ... 971 a=group:CLUE 11 12 100 972 ... 973 m=video 58722 RTP/AVP 96 974 a=rtpmap:96 H264/90000 975 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 976 a=sendrecv 977 a=mid:10 978 ... 979 m=video 58724 RTP/AVP 96 980 a=rtpmap:96 H264/90000 981 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 982 a=recvonly 983 a=mid:11 984 m=video 58726 RTP/AVP 96 985 a=rtpmap:96 H264/90000 986 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 987 a=recvonly 988 a=mid:12 989 m=video 0 RTP/AVP 96 991 On receiving 200 OK 2 from Bob Alice is now able to send the two 992 streams of video Bob requested - this is illustrated as MEDIA 2. 994 The constraints of offer/answer meant that Bob could not include his 995 encoder information as new m-lines in 200 OK 2. As such Bob now 996 sends INVITE 3 to generate a new offer. Along with all the streams 997 from 200 OK 2 Bob also includes two new sendonly streams. Each 998 stream has a label corresponding to the encoding ids in his 999 ADVERTISEMENT 2 message. He also adds their mid values to the 1000 grouping attribute to show they are controlled by the CLUE channel. 1001 A snippet of the SDP showing the grouping attribute and the video 1002 m-lines are shown below (mid 100 represents the CLUE channel, not 1003 shown): 1005 ... 1006 a=group:CLUE 11 12 13 14 100 1007 ... 1008 m=video 58722 RTP/AVP 96 1009 a=rtpmap:96 H264/90000 1010 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1011 a=sendrecv 1012 a=mid:10 1013 ... 1014 m=video 58724 RTP/AVP 96 1015 a=rtpmap:96 H264/90000 1016 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1017 a=recvonly 1018 a=mid:11 1019 m=video 58726 RTP/AVP 96 1020 a=rtpmap:96 H264/90000 1021 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1022 a=recvonly 1023 a=mid:12 1024 m=video 0 RTP/AVP 96 1025 m=video 58728 RTP/AVP 96 1026 a=rtpmap:96 H264/90000 1027 a=fmtp:96 profile-level-id=42e016 1028 a=sendonly 1029 a=label:foo 1030 a=mid:13 1031 m=video 58730 RTP/AVP 96 1032 a=rtpmap:96 H264/90000 1033 a=fmtp:96 profile-level-id=42e016 1034 a=sendonly 1035 a=label:bar 1036 a=mid:14 1038 Having received this Alice now has all the information she needs to 1039 send CONFIGURE 2. She requests the two static captures from Bob, to 1040 be sent on encodings "foo" and "bar". 1042 Bob receives Alice's message CONFIGURE 2 and sends RESPONSE 2 to ack 1043 its receptions. Bob does not yet send the capture encodings 1044 specified, because Alice hasn't yet negotiated the ability to receive 1045 these streams in SDP. 1047 Alice now sends 200 OK 3, matching two recvonly m-lines to Bob's new 1048 sendonly lines. She includes their mid values in the grouping 1049 attribute to show they are controlled by the CLUE channel. Alice 1050 also now deactivates the initial non-CLUE-controlled media, as 1051 bidirectional CLUE-controlled media is now available. A snippet of 1052 the SDP showing the grouping attribute and the video m-lines are 1053 shown below (mid 3 represents the data channel, not shown): 1055 ... 1056 a=group:CLUE 3 4 5 7 8 1057 ... 1058 m=video 0 RTP/AVP 96 1059 a=mid:2 1060 ... 1061 m=video 6004 RTP/AVP 96 1062 a=rtpmap:96 H264/90000 1063 a=fmtp:96 profile-level-id=42e016 1064 a=sendonly 1065 a=mid:4 1066 a=label:enc1 1067 m=video 6006 RTP/AVP 96 1068 a=rtpmap:96 H264/90000 1069 a=fmtp:96 profile-level-id=42e016 1070 a=sendonly 1071 a=mid:5 1072 a=label:enc2 1073 m=video 0 RTP/AVP 96 1074 m=video 6010 RTP/AVP 96 1075 a=rtpmap:96 H264/90000 1076 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1077 a=recvonly 1078 a=mid:7 1079 m=video 6012 RTP/AVP 96 1080 a=rtpmap:96 H264/90000 1081 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1082 a=recvonly 1083 a=mid:8 1085 Finally, on receiving 200 OK 3 Bob is now able to send the two 1086 streams of video Alice requested - this is illustrated as MEDIA 3. 1088 Both sides of the call are now sending multiple video streams with 1089 their sources defined via CLUE negotiation. As the call progresses 1090 either side can send new ADVERTISEMENT or CONFIGURE or new SDP 1091 negotiation to add, remove or change what they have available or want 1092 to receive. 1094 9. Example: A call between a CLUE-capable and non-CLUE endpoint 1096 In this brief example Alice is a CLUE-capable endpoint making a call 1097 to Bob, who is not CLUE-capable ((i.e. is not able to use the CLUE 1098 protocol). 1100 +----------+ +-----------+ 1101 | EP1 | | EP2 | 1102 | | | | 1103 +----+-----+ +-----+-----+ 1104 | | 1105 | | 1106 | SIP INVITE 1 | 1107 |--------------------------------->| 1108 | | 1109 | | 1110 | 200 0K 1 | 1111 |<---------------------------------| 1112 | | 1113 | | 1114 | ACK 1 | 1115 |--------------------------------->| 1116 | | 1117 | | 1118 | | 1119 |<########### MEDIA 1 ############>| 1120 | 1 video A->B, 1 video B->A | 1121 |<################################>| 1122 | | 1123 | | 1124 | | 1125 | | 1126 v v 1128 In INVITE 1, Alice sends Bob a SIP INVITE including in the SDP body 1129 the basilar audio and video capabilities and the information needed 1130 for opening a control channel to be used for CLUE protocol messages 1131 exchange, according to what is envisioned in the COMEDIA approach for 1132 a DTLS/SCTP channel [I-D.ietf-mmusic-sctp-sdp]. A snippet of the SDP 1133 showing the grouping attribute, data channel and the video m-line are 1134 shown below: 1136 ... 1137 a=group:CLUE 3 1138 ... 1139 m=video 6002 RTP/AVP 96 1140 a=rtpmap:96 H264/90000 1141 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1142 a=sendrecv 1143 a=mid:2 1144 ... 1145 m=application 6100 DTLS/SCTP webrtc-datachannel 1146 a=fmtp:webrtc-datachannel max-message-size=100000 1147 a=sctp-port 5000 1148 a=mid:3 1150 Bob is not CLUE-capable, and hence does not recognize the "CLUE" 1151 semantic for grouping attribute, nor does he support the data 1152 channel. He responds with an answer with audio and video, but with 1153 the data channel zeroed. 1155 From the lack of the data channel and grouping framework Alice 1156 understands that Bob does not support CLUE, or does not wish to use 1157 it. Both sides are now able to send a single audio and video stream 1158 to each other. Alice at this point begins to send her fallback 1159 video: in this case likely a switched view from whichever camera 1160 shows the current loudest participant on her side. 1162 10. Open Issues 1164 Here are issues pertinent to signaling that need resolution. 1165 Resolution will probably result in changes somewhere in this 1166 document, but may also impact other documents. 1168 o The current method for expressing encodings in SDP limits the 1169 parameters available when describing H264 encoder capabilities to 1170 those defined in Table 6 in [RFC6184] 1172 11. Acknowledgements 1174 The team focusing on this draft consists of: Roni Even, Rob Hansen, 1175 Christer Holmberg, Paul Kyzivat, Simon Pietro-Romano, Roberta Presta. 1177 Christian Groves and Jonathon Lennox have contributed detailed 1178 comments and suggestions. 1180 12. IANA Considerations 1182 We will need to register the 'CLUE' grouping semantic and the 1183 'sip.clue' media feature tag with IANA. Christian has some proposed 1184 text for when this happens. 1186 13. Security Considerations 1188 CLUE makes use of a number of protocols and mechanism, either defined 1189 by CLUE or long-standing. The security considerations section of the 1190 CLUE Framework [I-D.ietf-clue-framework] addresses the need to secure 1191 these mechanisms by following the recommendations of the individual 1192 protocols. 1194 Beyond the need to secure the consistuent protocols, the use of CLUE 1195 does impose additional security concerns. One area of increased risk 1196 involves the potential for a malicious party to subvert a CLUE- 1197 capable device to attack a third party by driving large volumes of 1198 media (particularly video) traffic at them by establishing a 1199 connection to the CLUE-capable device and directing the media to the 1200 victim. While this is a risk for all media devices, a CLUE-capable 1201 device may allow the attacker to configure multiple media streams to 1202 be sent, significantly increasing the volume of traffic directed at 1203 the victim. 1205 To prevent this attack, a CLUE-capable device SHOULD take steps to 1206 authenticate the media receiver via DTLS [RFC5763] and/or validate 1207 that the media recipient wishes to receive the media via ICE 1208 [RFC5245]. 1210 CLUE also defines a new media feature tag that indicates CLUE 1211 support. This tag may be present even in non-CLUE calls, which 1212 increases the metadata available about the sending device, which can 1213 help an attacker differentiate between multiple devices and help them 1214 identify otherwise anonymised users via the fingerprint of features 1215 their device supports. To prevent this, SIP signalling SHOULD always 1216 be encrypted using TLS [RFC5630]. 1218 14. Change History 1220 Revision by Rob Hansen 1222 o Updated DTLS/SCTP channel syntax in examples to fix errors and 1223 match latest format defined in draft-ietf-mmusic-sctp-sdp-07. 1225 o Clarified the behaviour if an SDP offer includes a CLUE-controlled 1226 "m" line and the answer accepts that "m" line but without CLUE 1227 control of that line. 1229 o Added a new section on the sending and receiving of CaptureIds in 1230 RTP and RTCP. Includes a section on the necessity of the receiver 1231 coping with unexpected CaptureIds (or the lack thereof) due to 1232 MCCs being redefined in new ADVERTISEMENT messages. 1234 o Added reminder on IANA section on registering grouping semantic 1235 and media feature tag, removed the less formal sections that did 1236 the same job. 1238 o Fixed and clarified issues raised by Christian's document review. 1240 o Added a number of security considerations. 1242 Revision by Rob Hansen 1244 o Clarified text on not rejecting messages because they contain 1245 unknown encIDs. 1247 o Removed normative language in section on accepting/rejecting non- 1248 CLUE-controlled media in the initial answer. 1250 o Example SDP updated to include the data channel "m" lines. 1252 o Example call flow updated to show disablement of non-CLUE- 1253 controlled media once CLUE-controlled media is flowing. 1255 -02: Revision by Rob Hansen 1257 * Added section on not accepting non-CLUE-controlled "m" lines in 1258 the initial answer when CLUE is to be negotiated. 1260 * Removed previous language attempting to describe media 1261 restrictions for CLUE-controlled "m" lines that had not been 1262 configured, and replaced it with much more accurate 'treat as 1263 "a=inactive" was set'. 1265 * Made label element mandatory for CLUE-controlled media (was 1266 previously "SHOULD include", but there didn't seem a good 1267 reason for this - anyone wishing to include the "m" line but 1268 not immediately use it in CLUE can simply leave it out of the 1269 .) 1271 * Added a section on the specifics of relating encodings in SDP 1272 to elements in the CLUE protocol, including the fact 1273 that both ADVERTISMENTS and CONFIGURE messages reference the 1274 *encoding* (eg, in the CONFIGURE case the sender of the 1275 CONFIGURE message includes the labels of the recipient's "m" 1276 lines as their contents). 1278 * Minor revisions to the section on complying with normative SDP/ 1279 CLUEstate machine language to clarify that these were not new 1280 normative language, merely that existing normative language 1281 still applies. 1283 * Removed appendices which previously contained information to be 1284 transferred to the protocol and data channel drafts. Removed 1285 other text that discussed alternatives to the current approach. 1287 * Cleaned up some 'todo' text. 1289 -01: Revision by Rob Hansen 1291 * Revised terminology - removed the term 'CLUE-enabled' device as 1292 insufficiently distinct from 'CLUE-capable' and instead added a 1293 term for 'CLUE-enabled' calls. 1295 * Removed text forbidding RTCP and instead added text that ICE/ 1296 DTLS negotiation for CLUE controlled media must be done as 1297 normal irrespective of CLUE negotiation. 1299 * Changed 'sip.telepresence' to 'sip.clue' and 'TELEPRESENCE' 1300 grouping semantic back to CLUE. 1302 * Made it mandatory to have exactly one mid corresponding to a 1303 data channel in a CLUE group 1305 * Forbade having multiple CLUE groups unless a specification for 1306 doing so is published. 1308 * Refactored SDP-related text; previously the encoding 1309 information had been in the "initial offer" section despite the 1310 fact that we recommend that the initial offer doesn't actually 1311 include any encodings. I moved the specifications of encodings 1312 and how they're received to an earlier, seperate section. 1314 * Added text on how the state machines in CLUE and SDP are 1315 allowed to affect one another, and further recommendations on 1316 how a device should handle the sending of CLUE and SDP changes. 1318 -00: Revision by Rob Hansen 1320 * Submitted as -00 working group document 1322 draft-kyzivat-08: Revisions by Rob Hansen 1324 * Added media feature tag for CLUE support ('sip.telepresence') 1325 * Changed grouping semantic from 'CLUE' to 'TELEPRESENCE' 1327 * Restructured document to be more centred on the grouping 1328 semantic and its use with O/A 1330 * Lots of additional text on usage of the grouping semantic 1332 * Stricter definition of CLUE-controlled m lines and how they 1333 work 1335 * Some additional text on defining what happens when CLUE 1336 supports is added or removed 1338 * Added details on when to not send RTCP for CLUE-controlled "m" 1339 lines. 1341 * Added a section on using BUNDLE with CLUE 1343 * Updated data channel references to point at new WG document 1344 rather than indivual draft 1346 draft-kyzivat-07: Revisions by Rob Hansen 1348 * Removed the text providing arguments for encoding limits being 1349 in SDP and encoding groups in the CLUE protocol in favor of the 1350 specifics of how to negotiate encodings in SDP 1352 * Added normative language on the setting up of a CLUE call, and 1353 added sections on mid-call changes to the CLUE status. 1355 * Added references to [I-D.ietf-clue-datachannel] where 1356 appropriate. 1358 * Added some terminology for various types of CLUE and non-CLUE 1359 states of operation. 1361 * Moved language related to topics that should be in 1362 [I-D.ietf-clue-datachannel] and [I-D.ietf-clue-protocol], but 1363 that has not yet been resolved in those documents, into an 1364 appendix. 1366 draft-kyzivat-06: Revisions by Rob Hansen 1368 * Removed CLUE message XML schema and details that are now in 1369 draft-presta-clue-protocol 1371 * Encoding limits in SDP section updated to note that this has 1372 been investigated and discussed and is the current working 1373 assumption of the WG, though consensus has not been fully 1374 achieved. 1376 * A section has also been added on the current mandation of 1377 unidirectional "m"-lines. 1379 * Updated CLUE messaging in example call flow to match draft- 1380 presta-clue-protocol-03 1382 draft-kyzivat-05: Revisions by pkyzivat: 1384 * Specified versioning model and mechanism. 1386 * Added explicit response to all messages. 1388 * Rearranged text to work with the above changes. (Which 1389 rendered diff almost useless.) 1391 draft-kyzivat-04: Revisions by Rob Hansen: ??? 1393 draft-kyzivat-03: Revisions by pkyzivat: 1395 * Added a syntax section with an XML schema for CLUE messages. 1396 This is a strawhorse, and is very incomplete, but it 1397 establishes a template for doing this based on elements defined 1398 in the data model. (Thanks to Roberta for help with this!) 1400 * Did some rewording to fit the syntax section in and reference 1401 it. 1403 * Did some relatively minor restructuring of the document to make 1404 it flow better in a logical way. 1406 draft-kyzivat-02: A bunch of revisions by pkyzivat: 1408 * Moved roberta's call flows to a more appropriate place in the 1409 document. 1411 * New section on versioning. 1413 * New section on NAK. 1415 * A couple of possible alternatives for message acknowledgment. 1417 * Some discussion of when/how to signal changes in provider 1418 state. 1420 * Some discussion about the handling of transport errors. 1422 * Added a change history section. 1424 These were developed by Lennard Xiao, Christian Groves and Paul, 1425 so added Lennard and Christian as authors. 1427 draft-kyzivat-01: Updated by roberta to include some sample call 1428 flows. 1430 draft-kyzivat-00: Initial version by pkyzivat. Established general 1431 outline for the document, and specified a few things thought to 1432 represent wg consensus. 1434 15. References 1436 15.1. Normative References 1438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1439 Requirement Levels", BCP 14, RFC 2119, March 1997. 1441 [I-D.ietf-clue-framework] 1442 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 1443 for Telepresence Multi-Streams", draft-ietf-clue- 1444 framework-18 (work in progress), October 2014. 1446 [I-D.ietf-clue-data-model-schema] 1447 Presta, R. and S. Romano, "An XML Schema for the CLUE data 1448 model", draft-ietf-clue-data-model-schema-07 (work in 1449 progress), September 2014. 1451 [I-D.ietf-clue-protocol] 1452 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 1453 clue-protocol-02 (work in progress), October 2014. 1455 [I-D.ietf-clue-datachannel] 1456 Holmberg, C., "CLUE Protocol Data Channel", draft-ietf- 1457 clue-datachannel-01 (work in progress), September 2014. 1459 [I-D.ietf-clue-rtp-mapping] 1460 Even, R. and J. Lennox, "Mapping RTP streams to CLUE media 1461 captures", draft-ietf-clue-rtp-mapping-03 (work in 1462 progress), October 2014. 1464 [I-D.groves-clue-latent-config] 1465 Groves, C., Yang, W., and R. Even, "CLUE and latent 1466 configurations", draft-groves-clue-latent-config-00 (work 1467 in progress), January 2014. 1469 [I-D.ietf-mmusic-sctp-sdp] 1470 Loreto, S. and G. Camarillo, "Stream Control Transmission 1471 Protocol (SCTP)-Based Media Transport in the Session 1472 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-07 1473 (work in progress), July 2014. 1475 [I-D.tuexen-tsvwg-sctp-dtls-encaps] 1476 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 1477 Encapsulation of SCTP Packets for RTCWEB", draft-tuexen- 1478 tsvwg-sctp-dtls-encaps-01 (work in progress), July 2012. 1480 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1481 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1483 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1484 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1486 15.2. Informative References 1488 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1489 with Session Description Protocol (SDP)", RFC 3264, June 1490 2002. 1492 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1493 UPDATE Method", RFC 3311, October 2002. 1495 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1496 (ICE): A Protocol for Network Address Translator (NAT) 1497 Traversal for Offer/Answer Protocols", RFC 5245, April 1498 2010. 1500 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1501 Session Initiation Protocol (SIP)", RFC 4353, February 1502 2006. 1504 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1505 Initiation Protocol (SIP)", RFC 5630, October 2009. 1507 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1508 for Establishing a Secure Real-time Transport Protocol 1509 (SRTP) Security Context Using Datagram Transport Layer 1510 Security (DTLS)", RFC 5763, May 2010. 1512 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1513 Protocol (XMPP): Core", RFC 6120, March 2011. 1515 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1516 Payload Format for H.264 Video", RFC 6184, May 2011. 1518 [I-D.even-clue-sdp-clue-relation] 1519 Even, R., "Signalling of CLUE and SDP offer/answer", 1520 draft-even-clue-sdp-clue-relation-01 (work in progress), 1521 October 2012. 1523 [I-D.even-clue-rtp-mapping] 1524 Even, R. and J. Lennox, "Mapping RTP streams to CLUE media 1525 captures", draft-even-clue-rtp-mapping-05 (work in 1526 progress), February 2013. 1528 [I-D.hansen-clue-sdp-interaction] 1529 Hansen, R., "SDP and CLUE message interactions", draft- 1530 hansen-clue-sdp-interaction-01 (work in progress), 1531 February 2013. 1533 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1534 Holmberg, C., Alvestrand, H., and C. Jennings, 1535 "Negotiating Media Multiplexing Using the Session 1536 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1537 negotiation-12 (work in progress), October 2014. 1539 Authors' Addresses 1541 Paul Kyzivat 1542 Huawei 1544 Email: pkyzivat@alum.mit.edu 1546 Lennard Xiao 1547 Huawei 1549 Email: lennard.xiao@huawei.com 1551 Christian Groves 1552 Huawei 1554 Email: Christian.Groves@nteczone.com 1556 Robert Hansen 1557 Cisco Systems 1559 Email: rohanse2@cisco.com