idnits 2.17.1 draft-ietf-clue-signaling-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-clue-protocol], [I-D.ietf-clue-datachannel]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When a Media Provider redefines an MCC which involves CaptureIDs, the reception of the relevant CaptureIDs by the recipient will either lead or lag reception and processing of the new Advertisement by the recipient. As such, a Media Consumer MUST not be disrupted by any of the following in any CLUE- controlled media stream it is receiving, whether that stream is for a static Capture or for an MCC (as any static Capture may be redefined to an MCC in a later Advertisement): -- The document date (March 21, 2016) is 2929 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-clue-data-model-schema-13 == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-protocol (ref. 'I-D.ietf-clue-protocol') == Outdated reference: A later version (-18) exists of draft-ietf-clue-datachannel-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel') == Outdated reference: A later version (-14) exists of draft-ietf-clue-rtp-mapping-06 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-16 == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-08 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-27 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Kyzivat 3 Internet-Draft 4 Intended status: Standards Track L. Xiao 5 Expires: September 22, 2016 C. Groves 6 Huawei 7 R. Hansen 8 Cisco Systems 9 March 21, 2016 11 CLUE Signaling 12 draft-ietf-clue-signaling-09 14 Abstract 16 This document specifies how CLUE-specific signaling such as the CLUE 17 protocol [I-D.ietf-clue-protocol] and the CLUE data channel 18 [I-D.ietf-clue-datachannel] are used with each other and with 19 existing signaling mechanisms such as SIP and SDP to produce a 20 telepresence call. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 22, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Media Feature Tag Definition . . . . . . . . . . . . . . . . 4 59 4. SDP Grouping Framework CLUE Extension Semantics . . . . . . . 4 60 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. The CLUE data channel and the CLUE grouping semantic . . 4 62 4.3. CLUE-controlled media and the CLUE grouping semantic . . 5 63 4.4. SDP semantics for CLUE-controlled media . . . . . . . . . 5 64 4.4.1. Signaling CLUE Encodings . . . . . . . . . . . . . . 5 65 4.4.1.1. Referencing Encodings in the CLUE protocol . . . 6 66 4.4.2. Negotiating receipt of CLUE Capture Encodings in SDP 7 67 4.5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 7 68 4.5.1. Generating the Initial Offer . . . . . . . . . . . . 7 69 4.5.2. Generating the Answer . . . . . . . . . . . . . . . . 7 70 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 7 71 4.5.2.2. Negotiating CLUE-controlled media . . . . . . . . 8 72 4.5.2.3. Negotiating non-CLUE controlled media . . . . . . 8 73 4.5.3. Processing the initial Offer/Answer negotiation . . . 9 74 4.5.3.1. Successful CLUE negotiation . . . . . . . . . . . 9 75 4.5.3.2. CLUE negotiation failure . . . . . . . . . . . . 9 76 4.5.4. Modifying the session . . . . . . . . . . . . . . . . 9 77 4.5.4.1. Adding and removing CLUE-controlled media . . . . 9 78 4.5.4.2. Enabling CLUE mid-call . . . . . . . . . . . . . 10 79 4.5.4.3. Disabling CLUE mid-call . . . . . . . . . . . . . 10 80 5. Interaction of CLUE protocol and SDP negotiations . . . . . . 11 81 5.1. Independence of SDP and CLUE negotiation . . . . . . . . 11 82 5.2. Constraints on sending media . . . . . . . . . . . . . . 12 83 5.3. Recommendations for operating with non-atomic operations 12 84 6. Interaction of CLUE protocol and RTP/RTCP CaptureID . . . . . 13 85 6.1. CaptureID reception during MCC redefinition . . . . . . . 13 86 7. Multiplexing of CLUE-controlled media using BUNDLE . . . . . 14 87 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 88 7.2. Usage of BUNDLE with CLUE . . . . . . . . . . . . . . . . 14 89 7.2.1. Generating the Initial Offer . . . . . . . . . . . . 15 90 7.2.2. Multiplexing of the data channel and RTP media . . . 15 91 8. Example: A call between two CLUE-capable Endpoints . . . . . 15 92 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 24 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 11.1. New SDP Grouping Framework Attribute . . . . . . . . . . 25 96 11.2. New SIP Media Feature Tag . . . . . . . . . . . . . . . 26 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 99 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 27 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 34 102 14.2. Informative References . . . . . . . . . . . . . . . . . 35 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 105 1. Introduction 107 To enable devices to participate in a telepresence call, selecting 108 the sources they wish to view, receiving those media sources and 109 displaying them in an optimal fashion, CLUE employs two principal and 110 inter-related protocol negotiations. SDP, conveyed via SIP, is used 111 to negotiate the specific media capabilities that can be delivered to 112 specific addresses on a device. Meanwhile, CLUE protocol 113 [I-D.ietf-clue-protocol] messages, transported via a CLUE data 114 channel [I-D.ietf-clue-datachannel], are used to negotiate the 115 Capture Sources available, their attributes and any constraints in 116 their use. They also allow the far end device to specify which 117 Captures they wish to receive. 119 Beyond negotiating the CLUE channel, SDP is also used to negotiate 120 the details of supported media streams and the maximum capability of 121 each of those streams. As the CLUE Framework 122 [I-D.ietf-clue-framework] defines a manner in which the Media 123 Provider expresses their maximum encoding group capabilities, SDP is 124 also used to express the encoding limits for each potential Encoding. 126 Backwards-compatibility is an important consideration of the 127 protocol: it is vital that a CLUE-capable device contacting a device 128 that does not support CLUE is able to fall back to a fully functional 129 non-CLUE call. The document also defines how a non-CLUE call may be 130 upgraded to CLUE in mid-call, and similarly how CLUE functionality 131 can be removed mid-call to return to a standard non-CLUE call. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 This document uses terminology defined in the CLUE Framework 140 [I-D.ietf-clue-framework]. 142 A few additional terms specific to this document are defined as 143 follows: 145 non-CLUE device: A device that supports standard SIP and SDP, but 146 either does not support CLUE, or that does but does not currently 147 wish to invoke CLUE capabilities. 149 CLUE-controlled media: A media "m=" line that is under CLUE control; 150 the Capture Source that provides the media on this "m=" line is 151 negotiated in CLUE. See Section 4 for details of how this control 152 is signaled in SDP. There is a corresponding "non-CLUE- 153 controlled" media term. 155 3. Media Feature Tag Definition 157 The "sip.clue" media feature tag indicates support for CLUE. A CLUE- 158 capable device SHOULD include this media feature tag in its REGISTER 159 requests and OPTION responses. It SHOULD also include the media 160 feature tag in INVITE and UPDATE [RFC3311] requests and responses. 162 Presence of the media feature tag in the contact field of a request 163 or response can be used to determine that the far end supports CLUE. 165 4. SDP Grouping Framework CLUE Extension Semantics 167 4.1. General 169 This section defines a new SDP Grouping Framework [RFC5888] extension 170 called 'CLUE'. 172 The CLUE extension can be indicated using an SDP session-level 173 'group' attribute. Each SDP media "m=" line that is included in this 174 group, using SDP media-level mid attributes, is CLUE-controlled, by a 175 CLUE data channel also included in this CLUE group. 177 Currently only support for a single CLUE group is specified; support 178 for multiple CLUE groups in a single session is beyond the scope of 179 this document. A device MUST NOT include more than one CLUE group in 180 its SDP unless it is following a specification that defines how 181 multiple CLUE channels are signaled, and is either able to determine 182 that the other side of the SDP exchange supports multiple CLUE 183 channels, or is able to fail gracefully in the event it does not. 185 4.2. The CLUE data channel and the CLUE grouping semantic 187 The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional 188 data channel [I-D.ietf-rtcweb-data-channel] used for the transport of 189 CLUE messages, conveyed within an SCTP over DTLS connection. This 190 channel must be established before CLUE protocol messages can be 191 exchanged and CLUE-controlled media can be sent. 193 The data channel is negotiated over SDP as described in 194 [I-D.ietf-mmusic-data-channel-sdpneg]. A CLUE-capable device wishing 195 to negotiate CLUE MUST also include a CLUE group in the SDP and 196 include the "mid" of the "m=" line for the data channel in that 197 group. A CLUE group MUST include the "mid" of the "m=" line for one 198 (and only one) data channel. 200 Presence of the data channel in a CLUE group in an SDP offer or 201 answer also serves, along with the "sip.clue" media feature tag, as 202 an indication that the device supports CLUE and wishes to upgrade the 203 call to include CLUE-controlled media. A CLUE-capable device SHOULD 204 include a data channel "m=" line in offers and, when allowed by 205 [RFC3264], answers. 207 4.3. CLUE-controlled media and the CLUE grouping semantic 209 CLUE-controlled media lines in an SDP are "m=" lines in which the 210 content of the media streams to be sent is negotiated via the CLUE 211 protocol [I-D.ietf-clue-protocol]. For an "m=" line to be CLUE- 212 controlled, its "mid" value MUST be included in a CLUE group. CLUE- 213 controlled media is controlled by the CLUE protocol as negotiated on 214 the CLUE data channel with an "mid" included in the CLUE group. 216 "m=" lines not specified as under CLUE control follow normal rules 217 for media streams negotiated in SDP as defined in documents such as 218 [RFC3264]. 220 The restrictions on CLUE-controlled media always apply to "m=" lines 221 in an SDP offer or answer, even if negotiation of the data channel in 222 SDP failed due to lack of CLUE support by the remote device or for 223 any other reason, or in an offer if the recipient does not include 224 the "mid" of the corresponding "m=" line in their CLUE group. 226 4.4. SDP semantics for CLUE-controlled media 228 4.4.1. Signaling CLUE Encodings 230 The CLUE Framework [I-D.ietf-clue-framework] defines the concept of 231 "Encodings", which represent the sender's encode ability. Each 232 Encoding the Media Provider wishes to signal is signaled via an "m=" 233 line of the appropriate media type, which MUST be marked as sendonly 234 with the "a=sendonly" attribute or as inactive with the "a=inactive" 235 attribute. 237 The encoder limits of active (eg, "a=sendonly") Encodings can then be 238 expressed using existing SDP syntax. For instance, for H.264 see 239 Table 6 in [RFC6184] for a list of valid parameters for representing 240 encoder sender stream limits. 242 These Encodings are CLUE-controlled and hence MUST include an "mid" 243 in a CLUE group as defined above. 245 As well as the normal restrictions defined in [RFC3264] the stream 246 MUST be treated as if the "m=" line direction attribute had been set 247 to "a=inactive" until the Media Provider has received a valid CLUE 248 Configure message specifying the Capture to be used for this stream. 249 This means that RTP packets MUST NOT be sent until configuration is 250 complete, while non-media packets such as STUN, RTCP and DTLS MUST be 251 sent as per their relevant specifications if negotiated. 253 Every "m=" line representing a CLUE Encoding MUST contain a "label" 254 attribute as defined in [RFC4574]. This label is used to identify 255 the Encoding by the sender in CLUE Advertisement messages and by the 256 receiver in CLUE Configure messages. Each label used for a CLUE- 257 controlled "m=" line MUST be different from the label on all other 258 "m=" lines in the same CLUE group in the SDP message, unless an "m=" 259 line represents a dependent stream related to another "m=" line (such 260 as a FEC stream), in which case it MUST have the same label value as 261 the "m=" line on which it depends. 263 4.4.1.1. Referencing Encodings in the CLUE protocol 265 CLUE Encodings are defined in SDP, but can be referenced from CLUE 266 protocol messages - this is how the protocol defines which Encodings 267 are part of an Encoding group (in Advertisement messages) and which 268 Encoding with which to encode a specific Capture (in Configure 269 messages). The labels on the CLUE-controlled "m=" lines are the 270 references that are used in the CLUE protocol. 272 Each (in encodingIDList) in a CLUE Advertisement message 273 SHOULD represent an Encoding defined in SDP; the specific Encoding 274 referenced is a CLUE-controlled "m=" line in the most recent SDP sent 275 by the sender of the Advertisement message with a label value 276 corresponding to the text content of the . 278 Similarly, each (in captureEncodingType) in a CLUE 279 Configure message SHOULD represent an Encoding defined in SDP; the 280 specific Encoding referenced is a CLUE-controlled "m=" line in the 281 most recent SDP received by the sender of the Configure message with 282 a label value corresponding to the text content of the . 284 Note that the non-atomic nature of SDP/CLUE protocol interaction may 285 mean that there are temporary periods where an / 286 in a CLUE message does not reference an SDP "m=" line, or where an 287 Encoding represented in SDP is not referenced in a CLUE protocol 288 message. See Section 5 for specifics. 290 4.4.2. Negotiating receipt of CLUE Capture Encodings in SDP 292 A receiver who wishes to receive a CLUE stream via a specific 293 Encoding requires an "a=recvonly" "m=" line that matches the 294 "a=sendonly" Encoding. 296 These "m=" lines are CLUE-controlled and hence MUST include their 297 "mid" in the CLUE group corresponding to the CLUE group of the 298 Encoding they wish to receive. They MAY include a "label" attribute, 299 but this is not required by CLUE, as only label values associated 300 with "a=sendonly" Encodings are referenced by CLUE protocol messages. 302 4.5. SDP Offer/Answer Procedures 304 4.5.1. Generating the Initial Offer 306 A CLUE-capable device sending an initial SDP offer of a SIP session 307 SHOULD include an "m=" line for the data channel to convey the CLUE 308 protocol, along with a CLUE group containing the "mid" of the data 309 channel "m=" line. 311 For interoperability with non-CLUE devices a CLUE-capable device 312 sending an initial SDP offer SHOULD NOT include any "m=" line for 313 CLUE-controlled media beyond the "m=" line for the CLUE data channel, 314 and SHOULD include at least one non-CLUE-controlled media "m=" line. 316 If the device has evidence that the receiver is also CLUE-capable, 317 for instance due to receiving an initial INVITE with no SDP but 318 including a "sip.clue" media feature tag, the above recommendation is 319 waived, and the initial offer MAY contain "m=" lines for CLUE- 320 controlled media. 322 With the same interoperability recommendations as for Encodings, the 323 sender of the initial SDP offer MAY also include "a=recvonly" media 324 lines to preallocate "m=" lines to receive media. Alternatively, it 325 MAY wait until CLUE protocol negotiation has completed before 326 including these lines in a new offer/answer exchange - see Section 5 327 for recommendations. 329 4.5.2. Generating the Answer 331 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 333 If the recipient is CLUE-capable and the initial offer contains both 334 an "m=" line for a data channel and a CLUE group containing the "mid" 335 for that "m=" line, they SHOULD negotiate data channel support for an 336 "m=" line, and include the "mid" of that "m=" line in a corresponding 337 CLUE group. 339 A CLUE-capable recipient that receives an "m=" line for a data 340 channel but no corresponding CLUE group containing the "mid" of that 341 "m=" line MAY still include a corresponding data channel "m=" line if 342 there are any other non-CLUE protocols it can convey over that 343 channel, but MUST NOT negotiate use of the CLUE protocol on this 344 channel. 346 4.5.2.2. Negotiating CLUE-controlled media 348 If the initial offer contained "a=recvonly" CLUE-controlled media 349 lines the recipient SHOULD include corresponding "a=sendonly" CLUE- 350 controlled media lines for accepted Encodings, up to the maximum 351 number of Encodings it wishes to advertise. As CLUE-controlled 352 media, the "mid" of these "m=" lines must be included in the 353 corresponding CLUE group. 355 If the initial offer contained "a=sendonly" CLUE-controlled media 356 lines the recipient MAY include corresponding "a=recvonly" CLUE- 357 controlled media lines, up to the maximum number of Capture Encodings 358 it wishes to receive. Alternatively, it MAY wait until CLUE protocol 359 negotiation has completed before including these lines in a new 360 offer/answer exchange - see Section 5 for recommendations. 362 4.5.2.3. Negotiating non-CLUE controlled media 364 A CLUE-controlled device implementation may prefer to render initial, 365 single-stream audio and/or video for the user as rapidly as possible, 366 transitioning to CLUE-controlled media once that has been negotiated. 367 Alternatively, an implementation may wish to suppress initial media, 368 only providing media once the final, CLUE-controlled streams have 369 been negotiated. 371 The receiver of the initial offer, if making the call CLUE-enabled 372 with their SDP answer, can make their preference clear by their 373 action in accepting or rejecting non-CLUE-controlled media lines. 374 Rejecting these "m=" lines will ensure that no non-CLUE-controlled 375 media flows before the CLUE-controlled media is negotiated. In 376 contrast, accepting one or more non-CLUE-controlled "m=" lines in 377 this initial answer will enable initial media to flow. 379 If the answerer chooses to send initial non-CLUE-controlled media in 380 a CLUE-enabled call, Section 4.5.4.1 addresses the need to disable it 381 once CLUE-controlled media is fully negotiated. 383 4.5.3. Processing the initial Offer/Answer negotiation 385 In the event that both offer and answer include a data channel "m=" 386 line with a mid value included in corresponding CLUE groups, CLUE has 387 been successfully negotiated and the call is now CLUE-enabled. If 388 not then the call is not CLUE-enabled. 390 4.5.3.1. Successful CLUE negotiation 392 In the event of successful CLUE-enablement of the call, devices MUST 393 now begin negotiation of the CLUE channel, see 394 [I-D.ietf-clue-datachannel] for negotiation details. If negotiation 395 is successful, sending of CLUE protocol [I-D.ietf-clue-protocol] 396 messages can begin. 398 A CLUE-capable device MAY choose not to send media on the non-CLUE- 399 controlled channels during the period in which control of the CLUE- 400 controlled media lines is being negotiated. However, a CLUE-capable 401 device MUST still be prepared to receive media on non-CLUE-controlled 402 media lines that have been successfully negotiated as defined in 403 [RFC3264]. 405 If either side of the call wishes to add additional CLUE-controlled 406 "m=" lines to send or receive CLUE-controlled media they MAY now send 407 a SIP request with a new SDP offer following the normal rules of SDP 408 offer/answer and any negotiated extensions. 410 4.5.3.2. CLUE negotiation failure 412 In the event that the negotiation of CLUE fails and the call is not 413 CLUE-enabled once the initial offer/answer negotiation completes then 414 CLUE is not in use in the call. The CLUE-capable devices MUST either 415 revert to non-CLUE behaviour or terminate the call. 417 4.5.4. Modifying the session 419 4.5.4.1. Adding and removing CLUE-controlled media 421 Subsequent offer/answer exchanges MAY add additional "m=" lines for 422 CLUE-controlled media; in most cases at least one additional exchange 423 will be required before both sides have added all the Encodings and 424 ability to receive Encodings that they desire. Devices MAY delay 425 adding "a=recvonly" CLUE-controlled "m=" lines until after CLUE 426 protocol negotiation completes - see Section 5 for recommendations. 428 Subsequent offer/answer exchanges MAY also deactivate "m=" lines for 429 CLUE-controlled media. 431 Once CLUE media has been successfully negotiated devices SHOULD 432 ensure that non-CLUE-controlled media is deactivated in cases where 433 it corresponds to the media type of CLUE-controlled media that has 434 been successfully negotiated. This deactivation may require an 435 additional SDP exchange, or may be incorporated into one that is part 436 of the CLUE negotiation. 438 4.5.4.2. Enabling CLUE mid-call 440 A CLUE-capable device that receives an initial SDP offer from a non- 441 CLUE device SHOULD include a new data channel "m=" line and 442 corresponding CLUE group in any subsequent offers it sends, to 443 indicate that it is CLUE-capable. 445 If, in an ongoing non-CLUE call, an SDP offer/answer exchange 446 completes with both sides having included a data channel "m=" line in 447 their SDP and with the "mid" for that channel in corresponding CLUE 448 groups then the call is now CLUE-enabled; negotiation of the data 449 channel and subsequently the CLUE protocol begin. 451 4.5.4.3. Disabling CLUE mid-call 453 If, during an ongoing CLUE-enabled call a device wishes to disable 454 CLUE, it can do so by following the procedures for closing a data 455 channel defined in Section 5.2.4 of 456 [I-D.ietf-mmusic-data-channel-sdpneg]: sending a new SDP offer/answer 457 exchange and subsequent SCTP SSN reset for the CLUE channel. It MUST 458 also remove the 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 979 Alice receives Bob's message CLUE CONFIGURE 1 and sends CLUE RESPONSE 980 1 to ack its reception. She does not yet send the Capture Encodings 981 specified, because at this stage she hasn't processed Bob's answer 982 SDP and so hasn't negotiated the ability for Bob to receive these 983 streams. 985 On receiving SIP 200 OK 2 from Bob Alice sends her SIP ACK (SIP ACK 986 2). She is now able to send the two streams of video Bob requested - 987 this is illustrated as MEDIA 2. 989 The constraints of offer/answer meant that Bob could not include his 990 encoding information as new "m=" lines in SIP 200 OK 2. As such Bob 991 now sends SIP INVITE 3 to generate a new offer. Along with all the 992 streams from SIP 200 OK 2 Bob also includes two new sendonly streams. 993 Each stream has a label corresponding to the Encoding IDs in his CLUE 994 ADVERTISEMENT 2 message. He also adds their mid values to the 995 grouping attribute to show they are controlled by the CLUE channel. 996 A snippet of the SDP showing the grouping attribute and the video 997 "m=" lines are shown below (mid 100 represents the CLUE channel, not 998 shown): 1000 ... 1001 a=group:CLUE 11 12 13 14 100 1002 ... 1003 m=video 58722 RTP/AVP 96 1004 a=rtpmap:96 H264/90000 1005 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1006 a=sendrecv 1007 a=mid:10 1008 ... 1009 m=video 58724 RTP/AVP 96 1010 a=rtpmap:96 H264/90000 1011 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1012 a=recvonly 1013 a=mid:11 1014 m=video 58726 RTP/AVP 96 1015 a=rtpmap:96 H264/90000 1016 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1017 a=recvonly 1018 a=mid:12 1019 m=video 0 RTP/AVP 96 1020 m=video 58728 RTP/AVP 96 1021 a=rtpmap:96 H264/90000 1022 a=fmtp:96 profile-level-id=42e016 1023 a=sendonly 1024 a=label:foo 1025 a=mid:13 1026 m=video 58730 RTP/AVP 96 1027 a=rtpmap:96 H264/90000 1028 a=fmtp:96 profile-level-id=42e016 1029 a=sendonly 1030 a=label:bar 1031 a=mid:14 1033 Having received this Alice now has all the information she needs to 1034 send her CLUE Configure message and her SDP answer. In CLUE 1035 CONFIGURE 2 she requests the two static Captures from Bob, to be sent 1036 on Encodings "foo" and "bar". 1038 Alice also sends SIP 200 OK 3, matching two recvonly "m=" lines to 1039 Bob's new sendonly lines. She includes their mid values in the 1040 grouping attribute to show they are controlled by the CLUE channel. 1041 Alice also now deactivates the initial non-CLUE-controlled media, as 1042 bidirectional CLUE-controlled media is now available. A snippet of 1043 the SDP showing the grouping attribute and the video "m=" lines are 1044 shown below (mid 3 represents the data channel, not shown): 1046 ... 1047 a=group:CLUE 3 4 5 7 8 1048 ... 1049 m=video 0 RTP/AVP 96 1050 a=mid:2 1051 ... 1052 m=video 6004 RTP/AVP 96 1053 a=rtpmap:96 H264/90000 1054 a=fmtp:96 profile-level-id=42e016 1055 a=sendonly 1056 a=mid:4 1057 a=label:enc1 1058 m=video 6006 RTP/AVP 96 1059 a=rtpmap:96 H264/90000 1060 a=fmtp:96 profile-level-id=42e016 1061 a=sendonly 1062 a=mid:5 1063 a=label:enc2 1064 m=video 0 RTP/AVP 96 1065 m=video 6010 RTP/AVP 96 1066 a=rtpmap:96 H264/90000 1067 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1068 a=recvonly 1069 a=mid:7 1070 m=video 6012 RTP/AVP 96 1071 a=rtpmap:96 H264/90000 1072 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1073 a=recvonly 1074 a=mid:8 1076 Bob receives Alice's message CLUE CONFIGURE 2 and sends CLUE RESPONSE 1077 2 to ack its reception. Bob does not yet send the Capture Encodings 1078 specified, because he hasn't yet received and processed Alice's SDP 1079 answer and negotiated the ability to send these streams. 1081 Finally, on receiving SIP 200 OK 3 Bob is now able to send the two 1082 streams of video Alice requested - this is illustrated as MEDIA 3. 1084 Both sides of the call are now sending multiple video streams with 1085 their sources defined via CLUE negotiation. As the call progresses 1086 either side can send new Advertisement or Configure message or new 1087 SDP offer/answers to add, remove or change what they have available 1088 or want to receive. 1090 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 1092 In this brief example Alice is a CLUE-capable Endpoint making a call 1093 to Bob, who is not CLUE-capable (i.e. is not able to use the CLUE 1094 protocol). 1096 +----------+ +-----------+ 1097 | EP1 | | EP2 | 1098 | | | | 1099 +----+-----+ +-----+-----+ 1100 | | 1101 | | 1102 | SIP INVITE 1 | 1103 |--------------------------------->| 1104 | | 1105 | | 1106 | 200 0K 1 | 1107 |<---------------------------------| 1108 | | 1109 | | 1110 | ACK 1 | 1111 |--------------------------------->| 1112 | | 1113 | | 1114 | | 1115 |<########### MEDIA 1 ############>| 1116 | 1 video A->B, 1 video B->A | 1117 |<################################>| 1118 | | 1119 | | 1120 | | 1121 | | 1122 v v 1124 In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP 1125 body the basic audio and video capabilities and the data channel as 1126 per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" 1127 media feature tag in the INVITE. A snippet of the SDP showing the 1128 grouping attribute and the video "m=" line are shown below. Alice 1129 has included a "CLUE" group, and included the mid corresponding to a 1130 data channel in the group (3). Note that Alice has chosen not to 1131 include any CLUE-controlled media in the initial offer - the mid 1132 value of the video line is not included in the "CLUE" group. 1134 ... 1135 a=group:CLUE 3 1136 ... 1137 m=video 6002 RTP/AVP 96 1138 a=rtpmap:96 H264/90000 1139 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 1140 a=sendrecv 1141 a=mid:2 1142 ... 1143 m=application 6100 UDP/DTLS/SCTP webrtc-datachannel 1144 a=sctp-port: 5000 1145 a=dcmap:2 subprotocol="CLUE";ordered=true 1146 a=mid:3 1148 Bob is not CLUE-capable, and hence does not recognize the "CLUE" 1149 semantic for grouping attribute, nor does he support the data 1150 channel. IN SIP 200 OK 1 he responds with an answer with audio and 1151 video, but with the data channel zeroed. 1153 From the lack of the data channel and grouping framework Alice 1154 understands that Bob does not support CLUE, or does not wish to use 1155 it. Both sides are now able to send a single audio and video stream 1156 to each other. Alice at this point begins to send her fallback 1157 video: in this case likely a switched view from whichever camera 1158 shows the current loudest participant on her side. 1160 10. Acknowledgements 1162 The team focusing on this draft consists of: Roni Even, Rob Hansen, 1163 Christer Holmberg, Paul Kyzivat, Simon Pietro-Romano, Roberta Presta. 1165 Christian Groves and Jonathan Lennox have contributed detailed 1166 comments and suggestions. 1168 11. IANA Considerations 1170 11.1. New SDP Grouping Framework Attribute 1172 This document registers the following semantics with IANA in the 1173 "Semantics for the "group" SDP Attribute" subregistry (under the 1174 "Session Description Protocol (SDP) Parameters" registry per 1175 [RFC5888]: 1177 Semantics Token Reference 1178 ------------------------------------- ------ --------- 1179 CLUE-controlled m-line CLUE [this draft] 1181 11.2. New SIP Media Feature Tag 1183 This specification registers a new media feature tag in the SIP 1184 [RFC3264] tree per the procedures defined in [RFC2506] and [RFC3840]. 1186 Media feature tag name: sip.clue 1188 ASN.1 Identifier: 1.3.6.1.8.4.29 1190 Summary of the media feature indicated by this tag: This feature tag 1191 indicates that the device supports CLUE-controlled media. 1193 Values appropriate for use with this feature tag: Boolean. 1195 The feature tag is intended primarily for use in the following 1196 applications, protocols, services, or negotiation mechanisms: 1198 This feature tag is most useful in a communications application for 1199 describing the capabilities of a device to use the CLUE control 1200 protocol to negotiate the use of multiple media streams. 1202 Related standards or documents: [this draft] 1204 Security Considerations: Security considerations for this media 1205 feature tag are discussed in Section 12 of [this draft]. 1207 Name(s) & email address(es) of person(s) to contact for further 1208 information: 1210 o CLUE workgroup: clue@ietf.org 1212 o CLUE chairs: clue-chairs@ietf.org 1214 Intended usage: COMMON 1216 12. Security Considerations 1218 CLUE makes use of a number of protocols and mechanisms, either 1219 defined by CLUE or long-standing. The security considerations 1220 section of the CLUE Framework [I-D.ietf-clue-framework] addresses the 1221 need to secure these mechanisms by following the recommendations of 1222 the individual protocols. 1224 Beyond the need to secure the constituent protocols, the use of CLUE 1225 does impose additional security concerns. One area of increased risk 1226 involves the potential for a malicious party to subvert a CLUE- 1227 capable device to attack a third party by driving large volumes of 1228 media (particularly video) traffic at them by establishing a 1229 connection to the CLUE-capable device and directing the media to the 1230 victim. While this is a risk for all media devices, a CLUE-capable 1231 device may allow the attacker to configure multiple media streams to 1232 be sent, significantly increasing the volume of traffic directed at 1233 the victim. 1235 This attack can be prevented by ensuring that the media recipient 1236 intends to receive the media packets. As such all CLUE-capable 1237 devices MUST support key negotiation and receiver intent assurance 1238 via DTLS [RFC5763] on CLUE-controlled RTP "m=" lines. All CLUE- 1239 controlled RTP "m" lines must be secured and implemented using 1240 mechanisms such as SRTP [RFC3711]; no specific security mechanisms 1241 are made mandatory to use due to the issues addressed in [RFC7202]. 1242 Due to the requirements of backwards compatibility, this is not a 1243 mandatory requirement for non-CLUE-controlled "m=" lines. 1245 CLUE also defines a new media feature tag that indicates CLUE 1246 support. This tag may be present even in non-CLUE calls, which 1247 increases the metadata available about the sending device, which can 1248 help an attacker differentiate between multiple devices and help them 1249 identify otherwise anonymised users via the fingerprint of features 1250 their device supports. To prevent this, SIP signaling SHOULD always 1251 be encrypted using TLS [RFC5630]. 1253 13. Change History 1255 -09: Revision by Rob Hansen 1257 * A few minor spelling tweaks 1259 * Made removing the CLUE group mandatory when disabling CLUE mid- 1260 call. Made clear that any CLUE-controlled m-lines should be 1261 disabled or else how they're used is up to the implementation. 1263 -08: Revision by Rob Hansen 1265 * Spelling and grammar fixes from Paul and Christian gratefully 1266 adopted 1268 * Expanded the section on disabling CLUE mid-call to make 1269 explicit the actions required to disable the CLUE channel 1270 gracefully, or to handle someone else doing the same. 1272 * Made a number of fixes to the example call flow to better 1273 reflect the recommendations in the document. 1275 -07: Revision by Rob Hansen 1277 * Removed the entire 'Media line directionality' section as a 1278 discussion of the pros/cons of using bidirectional vs 1279 unidirectional schemes wasn't suitable for a finalised version. 1280 The unidirectionality requirement is covered normatively in an 1281 earlier section. 1283 * BUNDLE no longer includes an address synchronisation step so 1284 the suggestion to wait until that done has been replaced with 1285 some general language about following any negotiated 1286 extensions. 1288 * Added OPTIONS negotiation to the example flow, and revised the 1289 flow to ensure it matched protocol document. 1291 * Section on not sending CLUE control media until CLUE 1292 negotiation completes narrowed to notify that only RTP should 1293 not be sent until negotiation completes and add RTCP to the 1294 list of things that should be sent as normal, in line with 1295 a=inactive. 1297 * Make explicit that m=recvonly lines don't need to have a label, 1298 as only m=sendonly lines are referenced by CLUE protocol 1299 messages. 1301 * Fix formatting of IANA sections. Improve syntax of feature tag 1302 section in line with Paul's suggestions. Definition of feature 1303 tag narrowed to be multiple media lines *negotiated via CLUE 1304 protocol* rather than more generic 'multiple media lines'. 1306 * General corrections to grammar, spelling and readability based 1307 on Christian, Paul and Mark; in many cases suggested text was 1308 gratefully accepted. 1310 -06: Revision by Rob Hansen 1312 * State machine interactions updated to match versions in -04 of 1313 protocol doc. 1315 * Section on encoding updated to specify both encID and 1316 encodingID from data model doc. 1318 * Removed the limitations on describing H264 encoding limits 1319 using SDP syntax as an open issue. 1321 * Previous draft had SRTP and DTLS mandatory to implement and to 1322 use on CLUE- controlled m lines. Current version has DTLS 1323 mandatory to implement, and 'security' mandatory to use but 1324 does not define what that security is. 1326 * Terminology reference to framework doc reinforced. All 1327 terminology that duplicates framework removed. All text 1328 updated with capitalisation that matches framework document's 1329 terminology. 1331 * SDP example syntax updated to match that of ietf-clue- 1332 datachannel and hence ietf-mmusic-data-channel-sdpneg. 1334 -05: Revision by Rob Hansen 1336 * SRTP/DTLS made mandatory for CLUE-controlled media lines. 1338 * IANA consideration section added (text as proposed by Christian 1339 Groves). 1341 * Includes provision for dependent streams on seperate "m" lines 1342 having the same encID as their parent "m" line. 1344 * References to putting CLUE-controlled media and data channels 1345 in more than one CLUE group removed, since the document no 1346 longer supports using more than one CLUE group. 1348 * Section on CLUE controlled media restrictions still applying 1349 even if the call does not end up being CLUE enabled being 1350 rewritten to hopefully be clearer. 1352 * Other minor syntax improvements. 1354 -04: Revision by Rob Hansen 1356 * Updated DTLS/SCTP channel syntax in examples to fix errors and 1357 match latest format defined in draft-ietf-mmusic-sctp-sdp-07. 1359 * Clarified the behaviour if an SDP offer includes a CLUE- 1360 controlled "m" line and the answer accepts that "m" line but 1361 without CLUE control of that line. 1363 * Added a new section on the sending and receiving of CaptureIDs 1364 in RTP and RTCP. Includes a section on the necessity of the 1365 receiver coping with unexpected CaptureIDs (or the lack 1366 thereof) due to MCCs being redefined in new Advertisement 1367 messages. 1369 * Added reminder on IANA section on registering grouping semantic 1370 and media feature tag, removed the less formal sections that 1371 did the same job. 1373 * Fixed and clarified issues raised by Christian's document 1374 review. 1376 * Added a number of security considerations. 1378 -03: Revision by Rob Hansen 1380 * Clarified text on not rejecting messages because they contain 1381 unknown encIDs. 1383 * Removed normative language in section on accepting/rejecting 1384 non-CLUE-controlled media in the initial answer. 1386 * Example SDP updated to include the data channel "m" lines. 1388 * Example call flow updated to show disablement of non-CLUE- 1389 controlled media once CLUE-controlled media is flowing. 1391 -02: Revision by Rob Hansen 1393 * Added section on not accepting non-CLUE-controlled "m" lines in 1394 the initial answer when CLUE is to be negotiated. 1396 * Removed previous language attempting to describe media 1397 restrictions for CLUE-controlled "m" lines that had not been 1398 configured, and replaced it with much more accurate 'treat as 1399 "a=inactive" was set'. 1401 * Made label element mandatory for CLUE-controlled media (was 1402 previously "SHOULD include", but there didn't seem a good 1403 reason for this - anyone wishing to include the "m" line but 1404 not immediately use it in CLUE can simply leave it out of the 1405 .) 1407 * Added a section on the specifics of relating encodings in SDP 1408 to elements in the CLUE protocol, including the fact 1409 that both Advertisement and Configure messages reference the 1410 *encoding* (eg, in the Configure case the sender of the 1411 Configure message includes the labels of the recipient's "m" 1412 lines as their contents). 1414 * Minor revisions to the section on complying with normative SDP/ 1415 CLUEstate machine language to clarify that these were not new 1416 normative language, merely that existing normative language 1417 still applies. 1419 * Removed appendices which previously contained information to be 1420 transferred to the protocol and data channel drafts. Removed 1421 other text that discussed alternatives to the current approach. 1423 * Cleaned up some 'todo' text. 1425 -01: Revision by Rob Hansen 1427 * Revised terminology - removed the term 'CLUE-enabled' device as 1428 insufficiently distinct from 'CLUE-capable' and instead added a 1429 term for 'CLUE-enabled' calls. 1431 * Removed text forbidding RTCP and instead added text that ICE/ 1432 DTLS negotiation for CLUE controlled media must be done as 1433 normal irrespective of CLUE negotiation. 1435 * Changed 'sip.telepresence' to 'sip.clue' and 'TELEPRESENCE' 1436 grouping semantic back to CLUE. 1438 * Made it mandatory to have exactly one mid corresponding to a 1439 data channel in a CLUE group 1441 * Forbade having multiple CLUE groups unless a specification for 1442 doing so is published. 1444 * Refactored SDP-related text; previously the encoding 1445 information had been in the "initial offer" section despite the 1446 fact that we recommend that the initial offer doesn't actually 1447 include any encodings. I moved the specifications of encodings 1448 and how they're received to an earlier, seperate section. 1450 * Added text on how the state machines in CLUE and SDP are 1451 allowed to affect one another, and further recommendations on 1452 how a device should handle the sending of CLUE and SDP changes. 1454 -00: Revision by Rob Hansen 1456 * Submitted as -00 working group document 1458 draft-kyzivat-08: Revisions by Rob Hansen 1460 * Added media feature tag for CLUE support ('sip.telepresence') 1462 * Changed grouping semantic from 'CLUE' to 'TELEPRESENCE' 1463 * Restructured document to be more centred on the grouping 1464 semantic and its use with O/A 1466 * Lots of additional text on usage of the grouping semantic 1468 * Stricter definition of CLUE-controlled m lines and how they 1469 work 1471 * Some additional text on defining what happens when CLUE 1472 supports is added or removed 1474 * Added details on when to not send RTCP for CLUE-controlled "m" 1475 lines. 1477 * Added a section on using BUNDLE with CLUE 1479 * Updated data channel references to point at new WG document 1480 rather than indivual draft 1482 draft-kyzivat-07: Revisions by Rob Hansen 1484 * Removed the text providing arguments for encoding limits being 1485 in SDP and encoding groups in the CLUE protocol in favor of the 1486 specifics of how to negotiate encodings in SDP 1488 * Added normative language on the setting up of a CLUE call, and 1489 added sections on mid-call changes to the CLUE status. 1491 * Added references to [I-D.ietf-clue-datachannel] where 1492 appropriate. 1494 * Added some terminology for various types of CLUE and non-CLUE 1495 states of operation. 1497 * Moved language related to topics that should be in 1498 [I-D.ietf-clue-datachannel] and [I-D.ietf-clue-protocol], but 1499 that has not yet been resolved in those documents, into an 1500 appendix. 1502 draft-kyzivat-06: Revisions by Rob Hansen 1504 * Removed CLUE message XML schema and details that are now in 1505 draft-presta-clue-protocol 1507 * Encoding limits in SDP section updated to note that this has 1508 been investigated and discussed and is the current working 1509 assumption of the WG, though consensus has not been fully 1510 achieved. 1512 * A section has also been added on the current mandation of 1513 unidirectional "m" lines. 1515 * Updated CLUE messaging in example call flow to match draft- 1516 presta-clue-protocol-03 1518 draft-kyzivat-05: Revisions by pkyzivat: 1520 * Specified versioning model and mechanism. 1522 * Added explicit response to all messages. 1524 * Rearranged text to work with the above changes. (Which 1525 rendered diff almost useless.) 1527 draft-kyzivat-04: Revisions by Rob Hansen: ??? 1529 draft-kyzivat-03: Revisions by pkyzivat: 1531 * Added a syntax section with an XML schema for CLUE messages. 1532 This is a strawhorse, and is very incomplete, but it 1533 establishes a template for doing this based on elements defined 1534 in the data model. (Thanks to Roberta for help with this!) 1536 * Did some rewording to fit the syntax section in and reference 1537 it. 1539 * Did some relatively minor restructuring of the document to make 1540 it flow better in a logical way. 1542 draft-kyzivat-02: A bunch of revisions by pkyzivat: 1544 * Moved roberta's call flows to a more appropriate place in the 1545 document. 1547 * New section on versioning. 1549 * New section on NAK. 1551 * A couple of possible alternatives for message acknowledgment. 1553 * Some discussion of when/how to signal changes in provider 1554 state. 1556 * Some discussion about the handling of transport errors. 1558 * Added a change history section. 1560 These were developed by Lennard Xiao, Christian Groves and Paul, 1561 so added Lennard and Christian as authors. 1563 draft-kyzivat-01: Updated by roberta to include some sample call 1564 flows. 1566 draft-kyzivat-00: Initial version by pkyzivat. Established general 1567 outline for the document, and specified a few things thought to 1568 represent wg consensus. 1570 14. References 1572 14.1. Normative References 1574 [I-D.ietf-clue-framework] 1575 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 1576 for Telepresence Multi-Streams", draft-ietf-clue- 1577 framework-25 (work in progress), January 2016. 1579 [I-D.ietf-clue-data-model-schema] 1580 Presta, R. and S. Romano, "An XML Schema for the CLUE data 1581 model", draft-ietf-clue-data-model-schema-13 (work in 1582 progress), March 2016. 1584 [I-D.ietf-clue-protocol] 1585 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 1586 clue-protocol-06 (work in progress), October 2015. 1588 [I-D.ietf-clue-datachannel] 1589 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 1590 clue-datachannel-12 (work in progress), March 2016. 1592 [I-D.ietf-clue-rtp-mapping] 1593 Even, R. and J. Lennox, "Mapping RTP streams to CLUE media 1594 captures", draft-ietf-clue-rtp-mapping-06 (work in 1595 progress), January 2016. 1597 [I-D.ietf-mmusic-sctp-sdp] 1598 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 1599 Control Transmission Protocol (SCTP)-Based Media Transport 1600 in the Session Description Protocol (SDP)", draft-ietf- 1601 mmusic-sctp-sdp-16 (work in progress), February 2016. 1603 [I-D.ietf-mmusic-data-channel-sdpneg] 1604 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1605 and J. Marcon, "SDP-based Data Channel Negotiation", 1606 draft-ietf-mmusic-data-channel-sdpneg-08 (work in 1607 progress), February 2016. 1609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1610 Requirement Levels", BCP 14, RFC 2119, 1611 DOI 10.17487/RFC2119, March 1997, 1612 . 1614 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1615 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1616 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1617 . 1619 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1620 Protocol (SDP) Label Attribute", RFC 4574, 1621 DOI 10.17487/RFC4574, August 2006, 1622 . 1624 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1625 for Establishing a Secure Real-time Transport Protocol 1626 (SRTP) Security Context Using Datagram Transport Layer 1627 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1628 2010, . 1630 14.2. Informative References 1632 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1633 Registration Procedure", BCP 31, RFC 2506, 1634 DOI 10.17487/RFC2506, March 1999, 1635 . 1637 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1638 A., Peterson, J., Sparks, R., Handley, M., and E. 1639 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1640 DOI 10.17487/RFC3261, June 2002, 1641 . 1643 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1644 with Session Description Protocol (SDP)", RFC 3264, 1645 DOI 10.17487/RFC3264, June 2002, 1646 . 1648 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1649 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1650 2002, . 1652 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1653 "Indicating User Agent Capabilities in the Session 1654 Initiation Protocol (SIP)", RFC 3840, 1655 DOI 10.17487/RFC3840, August 2004, 1656 . 1658 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1659 (ICE): A Protocol for Network Address Translator (NAT) 1660 Traversal for Offer/Answer Protocols", RFC 5245, 1661 DOI 10.17487/RFC5245, April 2010, 1662 . 1664 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1665 Initiation Protocol (SIP)", RFC 5630, 1666 DOI 10.17487/RFC5630, October 2009, 1667 . 1669 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1670 Protocol (SDP) Grouping Framework", RFC 5888, 1671 DOI 10.17487/RFC5888, June 2010, 1672 . 1674 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1675 Payload Format for H.264 Video", RFC 6184, 1676 DOI 10.17487/RFC6184, May 2011, 1677 . 1679 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 1680 Framework: Why RTP Does Not Mandate a Single Media 1681 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 1682 2014, . 1684 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1685 Holmberg, C., Alvestrand, H., and C. Jennings, 1686 "Negotiating Media Multiplexing Using the Session 1687 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1688 negotiation-27 (work in progress), February 2016. 1690 [I-D.ietf-rtcweb-data-channel] 1691 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1692 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1693 progress), January 2015. 1695 Authors' Addresses 1697 Paul Kyzivat 1699 Email: pkyzivat@alum.mit.edu 1701 Lennard Xiao 1702 Huawei 1704 Email: lennard.xiao@huawei.com 1705 Christian Groves 1706 Huawei 1708 Email: Christian.Groves@nteczone.com 1710 Robert Hansen 1711 Cisco Systems 1713 Email: rohanse2@cisco.com