idnits 2.17.1 draft-ietf-clue-signaling-08.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 (March 14, 2016) is 2965 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-13 == 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-16 == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-08 -- 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-27 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: September 15, 2016 C. Groves 6 Huawei 7 R. Hansen 8 Cisco Systems 9 March 14, 2016 11 CLUE Signaling 12 draft-ietf-clue-signaling-08 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 September 15, 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 . . . . . . 11 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 . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . . 34 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 34 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 accepted 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=" lines 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, during an ongoing CLUE-enabled call a device wishes to disable 454 CLUE, it can do so by following the procedures for closing a data 455 channel defined in Section 5.2.4 of 456 [I-D.ietf-mmusic-data-channel-sdpneg]: sending a new SDP offer/answer 457 exchange and subsequent SCTP SSN reset for the CLUE channel. It MUST 458 also remove the "mid" for the data channel from the CLUE group. 460 If a device follows the procedure above, or an SDP offer-answer 461 negotiation completes in a fashion in which either the "m=" CLUE data 462 channel line was not successfully negotiated, and/or one side did not 463 include the data channel in a matching CLUE group then CLUE for this 464 call is disabled. In the event that this occurs, CLUE is no longer 465 enabled and sending of all CLUE-controlled media associated with the 466 corresponding CLUE group MUST stop. If the data channel is still 467 present but not included in the CLUE group semantic CLUE protocol 468 messages MUST no longer be sent. 470 Note that this is distinct from cases where the CLUE protocol 471 negotiation fails, or an error occurs in the CLUE protocol; see 472 [I-D.ietf-clue-protocol] for details of media and state preservation 473 in this circumstance. These measures also apply if the CLUE data 474 channel fails, or is closed/reset without a corresponding SDP 475 exchange to disable the "m=" line. 477 5. Interaction of CLUE protocol and SDP negotiations 479 Information about media streams in CLUE is split between two message 480 types: SDP, which defines media addresses and limits, and the CLUE 481 channel, which defines properties of Capture Devices available, scene 482 information and additional constraints. As a result certain 483 operations, such as advertising support for a new transmissible 484 Capture with associated stream, cannot be performed atomically, as 485 they require changes to both SDP and CLUE messaging. 487 This section defines how the negotiation of the two protocols 488 interact, provides some recommendations on dealing with intermediate 489 stages in non-atomic operations, and mandates additional constraints 490 on when CLUE-configured media can be sent. 492 5.1. Independence of SDP and CLUE negotiation 494 To avoid the need to implement interlocking state machines with the 495 potential to reach invalid states if messages were to be lost, or be 496 rewritten en-route by middle boxes, the state machines in SDP and 497 CLUE operate independently. The state of the CLUE channel does not 498 restrict when an implementation may send a new SDP offer or answer, 499 and likewise the implementation's ability to send a new CLUE 500 Advertisement or Configure message is not restricted by the results 501 of or the state of the most recent SDP negotiation (unless the SDP 502 negotiation has removed the CLUE channel). 504 The primary implication of this is that a device may receive an SDP 505 with a CLUE Encoding for which it does not yet have Capture 506 information, or receive a CLUE Configure message specifying a Capture 507 Encoding for which the far end has not negotiated a media stream in 508 SDP. 510 CLUE messages contain an (in encodingIDList) or 511 (in captureEncodingType), which is used to identify a specific 512 encoding or captureEncoding in SDP; see 513 [I-D.ietf-clue-data-model-schema] for specifics. The non-atomic 514 nature of CLUE negotiation means that a sender may wish to send a new 515 Advertisement before the corresponding SDP message. As such the 516 sender of the CLUE message MAY include an which does not 517 currently match a CLUE-controlled "m=" line label in SDP; A CLUE- 518 capable implementation MUST NOT reject a CLUE protocol message solely 519 because it contains elements that do not match a label in 520 SDP. 522 The current state of the CLUE participant or Media Provider/Consumer 523 state machines do not affect compliance with any of the normative 524 language of [RFC3264]. That is, they MUST NOT delay an ongoing SDP 525 exchange as part of a SIP server or client transaction; an 526 implementation MUST NOT delay an SDP exchange while waiting for CLUE 527 negotiation to complete or for a Configure message to arrive. 529 Similarly, a device in a CLUE-enabled call MUST NOT delay any 530 mandatory state transitions in the CLUE Participant or Media 531 Provider/Consumer state machines due to the presence or absence of an 532 ongoing SDP exchange. 534 A device with the CLUE Participant state machine in the ACTIVE state 535 MAY choose not to move from ESTABLISHED to ADV (Media Provider state 536 machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media 537 Consumer state machine) based on the SDP state. See 538 [I-D.ietf-clue-protocol] for CLUE state machine specifics. 539 Similarly, a device MAY choose to delay initiating a new SDP exchange 540 based on the state of their CLUE state machines. 542 5.2. Constraints on sending media 544 While SDP and CLUE message states do not impose constraints on each 545 other, both impose constraints on the sending of media - CLUE- 546 controlled media MUST NOT be sent unless it has been negotiated in 547 both CLUE and SDP: an implementation MUST NOT send a specific CLUE 548 Capture Encoding unless its most recent SDP exchange contains an 549 active media channel for that Encoding AND the far end has sent a 550 CLUE Configure message specifying a valid Capture for that Encoding. 552 5.3. Recommendations for operating with non-atomic operations 554 CLUE-capable devices MUST be able to handle states in which CLUE 555 messages make reference to EncodingIDs that do not match the most 556 recently received SDP, irrespective of the order in which SDP and 557 CLUE messages are received. While these mismatches will usually be 558 transitory a device MUST be able to cope with such mismatches 559 remaining indefinitely. However, this document makes some 560 recommendations on message ordering for these non-atomic transitions. 562 CLUE-capable devices SHOULD ensure that any inconsistencies between 563 SDP and CLUE signaling are temporary by sending updated SDP or CLUE 564 messages as soon as the relevant state machines and other constraints 565 permit. 567 Generally, implementations that receive messages for which they have 568 incomplete information SHOULD wait until they have the corresponding 569 information they lack before sending messages to make changes related 570 to that information. For example, an answerer that receives a new 571 SDP offer with three new "a=sendonly" CLUE "m=" lines for which it 572 has received no CLUE Advertisement providing the corresponding 573 capture information SHOULD include corresponding "a=inactive" lines 574 in its answer, and SHOULD make a new SDP offer with "a=recvonly" when 575 and if a new Advertisement arrives with Captures relevant to those 576 Encodings. 578 Because of the constraints of SDP offer/answer and because new SDP 579 negotiations are generally more 'costly' than sending a new CLUE 580 message, implementations needing to make changes to both channels 581 SHOULD prioritize sending the updated CLUE message over sending the 582 new SDP message. The aim is for the recipient to receive the CLUE 583 changes before the SDP changes, allowing the recipient to send their 584 SDP answers without incomplete information, reducing the number of 585 new SDP offers required. 587 6. Interaction of CLUE protocol and RTP/RTCP CaptureID 589 [I-D.ietf-clue-framework] allows for Multiple Content Captures MCCs): 590 Captures which contain multiple source Captures, whether composited 591 into a single stream or switched based on some metric. 593 The Captures that contribute to these MCCs may or may not be defined 594 in the Advertisement message. If they are defined and the MCC is 595 providing them in a switched format the recipient may wish to 596 determine which originating source Capture is currently being 597 provided, so that they can apply geometric corrections based on that 598 Capture's geometry, or take some other action based on the original 599 Capture information. 601 To do this, [I-D.ietf-clue-rtp-mapping] allows for the CaptureID of 602 the originating Capture to be conveyed via RTP or RTCP. A Media 603 Provider sending switched media for an MCC with defined originating 604 sources MUST send the CaptureID in both RTP and RTCP, as described in 605 the mapping document. 607 6.1. CaptureID reception during MCC redefinition 609 Because the RTP/RTCP CaptureID is delivered via a different channel 610 to the Advertisement in which in the contents of the MCC are defined 611 there is an intrinsic race condition in cases in which the contents 612 of an MCC are redefined. 614 When a Media Provider redefines an MCC which involves CaptureIDs, the 615 reception of the relevant CaptureIDs by the recipient will either 616 lead or lag reception and processing of the new Advertisement by the 617 recipient. As such, a Media Consumer MUST not be disrupted by any of 618 the following in any CLUE- controlled media stream it is receiving, 619 whether that stream is for a static Capture or for an MCC (as any 620 static Capture may be redefined to an MCC in a later Advertisement): 622 o Receiving RTP or RTCP containing a CaptureID when the most 623 recently processed Advertisement means that none are expected. 625 o Receiving RTP or RTCP without CaptureIDs when the most recently 626 processed Advertisement means that media CaptureIDs are expected. 628 o Receiving a CaptureID in RTP or RTCP for a Capture defined in the 629 most recently processed Advertisement, but which the same 630 Advertisement does not include in the MCC. 632 o Receiving a CaptureID in RTP or RTCP for a Capture not defined in 633 the most recently processed Advertisement. 635 7. Multiplexing of CLUE-controlled media using BUNDLE 637 7.1. Overview 639 A CLUE call may involve sending and/or receiving significant numbers 640 of media streams. Conventionally, media streams are sent and 641 received on unique ports. However, each separate port used for this 642 purpose may impose costs that a device wishes to avoid, such as the 643 need to open that port on firewalls and NATs, the need to collect ICE 644 candidates [RFC5245], etc. 646 The BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] extension can be 647 used to negotiate the multiplexing of multiple media lines onto a 648 single 5-tuple for sending and receiving media, allowing devices in 649 calls to another BUNDLE-supporting device to potentially avoid some 650 of the above costs. 652 While CLUE-capable devices MAY support the BUNDLE extension for this 653 purpose supporting the extension is not mandatory for a device to be 654 CLUE-compliant. 656 7.2. Usage of BUNDLE with CLUE 658 This specification imposes no additional requirements or restrictions 659 on the usage of BUNDLE when used with CLUE. There is no restriction 660 on combining CLUE-controlled media lines and non-CLUE-controlled 661 media lines in the same BUNDLE group or in multiple such groups. 662 However, there are several steps an implementation may wish to take 663 to ameliorate the cost and time requirements of extra SDP offer/ 664 answer exchanges between CLUE and BUNDLE. 666 7.2.1. Generating the Initial Offer 668 BUNDLE mandates that the initial SDP offer MUST use a unique address 669 for each "m=" line with a non-zero port. Because CLUE 670 implementations generally will not include CLUE-controlled media 671 lines with the exception of the data channel in the initial SDP 672 offer, CLUE devices that support large numbers of streams can avoid 673 ever having to open large numbers of ports if they successfully 674 negotiate BUNDLE. 676 7.2.2. Multiplexing of the data channel and RTP media 678 BUNDLE-supporting CLUE-capable devices MAY include the data channel 679 in the same BUNDLE group as RTP media. In this case the device MUST 680 be able to demultiplex the various transports - see section 9.2 of 681 the BUNDLE draft [I-D.ietf-mmusic-sdp-bundle-negotiation]. If the 682 BUNDLE group includes other protocols than the data channel 683 transported via DTLS the device MUST also be able to differentiate 684 the various protocols. 686 8. Example: A call between two CLUE-capable Endpoints 688 This example illustrates a call between two CLUE-capable Endpoints. 689 Alice, initiating the call, is a system with three cameras and three 690 screens. Bob, receiving the call, is a system with two cameras and 691 two screens. A call-flow diagram is presented, followed by a summary 692 of each message. 694 To manage the size of this section the SDP snippets only illustrate 695 video "m=" lines. SIP ACKs are not always discussed. Note that 696 BUNDLE is not in use. 698 +----------+ +-----------+ 699 | Alice | | Bob | 700 | | | | 701 +----+-----+ +-----+-----+ 702 | | 703 | | 704 | SIP INVITE 1 | 705 |--------------------------------->| 706 | | 707 | | 708 | SIP 200 OK 1 | 709 |<---------------------------------| 710 | | 711 | | 712 | SIP ACK 1 | 713 |--------------------------------->| 714 | | 715 | | 716 | | 717 |<########### MEDIA 1 ############>| 718 | 1 video A->B, 1 video B->A | 719 |<################################>| 720 | | 721 | | 722 | | 723 |<================================>| 724 | CLUE DATA CHANNEL ESTABLISHED | 725 |<================================>| 726 | | 727 | | 728 | CLUE OPTIONS | 729 |<*********************************| 730 | | 731 | | 732 | CLUE OPTIONS RESPONSE | 733 |*********************************>| 734 | | 735 | | 736 | CLUE ADVERTISEMENT 1 | 737 |*********************************>| 738 | | 739 | | 740 | CLUE ADVERTISEMENT 2 | 741 |<*********************************| 742 | | 743 | | 744 | CLUE ADVERTISEMENT ACK 1 | 745 |<*********************************| 746 | | 747 | | 748 | CLUE ADVERTISEMENT ACK 2 | 749 |*********************************>| 750 | | 751 | | 752 | SIP INVITE 2 (+3 sendonly) | 753 |--------------------------------->| 754 | | 755 | | 756 | CLUE CONFIGURE 1 | 757 |<*********************************| 758 | | 759 | | 760 | SIP 200 OK 2 (+2 recvonly) | 761 |<---------------------------------| 762 | | 763 | | 764 | CLUE CONFIGURE RESPONSE 1 | 765 |*********************************>| 766 | | 767 | | 768 | SIP ACK 2 | 769 |--------------------------------->| 770 | | 771 | | 772 | | 773 |<########### MEDIA 2 ############>| 774 | 2 video A->B, 1 video B->A | 775 |<################################>| 776 | | 777 | | 778 | SIP INVITE 3 (+2 sendonly) | 779 |<---------------------------------| 780 | | 781 | | 782 | CLUE CONFIGURE 2 | 783 |*********************************>| 784 | | 785 | | 786 | SIP 200 OK 3 (+2 recvonly) | 787 |--------------------------------->| 788 | | 789 | | 790 | CLUE CONFIGURE RESPONSE 2 | 791 |<*********************************| 792 | | 793 | | 794 | SIP ACK 3 | 795 |<---------------------------------| 796 | | 797 | | 798 | | 799 |<########### MEDIA 3 ############>| 800 | 2 video A->B, 2 video B->A | 801 |<################################>| 802 | | 803 | | 804 | | 805 v v 807 In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP 808 body the basic audio and video capabilities and the data channel as 809 per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" 810 media feature tag in the INVITE. A snippet of the SDP showing the 811 grouping attribute and the video "m=" line are shown below. Alice 812 has included a "CLUE" group, and included the mid corresponding to a 813 data channel in the group (3). Note that Alice has chosen not to 814 include any CLUE-controlled media in the initial offer - the mid 815 value of the video line is not included in the "CLUE" group. 817 ... 818 a=group:CLUE 3 819 ... 820 m=video 6002 RTP/AVP 96 821 a=rtpmap:96 H264/90000 822 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 823 a=sendrecv 824 a=mid:2 825 ... 826 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 827 a=sctp-port: 5000 828 a=dcmap:2 subprotocol="CLUE";ordered=true 829 a=mid:3 831 Bob responds with a similar SDP in SIP 200 OK 1, which also has a 832 "CLUE" group including the mid value of a data channel; due to their 833 similarity no SDP snippet is shown here. Bob wishes to receive 834 initial media, and so includes corresponding non-CLUE-controlled 835 audio and video lines. Bob also includes the "sip.clue" media 836 feature tag in the 200 OK. Alice and Bob are each now able to send a 837 single audio and video stream. This is illustrated as MEDIA 1. 839 With the successful initial SDP O/A Alice and Bob are also free to 840 negotiate the CLUE data channel. This is illustrated as CLUE DATA 841 CHANNEL ESTABLISHED. 843 Once the data channel is established CLUE protocol negotiation 844 begins. In this case Bob is the Channel Initiator and sends a CLUE 845 OPTIONS message describing his version support. On receiving that 846 message Alice sends her corresponding CLUE OPTIONS RESPONSE. 848 With the OPTIONS phase complete Alice now sends her CLUE 849 Advertisement (CLUE ADVERTISEMENT 1). She advertises three static 850 Captures representing her three cameras. She also includes switched 851 Captures suitable for two- and one-screen systems. All of these 852 Captures are in a single Capture Scene, with suitable Capture Scene 853 Views to tell Bob that he should either subscribe to the three static 854 Captures, the two switched Captures or the one switched Capture. 855 Alice has no simultaneity constraints, so includes all six Captures 856 in one simultaneous set. Finally, Alice includes an Encoding Group 857 with three Encoding IDs: "enc1", "enc2" and "enc3". These Encoding 858 IDs aren't currently valid, but will match the next SDP offer she 859 sends. 861 Bob received CLUE ADVERTISEMENT 1 but does not yet send a Configure 862 message, because he has not yet received Alice's Encoding 863 information, so as yet he does not know if she will have sufficient 864 resources to send him the two streams he ideally wants at a quality 865 he is happy with. Because Bob is not sending an immediate Configure 866 with the "ack" element set he must send an explicit Advertisement 867 Acknowledgement message (CLUE ADVERTISEMENT ACK 1) to signal receipt 868 of CLUE ADVERTISEMENT 1. 870 Bob also sends his CLUE Advertisement (CLUE ADVERTISEMENT 2) - though 871 the diagram shows that this occurs after Alice sends CLUE 872 ADVERTISEMENT 1 Bob sends his Advertisement independently and does 873 not wait for CLUE ADVERTISEMENT 1 to arrive. He advertises two 874 static Captures representing his cameras. He also includes a single 875 composed Capture for single-screen systems, in which he will 876 composite the two camera views into a single video stream. All three 877 Captures are in a single Capture Scene, with suitable Capture Scene 878 Views to tell Alice that she should either subscribe to the two 879 static Captures, or the single composed Capture. Bob also has no 880 simultaneity constraints, so includes all three Captures in one 881 simultaneous set. Bob also includes a single Encoding Group with two 882 Encoding IDs: "foo" and "bar". 884 Similarly, Alice receives CLUE ADVERTISEMENT 2 but does not yet send 885 a Configure message, because she has not yet received Bob's Encoding 886 information, sending instead an Advertisement Acknowledgement(CLUE 887 ADVERTISEMENT ACK 2). 889 Both sides have now sent their CLUE Advertisement messages and an SDP 890 exchange is required to negotiate Encodings. For simplicity, in this 891 case Alice is shown sending an INVITE with a new offer; in many 892 implementations both sides might send an INVITE, which would be 893 resolved by use of the 491 Request Pending resolution mechanism from 894 [RFC3261]. 896 Alice now sends SIP INVITE 2. She maintains the sendrecv audio, 897 video and CLUE "m=" lines, and she adds three new sendonly "m=" lines 898 to represent the three CLUE-controlled Encodings she can send. Each 899 of these "m=" lines has a label corresponding to one of the Encoding 900 IDs from CLUE ADVERTISEMENT 1. Each also has its mid added to the 901 grouping attribute to show they are controlled by the CLUE channel. 902 A snippet of the SDP showing the grouping attribute, data channel and 903 the video "m=" lines are shown below: 905 ... 906 a=group:CLUE 3 4 5 6 907 ... 908 m=video 6002 RTP/AVP 96 909 a=rtpmap:96 H264/90000 910 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 911 a=sendrecv 912 a=mid:2 913 ... 914 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 915 a=sctp-port: 5000 916 a=dcmap:2 subprotocol="CLUE";ordered=true 917 a=mid:3 918 ... 919 m=video 6004 RTP/AVP 96 920 a=rtpmap:96 H264/90000 921 a=fmtp:96 profile-level-id=42e016 922 a=sendonly 923 a=mid:4 924 a=label:enc1 925 m=video 6006 RTP/AVP 96 926 a=rtpmap:96 H264/90000 927 a=fmtp:96 profile-level-id=42e016 928 a=sendonly 929 a=mid:5 930 a=label:enc2 931 m=video 6008 RTP/AVP 96 932 a=rtpmap:96 H264/90000 933 a=fmtp:96 profile-level-id=42e016 934 a=sendonly 935 a=mid:6 936 a=label:enc3 938 Bob now has all the information he needs to decide which streams to 939 configure, allowing him to send both a CLUE Configure message and his 940 SDP answer. As such he now sends CLUE CONFIGURE 1. This requests 941 the pair of switched Captures that represent Alice's scene, and he 942 configures them with encoder ids "enc1" and "enc2". 944 Bob also sends his SDP answer as part of SIP 200 OK 2. Alongside his 945 original audio, video and CLUE "m=" lines he includes two active 946 recvonly "m= "lines and a zeroed "m=" line for the third. He adds 947 their mid values to the grouping attribute to show they are 948 controlled by the CLUE channel. A snippet of the SDP showing the 949 grouping attribute and the video "m=" lines are shown below (mid 100 950 represents the CLUE channel, not shown): 952 ... 953 a=group:CLUE 11 12 100 954 ... 955 m=video 58722 RTP/AVP 96 956 a=rtpmap:96 H264/90000 957 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 958 a=sendrecv 959 a=mid:10 960 ... 961 m=video 58724 RTP/AVP 96 962 a=rtpmap:96 H264/90000 963 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 964 a=recvonly 965 a=mid:11 966 m=video 58726 RTP/AVP 96 967 a=rtpmap:96 H264/90000 968 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 969 a=recvonly 970 a=mid:12 971 m=video 0 RTP/AVP 96 973 Alice receives Bob's message CLUE CONFIGURE 1 and sends CLUE RESPONSE 974 1 to ack its reception. She does not yet send the Capture Encodings 975 specified, because at this stage she hasn't processed Bob's answer 976 SDP and so hasn't negotiated the ability for Bob to receive these 977 streams. 979 On receiving SIP 200 OK 2 from Bob Alice sends her SIP ACK (SIP ACK 980 2). She is now able to send the two streams of video Bob requested - 981 this is illustrated as MEDIA 2. 983 The constraints of offer/answer meant that Bob could not include his 984 encoding information as new "m=" lines in SIP 200 OK 2. As such Bob 985 now sends SIP INVITE 3 to generate a new offer. Along with all the 986 streams from SIP 200 OK 2 Bob also includes two new sendonly streams. 987 Each stream has a label corresponding to the Encoding IDs in his CLUE 988 ADVERTISEMENT 2 message. He also adds their mid values to the 989 grouping attribute to show they are controlled by the CLUE channel. 990 A snippet of the SDP showing the grouping attribute and the video 991 "m=" lines are shown below (mid 100 represents the CLUE channel, not 992 shown): 994 ... 995 a=group:CLUE 11 12 13 14 100 996 ... 997 m=video 58722 RTP/AVP 96 998 a=rtpmap:96 H264/90000 999 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1000 a=sendrecv 1001 a=mid:10 1002 ... 1003 m=video 58724 RTP/AVP 96 1004 a=rtpmap:96 H264/90000 1005 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1006 a=recvonly 1007 a=mid:11 1008 m=video 58726 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=recvonly 1012 a=mid:12 1013 m=video 0 RTP/AVP 96 1014 m=video 58728 RTP/AVP 96 1015 a=rtpmap:96 H264/90000 1016 a=fmtp:96 profile-level-id=42e016 1017 a=sendonly 1018 a=label:foo 1019 a=mid:13 1020 m=video 58730 RTP/AVP 96 1021 a=rtpmap:96 H264/90000 1022 a=fmtp:96 profile-level-id=42e016 1023 a=sendonly 1024 a=label:bar 1025 a=mid:14 1027 Having received this Alice now has all the information she needs to 1028 send her CLUE Configure message and her SDP answer. In CLUE 1029 CONFIGURE 2 she requests the two static Captures from Bob, to be sent 1030 on Encodings "foo" and "bar". 1032 Alice also sends SIP 200 OK 3, matching two recvonly "m=" lines to 1033 Bob's new sendonly lines. She includes their mid values in the 1034 grouping attribute to show they are controlled by the CLUE channel. 1035 Alice also now deactivates the initial non-CLUE-controlled media, as 1036 bidirectional CLUE-controlled media is now available. A snippet of 1037 the SDP showing the grouping attribute and the video "m=" lines are 1038 shown below (mid 3 represents the data channel, not shown): 1040 ... 1041 a=group:CLUE 3 4 5 7 8 1042 ... 1043 m=video 0 RTP/AVP 96 1044 a=mid:2 1045 ... 1046 m=video 6004 RTP/AVP 96 1047 a=rtpmap:96 H264/90000 1048 a=fmtp:96 profile-level-id=42e016 1049 a=sendonly 1050 a=mid:4 1051 a=label:enc1 1052 m=video 6006 RTP/AVP 96 1053 a=rtpmap:96 H264/90000 1054 a=fmtp:96 profile-level-id=42e016 1055 a=sendonly 1056 a=mid:5 1057 a=label:enc2 1058 m=video 0 RTP/AVP 96 1059 m=video 6010 RTP/AVP 96 1060 a=rtpmap:96 H264/90000 1061 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1062 a=recvonly 1063 a=mid:7 1064 m=video 6012 RTP/AVP 96 1065 a=rtpmap:96 H264/90000 1066 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1067 a=recvonly 1068 a=mid:8 1070 Bob receives Alice's message CLUE CONFIGURE 2 and sends CLUE RESPONSE 1071 2 to ack its reception. Bob does not yet send the Capture Encodings 1072 specified, because he hasn't yet received and processed Alice's SDP 1073 answer and negotiated the ability to send these streams. 1075 Finally, on receiving SIP 200 OK 3 Bob is now able to send the two 1076 streams of video Alice requested - this is illustrated as MEDIA 3. 1078 Both sides of the call are now sending multiple video streams with 1079 their sources defined via CLUE negotiation. As the call progresses 1080 either side can send new Advertisement or Configure message or new 1081 SDP offer/answers to add, remove or change what they have available 1082 or want to receive. 1084 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 1086 In this brief example Alice is a CLUE-capable Endpoint making a call 1087 to Bob, who is not CLUE-capable (i.e. is not able to use the CLUE 1088 protocol). 1090 +----------+ +-----------+ 1091 | EP1 | | EP2 | 1092 | | | | 1093 +----+-----+ +-----+-----+ 1094 | | 1095 | | 1096 | SIP INVITE 1 | 1097 |--------------------------------->| 1098 | | 1099 | | 1100 | 200 0K 1 | 1101 |<---------------------------------| 1102 | | 1103 | | 1104 | ACK 1 | 1105 |--------------------------------->| 1106 | | 1107 | | 1108 | | 1109 |<########### MEDIA 1 ############>| 1110 | 1 video A->B, 1 video B->A | 1111 |<################################>| 1112 | | 1113 | | 1114 | | 1115 | | 1116 v v 1118 In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP 1119 body the basic audio and video capabilities and the data channel as 1120 per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" 1121 media feature tag in the INVITE. A snippet of the SDP showing the 1122 grouping attribute and the video "m=" line are shown below. Alice 1123 has included a "CLUE" group, and included the mid corresponding to a 1124 data channel in the group (3). Note that Alice has chosen not to 1125 include any CLUE-controlled media in the initial offer - the mid 1126 value of the video line is not included in the "CLUE" group. 1128 ... 1129 a=group:CLUE 3 1130 ... 1131 m=video 6002 RTP/AVP 96 1132 a=rtpmap:96 H264/90000 1133 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1134 a=sendrecv 1135 a=mid:2 1136 ... 1137 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 1138 a=sctp-port: 5000 1139 a=dcmap:2 subprotocol="CLUE";ordered=true 1140 a=mid:3 1142 Bob is not CLUE-capable, and hence does not recognize the "CLUE" 1143 semantic for grouping attribute, nor does he support the data 1144 channel. IN SIP 200 OK 1 he responds with an answer with audio and 1145 video, but with the data channel zeroed. 1147 From the lack of the data channel and grouping framework Alice 1148 understands that Bob does not support CLUE, or does not wish to use 1149 it. Both sides are now able to send a single audio and video stream 1150 to each other. Alice at this point begins to send her fallback 1151 video: in this case likely a switched view from whichever camera 1152 shows the current loudest participant on her side. 1154 10. Acknowledgements 1156 The team focusing on this draft consists of: Roni Even, Rob Hansen, 1157 Christer Holmberg, Paul Kyzivat, Simon Pietro-Romano, Roberta Presta. 1159 Christian Groves and Jonathan Lennox have contributed detailed 1160 comments and suggestions. 1162 11. IANA Considerations 1164 11.1. New SDP Grouping Framework Attribute 1166 This document registers the following semantics with IANA in the 1167 "Semantics for the "group" SDP Attribute" subregistry (under the 1168 "Session Description Protocol (SDP) Parameters" registry per 1169 [RFC5888]: 1171 Semantics Token Reference 1172 ------------------------------------- ------ --------- 1173 CLUE-controlled m-line CLUE [this draft] 1175 11.2. New SIP Media Feature Tag 1177 This specification registers a new media feature tag in the SIP 1178 [RFC3264] tree per the procedures defined in [RFC2506] and [RFC3840]. 1180 Media feature tag name: sip.clue 1182 ASN.1 Identifier: 1.3.6.1.8.4.29 1184 Summary of the media feature indicated by this tag: This feature tag 1185 indicates that the device supports CLUE-controlled media. 1187 Values appropriate for use with this feature tag: Boolean. 1189 The feature tag is intended primarily for use in the following 1190 applications, protocols, services, or negotiation mechanisms: 1192 This feature tag is most useful in a communications application for 1193 describing the capabilities of a device to use the CLUE control 1194 protocol to negotiate the use of multiple media streams. 1196 Related standards or documents: [this draft] 1198 Security Considerations: Security considerations for this media 1199 feature tag are discussed in Section 12 of [this draft]. 1201 Name(s) & email address(es) of person(s) to contact for further 1202 information: 1204 o CLUE workgroup: clue@ietf.org 1206 o CLUE chairs: clue-chairs@ietf.org 1208 Intended usage: COMMON 1210 12. Security Considerations 1212 CLUE makes use of a number of protocols and mechanisms, either 1213 defined by CLUE or long-standing. The security considerations 1214 section of the CLUE Framework [I-D.ietf-clue-framework] addresses the 1215 need to secure these mechanisms by following the recommendations of 1216 the individual protocols. 1218 Beyond the need to secure the constituent protocols, the use of CLUE 1219 does impose additional security concerns. One area of increased risk 1220 involves the potential for a malicious party to subvert a CLUE- 1221 capable device to attack a third party by driving large volumes of 1222 media (particularly video) traffic at them by establishing a 1223 connection to the CLUE-capable device and directing the media to the 1224 victim. While this is a risk for all media devices, a CLUE-capable 1225 device may allow the attacker to configure multiple media streams to 1226 be sent, significantly increasing the volume of traffic directed at 1227 the victim. 1229 This attack can be prevented by ensuring that the media recipient 1230 intends to receive the media packets. As such all CLUE-capable 1231 devices MUST support key negotiation and receiver intent assurance 1232 via DTLS [RFC5763] on CLUE-controlled RTP "m=" lines. All CLUE- 1233 controlled RTP "m" lines must be secured and implemented using 1234 mechanisms such as SRTP [RFC3711]; no specific security mechanisms 1235 are made mandatory to use due to the issues addressed in [RFC7202]. 1236 Due to the requirements of backwards compatibility, this is not a 1237 mandatory requirement for non-CLUE-controlled "m=" lines. 1239 CLUE also defines a new media feature tag that indicates CLUE 1240 support. This tag may be present even in non-CLUE calls, which 1241 increases the metadata available about the sending device, which can 1242 help an attacker differentiate between multiple devices and help them 1243 identify otherwise anonymised users via the fingerprint of features 1244 their device supports. To prevent this, SIP signaling SHOULD always 1245 be encrypted using TLS [RFC5630]. 1247 13. Change History 1249 -08: Revision by Rob Hansen 1251 * Spelling and grammar fixes from Paul and Christian gratefully 1252 adopted 1254 * Expanded the section on disabling CLUE mid-call to make 1255 explicit the actions required to disable the CLUE channel 1256 gracefully, or to handle someone else doing the same. 1258 * Expanded the section on disabling CLUE mid-call to make 1259 explicit the actions required to disable the CLUE channel 1260 gracefully, or to handle someone else doing the same. 1262 -07: Revision by Rob Hansen 1264 * Removed the entire 'Media line directionality' section as a 1265 discussion of the pros/cons of using bidirectional vs 1266 unidirectional schemes wasn't suitable for a finalised version. 1267 The unidirectionality requirement is covered normatively in an 1268 earlier section. 1270 * BUNDLE no longer includes an address synchronisation step so 1271 the suggestion to wait until that done has been replaced with 1272 some general language about following any negotiated 1273 extensions. 1275 * Added OPTIONS negotiation to the example flow, and revised the 1276 flow to ensure it matched protocol document. 1278 * Section on not sending CLUE control media until CLUE 1279 negotiation completes narrowed to notify that only RTP should 1280 not be sent until negotiation completes and add RTCP to the 1281 list of things that should be sent as normal, in line with 1282 a=inactive. 1284 * Make explicit that m=recvonly lines don't need to have a label, 1285 as only m=sendonly lines are referenced by CLUE protocol 1286 messages. 1288 * Fix formatting of IANA sections. Improve syntax of feature tag 1289 section in line with Paul's suggestions. Definition of feature 1290 tag narrowed to be multiple media lines *negotiated via CLUE 1291 protocol* rather than more generic 'multiple media lines'. 1293 * General corrections to grammar, spelling and readability based 1294 on Christian, Paul and Mark; in many cases suggested text was 1295 gratefully accepted. 1297 -06: Revision by Rob Hansen 1299 * State machine interactions updated to match versions in -04 of 1300 protocol doc. 1302 * Section on encoding updated to specify both encID and 1303 encodingID from data model doc. 1305 * Removed the limitations on describing H264 encoding limits 1306 using SDP syntax as an open issue. 1308 * Previous draft had SRTP and DTLS mandatory to implement and to 1309 use on CLUE- controlled m lines. Current version has DTLS 1310 mandatory to implement, and 'security' mandatory to use but 1311 does not define what that security is. 1313 * Terminology reference to framework doc reinforced. All 1314 terminology that duplicates framework removed. All text 1315 updated with capitalisation that matches framework document's 1316 terminology. 1318 * SDP example syntax updated to match that of ietf-clue- 1319 datachannel and hence ietf-mmusic-data-channel-sdpneg. 1321 -05: Revision by Rob Hansen 1323 * SRTP/DTLS made mandatory for CLUE-controlled media lines. 1325 * IANA consideration section added (text as proposed by Christian 1326 Groves). 1328 * Includes provision for dependent streams on seperate "m" lines 1329 having the same encID as their parent "m" line. 1331 * References to putting CLUE-controlled media and data channels 1332 in more than one CLUE group removed, since the document no 1333 longer supports using more than one CLUE group. 1335 * Section on CLUE controlled media restrictions still applying 1336 even if the call does not end up being CLUE enabled being 1337 rewritten to hopefully be clearer. 1339 * Other minor syntax improvements. 1341 -04: Revision by Rob Hansen 1343 * Updated DTLS/SCTP channel syntax in examples to fix errors and 1344 match latest format defined in draft-ietf-mmusic-sctp-sdp-07. 1346 * Clarified the behaviour if an SDP offer includes a CLUE- 1347 controlled "m" line and the answer accepts that "m" line but 1348 without CLUE control of that line. 1350 * Added a new section on the sending and receiving of CaptureIDs 1351 in RTP and RTCP. Includes a section on the necessity of the 1352 receiver coping with unexpected CaptureIDs (or the lack 1353 thereof) due to MCCs being redefined in new Advertisement 1354 messages. 1356 * Added reminder on IANA section on registering grouping semantic 1357 and media feature tag, removed the less formal sections that 1358 did the same job. 1360 * Fixed and clarified issues raised by Christian's document 1361 review. 1363 * Added a number of security considerations. 1365 -03: Revision by Rob Hansen 1367 * Clarified text on not rejecting messages because they contain 1368 unknown encIDs. 1370 * Removed normative language in section on accepting/rejecting 1371 non-CLUE-controlled media in the initial answer. 1373 * Example SDP updated to include the data channel "m" lines. 1375 * Example call flow updated to show disablement of non-CLUE- 1376 controlled media once CLUE-controlled media is flowing. 1378 -02: Revision by Rob Hansen 1380 * Added section on not accepting non-CLUE-controlled "m" lines in 1381 the initial answer when CLUE is to be negotiated. 1383 * Removed previous language attempting to describe media 1384 restrictions for CLUE-controlled "m" lines that had not been 1385 configured, and replaced it with much more accurate 'treat as 1386 "a=inactive" was set'. 1388 * Made label element mandatory for CLUE-controlled media (was 1389 previously "SHOULD include", but there didn't seem a good 1390 reason for this - anyone wishing to include the "m" line but 1391 not immediately use it in CLUE can simply leave it out of the 1392 .) 1394 * Added a section on the specifics of relating encodings in SDP 1395 to elements in the CLUE protocol, including the fact 1396 that both Advertisement and Configure messages reference the 1397 *encoding* (eg, in the Configure case the sender of the 1398 Configure message includes the labels of the recipient's "m" 1399 lines as their contents). 1401 * Minor revisions to the section on complying with normative SDP/ 1402 CLUEstate machine language to clarify that these were not new 1403 normative language, merely that existing normative language 1404 still applies. 1406 * Removed appendices which previously contained information to be 1407 transferred to the protocol and data channel drafts. Removed 1408 other text that discussed alternatives to the current approach. 1410 * Cleaned up some 'todo' text. 1412 -01: Revision by Rob Hansen 1414 * Revised terminology - removed the term 'CLUE-enabled' device as 1415 insufficiently distinct from 'CLUE-capable' and instead added a 1416 term for 'CLUE-enabled' calls. 1418 * Removed text forbidding RTCP and instead added text that ICE/ 1419 DTLS negotiation for CLUE controlled media must be done as 1420 normal irrespective of CLUE negotiation. 1422 * Changed 'sip.telepresence' to 'sip.clue' and 'TELEPRESENCE' 1423 grouping semantic back to CLUE. 1425 * Made it mandatory to have exactly one mid corresponding to a 1426 data channel in a CLUE group 1428 * Forbade having multiple CLUE groups unless a specification for 1429 doing so is published. 1431 * Refactored SDP-related text; previously the encoding 1432 information had been in the "initial offer" section despite the 1433 fact that we recommend that the initial offer doesn't actually 1434 include any encodings. I moved the specifications of encodings 1435 and how they're received to an earlier, seperate section. 1437 * Added text on how the state machines in CLUE and SDP are 1438 allowed to affect one another, and further recommendations on 1439 how a device should handle the sending of CLUE and SDP changes. 1441 -00: Revision by Rob Hansen 1443 * Submitted as -00 working group document 1445 draft-kyzivat-08: Revisions by Rob Hansen 1447 * Added media feature tag for CLUE support ('sip.telepresence') 1449 * Changed grouping semantic from 'CLUE' to 'TELEPRESENCE' 1451 * Restructured document to be more centred on the grouping 1452 semantic and its use with O/A 1454 * Lots of additional text on usage of the grouping semantic 1456 * Stricter definition of CLUE-controlled m lines and how they 1457 work 1459 * Some additional text on defining what happens when CLUE 1460 supports is added or removed 1462 * Added details on when to not send RTCP for CLUE-controlled "m" 1463 lines. 1465 * Added a section on using BUNDLE with CLUE 1467 * Updated data channel references to point at new WG document 1468 rather than indivual draft 1470 draft-kyzivat-07: Revisions by Rob Hansen 1472 * Removed the text providing arguments for encoding limits being 1473 in SDP and encoding groups in the CLUE protocol in favor of the 1474 specifics of how to negotiate encodings in SDP 1476 * Added normative language on the setting up of a CLUE call, and 1477 added sections on mid-call changes to the CLUE status. 1479 * Added references to [I-D.ietf-clue-datachannel] where 1480 appropriate. 1482 * Added some terminology for various types of CLUE and non-CLUE 1483 states of operation. 1485 * Moved language related to topics that should be in 1486 [I-D.ietf-clue-datachannel] and [I-D.ietf-clue-protocol], but 1487 that has not yet been resolved in those documents, into an 1488 appendix. 1490 draft-kyzivat-06: Revisions by Rob Hansen 1492 * Removed CLUE message XML schema and details that are now in 1493 draft-presta-clue-protocol 1495 * Encoding limits in SDP section updated to note that this has 1496 been investigated and discussed and is the current working 1497 assumption of the WG, though consensus has not been fully 1498 achieved. 1500 * A section has also been added on the current mandation of 1501 unidirectional "m" lines. 1503 * Updated CLUE messaging in example call flow to match draft- 1504 presta-clue-protocol-03 1506 draft-kyzivat-05: Revisions by pkyzivat: 1508 * Specified versioning model and mechanism. 1510 * Added explicit response to all messages. 1512 * Rearranged text to work with the above changes. (Which 1513 rendered diff almost useless.) 1515 draft-kyzivat-04: Revisions by Rob Hansen: ??? 1517 draft-kyzivat-03: Revisions by pkyzivat: 1519 * Added a syntax section with an XML schema for CLUE messages. 1520 This is a strawhorse, and is very incomplete, but it 1521 establishes a template for doing this based on elements defined 1522 in the data model. (Thanks to Roberta for help with this!) 1524 * Did some rewording to fit the syntax section in and reference 1525 it. 1527 * Did some relatively minor restructuring of the document to make 1528 it flow better in a logical way. 1530 draft-kyzivat-02: A bunch of revisions by pkyzivat: 1532 * Moved roberta's call flows to a more appropriate place in the 1533 document. 1535 * New section on versioning. 1537 * New section on NAK. 1539 * A couple of possible alternatives for message acknowledgment. 1541 * Some discussion of when/how to signal changes in provider 1542 state. 1544 * Some discussion about the handling of transport errors. 1546 * Added a change history section. 1548 These were developed by Lennard Xiao, Christian Groves and Paul, 1549 so added Lennard and Christian as authors. 1551 draft-kyzivat-01: Updated by roberta to include some sample call 1552 flows. 1554 draft-kyzivat-00: Initial version by pkyzivat. Established general 1555 outline for the document, and specified a few things thought to 1556 represent wg consensus. 1558 14. References 1560 14.1. Normative References 1562 [I-D.ietf-clue-framework] 1563 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 1564 for Telepresence Multi-Streams", draft-ietf-clue- 1565 framework-25 (work in progress), January 2016. 1567 [I-D.ietf-clue-data-model-schema] 1568 Presta, R. and S. Romano, "An XML Schema for the CLUE data 1569 model", draft-ietf-clue-data-model-schema-13 (work in 1570 progress), March 2016. 1572 [I-D.ietf-clue-protocol] 1573 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 1574 clue-protocol-06 (work in progress), October 2015. 1576 [I-D.ietf-clue-datachannel] 1577 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1578 clue-datachannel-11 (work in progress), November 2015. 1580 [I-D.ietf-clue-rtp-mapping] 1581 Even, R. and J. Lennox, "Mapping RTP streams to CLUE media 1582 captures", draft-ietf-clue-rtp-mapping-06 (work in 1583 progress), January 2016. 1585 [I-D.ietf-mmusic-sctp-sdp] 1586 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 1587 Control Transmission Protocol (SCTP)-Based Media Transport 1588 in the Session Description Protocol (SDP)", draft-ietf- 1589 mmusic-sctp-sdp-16 (work in progress), February 2016. 1591 [I-D.ietf-mmusic-data-channel-sdpneg] 1592 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1593 and J. Marcon, "SDP-based Data Channel Negotiation", 1594 draft-ietf-mmusic-data-channel-sdpneg-08 (work in 1595 progress), February 2016. 1597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1598 Requirement Levels", BCP 14, RFC 2119, 1599 DOI 10.17487/RFC2119, March 1997, 1600 . 1602 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1603 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1604 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1605 . 1607 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1608 Protocol (SDP) Label Attribute", RFC 4574, 1609 DOI 10.17487/RFC4574, August 2006, 1610 . 1612 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1613 for Establishing a Secure Real-time Transport Protocol 1614 (SRTP) Security Context Using Datagram Transport Layer 1615 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1616 2010, . 1618 14.2. Informative References 1620 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1621 Registration Procedure", BCP 31, RFC 2506, 1622 DOI 10.17487/RFC2506, March 1999, 1623 . 1625 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1626 A., Peterson, J., Sparks, R., Handley, M., and E. 1627 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1628 DOI 10.17487/RFC3261, June 2002, 1629 . 1631 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1632 with Session Description Protocol (SDP)", RFC 3264, 1633 DOI 10.17487/RFC3264, June 2002, 1634 . 1636 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1637 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1638 2002, . 1640 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1641 "Indicating User Agent Capabilities in the Session 1642 Initiation Protocol (SIP)", RFC 3840, 1643 DOI 10.17487/RFC3840, August 2004, 1644 . 1646 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1647 (ICE): A Protocol for Network Address Translator (NAT) 1648 Traversal for Offer/Answer Protocols", RFC 5245, 1649 DOI 10.17487/RFC5245, April 2010, 1650 . 1652 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1653 Initiation Protocol (SIP)", RFC 5630, 1654 DOI 10.17487/RFC5630, October 2009, 1655 . 1657 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1658 Protocol (SDP) Grouping Framework", RFC 5888, 1659 DOI 10.17487/RFC5888, June 2010, 1660 . 1662 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1663 Payload Format for H.264 Video", RFC 6184, 1664 DOI 10.17487/RFC6184, May 2011, 1665 . 1667 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 1668 Framework: Why RTP Does Not Mandate a Single Media 1669 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 1670 2014, . 1672 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1673 Holmberg, C., Alvestrand, H., and C. Jennings, 1674 "Negotiating Media Multiplexing Using the Session 1675 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1676 negotiation-27 (work in progress), February 2016. 1678 [I-D.ietf-rtcweb-data-channel] 1679 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1680 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1681 progress), January 2015. 1683 Authors' Addresses 1685 Paul Kyzivat 1687 Email: pkyzivat@alum.mit.edu 1689 Lennard Xiao 1690 Huawei 1692 Email: lennard.xiao@huawei.com 1693 Christian Groves 1694 Huawei 1696 Email: Christian.Groves@nteczone.com 1698 Robert Hansen 1699 Cisco Systems 1701 Email: rohanse2@cisco.com