idnits 2.17.1 draft-ietf-clue-signaling-02.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-datachannel], [I-D.presta-clue-protocol]), 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: The primary implication of this is that a device may receive an SDP with a CLUE encoding it does not yet have capture information for, or receive a CLUE CONFIGURE message specifying a capture encoding for which the far end has not negotiated a media stream in SDP. An implementation that is CLUE messages contain an which is used to identify a specific encoding or captureEncoding in SDP. The non-atomic nature of CLUE negotiation means that a sender may wish to send a new ADVERTISEMENT before the corresponding SDP message. As such the sender of the CLUE message MAY include an which does not currently match a CLUE-controlled "m" line label in SDP; A CLUE-capable implementation MUST not reject CLUE protocol messages that contain elements that do not match an id in SDP. -- The document date (July 4, 2014) is 3577 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.presta-clue-data-model-schema' is defined on line 1268, but no explicit reference was found in the text == Unused Reference: 'I-D.groves-clue-latent-config' is defined on line 1283, but no explicit reference was found in the text == Unused Reference: 'I-D.tuexen-tsvwg-sctp-dtls-encaps' is defined on line 1294, but no explicit reference was found in the text == Unused Reference: 'RFC4353' is defined on line 1320, but no explicit reference was found in the text == Unused Reference: 'RFC6120' is defined on line 1324, but no explicit reference was found in the text == Unused Reference: 'I-D.even-clue-sdp-clue-relation' is defined on line 1330, but no explicit reference was found in the text == Unused Reference: 'I-D.even-clue-rtp-mapping' is defined on line 1335, but no explicit reference was found in the text == Unused Reference: 'I-D.hansen-clue-sdp-interaction' is defined on line 1340, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-16 ** Downref: Normative reference to an Informational draft: draft-presta-clue-data-model-schema (ref. 'I-D.presta-clue-data-model-schema') == Outdated reference: A later version (-18) exists of draft-ietf-clue-datachannel-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel') ** 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-06 -- 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-07 Summary: 4 errors (**), 0 flaws (~~), 14 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: January 5, 2015 Huawei 6 R. Hansen 7 Cisco Systems 8 July 4, 2014 10 CLUE Signaling 11 draft-ietf-clue-signaling-02 13 Abstract 15 This document specifies how CLUE-specific signaling such as the CLUE 16 protocol [I-D.presta-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 January 5, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Media Feature Tag Definition . . . . . . . . . . . . . . . . . 5 58 4. SDP Grouping Framework CLUE Extension Semantics . . . . . . . 5 59 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. The CLUE data channel and the CLUE grouping semantic . . . 6 61 4.3. CLUE-controlled media and the CLUE grouping semantic . . . 6 62 4.4. SDP semantics for CLUE-controlled media . . . . . . . . . 6 63 4.4.1. Signalling CLUE Encodings . . . . . . . . . . . . . . 7 64 4.4.1.1. Referencing encodings in the CLUE protocol . . . . 7 65 4.4.1.2. Media line directionality . . . . . . . . . . . . 8 66 4.4.2. Negotiating receipt of CLUE capture encodings in 67 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 9 69 4.5.1. Generating the Initial Offer . . . . . . . . . . . . . 9 70 4.5.2. Generating the Answer . . . . . . . . . . . . . . . . 9 71 4.5.2.1. Negotiating use of CLUE and the CLUE data 72 channel . . . . . . . . . . . . . . . . . . . . . 9 73 4.5.2.2. Negotiating CLUE-controlled media . . . . . . . . 9 74 4.5.2.3. Negotating non-CLUE controlled media . . . . . . . 10 75 4.5.3. Processing the initial Offer/Answer negotiation . . . 10 76 4.5.3.1. Successful CLUE negotiation . . . . . . . . . . . 10 77 4.5.3.2. CLUE negotiation failure . . . . . . . . . . . . . 11 78 4.5.4. Modifying the session . . . . . . . . . . . . . . . . 11 79 4.5.4.1. Adding and removing CLUE-controlled media . . . . 11 80 4.5.4.2. Enabling CLUE mid-call . . . . . . . . . . . . . . 11 81 4.5.4.3. Disabling CLUE mid-call . . . . . . . . . . . . . 12 82 5. Interaction of CLUE protocol and SDP negotiations . . . . . . 12 83 5.1. Independence of SDP and CLUE negotiation . . . . . . . . . 12 84 5.2. Constraints on sending media . . . . . . . . . . . . . . . 13 85 5.3. Recommendations for operating with non-atomic 86 operations . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6. Multiplexing of CLUE-controlled media using BUNDLE . . . . . . 14 88 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 6.2. Usage of BUNDLE with CLUE . . . . . . . . . . . . . . . . 15 90 6.2.1. Generating the Initial Offer . . . . . . . . . . . . . 15 91 6.2.2. Bundle Address Synchronization . . . . . . . . . . . . 15 92 6.2.3. Multiplexing of the data channel and RTP media . . . . 15 93 7. Example: A call between two CLUE-capable endpoints . . . . . . 15 94 8. Example: A call between a CLUE-capable and non-CLUE 95 endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 9. CLUE requirements on SDP O/A . . . . . . . . . . . . . . . . . 25 98 10. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 25 99 11. CLUE over RTCWEB . . . . . . . . . . . . . . . . . . . . . . . 25 100 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 13. What else? . . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 103 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 104 16. Security Considerations . . . . . . . . . . . . . . . . . . . 26 105 17. Change History . . . . . . . . . . . . . . . . . . . . . . . . 26 106 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 107 18.1. Normative References . . . . . . . . . . . . . . . . . . . 29 108 18.2. Informative References . . . . . . . . . . . . . . . . . . 30 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 111 1. Introduction 113 To enable devices to participate in a telepresence call, selecting 114 the sources they wish to view, receiving those media sources and 115 displaying them in an optimal fashion, CLUE involves two principal 116 and inter-related protocol negotiations. SDP, conveyed via SIP, is 117 used to negotiate the specific media capabilities that can be 118 delivered to specific addresses on a device. Meanwhile, a CLUE 119 protocol [I-D.presta-clue-protocol], transported via a CLUE data 120 channel [I-D.ietf-clue-datachannel], is used to negotiate the capture 121 sources available, their attributes and any constraints in their use, 122 along which which captures the far end provides a device wishes to 123 receive. 125 Beyond negotiating the CLUE channel, SDP is also used to negotiate 126 the details of supported media streams and the maximum capability of 127 each of those streams. As the CLUE Framework 128 [I-D.ietf-clue-framework] defines a manner in which the media 129 provider expresses their maximum encoding capabilities, SDP is also 130 used to express the encoding limits for each potential encoding. 132 Backwards-compatibility is an important consideration of the 133 document: it is vital that a CLUE-capable device contacting a device 134 that does not support CLUE is able to fall back to a fully functional 135 non-CLUE call. The document also defines how a non-CLUE call may be 136 upgraded to CLUE in mid-call, and similarly how CLUE functionality 137 can be removed mid-call to return to a standard non-CLUE call. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 This document draws liberally from the terminology defined in the 146 CLUE Framework [I-D.ietf-clue-framework]. 148 Other terms introduced here: 150 CLUE data channel: A reliable, bidirectional, transport mechanism 151 used to convey CLUE messages. See [I-D.ietf-clue-datachannel] for 152 more details. 153 CLUE-capable device: A device that supports the CLUE data channel 154 [I-D.ietf-clue-datachannel], the CLUE protocol 155 [I-D.presta-clue-protocol] and the principles of CLUE negotiation, 156 and wishes to upgrade the call to CLUE-enabled status. 158 CLUE-enabled call: A call in which two CLUE-capable devices have 159 successfully negotiated support for a CLUE data channel in SDP. A 160 CLUE-enabled call is not necessarily immediately able to send 161 CLUE-controlled media; negotiation of the data channel and of the 162 CLUE protocol must complete first. Calls between two CLUE-capable 163 devices which have not yet successfully completed negotiation of 164 support for the CLUE data channel in SDP are not considered CLUE- 165 enabled. 166 Non-CLUE device: A device that supports standard SIP and SDP, but 167 either does not support CLUE, or that does but does not currently 168 wish to invoke CLUE capabilities. 169 CLUE-controlled media: A media "m" line that is under CLUE control; 170 the capture source that provides the media on this "m" line is 171 negotiated in CLUE. See Section 4 for details of how this control 172 is signalled in SDP. There is a corresponding "non-CLUE- 173 controlled" media term. 175 3. Media Feature Tag Definition 177 The "sip.clue" media feature tag indicates support for CLUE. A CLUE- 178 capable device SHOULD include this media feature tag in its REGISTER 179 requests and OPTION responses. It SHOULD also include the media 180 feature tag in INVITE and UPDATE [RFC3311] requests and responses. 182 Presence of the media feature tag in the contact field of a request 183 or response can be used to determine that the far end supports CLUE. 185 4. SDP Grouping Framework CLUE Extension Semantics 187 4.1. General 189 This section defines a new SDP Grouping Framework extension, CLUE. 191 The CLUE extension can be indicated using an SDP session-level 192 'group' attribute. Each SDP media "m" line that is included in this 193 group, using SDP media-level mid attributes, is CLUE-controlled, by a 194 CLUE data channel also included in this CLUE group. 196 Currently only support for a single CLUE group is specified. A 197 device MUST NOT include more than one CLUE group in its SDP unless it 198 is following a specification that defines how multiple CLUE channels 199 are defined, and is either able to determine that the other side of 200 the SDP exchange supports multiple CLUE channels, or is able to fail 201 gracefully in the event it does not. 203 4.2. The CLUE data channel and the CLUE grouping semantic 205 The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional 206 SCTP over DTLS channel used for the transport of CLUE messages. This 207 channel must be established before CLUE protocol messages can be 208 exchanged and CLUE-controlled media can be sent. 210 The data channel is a generic transport that is not specific to CLUE 211 - if a device wishes to use the CLUE protocol on the data channel it 212 MUST include a CLUE group in the SDP and include the "mid" of the "m" 213 line for the data channel in that group. A CLUE group MUST include 214 the "mid" of the "m" line for one (and only one) data channel, and 215 the "mid" of the "m" line of a data channel "mid" MUST NOT be 216 included in more than one CLUE group. 218 Presence of the data channel in a CLUE group in an SDP offer or 219 answer also serves, along with the "sip.clue" media feature tag, as 220 an indication that the device supports CLUE and wishes to upgrade the 221 call to include CLUE-controlled media. A CLUE-capable device SHOULD 222 include a data channel "m" line in offers and, when allowed by 223 [RFC3264], answers. 225 4.3. CLUE-controlled media and the CLUE grouping semantic 227 CLUE-controlled media lines in an SDP are "m" lines in which the 228 content of the media streams to be sent is negotiated via the CLUE 229 protocol [I-D.presta-clue-protocol]. For an "m" line to be CLUE- 230 controlled, its "mid" value MUST be included in a CLUE group. CLUE- 231 controlled media line "mid"s MUST NOT be included in more than one 232 CLUE group. 234 CLUE-controlled media is controlled by the CLUE protocol as 235 negotiated on the CLUE data channel with an "mid" included in the 236 CLUE group. If negotiation of the data channel in SDP failed due to 237 lack of CLUE support by the remote device or for any other reason the 238 other "m" lines in the group are still considered CLUE-controlled and 239 under all the restrictions of CLUE-controlled media specified in this 240 document. 242 "m" lines not specified as under CLUE control follow normal rules for 243 media streams negotiated in SDP as defined in documents such as 244 [RFC3264]. 246 4.4. SDP semantics for CLUE-controlled media 247 4.4.1. Signalling CLUE Encodings 249 The CLUE Framework [I-D.ietf-clue-framework] defines the concept of 250 "encodings", which represent the sender's encode ability. Each 251 encoding the media provider wishes to signal is signalled via an "m" 252 line of the appropriate media type, which MUST be marked as sendonly 253 with the "a=sendonly" attribute or as inactive with the "a=inactive" 254 attribute. 256 The encoder limits of active (eg, "a=sendonly") encodings can then be 257 expressed using existing SDP syntax. For instance, for H.264 see 258 Table 6 in [RFC6184] for a list of valid parameters for representing 259 encoder sender stream limits. 261 These encodings are CLUE-controlled and hence MUST include an "mid" 262 in a CLUE group as defined above. 264 As well as the normal restrictions defined in [RFC3264] the stream 265 MUST be treated as if the "m" line direction attribute had been set 266 to "a=inactive" until the media provider has received a valid CLUE 267 CONFIGURE message specifying the capture to be used for this stream. 268 This means that media packets MUST NOT be sent until configuration is 269 complete, while non-media packets such as STUN and DTLS MUST be sent 270 as normal if negotiated. 272 Every "m" line representing a CLUE encoding MUST contain a "label" 273 attribute as defined in [RFC4574]. This label is used to identify 274 the encoding by the sender in CLUE ADVERTISEMENT messages and by the 275 receiver in CLUE CONFIGURE messages. Each label used for a CLUE- 276 controlled "m" line MUST be different from the label on all other "m" 277 lines in the same CLUE group in the SDP message. 279 4.4.1.1. Referencing encodings in the CLUE protocol 281 CLUE encodings are defined in SDP, but can be referenced from CLUE 282 protocol messages - this is how the protocol defines which encodings 283 are part of an encoding group (in ADVERTISEMENT messages) and which 284 encoding with which to encode a specific capture (in CONFIGURE 285 messages). The labels on the CLUE-controlled "m" lines are the 286 references that are used in the CLUE protocol. 288 Each element in a CLUE ADVERTISEMENT message SHOULD 289 represents an encoding defined in SDP; the specific encoding 290 referenced is a CLUE-controlled "m" line in the most recent SDP sent 291 by the sender of the ADVERTISMENT message with a label value 292 corresponding to the text content of the . 294 Similarly, each element in a CLUE CONFIGURE message SHOULD 295 represents an encoding defined in SDP; the specific encoding 296 referenced is a CLUE-controlled "m" line in the most recent SDP 297 received by the sender of the CONFIGURE message with a label value 298 corresponding to the text content of the . 300 Note that the non-atomic nature of SDP/CLUE protocol interaction may 301 mean that there are temporary periods where an in a CLUE 302 message does not reference an SDP "m" line, or where an encoding 303 represented in SDP is not referenced in a CLUE protocol message. See 304 Section 5 for specifics. 306 4.4.1.2. Media line directionality 308 Presently, this specification mandates that CLUE-controlled "m"-lines 309 must be unidirectional. This is because setting "m"-lines to 310 "a=sendonly" allows the encoder limits to be expressed, whereas in 311 other cases codec attributes express the receive capabilities of a 312 media line. 314 It is possible that in future versions of this draft or its successor 315 this restriction will be relaxed. If a device does not feel there is 316 a benefit to expressing encode limitations, or if there are no 317 meaningful codec-specific limitations to express (such as with many 318 audio codecs) there are benefits to allowing bidirectional "m"-lines. 319 With bidirectional media lines recipients do not always need to 320 create a new offer to add their own "m"-lines to express their send 321 capabilities; if they can produce an equal or lesser number of 322 streams to send then they may not need additional "m"-lines. 324 However, at present the need to express encode limitations and the 325 wish to simplify the offer/answer procedure means that for the time 326 being only unidirectional media lines are allowed for CLUE-controlled 327 media. The highly asymmetric nature of CLUE means that the 328 probability of the recipient of the initial offer needing to make 329 their own offer to add additional "m"-lines is significantly higher 330 than it is for most other SIP call scenarios, in which there is a 331 tendancy for both sides to have similar numbers of potential audio 332 and video streams they can send. 334 4.4.2. Negotiating receipt of CLUE capture encodings in SDP 336 A receiver who wishes to receive a CLUE stream via a specific 337 encoding requires an "a=recvonly" "m" line that matches the 338 "a=sendonly" encoding. 340 These "m" lines are CLUE-controlled and hence MUST include their 341 "mid" in the CLUE group corresponding to the CLUE group of encoding 342 they wish to receive. 344 4.5. SDP Offer/Answer Procedures 346 4.5.1. Generating the Initial Offer 348 A CLUE-capable device sending an initial SDP offer of a SIP session 349 SHOULD include an "m" line for the data channel to convey the CLUE 350 protocol, along with a CLUE group containing the "mid" of the data 351 channel "m" line. 353 For interoperability with non-CLUE devices a CLUE-capable device 354 sending an initial SDP offer SHOULD NOT include any "m" line for 355 CLUE-controlled media beyond the "m" line for the CLUE data channel, 356 and SHOULD include at least one non-CLUE-controlled media "m" line. 358 If the device has evidence that the receiver is also CLUE-capable, 359 for instance due to receiving an initial INVITE with no SDP but 360 including a "sip.clue" media feature tag, the above recommendation is 361 waived, and the initial offer MAY contain "m" lines for CLUE- 362 controlled media. 364 With the same interoperability recommendations as for encodings, the 365 sender of the initial SDP offer MAY also include "a=recvonly" media 366 lines to preallocate "m" lines to receive media. Alternatively, it 367 MAY wait until CLUE protocol negotiation has completed before 368 including these lines in a new offer/answer exchange - see Section 5 369 for recommendations. 371 4.5.2. Generating the Answer 373 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 375 If the recipient is CLUE-capable and the initial offer contains both 376 an "m" line for a data channel and a CLUE group containing the "mid" 377 for that "m" line, they SHOULD negotiate data channel support for an 378 "m" line, and include the "mid" of that "m" line in a corresponding 379 CLUE group. 381 A CLUE-capable recipient that receives an "m" line for a data channel 382 but no corresponding CLUE group containing the "mid" of that "m" line 383 SHOULD include a corresponding data channel "m" line if there are any 384 other non-CLUE protocols it can convey over that channel, otherwise 385 it SHOULD NOT negotiate the data channel. 387 4.5.2.2. Negotiating CLUE-controlled media 389 If the initial offer contained "a=recvonly" CLUE-controlled media 390 lines the recipient SHOULD include corresponding "a=sendonly" CLUE- 391 controlled media lines, up to the maximum number of encodings it 392 wishes to advertise. As CLUE-controlled media, the "mid" of these 393 "m" lines must be included in the corresponding CLUE group. 395 If the initial offer contained "a=sendonly" CLUE-controlled media 396 lines the recipient MAY include corresponding "a=recvonly" CLUE- 397 controlled media lines, up to the maximum number of capture encodings 398 it wishes to receive. Alternatively, it MAY wait until CLUE protocol 399 negotiation has completed before including these lines in a new 400 offer/answer exchange - see Section 5 for recommendations. 402 4.5.2.3. Negotating non-CLUE controlled media 404 A CLUE-controlled device implementation MAY prefer to render initial, 405 single-stream audio and/or video for the user as rapidly as possible, 406 transitioning to CLUE-controlled media once that has been negotiated. 407 Alternatively, an implementation may wish to suppress initial media, 408 only providing media once the final, CLUE-controlled streams have 409 been negotiated. 411 If the receiver of the initial offer is in the latter category and 412 will be making the call CLUE-enabled with their SDP answer, they 413 SHOULD reject all non-CLUE-controlled media lines that relate to the 414 media they do not wish to receive in their SDP answer. 416 4.5.3. Processing the initial Offer/Answer negotiation 418 In the event that both offer and answer include a data channel "m" 419 line with a mid value included in corresponding CLUE groups CLUE has 420 been successfully negotiated and the call is now CLUE-enabled, 421 otherwise the call is not CLUE enabled. 423 4.5.3.1. Successful CLUE negotiation 425 In the event of successful CLUE enablement of the call, devices MUST 426 now begin negotiation of the CLUE channel, see 427 [I-D.ietf-clue-datachannel] for negotiation details. If negotiation 428 is successful, sending of CLUE protocol [I-D.presta-clue-protocol] 429 messages can begin. 431 A CLUE-capable device MAY choose not to send media on the non-CLUE- 432 controlled channels during the period in which control of the CLUE- 433 controlled media lines is being negotiated. However, a CLUE-capable 434 device MUST still be prepared to receive media on non-CLUE-controlled 435 media lines that have been successfully negotiated as defined in 436 [RFC3264]. 438 If either side of the call wishes to add additional CLUE-controlled 439 "m" lines to send or receive CLUE-controlled media they MAY now send 440 a SIP request with a new SDP offer. Note that if BUNDLE has been 441 successfully negotiated and a Bundle Address Synchronization offer is 442 required, the device to receive that offer SHOULD NOT generate a new 443 SDP offer until it has received that BAS offer. 445 4.5.3.2. CLUE negotiation failure 447 In the event that the negotiation of CLUE fails and the call is not 448 CLUE enabled in the initial offer/answer then CLUE is not in use in 449 the call, and the CLUE-capable devices MUST either revert to non-CLUE 450 behaviour or terminate the call. 452 4.5.4. Modifying the session 454 4.5.4.1. Adding and removing CLUE-controlled media 456 Subsequent offer/answer exchanges MAY add additional "m" lines for 457 CLUE-controlled media; in most cases at least one additional exchange 458 will be required before both sides have added all the encodings and 459 ability to receive encodings that they desire. Devices MAY delay 460 adding "a=recvonly" CLUE-controlled m-lines until after CLUE protocol 461 negotiation completes - see Section 5 for recommendations. 463 Subsequent offer/answer exchanges MAY also deactive "m" lines for 464 CLUE-controlled media. 466 Once CLUE media has been successfully negotiated devices SHOULD 467 ensure that non-CLUE-controlled media is deactived in cases where it 468 corresponds to CLUE-controlled media that has been successfully 469 negotiated. Implementations can decide if they wish to disable non- 470 CLUE controlled media once the call has been made CLUE enabled, or to 471 wait until sending of the CLUE-controlled media has been successfully 472 negotiated. 474 4.5.4.2. Enabling CLUE mid-call 476 A CLUE-capable device that receives an initial SDP offer from a non- 477 CLUE device SHOULD include a new data channel "m" line and 478 corresponding CLUE group in any subsequent offers it sends, to 479 indicate that it is CLUE-capable. 481 If, in an ongoing non-CLUE call, one or both sides of the call add 482 the CLUE data channel "m" line to their SDP and places the "mid" for 483 that channel in corresponding CLUE groups then the call is now CLUE- 484 enabled; negotiation of the data channel and subsequently the CLUE 485 protocol begin. 487 4.5.4.3. Disabling CLUE mid-call 489 If, in an ongoing CLUE-enabled call, an SDP offer-answer negotiation 490 completes in a fashion in which either the CLUE data channel was not 491 successfully negotiated or one side did not include the data channel 492 in a matching CLUE group then CLUE for this channel is disabled. In 493 the event that this occurs, CLUE is no longer enabled and sending of 494 all CLUE-controlled media associated with the corresponding CLUE 495 group MUST stop. 497 Note that this is distinct to cases where the CLUE data channel fails 498 or an error occurs on the CLUE protocol; see 499 [I-D.presta-clue-protocol] for details of media and state 500 preservation in this circumstance. 502 5. Interaction of CLUE protocol and SDP negotiations 504 Information about media streams in CLUE is split between two message 505 types: SDP, which defines media addresses and limits, and the CLUE 506 channel, which defines properties of capture devices available, scene 507 information and additional constraints. As a result certain 508 operations, such as advertising support for a new transmissible 509 capture with associated stream, cannot be performed atomically, as 510 they require changes to both SDP and CLUE messaging. 512 This section defines how the negotiation of the two protocols 513 interact, provides some recommendations on dealing with intermediary 514 stages in non-atomic operations, and mandates additional constraints 515 on when CLUE-configured media can be sent. 517 5.1. Independence of SDP and CLUE negotiation 519 To avoid the need to implement interlocking state machines with the 520 potential to reach invalid states if messages were to be lost, or be 521 rewritten en-route by middle boxes, the state machines in SDP and 522 CLUE operate independently. The state of the CLUE channel does not 523 restrict when an implementation may send a new SDP offer or answer, 524 and likewise the implementation's ability to send a new CLUE 525 ADVERTISEMENT or CONFIGURE message is not restricted by the results 526 of or the state of the most recent SDP negotiation. 528 The primary implication of this is that a device may receive an SDP 529 with a CLUE encoding it does not yet have capture information for, or 530 receive a CLUE CONFIGURE message specifying a capture encoding for 531 which the far end has not negotiated a media stream in SDP. An 532 implementation that is 533 CLUE messages contain an which is used to identify a specific 534 encoding or captureEncoding in SDP. The non-atomic nature of CLUE 535 negotiation means that a sender may wish to send a new ADVERTISEMENT 536 before the corresponding SDP message. As such the sender of the CLUE 537 message MAY include an which does not currently match a CLUE- 538 controlled "m" line label in SDP; A CLUE-capable implementation MUST 539 not reject CLUE protocol messages that contain elements that 540 do not match an id in SDP. 542 The current state of the CLUE participant or CLUE media provider/ 543 consumer state machines do not affect compliance with any of the 544 normative language of [RFC3264]. That is, they MUST NOT delay an 545 ongoing SDP exchange as part of a SIP server or client transaction; 546 an implementation MUST NOT delay an SDP exchange while waiting for 547 CLUE negotiation to complete or for a CONFIGURE message to arrive. 549 Similarly, a device in a CLUE-enabled call MUST NOT delay any 550 mandatory state transitions in the CLUE participant or media 551 provider/consumer state machines due to the presence or absence of an 552 ongoing SDP exchange. 554 A device with the CLUE participant state machine in the ACTIVE state 555 MAY choose not to move from CONF COMPLETED to PREPARING ADV (media 556 provider state machine) or from READY TO CONF to TRYING (media 557 consumer state machine) based on the SDP state. See 558 [I-D.presta-clue-protocol] for CLUE state machine specifics. 559 Similarly, a device MAY choose to delay initiating a new SDP exchange 560 based on the state of their CLUE state machines. 562 5.2. Constraints on sending media 564 While SDP and CLUE message states do not impose constraints on each 565 other, both impose constraints on the sending of media - CLUE- 566 controlled media MUST NOT be sent unless it has been negotiated in 567 both CLUE and SDP: an implementation MUST NOT send a specific CLUE 568 capture encoding unless its most recent SDP exchange contains an 569 active media channel for that encoding AND the far end has sent a 570 CLUE CONFIGURE message specifying a valid capture for that encoding. 572 5.3. Recommendations for operating with non-atomic operations 574 CLUE-capable devices MUST be able to handle states in which CLUE 575 messages make reference to EncodingIDs that do not match the most 576 recently received SDP, irrespective of the order in which SDP and 577 CLUE messages are received. While these mis-matches will usually be 578 transitory a device MUST be able to cope with such mismatches 579 remaining indefinitely. However, this document makes some 580 recommendations on message ordering for these non-atomic transitions. 582 CLUE-capable devices SHOULD ensure that any inconsistencies between 583 SDP and CLUE signalling are temporary by sending updated SDP or CLUE 584 messages as soon as the relevant state machines and other constraints 585 permit. 587 Generally, implementations that receive messages for which they have 588 incomplete information SHOULD wait until they have the corresponding 589 information they lack before sending messages to make changes related 590 to that information. For instance, an implementation that receives a 591 new SDP offer with three new "a=sendonly" CLUE "m" lines that has not 592 received the corresponding CLUE ADVERTISEMENT providing the capture 593 information for those streams SHOULD NOT include corresponding 594 "a=recvonly" lines in its answer, but instead should make a new SDP 595 offer when and if a new ADVERTISEMENT arrives with captures relevant 596 to those encodings. 598 Because of the constraints of offer/answer and because new SDP 599 negotiations are generally more 'costly' than sending a new CLUE 600 message, implementations needing to make changes to both channels 601 SHOULD prioritize sending the updated CLUE message over sending the 602 new SDP message. The aim is for the recipient to receive the CLUE 603 changes before the SDP changes, allowing the recipient to send their 604 SDP answers without incomplete information, reducing the number of 605 new SDP offers required. 607 6. Multiplexing of CLUE-controlled media using BUNDLE 609 6.1. Overview 611 A CLUE call may involve sending and/or receiving significant numbers 612 of media streams. Conventionally, media streams are sent and 613 received on unique ports. However, each seperate port used for this 614 purpose may impose costs that a device wishes to avoid, such as the 615 need to open that port on firewalls and NATs, the need to collect ICE 616 candidates [RFC5245], etc. 618 The BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] extension can be 619 used to negotiate the multiplexing of multiple media lines onto a 620 single 5-tuple for sending and receiving media, allowing devices in 621 calls to another BUNDLE-supporting device to potentially avoid some 622 of the above costs. 624 While CLUE-capable devices MAY support the BUNDLE extension for this 625 purpose supporting the extension is not mandatory for a device to be 626 CLUE-compliant. 628 6.2. Usage of BUNDLE with CLUE 630 This specification imposes no additional requirements or restrictions 631 on the usage of BUNDLE when used with CLUE. There is no restriction 632 on combining CLUE-controlled media lines and non-CLUE-controlled 633 media lines in the same BUNDLE group or in multiple such groups. 634 However, there are several steps an implementation may wish to 635 ameliorate the cost and time requirements of extra SDP offer/answer 636 exchanges between CLUE and BUNDLE. 638 6.2.1. Generating the Initial Offer 640 BUNDLE mandates that the initial SDP offer MUST use a unique address 641 for each m-line with a non-zero port. Because CLUE implementations 642 generarlly will not include CLUE-controlled media lines with the 643 exception of the data channel CLUE devices that support large numbers 644 of streams can avoid ever having to open large numbers of ports if 645 they successfully negotiate BUNDLE. 647 6.2.2. Bundle Address Synchronization 649 When using BUNDLE the initial offerer may be mandated to send a 650 Bundle Address Synchronisation offer. If the initial offerer also 651 followed the recommendation of not including CLUE-controlled media 652 lines in their offer, they MAY choose to include them in this 653 subsequent offer. In this circumstance the BUNDLE specification 654 recommends that the offerer does not "modify SDP parameters that 655 could get the answerer to reject the BAS offer". Including new CLUE- 656 controlled media lines using codecs and other attributes used in 657 existing media lines should not increase the chance of the answerer 658 rejecting the BAS offer; implementations should consider carefully 659 before including new codecs or other new SDP attributes in these 660 CLUE-controlled media lines. 662 6.2.3. Multiplexing of the data channel and RTP media 664 BUNDLE-supporting CLUE-capable devices MAY include the data channel 665 in the same BUNDLE group as RTP media. In this case the device MUST 666 be able to demultiplex the various transports - see section 7.2 of 667 the BUNDLE draft [I-D.ietf-mmusic-sdp-bundle-negotiation]. If the 668 BUNDLE group includes other protocols than the data channel 669 transported via DTLS the device MUST also be able to differentiate 670 the various protocols. 672 7. Example: A call between two CLUE-capable endpoints 674 This example illustrates a call between two CLUE-capable endpoints. 676 Alice, initiating the call, is a system with three cameras and three 677 screens. Bob, receiving the call, is a system with two cameras and 678 two screens. A call-flow diagram is presented, followed by an 679 summary of each message. 681 To manage the size of this section only video is considered, and SDP 682 snippets only illustrate video 'm' lines. ACKs are not discussed. 683 Note that BUNDLE is not in use. 685 +----------+ +-----------+ 686 | Alice | | Bob | 687 | | | | 688 +----+-----+ +-----+-----+ 689 | | 690 | | 691 | SIP INVITE 1 (BASIC SDP+COMEDIA) | 692 |--------------------------------->| 693 | | 694 | | 695 | SIP 200 OK 1 (BASIC SDP+COMEDIA) | 696 |<---------------------------------| 697 | | 698 | | 699 | SIP ACK 1 | 700 |--------------------------------->| 701 | | 702 | | 703 | | 704 |<########### MEDIA 1 ############>| 705 | 1 video A->B, 1 video B->A | 706 |<################################>| 707 | | 708 | | 709 | | 710 |<================================>| 711 | CLUE CTRL CHANNEL ESTABLISHED | 712 |<================================>| 713 | | 714 | | 715 | CLUE ADVERTISEMENT 1 | 716 |*********************************>| 717 | | 718 | | 719 | CLUE ADVERTISEMENT 2 | 720 |<*********************************| 721 | | 722 | | 723 | SIP INVITE 2 (+3 sendonly) | 724 |--------------------------------->| 725 | | 726 | | 727 | CLUE CONFIGURE 1 | 728 |<*********************************| 729 | | 730 | | 731 | CLUE RESPONSE 1 | 732 |*********************************>| 733 | | 734 | | 735 | SIP 200 OK 2 (+2 recvonly) | 736 |<---------------------------------| 737 | | 738 | | 739 | SIP ACK 2 | 740 |--------------------------------->| 741 | | 742 | | 743 | | 744 |<########### MEDIA 2 ############>| 745 | 2 video A->B, 1 video B->A | 746 |<################################>| 747 | | 748 | | 749 | SIP INVITE 3 (+2 sendonly) | 750 |<---------------------------------| 751 | | 752 | | 753 | CLUE CONFIGURE 2 | 754 |*********************************>| 755 | | 756 | | 757 | CLUE RESPONSE 2 | 758 |<*********************************| 759 | | 760 | | 761 | SIP 200 OK 3 (+2 recvonly) | 762 |--------------------------------->| 763 | | 764 | | 765 | | 766 | SIP ACK 3 | 767 |<---------------------------------| 768 | | 769 | | 770 | | 771 |<########### MEDIA 3 ############>| 772 | 2 video A->B, 2 video B->A | 773 |<################################>| 774 | | 775 | | 776 | | 777 v v 779 In INVITE 1, Alice sends Bob a SIP INVITE including in the SDP body 780 the basilar audio and video capabilities ("BASIC SDP") and the 781 information needed for opening a control channel to be used for CLUE 782 protocol messages exchange, according to what is envisioned in the 783 COMEDIA approach ("COMEDIA") for DTLS/SCTP channel 784 [I-D.ietf-mmusic-sctp-sdp]. A snippet of the SDP showing the 785 grouping attribute and the video m-line are shown below (mid 3 786 represents the CLUE channel): 788 ... 789 a=group:CLUE 3 790 ... 791 m=video 6002 RTP/AVP 96 792 a=rtpmap:96 H264/90000 793 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 794 a=sendrecv 795 a=mid:2 797 Bob responds with a similar SDP (200 OK 1); due to their similiarity 798 no SDP snippet is shown here. Alice and Bob are each able to send a 799 single audio and video stream (whether they choose to send this 800 initial media before CLUE has been negotiated is implementation- 801 dependent). This is illustrated as MEDIA 1. 803 With the successful initial O/A Alice and Bob are also free to 804 negotiate the CLUE channel. Once this is successfully established 805 CLUE negotiation can begin. This is illustrated as CLUE CHANNEL 806 ESTABLISHED. 808 Alice now sends her CLUE Advertisement (ADVERTISEMENT 1). She 809 advertises three static captures representing her three cameras. She 810 also includes switched captures suitable for two- and one-screen 811 systems. All of these captures are in a single capture scene, with 812 suitable capture scene entries to tell Bob that he should either 813 subscribe to the three static captures, the two switched capture view 814 or the one switched capture view. Alice has no simultaneity 815 constraints, so includes all six captures in one simultaneous set. 816 Finally, Alice includes an encoding group with three encoding IDs: 817 "enc1", "enc2" and "enc3". These encoding ids aren't currently 818 valid, but will match the next SDP offer she sends. 820 Bob received ADVERTISEMENT 1 but does not yet send a Configure 821 message, because he has not yet received Alice's encoding 822 information, so as yet he does not know if she will have sufficient 823 resources to send him the two streams he ideally wants at a quality 824 he is happy with. 826 Bob also sends his CLUE ADVERTISEMENT (ADVERTISEMENT 2). He 827 advertises two static captures representing his cameras. He also 828 includes a single composed capture for single-screen systems, in 829 which he will composite the two camera views into a single video 830 stream. All three captures are in a single capture scene, with 831 suitable capture scene entries to tell Alice that she should either 832 subscribe to the two static captures, or the single composed capture. 833 Bob also has no simultaneity constraints, so includes all three 834 captures in one simultaneous set. Bob also includes a single 835 encoding group with two encoding IDs: "foo" and "bar". 837 Similarly, Alices receives ADVERTISEMENT 2 but does not yet send a 838 CONFIGURE message, because she has not yet received Bob's encoding 839 information. 841 Alice now sends INVITE 2. She maintains the sendrecv audio, video 842 and CLUE m-lines, and she adds three new sendonly m-lines to 843 represents the maximum three encodings she can send. Each of these 844 m-lines has a label corresponding to one of the encoding ids from 845 ADVERTISEMENT 1. Each also has its mid added to the grouping 846 attribute to show they are controlled by the CLUE channel. A snippet 847 of the SDP showing the grouping attribute and the video m-lines are 848 shown below (mid 3 represents the CLUE channel): 850 ... 851 a=group:CLUE 3 4 5 6 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=video 6004 RTP/AVP 96 860 a=rtpmap:96 H264/90000 861 a=fmtp:96 profile-level-id=42e016 862 a=sendonly 863 a=mid:4 864 a=label:enc1 865 m=video 6006 RTP/AVP 96 866 a=rtpmap:96 H264/90000 867 a=fmtp:96 profile-level-id=42e016 868 a=sendonly 869 a=mid:5 870 a=label:enc2 871 m=video 6008 RTP/AVP 96 872 a=rtpmap:96 H264/90000 873 a=fmtp:96 profile-level-id=42e016 874 a=sendonly 875 a=mid:6 876 a=label:enc3 878 Bob now has all the information he needs to decide which streams to 879 configure. As such he now sends CONFIGURE 1. This requests the pair 880 of switched captures that represent Alice's scene, and he configures 881 them with encoder ids "enc1" and "enc2". This also serves as an ack 882 for Alice's ADVERTISMENT 1. 884 Alice receives Bob's message CONFIGURE 1 and sends RESPONSE 1 to ack 885 its receptions. She does not yet send the capture encodings 886 specified, because at this stage Bob hasn't negotiated the ability to 887 receive these streams in SDP. 889 Bob now sends his SDP answer as part of 200 OK 2. Alongside his 890 original audio, video and CLUE m-lines he includes two active 891 recvonly m-lines and a zeroed m-line for the third. He adds their 892 mid values to the grouping attribute to show they are controlled by 893 the CLUE channel. A snippet of the SDP showing the grouping 894 attribute and the video m-lines are shown below (mid 100 represents 895 the CLUE channel): 897 ... 898 a=group:CLUE 11 12 100 899 ... 900 m=video 58722 RTP/AVP 96 901 a=rtpmap:96 H264/90000 902 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 903 a=sendrecv 904 a=mid:10 905 ... 906 m=video 58724 RTP/AVP 96 907 a=rtpmap:96 H264/90000 908 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 909 a=recvonly 910 a=mid:11 911 m=video 58726 RTP/AVP 96 912 a=rtpmap:96 H264/90000 913 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 914 a=recvonly 915 a=mid:12 916 m=video 0 RTP/AVP 96 918 On receiving 200 OK 2 from Bob Alice is now able to send the two 919 streams of video Bob requested - this is illustrated as MEDIA 2. 921 The constraints of offer/answer meant that Bob could not include his 922 encoder information as new m-lines in 200 OK 2. As such Bob now 923 sends INVITE 3 to generate a new offer. Along with all the streams 924 from 200 OK 2 Bob also includes two new sendonly streams. Each 925 stream has a label corresponding to the encoding ids in his 926 ADVERTISEMENT 2 message. He also adds their mid values to the 927 grouping attribute to show they are controlled by the CLUE channel. 928 A snippet of the SDP showing the grouping attribute and the video 929 m-lines are shown below (mid 100 represents the CLUE channel): 931 ... 932 a=group:CLUE 11 12 13 14 100 933 ... 934 m=video 58722 RTP/AVP 96 935 a=rtpmap:96 H264/90000 936 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 937 a=sendrecv 938 a=mid:10 939 ... 940 m=video 58724 RTP/AVP 96 941 a=rtpmap:96 H264/90000 942 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 943 a=recvonly 944 a=mid:11 945 m=video 58726 RTP/AVP 96 946 a=rtpmap:96 H264/90000 947 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 948 a=recvonly 949 a=mid:12 950 m=video 0 RTP/AVP 96 951 m=video 58728 RTP/AVP 96 952 a=rtpmap:96 H264/90000 953 a=fmtp:96 profile-level-id=42e016 954 a=sendonly 955 a=label:foo 956 a=mid:13 957 m=video 58730 RTP/AVP 96 958 a=rtpmap:96 H264/90000 959 a=fmtp:96 profile-level-id=42e016 960 a=sendonly 961 a=label:bar 962 a=mid:14 964 Having received this Alice now has all the information she needs to 965 send CONFIGURE 2. She requests the two static captures from Bob, to 966 be sent on encodings "foo" and "bar". 968 Bob receives Alice's message CONFIGURE 2 and sends RESPONSE 2 to ack 969 its receptions. Bob does not yet send the capture encodings 970 specified, because Alice hasn't yet negotiated the ability to receive 971 these streams in SDP. 973 Alice now sends 200 OK 3, matching two recvonly m-lines to Bob's new 974 sendonly lines. She includes their mid values in the grouping 975 attribute to show they are controlled by the CLUE channel. A snippet 976 of the SDP showing the grouping attribute and the video m-lines are 977 shown below (mid 3 represents the CLUE channel): 979 ... 980 a=group:CLUE 3 4 5 7 8 981 ... 982 m=video 6002 RTP/AVP 96 983 a=rtpmap:96 H264/90000 984 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 985 a=sendrecv 986 a=mid:2 987 ... 988 m=video 6004 RTP/AVP 96 989 a=rtpmap:96 H264/90000 990 a=fmtp:96 profile-level-id=42e016 991 a=sendonly 992 a=mid:4 993 a=label:enc1 994 m=video 6006 RTP/AVP 96 995 a=rtpmap:96 H264/90000 996 a=fmtp:96 profile-level-id=42e016 997 a=sendonly 998 a=mid:5 999 a=label:enc2 1000 m=video 0 RTP/AVP 96 1001 m=video 6010 RTP/AVP 96 1002 a=rtpmap:96 H264/90000 1003 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1004 a=recvonly 1005 a=mid:7 1006 m=video 6012 RTP/AVP 96 1007 a=rtpmap:96 H264/90000 1008 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1009 a=recvonly 1010 a=mid:8 1012 Finally, on receiving 200 OK 3 Bob is now able to send the two 1013 streams of video Alice requested - this is illustrated as MEDIA 3. 1015 Both sides of the call are now sending multiple video streams with 1016 their sources defined via CLUE negotiation. As the call progresses 1017 either side can send new ADVERTISEMENT or CONFIGURE or new SDP 1018 negotiation to add, remove or change what they have available or want 1019 to receive. 1021 8. Example: A call between a CLUE-capable and non-CLUE endpoint 1023 In this brief example Alice is a CLUE-capable endpoint making a call 1024 to Bob, who is not CLUE-capable, i.e., it is not able to use the CLUE 1025 protocol. 1027 +----------+ +-----------+ 1028 | EP1 | | EP2 | 1029 | | | | 1030 +----+-----+ +-----+-----+ 1031 | | 1032 | | 1033 | SIP INVITE 1 (BASIC SDP+COMEDIA) | 1034 |--------------------------------->| 1035 | | 1036 | | 1037 | 200 0K 1 (BASIC SDP+*NO*COMEDIA) | 1038 |<---------------------------------| 1039 | | 1040 | | 1041 | ACK 1 | 1042 |--------------------------------->| 1043 | | 1044 | | 1045 | | 1046 |<########### MEDIA 1 ############>| 1047 | 1 video A->B, 1 video B->A | 1048 |<################################>| 1049 | | 1050 | | 1051 | | 1052 | | 1053 v v 1055 In INVITE 1, Alice sends Bob a SIP INVITE including in the SDP body 1056 the basilar audio and video capabilities ("BASIC SDP") and the 1057 information needed for opening a control channel to be used for CLUE 1058 protocol messages exchange, according to what is envisioned in the 1059 COMEDIA approach ("COMEDIA") for DTLS/SCTP channel 1060 [I-D.ietf-mmusic-sctp-sdp]. A snippet of the SDP showing the 1061 grouping attribute and the video m-line are shown below (mid 3 1062 represents the CLUE channel): 1064 ... 1065 a=group:CLUE 3 1066 ... 1067 m=video 6002 RTP/AVP 96 1068 a=rtpmap:96 H264/90000 1069 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1070 a=sendrecv 1071 a=mid:2 1073 Bob is not CLUE capable, and hence does not recognize the "CLUE" 1074 semantic for the grouping attribute, not does he support the CLUE 1075 channel. He responds with an answer with audio and video, but with 1076 the CLUE channel zeroed. 1078 From the lack of the CLUE channel Alice understands that Bob does not 1079 support CLUE, or does not wish to use it. Both sides are now able to 1080 send a single audio and video stream to each other. Alice at this 1081 point begins to send her fallback video: in this case likely a 1082 switched view from whichever camera shows the current loudest 1083 participant on her side. 1085 9. CLUE requirements on SDP O/A 1087 The current proposal calls for a new "CLUE" semantic for the SDP 1088 Grouping Framework [RFC5888]. 1090 10. SIP Signaling 1092 The current proposal calls for a "sip.clue" media feature tag. 1094 11. CLUE over RTCWEB 1096 We may want to rule this out of scope for now. But we should be 1097 thinking about this. 1099 12. Open Issues 1101 Here are issues pertinent to signaling that need resolution. 1102 Resolution will probably result in changes somewhere in this 1103 document, but may also impact other documents. 1104 o The current method for expressing encodings in SDP limits the 1105 parameters available when describing H264 encoder capabilities to 1106 those defined in Table 6 in [RFC6184] 1108 13. What else? 1110 14. Acknowledgements 1112 The team focusing on this draft consists of: Roni Even, Rob Hansen, 1113 Christer Holmberg, Paul Kyzivat, Simon Pietro-Romano, Roberta Presta. 1115 Christian Groves and Jonathon Lennox have contributed detailed 1116 comments and suggestions. 1118 The author list should be updated as people contribute substantial 1119 text to this document. 1121 15. IANA Considerations 1123 TBD 1125 16. Security Considerations 1127 TBD 1129 17. Change History 1131 -02: Revision by Rob Hansen 1132 * Added section on not accepting non-CLUE-controlled "m" lines in 1133 the initial answer when CLUE is to be negotiated. 1134 * Removed previous language attempting to describe media 1135 restrictions for CLUE-controlled "m" lines that had not been 1136 configured, and replaced it with much more accurate 'treat as 1137 "a=inactive" was set'. 1138 * Made label element mandatory for CLUE-controlled media (was 1139 previously "SHOULD include", but there didn't seem a good 1140 reason for this - anyone wishing to include the "m" line but 1141 not immediately use it in CLUE can simply leave it out of the 1142 .) 1143 * Added a section on the specifics of relating encodings in SDP 1144 to elements in the CLUE protocol, including the fact 1145 that both ADVERTISMENTS and CONFIGURE messages reference the 1146 *encoding* (eg, in the CONFIGURE case the sender of the 1147 CONFIGURE message includes the labels of the recipient's "m" 1148 lines as their contents). 1149 * Minor revisions to the section on complying with normative SDP/ 1150 CLUEstate machine language to clarify that these were not new 1151 normative language, merely that existing normative language 1152 still applies. 1153 * Removed appendices which previously contained information to be 1154 transferred to the protocol and data channel drafts. Removed 1155 other text that discussed alternatives to the current approach. 1156 * Cleaned up some 'todo' text. 1157 -01: Revision by Rob Hansen 1158 * Revised terminology - removed the term 'CLUE-enabled' device as 1159 insufficiently distinct from 'CLUE-capable' and instead added a 1160 term for 'CLUE-enabled' calls. 1161 * Removed text forbidding RTCP and instead added text that ICE/ 1162 DTLS negotiation for CLUE controlled media must be done as 1163 normal irrespective of CLUE negotiation. 1164 * Changed 'sip.telepresence' to 'sip.clue' and 'TELEPRESENCE' 1165 grouping semantic back to CLUE. 1166 * Made it mandatory to have exactly one mid corresponding to a 1167 data channel in a CLUE group 1168 * Forbade having multiple CLUE groups unless a specification for 1169 doing so is published 1170 * Refactored SDP-related text; previously the encoding 1171 information had been in the "initial offer" section despite the 1172 fact that we recommend that the initial offer doesn't actually 1173 include any encodings. I moved the specifications of encodings 1174 and how they're received to an earlier, seperate section. 1175 * Added text on how the state machines in CLUE and SDP are 1176 allowed to affect one another, and further recommendations on 1177 how a device should handle the sending of CLUE and SDP changes. 1178 -00: Revision by Rob Hansen 1179 * Submitted as -00 working group document 1180 draft-kyzivat-08: Revisions by Rob Hansen 1181 * Added media feature tag for CLUE support ('sip.telepresence') 1182 * Changed grouping semantic from 'CLUE' to 'TELEPRESENCE' 1183 * Restructured document to be more centred on the grouping 1184 semantic and its use with O/A 1185 * Lots of additional text on usage of the grouping semantic 1186 * Stricter definition of CLUE-controlled m lines and how they 1187 work 1188 * Some additional text on defining what happens when CLUE 1189 supports is added or removed 1190 * Added details on when to not send RTCP for CLUE-controlled "m" 1191 lines. 1192 * Added a section on using BUNDLE with CLUE 1193 * Updated data channel references to point at new WG document 1194 rather than indivual draft 1195 draft-kyzivat-07: Revisions by Rob Hansen 1196 * Removed the text providing arguments for encoding limits being 1197 in SDP and encoding groups in the CLUE protocol in favor of the 1198 specifics of how to negotiate encodings in SDP 1200 * Added normative language on the setting up of a CLUE call, and 1201 added sections on mid-call changes to the CLUE status. 1202 * Added references to [I-D.ietf-clue-datachannel] where 1203 appropriate. 1204 * Added some terminology for various types of CLUE and non-CLUE 1205 states of operation. 1206 * Moved language related to topics that should be in 1207 [I-D.ietf-clue-datachannel] and [I-D.presta-clue-protocol], but 1208 that has not yet been resolved in those documents, into an 1209 appendix. 1210 draft-kyzivat-06: Revisions by Rob Hansen 1211 * Removed CLUE message XML schema and details that are now in 1212 draft-presta-clue-protocol 1213 * Encoding limits in SDP section updated to note that this has 1214 been investigated and discussed and is the current working 1215 assumption of the WG, though consensus has not been fully 1216 achieved. 1217 * A section has also been added on the current mandation of 1218 unidirectional "m"-lines. 1219 * Updated CLUE messaging in example call flow to match 1220 draft-presta-clue-protocol-03 1221 draft-kyzivat-05: Revisions by pkyzivat: 1222 * Specified versioning model and mechanism. 1223 * Added explicit response to all messages. 1224 * Rearranged text to work with the above changes. (Which 1225 rendered diff almost useless.) 1226 draft-kyzivat-04: Revisions by Rob Hansen: ??? 1227 draft-kyzivat-03: Revisions by pkyzivat: 1228 * Added a syntax section with an XML schema for CLUE messages. 1229 This is a strawhorse, and is very incomplete, but it 1230 establishes a template for doing this based on elements defined 1231 in the data model. (Thanks to Roberta for help with this!) 1232 * Did some rewording to fit the syntax section in and reference 1233 it. 1234 * Did some relatively minor restructuring of the document to make 1235 it flow better in a logical way. 1236 draft-kyzivat-02: A bunch of revisions by pkyzivat: 1237 * Moved roberta's call flows to a more appropriate place in the 1238 document. 1239 * New section on versioning. 1240 * New section on NAK. 1241 * A couple of possible alternatives for message acknowledgment. 1242 * Some discussion of when/how to signal changes in provider 1243 state. 1244 * Some discussion about the handling of transport errors. 1245 * Added a change history section. 1246 These were developed by Lennard Xiao, Christian Groves and Paul, 1247 so added Lennard and Christian as authors. 1249 draft-kyzivat-01: Updated by roberta to include some sample call 1250 flows. 1251 draft-kyzivat-00: Initial version by pkyzivat. Established general 1252 outline for the document, and specified a few things thought to 1253 represent wg consensus. 1255 18. References 1257 18.1. Normative References 1259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1260 Requirement Levels", BCP 14, RFC 2119, March 1997. 1262 [I-D.ietf-clue-framework] 1263 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 1264 for Telepresence Multi-Streams", 1265 draft-ietf-clue-framework-16 (work in progress), 1266 June 2014. 1268 [I-D.presta-clue-data-model-schema] 1269 Presta, R. and S. Romano, "An XML Schema for the CLUE data 1270 model", draft-presta-clue-data-model-schema-03 (work in 1271 progress), March 2013. 1273 [I-D.presta-clue-protocol] 1274 Presta, R. and S. Romano, "CLUE protocol", 1275 draft-presta-clue-protocol-04 (work in progress), 1276 May 2014. 1278 [I-D.ietf-clue-datachannel] 1279 Holmberg, C., "CLUE Protocol Data Channel", 1280 draft-ietf-clue-datachannel-00 (work in progress), 1281 March 2014. 1283 [I-D.groves-clue-latent-config] 1284 Groves, C., Yang, W., and R. Even, "CLUE and latent 1285 configurations", draft-groves-clue-latent-config-00 (work 1286 in progress), January 2014. 1288 [I-D.ietf-mmusic-sctp-sdp] 1289 Loreto, S. and G. Camarillo, "Stream Control Transmission 1290 Protocol (SCTP)-Based Media Transport in the Session 1291 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-06 1292 (work in progress), February 2014. 1294 [I-D.tuexen-tsvwg-sctp-dtls-encaps] 1295 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 1296 Encapsulation of SCTP Packets for RTCWEB", 1297 draft-tuexen-tsvwg-sctp-dtls-encaps-01 (work in progress), 1298 July 2012. 1300 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1301 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1303 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1304 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1306 18.2. Informative References 1308 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1309 with Session Description Protocol (SDP)", RFC 3264, 1310 June 2002. 1312 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1313 UPDATE Method", RFC 3311, October 2002. 1315 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1316 (ICE): A Protocol for Network Address Translator (NAT) 1317 Traversal for Offer/Answer Protocols", RFC 5245, 1318 April 2010. 1320 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1321 Session Initiation Protocol (SIP)", RFC 4353, 1322 February 2006. 1324 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1325 Protocol (XMPP): Core", RFC 6120, March 2011. 1327 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1328 Payload Format for H.264 Video", RFC 6184, May 2011. 1330 [I-D.even-clue-sdp-clue-relation] 1331 Even, R., "Signalling of CLUE and SDP offer/answer", 1332 draft-even-clue-sdp-clue-relation-01 (work in progress), 1333 October 2012. 1335 [I-D.even-clue-rtp-mapping] 1336 Even, R. and J. Lennox, "Mapping RTP streams to CLUE media 1337 captures", draft-even-clue-rtp-mapping-05 (work in 1338 progress), February 2013. 1340 [I-D.hansen-clue-sdp-interaction] 1341 Hansen, R., "SDP and CLUE message interactions", 1342 draft-hansen-clue-sdp-interaction-01 (work in progress), 1343 February 2013. 1345 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1346 Holmberg, C., Alvestrand, H., and C. Jennings, 1347 "Negotiating Media Multiplexing Using the Session 1348 Description Protocol (SDP)", 1349 draft-ietf-mmusic-sdp-bundle-negotiation-07 (work in 1350 progress), April 2014. 1352 Authors' Addresses 1354 Paul Kyzivat 1355 Huawei 1357 Email: pkyzivat@alum.mit.edu 1359 Lennard Xiao 1360 Huawei 1362 Email: lennard.xiao@huawei.com 1364 Christian Groves 1365 Huawei 1367 Email: Christian.Groves@nteczone.com 1369 Robert Hansen 1370 Cisco Systems 1372 Email: rohanse2@cisco.com