idnits 2.17.1 draft-ietf-clue-signaling-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A CLUE-capable device that supports BUNDLE SHOULD also support rtcp-mux [RFC5761]. However, a CLUE-capable device that supports rtcp-mux MAY or MAY NOT support BUNDLE. -- The document date (August 20, 2017) is 2440 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 (-18) exists of draft-ietf-clue-datachannel-14 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel') == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-13 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-protocol (ref. 'I-D.ietf-clue-protocol') == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-12 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-38 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 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: February 21, 2018 Huawei 6 C. Groves 8 R. Hansen 9 Cisco Systems 10 August 20, 2017 12 Session Signaling for Controlling Multiple Streams for Telepresence 13 (CLUE) 14 draft-ietf-clue-signaling-12 16 Abstract 18 This document specifies how CLUE-specific signaling such as the CLUE 19 protocol and the CLUE data channel are used in conjunction with each 20 other and with existing signaling mechanisms such as SIP and SDP to 21 produce a telepresence call. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 21, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Media Feature Tag Definition . . . . . . . . . . . . . . . . 4 60 4. SDP Grouping Framework CLUE Extension Semantics . . . . . . . 4 61 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. The CLUE data channel and the CLUE grouping semantic . . 4 63 4.3. CLUE-controlled media and the CLUE grouping semantic . . 5 64 4.4. SDP semantics for CLUE-controlled media . . . . . . . . . 5 65 4.4.1. Signaling CLUE Encodings . . . . . . . . . . . . . . 5 66 4.4.1.1. Referencing Encodings in the CLUE protocol . . . 6 67 4.4.2. Negotiating receipt of CLUE Capture Encodings in SDP 7 68 4.5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 7 69 4.5.1. Generating the Initial Offer . . . . . . . . . . . . 7 70 4.5.2. Generating the Answer . . . . . . . . . . . . . . . . 8 71 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 8 72 4.5.2.2. Negotiating CLUE-controlled media . . . . . . . . 8 73 4.5.2.3. Negotiating non-CLUE controlled media . . . . . . 8 74 4.5.3. Processing the initial Offer/Answer negotiation . . . 9 75 4.5.3.1. Successful CLUE negotiation . . . . . . . . . . . 9 76 4.5.3.2. CLUE negotiation failure . . . . . . . . . . . . 9 77 4.5.4. Modifying the session . . . . . . . . . . . . . . . . 10 78 4.5.4.1. Adding and removing CLUE-controlled media . . . . 10 79 4.5.4.2. Enabling CLUE mid-call . . . . . . . . . . . . . 10 80 4.5.4.3. Disabling CLUE mid-call . . . . . . . . . . . . . 10 81 5. Interaction of CLUE protocol and SDP negotiations . . . . . . 11 82 5.1. Independence of SDP and CLUE negotiation . . . . . . . . 11 83 5.2. Constraints on sending media . . . . . . . . . . . . . . 12 84 5.3. Recommendations for operating with non-atomic operations 13 85 6. Interaction of CLUE protocol and RTP/RTCP CaptureID . . . . . 13 86 6.1. CaptureID reception during MCC redefinition . . . . . . . 14 87 7. Multiplexing of CLUE-controlled media using BUNDLE . . . . . 14 88 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 89 7.2. Usage of BUNDLE with CLUE . . . . . . . . . . . . . . . . 15 90 7.2.1. Generating the Initial Offer . . . . . . . . . . . . 15 91 7.2.2. Multiplexing of the data channel and RTP media . . . 15 92 8. Example: A call between two CLUE-capable Endpoints . . . . . 16 93 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 26 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 11.1. New SDP Grouping Framework Attribute . . . . . . . . . . 27 97 11.2. New SIP Media Feature Tag . . . . . . . . . . . . . . . 28 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 99 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 29 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 38 102 14.2. Informative References . . . . . . . . . . . . . . . . . 39 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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 [RFC4566], conveyed via SIP 111 [RFC3261], is used to negotiate the specific media capabilities that 112 can be delivered to specific addresses on a device. Meanwhile, CLUE 113 protocol [I-D.ietf-clue-protocol] messages, transported via a CLUE 114 data 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 SIP [RFC3840] indicates support for 158 CLUE in SIP [RFC3261] calls. A CLUE-capable device SHOULD include 159 this media feature tag in its REGISTER requests and OPTION responses. 160 It SHOULD also include the media feature tag in INVITE and UPDATE 161 [RFC3311] requests and responses. 163 Presence of the media feature tag in the contact field of a request 164 or response can be used to determine that the far end supports CLUE. 166 4. SDP Grouping Framework CLUE Extension Semantics 168 4.1. General 170 This section defines a new SDP Grouping Framework [RFC5888] extension 171 called 'CLUE'. 173 The CLUE extension can be indicated using an SDP session-level 174 'group' attribute. Each SDP media "m=" line that is included in this 175 group, using SDP media-level mid attributes, is CLUE-controlled, by a 176 CLUE data channel also included in this CLUE group. 178 Currently only support for a single CLUE group is specified; support 179 for multiple CLUE groups in a single session is outside the scope of 180 this document. A device MUST NOT include more than one CLUE group in 181 its SDP message unless it is following a specification that defines 182 how multiple CLUE channels are signaled, and is either able to 183 determine that the other side of the SDP exchange supports multiple 184 CLUE channels, or is able to fail gracefully in the event it does 185 not. 187 4.2. The CLUE data channel and the CLUE grouping semantic 189 The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional 190 data channel [I-D.ietf-rtcweb-data-channel] used for the transport of 191 CLUE messages, conveyed within an SCTP over DTLS connection. This 192 channel must be established before CLUE protocol messages can be 193 exchanged and CLUE-controlled media can be sent. 195 The data channel is negotiated over SDP as described in 196 [I-D.ietf-mmusic-data-channel-sdpneg]. A CLUE-capable device wishing 197 to negotiate CLUE MUST also include a CLUE group in their SDP offer 198 or answer and include the "mid" of the "m=" line for the data channel 199 in that group. The CLUE group MUST include the "mid" of the "m=" 200 line for one (and only one) data channel. 202 Presence of the data channel in the CLUE group in an SDP offer or 203 answer also serves, along with the "sip.clue" media feature tag, as 204 an indication that the device supports CLUE and wishes to upgrade the 205 call to include CLUE-controlled media. A CLUE-capable device SHOULD 206 include a data channel "m=" line in offers and, when allowed by 207 [RFC3264], answers. 209 4.3. CLUE-controlled media and the CLUE grouping semantic 211 CLUE-controlled media lines in an SDP are "m=" lines in which the 212 content of the media streams to be sent is negotiated via the CLUE 213 protocol [I-D.ietf-clue-protocol]. For an "m=" line to be CLUE- 214 controlled, its "mid" value MUST be included in the CLUE group. 215 CLUE-controlled media is controlled by the CLUE protocol as 216 negotiated on the CLUE data channel with an "mid" included in the 217 CLUE group. 219 "m=" lines not specified as under CLUE control follow normal rules 220 for media streams negotiated in SDP as defined in documents such as 221 [RFC3264]. 223 The restrictions on CLUE-controlled media always apply to "m=" lines 224 in an SDP offer or answer, even if negotiation of the data channel in 225 SDP failed due to lack of CLUE support by the remote device or for 226 any other reason, or in an offer if the recipient does not include 227 the "mid" of the corresponding "m=" line in their CLUE group. 229 4.4. SDP semantics for CLUE-controlled media 231 4.4.1. Signaling CLUE Encodings 233 The CLUE Framework [I-D.ietf-clue-framework] defines the concept of 234 "Encodings", which represent the sender's encode ability. Each 235 Encoding the Media Provider wishes to signal is signaled via an "m=" 236 line of the appropriate media type, which MUST be marked as sendonly 237 with the "a=sendonly" attribute or as inactive with the "a=inactive" 238 attribute. 240 The encoder limits of active (eg, "a=sendonly") Encodings can then be 241 expressed using existing SDP syntax. For instance, for H.264 see 242 Table 6 in [RFC6184] for a list of valid parameters for representing 243 encoder sender stream limits. 245 These Encodings are CLUE-controlled and hence MUST include an "mid" 246 in the CLUE group as defined above. 248 As well as the normal restrictions defined in [RFC3264] the stream 249 MUST be treated as if the "m=" line direction attribute had been set 250 to "a=inactive" until the Media Provider has received a valid CLUE 251 CONFIGURE message specifying the Capture to be used for this stream. 252 This means that RTP packets MUST NOT be sent until configuration is 253 complete, while non-media packets such as STUN, RTCP and DTLS MUST be 254 sent as per their relevant specifications if negotiated. 256 Every "m=" line representing a CLUE Encoding MUST contain a "label" 257 attribute as defined in [RFC4574]. This label is used to identify 258 the Encoding by the sender in CLUE ADVERTISEMENT messages and by the 259 receiver in CLUE CONFIGURE messages. Each label used for a CLUE- 260 controlled "m=" line MUST be different from the label on all other 261 "m=" lines in the CLUE group, unless an "m=" line represents a 262 dependent stream related to another "m=" line (such as an FEC 263 stream), in which case it MUST have the same label value as the "m=" 264 line on which it depends. 266 4.4.1.1. Referencing Encodings in the CLUE protocol 268 CLUE Encodings are defined in SDP, but can be referenced from CLUE 269 protocol messages - this is how the protocol defines which Encodings 270 are part of an Encoding Group (in ADVERTISEMENT messages) and which 271 Encoding with which to encode a specific Capture (in CONFIGURE 272 messages). The labels on the CLUE-controlled "m=" lines are the 273 references that are used in the CLUE protocol. 275 Each (in encodingIDList) in a CLUE ADVERTISEMENT message 276 SHOULD represent an Encoding defined in SDP; the specific Encoding 277 referenced is a CLUE-controlled "m=" line in the most recent SDP sent 278 by the sender of the ADVERTISEMENT message with a label value 279 corresponding to the text content of the . 281 Similarly, each (in captureEncodingType) in a CLUE 282 CONFIGURE message SHOULD represent an Encoding defined in SDP; the 283 specific Encoding referenced is a CLUE-controlled "m=" line in the 284 most recent SDP received by the sender of the CONFIGURE message with 285 a label value corresponding to the text content of the . 287 Note that the non-atomic nature of SDP/CLUE protocol interaction may 288 mean that there are temporary periods where an / 289 in a CLUE message does not reference an SDP "m=" line, or where an 290 Encoding represented in SDP is not referenced in a CLUE protocol 291 message. See Section 5 for specifics. 293 4.4.2. Negotiating receipt of CLUE Capture Encodings in SDP 295 A receiver who wishes to receive a CLUE stream via a specific 296 Encoding requires an "a=recvonly" "m=" line that matches the 297 "a=sendonly" Encoding. 299 These "m=" lines are CLUE-controlled and hence MUST include their 300 "mid" in the CLUE group. They MAY include a "label" attribute, but 301 this is not required by CLUE, as only label values associated with 302 "a=sendonly" Encodings are referenced by CLUE protocol messages. 304 4.5. SDP Offer/Answer Procedures 306 4.5.1. Generating the Initial Offer 308 A CLUE-capable device sending an initial SDP offer of a SIP session 309 SHOULD include an "m=" line for the data channel to convey the CLUE 310 protocol, along with a CLUE group containing the "mid" of the data 311 channel "m=" line. 313 For interoperability with non-CLUE devices a CLUE-capable device 314 sending an initial SDP offer SHOULD NOT include any "m=" line for 315 CLUE-controlled media beyond the "m=" line for the CLUE data channel, 316 and SHOULD include at least one non-CLUE-controlled media "m=" line. 318 If the device has evidence that the receiver is also CLUE-capable, 319 for instance due to receiving an initial INVITE with no SDP but 320 including a "sip.clue" media feature tag, the above recommendation is 321 waived, and the initial offer MAY contain "m=" lines for CLUE- 322 controlled media. 324 With the same interoperability recommendations as for Encodings, the 325 sender of the initial SDP offer MAY also include "a=recvonly" media 326 lines to preallocate "m=" lines to receive media. Alternatively, it 327 MAY wait until CLUE protocol negotiation has completed before 328 including these lines in a new offer/answer exchange - see Section 5 329 for recommendations. 331 4.5.2. Generating the Answer 333 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 335 If the recipient of an initial offer is CLUE-capable, and the offer 336 contains both an "m=" line for a data channel and a CLUE group 337 containing the "mid" for that "m=" line, they SHOULD negotiate data 338 channel support for an "m=" line, and include the "mid" of that "m=" 339 line in a corresponding CLUE group. 341 A CLUE-capable recipient that receives an "m=" line for a data 342 channel but no corresponding CLUE group containing the "mid" of that 343 "m=" line MAY still include a corresponding data channel "m=" line if 344 there are any other non-CLUE protocols it can convey over that 345 channel, but MUST NOT negotiate use of the CLUE protocol on this 346 channel. 348 4.5.2.2. Negotiating CLUE-controlled media 350 If the initial offer contained "a=recvonly" CLUE-controlled media 351 lines the recipient SHOULD include corresponding "a=sendonly" CLUE- 352 controlled media lines for accepted Encodings, up to the maximum 353 number of Encodings it wishes to advertise. As CLUE-controlled 354 media, the "mid" of these "m=" lines must be included in the 355 corresponding CLUE group. The recipient MUST set the direction of 356 the corresponding "m=" lines of any remaining "a=recvonly" CLUE- 357 controlled media lines received in the offer to "a=inactive". 359 If the initial offer contained "a=sendonly" CLUE-controlled media 360 lines the recipient MAY include corresponding "a=recvonly" CLUE- 361 controlled media lines, up to the maximum number of Capture Encodings 362 it wishes to receive. Alternatively, it MAY wait until CLUE protocol 363 negotiation has completed before including these lines in a new 364 offer/answer exchange - see Section 5 for recommendations. The 365 recipient MUST set the direction of the corresponding "m=" lines of 366 any remaining "a=recvonly" CLUE-controlled media lines received in 367 the offer to "a=inactive" 369 4.5.2.3. Negotiating non-CLUE controlled media 371 A CLUE-controlled device implementation may prefer to render initial, 372 single-stream audio and/or video for the user as rapidly as possible, 373 transitioning to CLUE-controlled media once that has been negotiated. 374 Alternatively, an implementation may wish to suppress initial media, 375 only providing media once the final, CLUE-controlled streams have 376 been negotiated. 378 The receiver of the initial offer, if making the call CLUE-enabled 379 with their SDP answer, can make their preference clear by their 380 action in accepting or rejecting non-CLUE-controlled media lines. 381 Rejecting these "m=" lines will ensure that no non-CLUE-controlled 382 media flows before the CLUE-controlled media is negotiated. In 383 contrast, accepting one or more non-CLUE-controlled "m=" lines in 384 this initial answer will enable initial media to flow. 386 If the answerer chooses to send initial non-CLUE-controlled media in 387 a CLUE-enabled call, Section 4.5.4.1 addresses the need to disable it 388 once CLUE-controlled media is fully negotiated. 390 4.5.3. Processing the initial Offer/Answer negotiation 392 In the event that both offer and answer include a data channel "m=" 393 line with a mid value included in corresponding CLUE groups, CLUE has 394 been successfully negotiated and the call is now CLUE-enabled. If 395 not then the call is not CLUE-enabled. 397 4.5.3.1. Successful CLUE negotiation 399 In the event of successful CLUE-enablement of the call, devices MUST 400 now begin negotiation of the CLUE channel, see 401 [I-D.ietf-clue-datachannel] for negotiation details. If negotiation 402 is successful, sending of CLUE protocol [I-D.ietf-clue-protocol] 403 messages can begin. 405 A CLUE-capable device MAY choose not to send RTP on the non-CLUE- 406 controlled channels during the period in which control of the CLUE- 407 controlled media lines is being negotiated (though RTCP MUST still be 408 sent and received as normal). However, a CLUE-capable device MUST 409 still be prepared to receive media on non-CLUE-controlled media lines 410 that have been successfully negotiated as defined in [RFC3264]. 412 If either side of the call wishes to add additional CLUE-controlled 413 "m=" lines to send or receive CLUE-controlled media they MAY now send 414 a SIP request with a new SDP offer following the normal rules of SDP 415 offer/answer and any negotiated extensions. 417 4.5.3.2. CLUE negotiation failure 419 In the event that the negotiation of CLUE fails and the call is not 420 CLUE-enabled once the initial offer/answer negotiation completes then 421 CLUE is not in use in the call. The CLUE-capable devices MUST either 422 revert to non-CLUE behaviour or terminate the call. 424 4.5.4. Modifying the session 426 4.5.4.1. Adding and removing CLUE-controlled media 428 Subsequent offer/answer exchanges MAY add additional "m=" lines for 429 CLUE-controlled media, or activate or deactivate existing "m=" lines 430 per the standard SDP mechanisms. 432 In most cases at least one additional exchange after the initial 433 offer/answer exchange will be required before both sides have added 434 all the Encodings and ability to receive Encodings that they desire. 435 Devices MAY delay adding "a=recvonly" CLUE-controlled "m=" lines 436 until after CLUE protocol negotiation completes - see Section 5 for 437 recommendations. 439 Once CLUE media has been successfully negotiated devices SHOULD 440 ensure that non-CLUE-controlled media is deactivated by setting their 441 ports to 0 in cases where it corresponds to the media type of CLUE- 442 controlled media that has been successfully negotiated. This 443 deactivation may require an additional SDP exchange, or may be 444 incorporated into one that is part of the CLUE negotiation. 446 4.5.4.2. Enabling CLUE mid-call 448 A CLUE-capable device that receives an initial SDP offer from a non- 449 CLUE device SHOULD include a new data channel "m=" line and 450 corresponding CLUE group in any subsequent offers it sends, to 451 indicate that it is CLUE-capable. 453 If, in an ongoing non-CLUE call, an SDP offer/answer exchange 454 completes with both sides having included a data channel "m=" line in 455 their SDP and with the "mid" for that channel in a corresponding CLUE 456 group then the call is now CLUE-enabled; negotiation of the data 457 channel and subsequently the CLUE protocol begin. 459 4.5.4.3. Disabling CLUE mid-call 461 If, during an ongoing CLUE-enabled call a device wishes to disable 462 CLUE, it can do so by following the procedures for closing a data 463 channel defined in Section 5.2.4 of 464 [I-D.ietf-mmusic-data-channel-sdpneg]: sending a new SDP offer/answer 465 exchange and subsequent SCTP SSN reset for the CLUE channel. It MUST 466 also remove the CLUE group. Without the CLUE group any "m=" lines 467 that were previously CLUE-controlled no longer are; implementations 468 MAY disable them by setting their ports to 0 or may continue to use 469 them - in the latter case how they are used is outside the scope of 470 this document. 472 If a device follows the procedure above, or an SDP offer-answer 473 negotiation completes in a fashion in which either the "m=" CLUE data 474 channel line was not successfully negotiated, and/or one side did not 475 include the data channel in the CLUE group then CLUE for this call is 476 disabled. In the event that this occurs, CLUE is no longer enabled. 477 Any active "m=" lines still included in the CLUE group are no longer 478 CLUE-controlled and the implementation MAY either disable them in a 479 subsequent negotiation or continue to use them in some other fashion. 480 If the data channel is still present but not included in the CLUE 481 group semantic CLUE protocol messages MUST no longer be sent. 483 Note that this is distinct from cases where the CLUE protocol 484 negotiation fails, or an error occurs in the CLUE protocol; see 485 [I-D.ietf-clue-protocol] for details of media and state preservation 486 in this circumstance. These measures also apply if the CLUE data 487 channel fails, or is closed/reset without a corresponding SDP 488 exchange to disable the "m=" line. 490 5. Interaction of CLUE protocol and SDP negotiations 492 Information about media streams in CLUE is split between two message 493 types: SDP, which defines media addresses and limits, and the CLUE 494 channel, which defines properties of Capture Devices available, scene 495 information and additional constraints. As a result certain 496 operations, such as advertising support for a new transmissible 497 Capture with associated stream, cannot be performed atomically, as 498 they require changes to both SDP and CLUE messaging. 500 This section defines how the negotiation of the two protocols 501 interact, provides some recommendations on dealing with intermediate 502 stages in non-atomic operations, and mandates additional constraints 503 on when CLUE-configured media can be sent. 505 5.1. Independence of SDP and CLUE negotiation 507 To avoid the need to implement interlocking state machines with the 508 potential to reach invalid states if messages were to be lost, or be 509 rewritten en-route by middle boxes, the state machines in SDP and 510 CLUE operate independently. The state of the CLUE channel does not 511 restrict when an implementation may send a new SDP offer or answer, 512 and likewise the implementation's ability to send a new CLUE 513 ADVERTISEMENT or CONFIGURE message is not restricted by the results 514 of or the state of the most recent SDP negotiation (unless the SDP 515 negotiation has removed the CLUE channel). 517 The primary implication of this is that a device may receive an SDP 518 with a CLUE Encoding for which it does not yet have Capture 519 information, or receive a CLUE CONFIGURE message specifying a Capture 520 Encoding for which the far end has not negotiated a media stream in 521 SDP. 523 CLUE messages contain an (in encodingIDList) or 524 (in captureEncodingType), which is used to identify a specific 525 encoding or captureEncoding in SDP; see 526 [I-D.ietf-clue-data-model-schema] for specifics. The non-atomic 527 nature of CLUE negotiation means that a sender may wish to send a new 528 ADVERTISEMENT before the corresponding SDP message. As such the 529 sender of the CLUE message MAY include an which does not 530 currently match a CLUE-controlled "m=" line label in SDP; A CLUE- 531 capable implementation MUST NOT reject a CLUE protocol message solely 532 because it contains elements that do not match a label in 533 SDP. 535 The current state of the CLUE participant or Media Provider/Consumer 536 state machines do not affect compliance with any of the normative 537 language of [RFC3264]. That is, they MUST NOT delay an ongoing SDP 538 exchange as part of a SIP server or client transaction; an 539 implementation MUST NOT delay an SDP exchange while waiting for CLUE 540 negotiation to complete or for a CONFIGURE message to arrive. 542 Similarly, a device in a CLUE-enabled call MUST NOT delay any 543 mandatory state transitions in the CLUE Participant or Media 544 Provider/Consumer state machines due to the presence or absence of an 545 ongoing SDP exchange. 547 A device with the CLUE Participant state machine in the ACTIVE state 548 MAY choose not to move from ESTABLISHED to ADV (Media Provider state 549 machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media 550 Consumer state machine) based on the SDP state. See 551 [I-D.ietf-clue-protocol] for CLUE state machine specifics. 552 Similarly, a device MAY choose to delay initiating a new SDP exchange 553 based on the state of their CLUE state machines. 555 5.2. Constraints on sending media 557 While SDP and CLUE message states do not impose constraints on each 558 other, both impose constraints on the sending of media - CLUE- 559 controlled media MUST NOT be sent unless it has been negotiated in 560 both CLUE and SDP: an implementation MUST NOT send a specific CLUE 561 Capture Encoding unless its most recent SDP exchange contains an 562 active media channel for that Encoding AND the far end has sent a 563 CLUE CONFIGURE message specifying a valid Capture for that Encoding. 565 5.3. Recommendations for operating with non-atomic operations 567 CLUE-capable devices MUST be able to handle states in which CLUE 568 messages make reference to EncodingIDs that do not match the most 569 recently received SDP, irrespective of the order in which SDP and 570 CLUE messages are received. While these mismatches will usually be 571 transitory a device MUST be able to cope with such mismatches 572 remaining indefinitely. However, this document makes some 573 recommendations on message ordering for these non-atomic transitions. 575 CLUE-capable devices SHOULD ensure that any inconsistencies between 576 SDP and CLUE signaling are temporary by sending updated SDP or CLUE 577 messages as soon as the relevant state machines and other constraints 578 permit. 580 Generally, implementations that receive messages for which they have 581 incomplete information SHOULD wait until they have the corresponding 582 information they lack before sending messages to make changes related 583 to that information. For example, an answerer that receives a new 584 SDP offer with three new "a=sendonly" CLUE "m=" lines for which it 585 has received no CLUE ADVERTISEMENT providing the corresponding 586 capture information SHOULD include corresponding "a=inactive" lines 587 in its answer, and SHOULD make a new SDP offer with "a=recvonly" when 588 and if a new ADVERTISEMENT arrives with Captures relevant to those 589 Encodings. 591 Because of the constraints of SDP offer/answer and because new SDP 592 negotiations are generally more 'costly' than sending a new CLUE 593 message, implementations needing to make changes to both channels 594 SHOULD prioritize sending the updated CLUE message over sending the 595 new SDP message. The aim is for the recipient to receive the CLUE 596 changes before the SDP changes, allowing the recipient to send their 597 SDP answers without incomplete information, reducing the number of 598 new SDP offers required. 600 6. Interaction of CLUE protocol and RTP/RTCP CaptureID 602 [I-D.ietf-clue-framework] allows for Multiple Content Captures MCCs): 603 Captures which contain multiple source Captures, whether composited 604 into a single stream or switched based on some metric. 606 The Captures that contribute to these MCCs may or may not be defined 607 in the ADVERTISEMENT message. If they are defined and the MCC is 608 providing them in a switched format the recipient may wish to 609 determine which originating source Capture is currently being 610 provided, so that they can apply geometric corrections based on that 611 Capture's geometry, or take some other action based on the original 612 Capture information. 614 To do this, [I-D.ietf-clue-rtp-mapping] allows for the CaptureID of 615 the originating Capture to be conveyed via RTP or RTCP. A Media 616 Provider sending switched media for an MCC with defined originating 617 sources MUST send the CaptureID in both RTP and RTCP, as described in 618 the mapping document. 620 6.1. CaptureID reception during MCC redefinition 622 Because the RTP/RTCP CaptureID is delivered via a different channel 623 to the ADVERTISEMENT in which in the contents of the MCC are defined 624 there is an intrinsic race condition in cases in which the contents 625 of an MCC are redefined. 627 When a Media Provider redefines an MCC which involves CaptureIDs, the 628 reception of the relevant CaptureIDs by the recipient will either 629 lead or lag reception and processing of the new ADVERTISEMENT by the 630 recipient. As such, a Media Consumer MUST NOT be disrupted by any of 631 the following in any CLUE- controlled media stream it is receiving, 632 whether that stream is for a static Capture or for an MCC (as any 633 static Capture may be redefined to an MCC in a later ADVERTISEMENT): 635 o Receiving RTP or RTCP containing a CaptureID when the most 636 recently processed ADVERTISEMENT means that none are expected. 638 o Receiving RTP or RTCP without CaptureIDs when the most recently 639 processed ADVERTISEMENT means that media CaptureIDs are expected. 641 o Receiving a CaptureID in RTP or RTCP for a Capture defined in the 642 most recently processed ADVERTISEMENT, but which the same 643 ADVERTISEMENT does not include in the MCC. 645 o Receiving a CaptureID in RTP or RTCP for a Capture not defined in 646 the most recently processed ADVERTISEMENT. 648 7. Multiplexing of CLUE-controlled media using BUNDLE 650 7.1. Overview 652 A CLUE call may involve sending and/or receiving significant numbers 653 of media streams. Conventionally, media streams are sent and 654 received on unique ports. However, each separate port used for this 655 purpose may impose costs that a device wishes to avoid, such as the 656 need to open that port on firewalls and NATs, the need to collect ICE 657 candidates [RFC5245], etc. 659 The BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] extension can be 660 used to negotiate the multiplexing of multiple media lines onto a 661 single 5-tuple for sending and receiving media, allowing devices in 662 calls to another BUNDLE-supporting device to potentially avoid some 663 of the above costs. 665 While CLUE-capable devices MAY support the BUNDLE extension for this 666 purpose supporting the extension is not mandatory for a device to be 667 CLUE-compliant. 669 A CLUE-capable device that supports BUNDLE SHOULD also support rtcp- 670 mux [RFC5761]. However, a CLUE-capable device that supports rtcp-mux 671 MAY or MAY NOT support BUNDLE. 673 7.2. Usage of BUNDLE with CLUE 675 This specification imposes no additional requirements or restrictions 676 on the usage of BUNDLE when used with CLUE. There is no restriction 677 on combining CLUE-controlled media lines and non-CLUE-controlled 678 media lines in the same BUNDLE group or in multiple such groups. 679 However, there are several steps an implementation may wish to take 680 to ameliorate the cost and time requirements of extra SDP offer/ 681 answer exchanges between CLUE and BUNDLE. 683 7.2.1. Generating the Initial Offer 685 BUNDLE mandates that the initial SDP offer MUST use a unique address 686 for each "m=" line with a non-zero port. Because CLUE 687 implementations generally will not include CLUE-controlled media 688 lines with the exception of the data channel in the initial SDP 689 offer, CLUE devices that support large numbers of streams can avoid 690 ever having to open large numbers of ports if they successfully 691 negotiate BUNDLE. 693 An implementation that does include CLUE-controlled media lines in 694 its initial SDP offer while also using BUNDLE must take care to avoid 695 renderings its CLUE-controlled media lines unusable in the event the 696 far end does not negotiate BUNDLE. An implementation MUST NOT send 697 any CLUE-controlled media lines in an initial offer with the 'bundle- 698 only' attribute unless is has established via some other channel that 699 the recipient supports and is able to use BUNDLE. 701 7.2.2. Multiplexing of the data channel and RTP media 703 BUNDLE-supporting CLUE-capable devices MAY include the data channel 704 in the same BUNDLE group as RTP media. In this case the device MUST 705 be able to demultiplex the various transports - see section 9.2 of 706 the BUNDLE draft [I-D.ietf-mmusic-sdp-bundle-negotiation]. If the 707 BUNDLE group includes other protocols than the data channel 708 transported via DTLS the device MUST also be able to differentiate 709 the various protocols. 711 8. Example: A call between two CLUE-capable Endpoints 713 This example illustrates a call between two CLUE-capable Endpoints. 714 Alice, initiating the call, is a system with three cameras and three 715 screens. Bob, receiving the call, is a system with two cameras and 716 two screens. A call-flow diagram is presented, followed by a summary 717 of each message. 719 To manage the size of this section the SDP snippets only illustrate 720 video "m=" lines. SIP ACKs are not always discussed. Note that 721 BUNDLE is not in use. 723 +----------+ +-----------+ 724 | Alice | | Bob | 725 | | | | 726 +----+-----+ +-----+-----+ 727 | | 728 | | 729 | SIP INVITE 1 | 730 |--------------------------------->| 731 | | 732 | | 733 | SIP 200 OK 1 | 734 |<---------------------------------| 735 | | 736 | | 737 | SIP ACK 1 | 738 |--------------------------------->| 739 | | 740 | | 741 | | 742 |<########### MEDIA 1 ############>| 743 | 1 video A->B, 1 video B->A | 744 |<################################>| 745 | | 746 | | 747 | | 748 |<================================>| 749 | CLUE DATA CHANNEL ESTABLISHED | 750 |<================================>| 751 | | 752 | | 753 | CLUE OPTIONS | 754 |<*********************************| 755 | | 756 | | 757 | CLUE OPTIONS RESPONSE | 758 |*********************************>| 759 | | 760 | | 761 | CLUE ADVERTISEMENT 1 | 762 |*********************************>| 763 | | 764 | | 765 | CLUE ADVERTISEMENT 2 | 766 |<*********************************| 767 | | 768 | | 769 | CLUE ADVERTISEMENT ACK 1 | 770 |<*********************************| 771 | | 772 | | 773 | CLUE ADVERTISEMENT ACK 2 | 774 |*********************************>| 775 | | 776 | | 777 | SIP INVITE 2 (+3 sendonly) | 778 |--------------------------------->| 779 | | 780 | | 781 | CLUE CONFIGURE 1 | 782 |<*********************************| 783 | | 784 | | 785 | SIP 200 OK 2 (+2 recvonly) | 786 |<---------------------------------| 787 | | 788 | | 789 | CLUE CONFIGURE RESPONSE 1 | 790 |*********************************>| 791 | | 792 | | 793 | SIP ACK 2 | 794 |--------------------------------->| 795 | | 796 | | 797 | | 798 |<########### MEDIA 2 ############>| 799 | 2 video A->B, 1 video B->A | 800 |<################################>| 801 | | 802 | | 803 | SIP INVITE 3 (+2 sendonly) | 804 |<---------------------------------| 805 | | 806 | | 807 | CLUE CONFIGURE 2 | 808 |*********************************>| 809 | | 810 | | 811 | SIP 200 OK 3 (+2 recvonly) | 812 |--------------------------------->| 813 | | 814 | | 815 | CLUE CONFIGURE RESPONSE 2 | 816 |<*********************************| 817 | | 818 | | 819 | SIP ACK 3 | 820 |<---------------------------------| 821 | | 822 | | 823 | | 824 |<########### MEDIA 3 ############>| 825 | 2 video A->B, 2 video B->A | 826 |<################################>| 827 | | 828 | | 829 | | 830 v v 832 In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP 833 body the basic audio and video capabilities and the data channel as 834 per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" 835 media feature tag in the INVITE. A snippet of the SDP showing the 836 grouping attribute and the video "m=" line are shown below. Alice 837 has included a "CLUE" group, and included the mid corresponding to a 838 data channel in the group (3). Note that Alice has chosen not to 839 include any CLUE-controlled media in the initial offer - the mid 840 value of the video line is not included in the "CLUE" group. 842 ... 843 a=group:CLUE 3 844 ... 845 m=video 6002 RTP/AVP 96 846 a=rtpmap:96 H264/90000 847 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 848 a=sendrecv 849 a=mid:2 850 ... 851 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 852 a=setup:actpass 853 a=sctp-port: 5000 854 a=dcmap:2 subprotocol="CLUE";ordered=true 855 a=mid:3 857 Bob responds with a similar SDP in SIP 200 OK 1, which also has a 858 "CLUE" group including the mid value of a data channel; due to their 859 similarity no SDP snippet is shown here. Bob wishes to receive 860 initial media, and so includes corresponding non-CLUE-controlled 861 audio and video lines. Bob also includes the "sip.clue" media 862 feature tag in the 200 OK. Alice and Bob are each now able to send a 863 single audio and video stream. This is illustrated as MEDIA 1. 865 With the successful initial SDP O/A Alice and Bob are also free to 866 negotiate the CLUE data channel. This is illustrated as CLUE DATA 867 CHANNEL ESTABLISHED. 869 Once the data channel is established CLUE protocol negotiation 870 begins. In this case Bob chose to be the DTLS client (sending 871 a=active in his SDP answer) and hence is the CLUE Channel Initiator 872 and sends a CLUE OPTIONS message describing his version support. On 873 receiving that message Alice sends her corresponding CLUE OPTIONS 874 RESPONSE. 876 With the OPTIONS phase complete Alice now sends her CLUE 877 ADVERTISEMENT (CLUE ADVERTISEMENT 1). She advertises three static 878 Captures representing her three cameras. She also includes switched 879 Captures suitable for two- and one-screen systems. All of these 880 Captures are in a single Capture Scene, with suitable Capture Scene 881 Views to tell Bob that he should either subscribe to the three static 882 Captures, the two switched Captures or the one switched Capture. 883 Alice has no simultaneity constraints, so includes all six Captures 884 in one simultaneous set. Finally, Alice includes an Encoding Group 885 with three Encoding IDs: "enc1", "enc2" and "enc3". These Encoding 886 IDs aren't currently valid, but will match the next SDP offer she 887 sends. 889 Bob received CLUE ADVERTISEMENT 1 but does not yet send a CONFIGURE 890 message, because he has not yet received Alice's Encoding 891 information, so as yet he does not know if she will have sufficient 892 resources to send him the two streams he ideally wants at a quality 893 he is happy with. Because Bob is not sending an immediate CONFIGURE 894 with the "ack" element set he must send an explicit ACK message (CLUE 895 ADVERTISEMENT ACK 1) to signal receipt of CLUE ADVERTISEMENT 1. 897 Bob also sends his CLUE ADVERTISEMENT (CLUE ADVERTISEMENT 2) - though 898 the diagram shows that this occurs after Alice sends CLUE 899 ADVERTISEMENT 1 Bob sends his ADVERTISEMENT independently and does 900 not wait for CLUE ADVERTISEMENT 1 to arrive. He advertises two 901 static Captures representing his cameras. He also includes a single 902 composed Capture for single-screen systems, in which he will 903 composite the two camera views into a single video stream. All three 904 Captures are in a single Capture Scene, with suitable Capture Scene 905 Views to tell Alice that she should either subscribe to the two 906 static Captures, or the single composed Capture. Bob also has no 907 simultaneity constraints, so includes all three Captures in one 908 simultaneous set. Bob also includes a single Encoding Group with two 909 Encoding IDs: "foo" and "bar". 911 Similarly, Alice receives CLUE ADVERTISEMENT 2 but does not yet send 912 a CONFIGURE message, because she has not yet received Bob's Encoding 913 information, sending instead an ACK (CLUE ADVERTISEMENT ACK 2). 915 Both sides have now sent their CLUE ADVERTISEMENT messages and an SDP 916 exchange is required to negotiate Encodings. For simplicity, in this 917 case Alice is shown sending an INVITE with a new offer; in many 918 implementations both sides might send an INVITE, which would be 919 resolved by use of the 491 Request Pending resolution mechanism from 920 [RFC3261]. 922 Alice now sends SIP INVITE 2. She maintains the sendrecv audio, 923 video and CLUE "m=" lines, and she adds three new sendonly "m=" lines 924 to represent the three CLUE-controlled Encodings she can send. Each 925 of these "m=" lines has a label corresponding to one of the Encoding 926 IDs from CLUE ADVERTISEMENT 1. Each also has its mid added to the 927 grouping attribute to show they are controlled by the CLUE channel. 928 A snippet of the SDP showing the grouping attribute, data channel and 929 the video "m=" lines are shown below: 931 ... 932 a=group:CLUE 3 4 5 6 933 ... 934 m=video 6002 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:2 939 ... 940 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 941 a=sctp-port: 5000 942 a=dcmap:2 subprotocol="CLUE";ordered=true 943 a=mid:3 944 ... 945 m=video 6004 RTP/AVP 96 946 a=rtpmap:96 H264/90000 947 a=fmtp:96 profile-level-id=42e016 948 a=sendonly 949 a=mid:4 950 a=label:enc1 951 m=video 6006 RTP/AVP 96 952 a=rtpmap:96 H264/90000 953 a=fmtp:96 profile-level-id=42e016 954 a=sendonly 955 a=mid:5 956 a=label:enc2 957 m=video 6008 RTP/AVP 96 958 a=rtpmap:96 H264/90000 959 a=fmtp:96 profile-level-id=42e016 960 a=sendonly 961 a=mid:6 962 a=label:enc3 964 Bob now has all the information he needs to decide which streams to 965 configure, allowing him to send both a CLUE CONFIGURE message and his 966 SDP answer. As such he now sends CLUE CONFIGURE 1. This requests 967 the pair of switched Captures that represent Alice's scene, and he 968 configures them with encoder ids "enc1" and "enc2". 970 Bob also sends his SDP answer as part of SIP 200 OK 2. Alongside his 971 original audio, video and CLUE "m=" lines he includes three 972 additional "m=" lines corresponding to the three added by Alice; two 973 active recvonly "m= "lines and an inactive "m=" line for the third. 974 He adds their mid values to the grouping attribute to show they are 975 controlled by the CLUE channel. A snippet of the SDP showing the 976 grouping attribute and the video "m=" lines are shown below (mid 100 977 represents the CLUE channel, not shown): 979 ... 980 a=group:CLUE 11 12 13 100 981 ... 982 m=video 58722 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:10 987 ... 988 m=video 58724 RTP/AVP 96 989 a=rtpmap:96 H264/90000 990 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 991 a=recvonly 992 a=mid:11 993 m=video 58726 RTP/AVP 96 994 a=rtpmap:96 H264/90000 995 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 996 a=recvonly 997 a=mid:12 998 m=video 58728 RTP/AVP 96 999 a=rtpmap:96 H264/90000 1000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1001 a=inactive 1002 a=mid:13 1004 Alice receives Bob's message CLUE CONFIGURE 1 and sends CLUE RESPONSE 1005 1 to ack its reception. She does not yet send the Capture Encodings 1006 specified, because at this stage she hasn't processed Bob's answer 1007 SDP and so hasn't negotiated the ability for Bob to receive these 1008 streams. 1010 On receiving SIP 200 OK 2 from Bob Alice sends her SIP ACK (SIP ACK 1011 2). She is now able to send the two streams of video Bob requested - 1012 this is illustrated as MEDIA 2. 1014 The constraints of offer/answer meant that Bob could not include his 1015 encoding information as new "m=" lines in SIP 200 OK 2. As such Bob 1016 now sends SIP INVITE 3 to generate a new offer. Along with all the 1017 streams from SIP 200 OK 2 Bob also includes two new sendonly streams. 1018 Each stream has a label corresponding to the Encoding IDs in his CLUE 1019 ADVERTISEMENT 2 message. He also adds their mid values to the 1020 grouping attribute to show they are controlled by the CLUE channel. 1021 A snippet of the SDP showing the grouping attribute and the video 1022 "m=" lines are shown below (mid 100 represents the CLUE channel, not 1023 shown): 1025 ... 1026 a=group:CLUE 11 12 14 15 100 1027 ... 1028 m=video 58722 RTP/AVP 96 1029 a=rtpmap:96 H264/90000 1030 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1031 a=sendrecv 1032 a=mid:10 1033 ... 1034 m=video 58724 RTP/AVP 96 1035 a=rtpmap:96 H264/90000 1036 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1037 a=recvonly 1038 a=mid:11 1039 m=video 58726 RTP/AVP 96 1040 a=rtpmap:96 H264/90000 1041 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1042 a=recvonly 1043 a=mid:12 1044 m=video 0 RTP/AVP 96 1045 a=mid:13 1046 m=video 58728 RTP/AVP 96 1047 a=rtpmap:96 H264/90000 1048 a=fmtp:96 profile-level-id=42e016 1049 a=sendonly 1050 a=label:foo 1051 a=mid:14 1052 m=video 58730 RTP/AVP 96 1053 a=rtpmap:96 H264/90000 1054 a=fmtp:96 profile-level-id=42e016 1055 a=sendonly 1056 a=label:bar 1057 a=mid:15 1059 Having received this, Alice now has all the information she needs to 1060 send her CLUE CONFIGURE message and her SDP answer. In CLUE 1061 CONFIGURE 2 she requests the two static Captures from Bob, to be sent 1062 on Encodings "foo" and "bar". 1064 Alice also sends SIP 200 OK 3, matching two recvonly "m=" lines to 1065 Bob's new sendonly lines. She includes their mid values in the 1066 grouping attribute to show they are controlled by the CLUE channel. 1067 Alice also now deactivates the initial non-CLUE-controlled media, as 1068 bidirectional CLUE-controlled media is now available. A snippet of 1069 the SDP showing the grouping attribute and the video "m=" lines are 1070 shown below (mid 3 represents the data channel, not shown): 1072 ... 1073 a=group:CLUE 3 4 5 7 8 1074 ... 1075 m=video 0 RTP/AVP 96 1076 a=mid:2 1077 ... 1078 m=video 6004 RTP/AVP 96 1079 a=rtpmap:96 H264/90000 1080 a=fmtp:96 profile-level-id=42e016 1081 a=sendonly 1082 a=mid:4 1083 a=label:enc1 1084 m=video 6006 RTP/AVP 96 1085 a=rtpmap:96 H264/90000 1086 a=fmtp:96 profile-level-id=42e016 1087 a=sendonly 1088 a=mid:5 1089 a=label:enc2 1090 m=video 0 RTP/AVP 96 1091 a=mid:6 1092 m=video 6010 RTP/AVP 96 1093 a=rtpmap:96 H264/90000 1094 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1095 a=recvonly 1096 a=mid:7 1097 m=video 6012 RTP/AVP 96 1098 a=rtpmap:96 H264/90000 1099 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1100 a=recvonly 1101 a=mid:8 1103 Bob receives Alice's message CLUE CONFIGURE 2 and sends CLUE RESPONSE 1104 2 to ack its reception. Bob does not yet send the Capture Encodings 1105 specified, because he hasn't yet received and processed Alice's SDP 1106 answer and negotiated the ability to send these streams. 1108 Finally, on receiving SIP 200 OK 3 Bob is now able to send the two 1109 streams of video Alice requested - this is illustrated as MEDIA 3. 1111 Both sides of the call are now sending multiple video streams with 1112 their sources defined via CLUE negotiation. As the call progresses 1113 either side can send new ADVERTISEMENT or CONFIGURE message or new 1114 SDP offer/answers to add, remove or change what they have available 1115 or want to receive. 1117 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 1119 In this brief example Alice is a CLUE-capable Endpoint making a call 1120 to Bob, who is not CLUE-capable (i.e. is not able to use the CLUE 1121 protocol). 1123 +----------+ +-----------+ 1124 | Alice | | Bob | 1125 | | | | 1126 +----+-----+ +-----+-----+ 1127 | | 1128 | | 1129 | SIP INVITE 1 | 1130 |--------------------------------->| 1131 | | 1132 | | 1133 | 200 0K 1 | 1134 |<---------------------------------| 1135 | | 1136 | | 1137 | ACK 1 | 1138 |--------------------------------->| 1139 | | 1140 | | 1141 | | 1142 |<########### MEDIA 1 ############>| 1143 | 1 video A->B, 1 video B->A | 1144 |<################################>| 1145 | | 1146 | | 1147 | | 1148 | | 1149 v v 1151 In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP 1152 body the basic audio and video capabilities and the data channel as 1153 per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" 1154 media feature tag in the INVITE. A snippet of the SDP showing the 1155 grouping attribute and the video "m=" line are shown below. Alice 1156 has included a "CLUE" group, and included the mid corresponding to a 1157 data channel in the group (3). Note that Alice has chosen not to 1158 include any CLUE-controlled media in the initial offer - the mid 1159 value of the video line is not included in the "CLUE" group. 1161 ... 1162 a=group:CLUE 3 1163 ... 1164 m=video 6002 RTP/AVP 96 1165 a=rtpmap:96 H264/90000 1166 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1167 a=sendrecv 1168 a=mid:2 1169 ... 1170 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 1171 a=sctp-port: 5000 1172 a=dcmap:2 subprotocol="CLUE";ordered=true 1173 a=mid:3 1175 Bob is not CLUE-capable, and hence does not recognize the "CLUE" 1176 semantic for grouping attribute, nor does he support the data 1177 channel. IN SIP 200 OK 1 he responds with an answer with audio and 1178 video, but with the data channel zeroed. 1180 From the lack of a CLUE group Alice understands that Bob does not 1181 support CLUE, or does not wish to use it. Both sides are now able to 1182 send a single audio and video stream to each other. Alice at this 1183 point begins to send her fallback video: in this case likely a 1184 switched view from whichever camera shows the current loudest 1185 participant on her side. 1187 10. Acknowledgements 1189 Besides the authors, the team focusing on this draft consists of: 1190 Roni Even, Simon Pietro-Romano, Roberta Presta. 1192 Christian Groves, Jonathan Lennox and Adam Roach have contributed 1193 detailed comments and suggestions. 1195 11. IANA Considerations 1197 11.1. New SDP Grouping Framework Attribute 1199 This document registers the following semantics with IANA in the 1200 "Semantics for the "group" SDP Attribute" subregistry (under the 1201 "Session Description Protocol (SDP) Parameters" registry per 1202 [RFC5888]: 1204 Semantics Token Reference 1205 ------------------------------------- ------ --------- 1206 CLUE-controlled m-line CLUE [this draft] 1208 11.2. New SIP Media Feature Tag 1210 This specification registers a new media feature tag in the SIP 1211 [RFC3261] tree per the procedures defined in [RFC2506] and [RFC3840]. 1213 Media feature tag name: sip.clue 1215 ASN.1 Identifier: 1.3.6.1.8.4.29 1217 Summary of the media feature indicated by this tag: This feature tag 1218 indicates that the device supports CLUE-controlled media. 1220 Values appropriate for use with this feature tag: Boolean. 1222 The feature tag is intended primarily for use in the following 1223 applications, protocols, services, or negotiation mechanisms: 1225 This feature tag is most useful in a communications application for 1226 describing the capabilities of a device to use the CLUE control 1227 protocol to negotiate the use of multiple media streams. 1229 Related standards or documents: [this draft] 1231 Security Considerations: Security considerations for this media 1232 feature tag are discussed in Section 12 of [this draft]. 1234 Name(s) & email address(es) of person(s) to contact for further 1235 information: 1237 o Internet Engineering Steering Group: iesg@ietf.org 1239 Intended usage: COMMON 1241 12. Security Considerations 1243 CLUE makes use of a number of protocols and mechanisms, either 1244 defined by CLUE or long-standing. The security considerations 1245 section of the CLUE Framework [I-D.ietf-clue-framework] addresses the 1246 need to secure these mechanisms by following the recommendations of 1247 the individual protocols. 1249 Beyond the need to secure the constituent protocols, the use of CLUE 1250 does impose additional security concerns. One area of increased risk 1251 involves the potential for a malicious party to subvert a CLUE- 1252 capable device to attack a third party by driving large volumes of 1253 media (particularly video) traffic at them by establishing a 1254 connection to the CLUE-capable device and directing the media to the 1255 victim. While this is a risk for all media devices, a CLUE-capable 1256 device may allow the attacker to configure multiple media streams to 1257 be sent, significantly increasing the volume of traffic directed at 1258 the victim. 1260 This attack can be prevented by ensuring that the media recipient 1261 intends to receive the media packets. As such all CLUE-capable 1262 devices MUST support key negotiation and receiver intent assurance 1263 via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines. All CLUE- 1264 controlled RTP "m" lines must be secured and implemented using 1265 mechanisms such as SRTP [RFC3711]. CLUE implementations MAY choose 1266 not to require the use of SRTP to secure legacy (non-CLUE-controlled) 1267 media for backwards compatibility with older SIP clients that are 1268 incapable of supporting it. 1270 CLUE also defines a new media feature tag that indicates CLUE 1271 support. This tag may be present even in non-CLUE calls, which 1272 increases the metadata available about the sending device, which can 1273 help an attacker differentiate between multiple devices and help them 1274 identify otherwise anonymised users via the fingerprint of features 1275 their device supports. To prevent this, SIP signaling used to set up 1276 CLUE sessions SHOULD always be encrypted using TLS [RFC5630]. 1278 The CLUE protocol also carries additional information that could be 1279 used to help fingerprint a particular user or to identify the 1280 specific version of software being used. CLUE Framework 1281 [I-D.ietf-clue-protocol] provides details of these issues and how to 1282 mitigate them. 1284 13. Change History 1286 Note to RFC Editor: please remove this section prior to publication 1288 -12: Revision by Rob Hansen 1290 * Title change to expand and elucidate our totally-not-contrived 1291 acronym 1293 * Explicit reference to RFC3840 added when first mentioning media 1294 feature tags 1296 * Have standardised references to Clue protocol messages to 1297 ADVERTISEMENT, CONFIGURE and ACK, in line with section 12.4.1. 1299 of the protocol document (though the protocol document also 1300 uses ADV and CONF). 1302 * 'MUST' in opening paragraph of 4.2 changed from normative 1303 'MUST' to logical 'must' 1305 * Per his request, removed Cristian's company affiliation and 1306 changed his email address 1308 * Clarified that an implementation that chooses not to send media 1309 during the initial negotiation process must still send RTCP as 1310 normal 1312 * Rewrote the section on adding/remove clue m-lines after the 1313 initial exchange to make clear that this is just standard SDP. 1314 For non-clue controlled lines, recommended they are deactivated 1315 by zeroing the port when turning them off after clue is 1316 successfully negotiated. 1318 * Added guidance that an initial offer containing clue-controlled 1319 m-lines MUST NOT set them bundle-only unless they somehow know 1320 the far end actually supports BUNDLE 1322 * Added section saying that CLUE devices that do BUNDLE SHOULD do 1323 rtcp-mux, but that the requirement doesn't exist in the other 1324 direction (eg, supporting rtcp-mux does not require or imply 1325 the need to implement BUNDLE) 1327 * For clue-controlled m-lines where the sender included more 1328 encodings than the recipient wants, have standardised on using 1329 "a=inactive" to not receive RTP on them (previously had a mix 1330 of "a=inactive" or port 0, or in some cases did not specify). 1332 * Page break added before the big ladder diagram in the example 1334 * Have added a direction attribute to the SDP example in the data 1335 channel, and made explicit that Bob is the DTLS client and 1336 hence the CLUE Channel Initiator. 1338 * Have removed all language that referenced the possibility of 1339 having multiple CLUE groups 1341 * Removed names appearing in the authors list from the 1342 acknowledgements 1344 * Changed the contact for the IANA registration to iesg@ietf.org 1345 * Security section updated to clarify that DTLS-SRTP must be 1346 supported (as opposed to DTLS) and removed the reference to 1347 RFC7202. 1349 * Other syntactic tweaks based on Paul and Adam's feedback 1351 -11: Revision by Rob Hansen 1353 * Some informative references added for SIP and SDP. 1355 * 'a=mid' lines added to example m-lines with port 0, per RFC5888 1356 section 6. 1358 * Instace of 'must' changed to normative 'MUST', along with 1359 various minor clarifications and corrections. 1361 * Abstract made standalone without citations, per RFC7322 section 1362 4.3. 1364 * RFC editor note added to remove this section. 1366 -10: Revision by Rob Hansen 1368 * Changes to draft-ietf-clue-protocol between 07 and 11 reviewed 1369 to ensure compatibility between documents has been maintained. 1371 * Expanded the portion of the document related to fingerprinting 1372 with info on the CLUE channel as well as SIP. 1374 -09: Revision by Rob Hansen 1376 * A few minor spelling tweaks 1378 * Made removing the CLUE group mandatory when disabling CLUE mid- 1379 call. Made clear that any CLUE-controlled m-lines should be 1380 disabled or else how they're used is up to the implementation. 1382 -08: Revision by Rob Hansen 1384 * Spelling and grammar fixes from Paul and Christian gratefully 1385 adopted 1387 * Expanded the section on disabling CLUE mid-call to make 1388 explicit the actions required to disable the CLUE channel 1389 gracefully, or to handle someone else doing the same. 1391 * Made a number of fixes to the example call flow to better 1392 reflect the recommendations in the document. 1394 -07: Revision by Rob Hansen 1396 * Removed the entire 'Media line directionality' section as a 1397 discussion of the pros/cons of using bidirectional vs 1398 unidirectional schemes wasn't suitable for a finalised version. 1399 The unidirectionality requirement is covered normatively in an 1400 earlier section. 1402 * BUNDLE no longer includes an address synchronisation step so 1403 the suggestion to wait until that done has been replaced with 1404 some general language about following any negotiated 1405 extensions. 1407 * Added OPTIONS negotiation to the example flow, and revised the 1408 flow to ensure it matched protocol document. 1410 * Section on not sending CLUE control media until CLUE 1411 negotiation completes narrowed to notify that only RTP should 1412 not be sent until negotiation completes and add RTCP to the 1413 list of things that should be sent as normal, in line with 1414 a=inactive. 1416 * Make explicit that m=recvonly lines don't need to have a label, 1417 as only m=sendonly lines are referenced by CLUE protocol 1418 messages. 1420 * Fix formatting of IANA sections. Improve syntax of feature tag 1421 section in line with Paul's suggestions. Definition of feature 1422 tag narrowed to be multiple media lines *negotiated via CLUE 1423 protocol* rather than more generic 'multiple media lines'. 1425 * General corrections to grammar, spelling and readability based 1426 on Christian, Paul and Mark; in many cases suggested text was 1427 gratefully accepted. 1429 -06: Revision by Rob Hansen 1431 * State machine interactions updated to match versions in -04 of 1432 protocol doc. 1434 * Section on encoding updated to specify both encID and 1435 encodingID from data model doc. 1437 * Removed the limitations on describing H264 encoding limits 1438 using SDP syntax as an open issue. 1440 * Previous draft had SRTP and DTLS mandatory to implement and to 1441 use on CLUE- controlled m lines. Current version has DTLS 1442 mandatory to implement, and 'security' mandatory to use but 1443 does not define what that security is. 1445 * Terminology reference to framework doc reinforced. All 1446 terminology that duplicates framework removed. All text 1447 updated with capitalisation that matches framework document's 1448 terminology. 1450 * SDP example syntax updated to match that of ietf-clue- 1451 datachannel and hence ietf-mmusic-data-channel-sdpneg. 1453 -05: Revision by Rob Hansen 1455 * SRTP/DTLS made mandatory for CLUE-controlled media lines. 1457 * IANA consideration section added (text as proposed by Christian 1458 Groves). 1460 * Includes provision for dependent streams on seperate "m" lines 1461 having the same encID as their parent "m" line. 1463 * References to putting CLUE-controlled media and data channels 1464 in more than one CLUE group removed, since the document no 1465 longer supports using more than one CLUE group. 1467 * Section on CLUE controlled media restrictions still applying 1468 even if the call does not end up being CLUE enabled being 1469 rewritten to hopefully be clearer. 1471 * Other minor syntax improvements. 1473 -04: Revision by Rob Hansen 1475 * Updated DTLS/SCTP channel syntax in examples to fix errors and 1476 match latest format defined in draft-ietf-mmusic-sctp-sdp-07. 1478 * Clarified the behaviour if an SDP offer includes a CLUE- 1479 controlled "m" line and the answer accepts that "m" line but 1480 without CLUE control of that line. 1482 * Added a new section on the sending and receiving of CaptureIDs 1483 in RTP and RTCP. Includes a section on the necessity of the 1484 receiver coping with unexpected CaptureIDs (or the lack 1485 thereof) due to MCCs being redefined in new Advertisement 1486 messages. 1488 * Added reminder on IANA section on registering grouping semantic 1489 and media feature tag, removed the less formal sections that 1490 did the same job. 1492 * Fixed and clarified issues raised by Christian's document 1493 review. 1495 * Added a number of security considerations. 1497 -03: Revision by Rob Hansen 1499 * Clarified text on not rejecting messages because they contain 1500 unknown encIDs. 1502 * Removed normative language in section on accepting/rejecting 1503 non-CLUE-controlled media in the initial answer. 1505 * Example SDP updated to include the data channel "m" lines. 1507 * Example call flow updated to show disablement of non-CLUE- 1508 controlled media once CLUE-controlled media is flowing. 1510 -02: Revision by Rob Hansen 1512 * Added section on not accepting non-CLUE-controlled "m" lines in 1513 the initial answer when CLUE is to be negotiated. 1515 * Removed previous language attempting to describe media 1516 restrictions for CLUE-controlled "m" lines that had not been 1517 configured, and replaced it with much more accurate 'treat as 1518 "a=inactive" was set'. 1520 * Made label element mandatory for CLUE-controlled media (was 1521 previously "SHOULD include", but there didn't seem a good 1522 reason for this - anyone wishing to include the "m" line but 1523 not immediately use it in CLUE can simply leave it out of the 1524 .) 1526 * Added a section on the specifics of relating encodings in SDP 1527 to elements in the CLUE protocol, including the fact 1528 that both Advertisement and Configure messages reference the 1529 *encoding* (eg, in the Configure case the sender of the 1530 Configure message includes the labels of the recipient's "m" 1531 lines as their contents). 1533 * Minor revisions to the section on complying with normative SDP/ 1534 CLUEstate machine language to clarify that these were not new 1535 normative language, merely that existing normative language 1536 still applies. 1538 * Removed appendices which previously contained information to be 1539 transferred to the protocol and data channel drafts. Removed 1540 other text that discussed alternatives to the current approach. 1542 * Cleaned up some 'todo' text. 1544 -01: Revision by Rob Hansen 1546 * Revised terminology - removed the term 'CLUE-enabled' device as 1547 insufficiently distinct from 'CLUE-capable' and instead added a 1548 term for 'CLUE-enabled' calls. 1550 * Removed text forbidding RTCP and instead added text that ICE/ 1551 DTLS negotiation for CLUE controlled media must be done as 1552 normal irrespective of CLUE negotiation. 1554 * Changed 'sip.telepresence' to 'sip.clue' and 'TELEPRESENCE' 1555 grouping semantic back to CLUE. 1557 * Made it mandatory to have exactly one mid corresponding to a 1558 data channel in a CLUE group 1560 * Forbade having multiple CLUE groups unless a specification for 1561 doing so is published. 1563 * Refactored SDP-related text; previously the encoding 1564 information had been in the "initial offer" section despite the 1565 fact that we recommend that the initial offer doesn't actually 1566 include any encodings. I moved the specifications of encodings 1567 and how they're received to an earlier, seperate section. 1569 * Added text on how the state machines in CLUE and SDP are 1570 allowed to affect one another, and further recommendations on 1571 how a device should handle the sending of CLUE and SDP changes. 1573 -00: Revision by Rob Hansen 1575 * Submitted as -00 working group document 1577 draft-kyzivat-08: Revisions by Rob Hansen 1579 * Added media feature tag for CLUE support ('sip.telepresence') 1581 * Changed grouping semantic from 'CLUE' to 'TELEPRESENCE' 1582 * Restructured document to be more centred on the grouping 1583 semantic and its use with O/A 1585 * Lots of additional text on usage of the grouping semantic 1587 * Stricter definition of CLUE-controlled m lines and how they 1588 work 1590 * Some additional text on defining what happens when CLUE 1591 supports is added or removed 1593 * Added details on when to not send RTCP for CLUE-controlled "m" 1594 lines. 1596 * Added a section on using BUNDLE with CLUE 1598 * Updated data channel references to point at new WG document 1599 rather than indivual draft 1601 draft-kyzivat-07: Revisions by Rob Hansen 1603 * Removed the text providing arguments for encoding limits being 1604 in SDP and Encoding Groups in the CLUE protocol in favor of the 1605 specifics of how to negotiate encodings in SDP 1607 * Added normative language on the setting up of a CLUE call, and 1608 added sections on mid-call changes to the CLUE status. 1610 * Added references to [I-D.ietf-clue-datachannel] where 1611 appropriate. 1613 * Added some terminology for various types of CLUE and non-CLUE 1614 states of operation. 1616 * Moved language related to topics that should be in 1617 [I-D.ietf-clue-datachannel] and [I-D.ietf-clue-protocol], but 1618 that has not yet been resolved in those documents, into an 1619 appendix. 1621 draft-kyzivat-06: Revisions by Rob Hansen 1623 * Removed CLUE message XML schema and details that are now in 1624 draft-presta-clue-protocol 1626 * Encoding limits in SDP section updated to note that this has 1627 been investigated and discussed and is the current working 1628 assumption of the WG, though consensus has not been fully 1629 achieved. 1631 * A section has also been added on the current mandation of 1632 unidirectional "m" lines. 1634 * Updated CLUE messaging in example call flow to match draft- 1635 presta-clue-protocol-03 1637 draft-kyzivat-05: Revisions by pkyzivat: 1639 * Specified versioning model and mechanism. 1641 * Added explicit response to all messages. 1643 * Rearranged text to work with the above changes. (Which 1644 rendered diff almost useless.) 1646 draft-kyzivat-04: Revisions by Rob Hansen: ??? 1648 draft-kyzivat-03: Revisions by pkyzivat: 1650 * Added a syntax section with an XML schema for CLUE messages. 1651 This is a strawhorse, and is very incomplete, but it 1652 establishes a template for doing this based on elements defined 1653 in the data model. (Thanks to Roberta for help with this!) 1655 * Did some rewording to fit the syntax section in and reference 1656 it. 1658 * Did some relatively minor restructuring of the document to make 1659 it flow better in a logical way. 1661 draft-kyzivat-02: A bunch of revisions by pkyzivat: 1663 * Moved roberta's call flows to a more appropriate place in the 1664 document. 1666 * New section on versioning. 1668 * New section on NAK. 1670 * A couple of possible alternatives for message acknowledgment. 1672 * Some discussion of when/how to signal changes in provider 1673 state. 1675 * Some discussion about the handling of transport errors. 1677 * Added a change history section. 1679 These were developed by Lennard Xiao, Christian Groves and Paul, 1680 so added Lennard and Christian as authors. 1682 draft-kyzivat-01: Updated by roberta to include some sample call 1683 flows. 1685 draft-kyzivat-00: Initial version by pkyzivat. Established general 1686 outline for the document, and specified a few things thought to 1687 represent wg consensus. 1689 14. References 1691 14.1. Normative References 1693 [I-D.ietf-clue-data-model-schema] 1694 Presta, R. and S. Romano, "An XML Schema for the CLUE data 1695 model", draft-ietf-clue-data-model-schema-17 (work in 1696 progress), August 2016. 1698 [I-D.ietf-clue-datachannel] 1699 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1700 clue-datachannel-14 (work in progress), August 2016. 1702 [I-D.ietf-clue-framework] 1703 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 1704 for Telepresence Multi-Streams", draft-ietf-clue- 1705 framework-25 (work in progress), January 2016. 1707 [I-D.ietf-clue-protocol] 1708 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 1709 clue-protocol-13 (work in progress), February 2017. 1711 [I-D.ietf-clue-rtp-mapping] 1712 Even, R. and J. Lennox, "Mapping RTP streams to CLUE Media 1713 Captures", draft-ietf-clue-rtp-mapping-14 (work in 1714 progress), February 2017. 1716 [I-D.ietf-mmusic-data-channel-sdpneg] 1717 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1718 and J. Marcon, "SDP-based Data Channel Negotiation", 1719 draft-ietf-mmusic-data-channel-sdpneg-12 (work in 1720 progress), March 2017. 1722 [I-D.ietf-mmusic-sctp-sdp] 1723 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 1724 "Session Description Protocol (SDP) Offer/Answer 1725 Procedures For Stream Control Transmission Protocol (SCTP) 1726 over Datagram Transport Layer Security (DTLS) Transport.", 1727 draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 1728 2017. 1730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1731 Requirement Levels", BCP 14, RFC 2119, 1732 DOI 10.17487/RFC2119, March 1997, . 1735 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1736 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1737 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1738 . 1740 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1741 Protocol (SDP) Label Attribute", RFC 4574, 1742 DOI 10.17487/RFC4574, August 2006, . 1745 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1746 for Establishing a Secure Real-time Transport Protocol 1747 (SRTP) Security Context Using Datagram Transport Layer 1748 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1749 2010, . 1751 14.2. Informative References 1753 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1754 Holmberg, C., Alvestrand, H., and C. Jennings, 1755 "Negotiating Media Multiplexing Using the Session 1756 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1757 negotiation-38 (work in progress), April 2017. 1759 [I-D.ietf-rtcweb-data-channel] 1760 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1761 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1762 progress), January 2015. 1764 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1765 Registration Procedure", BCP 31, RFC 2506, 1766 DOI 10.17487/RFC2506, March 1999, . 1769 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1770 A., Peterson, J., Sparks, R., Handley, M., and E. 1771 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1772 DOI 10.17487/RFC3261, June 2002, . 1775 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1776 with Session Description Protocol (SDP)", RFC 3264, 1777 DOI 10.17487/RFC3264, June 2002, . 1780 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1781 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1782 2002, . 1784 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1785 "Indicating User Agent Capabilities in the Session 1786 Initiation Protocol (SIP)", RFC 3840, 1787 DOI 10.17487/RFC3840, August 2004, . 1790 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1791 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1792 July 2006, . 1794 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1795 (ICE): A Protocol for Network Address Translator (NAT) 1796 Traversal for Offer/Answer Protocols", RFC 5245, 1797 DOI 10.17487/RFC5245, April 2010, . 1800 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1801 Initiation Protocol (SIP)", RFC 5630, 1802 DOI 10.17487/RFC5630, October 2009, . 1805 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1806 Control Packets on a Single Port", RFC 5761, 1807 DOI 10.17487/RFC5761, April 2010, . 1810 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1811 Protocol (SDP) Grouping Framework", RFC 5888, 1812 DOI 10.17487/RFC5888, June 2010, . 1815 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1816 Payload Format for H.264 Video", RFC 6184, 1817 DOI 10.17487/RFC6184, May 2011, . 1820 Authors' Addresses 1822 Paul Kyzivat 1824 Email: pkyzivat@alum.mit.edu 1826 Lennard Xiao 1827 Huawei 1829 Email: lennard.xiao@huawei.com 1831 Christian Groves 1833 Email: cngroves.std@gmail.com 1835 Robert Hansen 1836 Cisco Systems 1838 Email: rohanse2@cisco.com