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