idnits 2.17.1 draft-ietf-clue-signaling-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-clue-datachannel], [I-D.presta-clue-protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2014) is 3658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.presta-clue-data-model-schema' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'I-D.even-clue-sdp-clue-relation' is defined on line 1195, but no explicit reference was found in the text == Unused Reference: 'I-D.hansen-clue-sdp-interaction' is defined on line 1205, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-14 ** Downref: Normative reference to an Informational draft: draft-presta-clue-data-model-schema (ref. 'I-D.presta-clue-data-model-schema') == Outdated reference: A later version (-04) exists of draft-presta-clue-protocol-03 == Outdated reference: A later version (-18) exists of draft-ietf-clue-datachannel-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel') ** Downref: Normative reference to an Informational draft: draft-groves-clue-latent-config (ref. 'I-D.groves-clue-latent-config') == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-06 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-06 Summary: 4 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 L. Xiao 4 Intended status: Standards Track C. Groves 5 Expires: October 24, 2014 Huawei 6 R. Hansen 7 Cisco Systems 8 April 22, 2014 10 CLUE Signaling 11 draft-ietf-clue-signaling-00 13 Abstract 15 This document specifies how CLUE-specific signaling such as the CLUE 16 protocol [I-D.presta-clue-protocol] and the CLUE data channel 17 [I-D.ietf-clue-datachannel] are used with each other and with 18 existing signaling mechanisms such as SIP and SDP to produce a 19 telepresence call. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 24, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Media Feature Tag Definition . . . . . . . . . . . . . . . . . 5 58 4. SDP Grouping Framework TELEPRESENCE Extension Semantics . . . 5 59 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. The CLUE data channel and the TELEPRESENCE grouping 61 semantic . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. CLUE-controlled media and the TELEPRESENCE grouping 63 semantic . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 6 65 4.4.1. Generating the Initial Offer . . . . . . . . . . . . . 6 66 4.4.1.1. Signalling CLUE Encodings . . . . . . . . . . . . 6 67 4.4.1.2. Receiving CLUE-controlled media . . . . . . . . . 8 68 4.4.1.3. Interoperability with non-CLUE devices . . . . . . 8 69 4.4.2. Generating the Answer . . . . . . . . . . . . . . . . 8 70 4.4.2.1. Negotiating use of CLUE and the CLUE data 71 channel . . . . . . . . . . . . . . . . . . . . . 8 72 4.4.2.2. Negotiating receipt of CLUE capture encodings 73 in SDP . . . . . . . . . . . . . . . . . . . . . . 8 74 4.4.3. Processing the initial Offer/Answer negotiation . . . 9 75 4.4.3.1. Successful CLUE negotiation . . . . . . . . . . . 9 76 4.4.3.2. CLUE negotiation failure . . . . . . . . . . . . . 9 77 4.4.4. Modifying the session . . . . . . . . . . . . . . . . 9 78 4.4.4.1. Enabling CLUE mid-call . . . . . . . . . . . . . . 9 79 4.4.4.2. Disabling CLUE mid-call . . . . . . . . . . . . . 10 80 5. Interaction of CLUE protocol and SDP negotiations . . . . . . 10 81 5.1. Independence of SDP and CLUE negotiation . . . . . . . . . 10 82 5.2. Recommendations for operating with non-atomic 83 operations . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.3. Constraints on sending media . . . . . . . . . . . . . . . 11 85 6. Multiplexing of CLUE-controlled media using BUNDLE . . . . . . 12 86 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 6.2. Usage of BUNDLE with CLUE . . . . . . . . . . . . . . . . 12 88 6.2.1. Generating the Initial Offer . . . . . . . . . . . . . 12 89 6.2.2. Bundle Address Synchronization . . . . . . . . . . . . 12 90 6.2.3. Multiplexing of the data channel and RTP media . . . . 13 91 7. Example: A call between two CLUE-capable endpoints . . . . . . 13 92 8. Example: A call between a CLUE-capable and non-CLUE 93 endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 9. CLUE requirements on SDP O/A . . . . . . . . . . . . . . . . . 22 95 10. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 22 96 11. CLUE over RTCWEB . . . . . . . . . . . . . . . . . . . . . . . 22 97 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 13. What else? . . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 100 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 101 16. Security Considerations . . . . . . . . . . . . . . . . . . . 23 102 17. Change History . . . . . . . . . . . . . . . . . . . . . . . . 23 103 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 18.1. Normative References . . . . . . . . . . . . . . . . . . . 25 105 18.2. Informative References . . . . . . . . . . . . . . . . . . 26 106 Appendix A. CLUE Signalling and data channel concerns . . . . . . 27 107 A.1. Protocol Versioning and Options . . . . . . . . . . . . . 27 108 A.1.1. Versioning Objectives . . . . . . . . . . . . . . . . 27 109 A.1.2. Versioning Overview . . . . . . . . . . . . . . . . . 28 110 A.1.3. Version Negotiation . . . . . . . . . . . . . . . . . 30 111 A.1.4. Option Negotiation . . . . . . . . . . . . . . . . . . 31 112 A.1.5. Option Elements . . . . . . . . . . . . . . . . . . . 31 113 A.1.5.1. . . . . . . . . . . . . . . . . . 31 114 A.1.6. Version & option negotiation errors . . . . . . . . . 32 115 A.1.7. Definition and Use of Version Numbers . . . . . . . . 33 116 A.1.8. Version & Option Negotiation Examples . . . . . . . . 34 117 A.1.8.1. Successful Negotiation - Multi-version . . . . . . 34 118 A.1.8.2. Successful Negotiation - Consumer-Only Endpoint . 35 119 A.1.8.3. Successful Negotiation - Provider-Only Endpoint . 36 120 A.1.8.4. Version Incompatibility . . . . . . . . . . . . . 37 121 A.1.8.5. Option Incompatibility . . . . . . . . . . . . . . 38 122 A.1.8.6. Syntax Error . . . . . . . . . . . . . . . . . . . 39 123 A.2. Message Transport . . . . . . . . . . . . . . . . . . . . 39 124 A.2.1. CLUE Channel Lifetime . . . . . . . . . . . . . . . . 39 125 A.2.2. Channel Error Handling . . . . . . . . . . . . . . . . 40 126 A.3. Message Framing . . . . . . . . . . . . . . . . . . . . . 40 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 129 1. Introduction 131 To enable devices to participate in a telepresence call, selecting 132 the sources they wish to view, receiving those media sources and 133 displaying them in an optimal fashion, CLUE involves two principal 134 and inter-related protocol negotiations. SDP, conveyed via SIP, is 135 used to negotiate the specific media capabilities that can be 136 delivered to specific addresses on a device. Meanwhile, a CLUE 137 protocol [I-D.presta-clue-protocol], transported via a CLUE data 138 channel [I-D.ietf-clue-datachannel], is used to negotiate the capture 139 sources available, their attributes and any constraints in their use, 140 along which which captures the far end provides a device wishes to 141 receive. 143 Beyond negotiating the CLUE channel, SDP is also used to negotiate 144 the details of supported media streams and the maximum capability of 145 each of those streams. As the CLUE Framework 146 [I-D.ietf-clue-framework] defines a manner in which the media 147 provider expresses their maximum encoding capabilities, SDP is also 148 used to express the encoding limits for each potential encoding. 150 Backwards-compatibility is an important consideration of the 151 document: it is vital that a CLUE-capable device contacting a device 152 that does not support CLUE is able to fall back to a fully functional 153 non-CLUE call. The document also defines how a non-CLUE call may be 154 upgraded to CLUE in mid-call, and similarly how CLUE functionality 155 can be removed mid-call to return to a standard non-CLUE call. 157 This document originally also defined the CLUE protocol itself. 158 These details have mostly been split out into 159 [I-D.presta-clue-protocol] and expanded, but at present some details 160 remain in this document. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 This document draws liberally from the terminology defined in the 169 CLUE Framework [I-D.ietf-clue-framework]. 171 Other terms introduced here: 173 CLUE data channel: A reliable, bidirectional, transport mechanism 174 used to convey CLUE messages. See [I-D.ietf-clue-datachannel] for 175 more details.. 176 CLUE-capable device: A device that supports the CLUE data channel 177 [I-D.ietf-clue-datachannel], the CLUE protocol 178 [I-D.presta-clue-protocol] and the principles of CLUE negotiation. 179 CLUE-enabled device: A CLUE-capable device that wishes to negotiate 180 a CLUE data channel and send and/or receive CLUe-controlled media. 181 Non-CLUE device: A device that supports standard SIP and SDP, but 182 either does not support CLUE, or that does but does not currently 183 wish to invoke CLUE capabilities. 184 CLUE-controlled media: A media "m" line that is under CLUE control; 185 the capture source that provides the media on this "m" line is 186 negotiated in CLUE. There is a corresponding "non-CLUE- 187 controlled" media term. See Section 4 for details of how this 188 control is signalled in SDP 190 3. Media Feature Tag Definition 192 The "sip.telepresence" media feature tag indicates support for CLUE. 193 A CLUE-capable device SHOULD include this media feature tag in its 194 REGISTER requests and OPTION responses. It SHOULD also include the 195 media feature tag in INVITE and UPDATE [RFC3311] requests and 196 responses. 198 Presence of the media feature tag in the contact field of a request 199 or response can be used to determine that the far end supports CLUE. 201 4. SDP Grouping Framework TELEPRESENCE Extension Semantics 203 4.1. General 205 This section defines a new SDP Grouping Framework extension, 206 TELEPRESENCE. 208 The TELEPRESENCE extension can be indicated using an SDP session- 209 level 'group' attribute. Each SDP media "m" line that is included in 210 this group, using SDP media-level mid attributes, is CLUE-controlled, 211 by a CLUE data channel also included in this TELEPRESENCE group. 213 4.2. The CLUE data channel and the TELEPRESENCE grouping semantic 215 The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional 216 SCTP over DTLS channel used for the transport of CLUE messages. This 217 channel must be established before CLUE protocol messages can be 218 exchanged and CLUE-controlled media can be sent. 220 The data channel is a generic transport that is not specific to CLUE 221 - if a device wishes to use the CLUE protocol on the data channel it 222 MUST include a TELEPRESENCE group in the SDP and include the "mid" of 223 the "m" line for the data channel in that group. A TELEPRESENCE grup 224 MUST NOT include the "mid"s for more than one data channel, and the 225 data channel "mid" MUST NOT be included in more than one TELEPRESENCE 226 group. 228 Presence of the data channel in a CLUE group in an SDP offer or 229 answer also serves, along with the 'sip.telepresence' media feature 230 tag, as an indication that the device supports CLUE and wishes to 231 upgrade the call to include CLUE-controlled media. A CLUE-enabled 232 device SHOULD include a data channel "m" line in offers and, when 233 allowed by [RFC3264], answers. 235 4.3. CLUE-controlled media and the TELEPRESENCE grouping semantic 237 CLUE-controlled media lines in an SDP are "m" lines in which the 238 content of the media streams to be sent is negotiated via the CLUE 239 protocol [I-D.presta-clue-protocol]. For an "m" line to be CLUE- 240 controlled, its "mid" value MUST be included in a TELEPRESENCE group. 241 CLUE-controlled media line "mid"s MUST NOT be included in more than 242 one TELEPRESENCE group. 244 CLUE-controlled media is controlled by the CLUE protocol as 245 negotiated on the CLUE data channel with an "mid" included in the 246 TELEPRESENCE group. If no data channel is included in the group the 247 other "m" lines in the group are still considered CLUE-controlled and 248 under all the restrictions of CLUE-controlled media specified in this 249 document. 251 "m" lines not specified as under CLUE control follow normal rules for 252 media streams negotiated in SDP as defined in documents such as 253 [RFC3264]. 255 4.4. SDP Offer/Answer Procedures 257 4.4.1. Generating the Initial Offer 259 4.4.1.1. Signalling CLUE Encodings 261 The CLUE Framework [I-D.ietf-clue-framework] defines the concept of 262 "encodings", which represent the sender's encode ability. Each 263 encoding the media provider wishes to signal is signalled via an "m" 264 line of the appropriate media type, which MUST be marked as sendonly 265 with the "a=sendonly" attribute or as inactive with the "a=inactive" 266 attribute. 268 The encoder limits of active (eg, "a=sendonly") encodings can then be 269 expressed using existing SDP syntax. For instance, for H.264 see 270 Table 6 in [RFC6184] for a list of valid parameters for representing 271 encoder sender stream limits. 273 These encodings are CLUE-controlled and hence MUST include an "mid" 274 in a TELEPRESENCE group as defined above. 276 As well as the normal restrictions defined in [RFC3264] media MUST 277 NOT be sent on this stream until the media provider has received a 278 valid CLUE CONFIGURE message specifying the capture to be used for 279 this stream. In the case of RTP media this includes corresponding 280 RTCP packets. 282 Every "m" line representing a CLUE encoding SHOULD contain a "label" 283 attribute as defined in [RFC4574]. This label is used to identify 284 the encoding by the sender in CLUE ADVERTISEMENT messages and by the 285 receiver in CLUE CONFIGURE messages. 287 4.4.1.1.1. Media line directionality 289 Presently, this specification mandates that CLUE-controlled "m"-lines 290 must be unidirectional. This is because setting "m"-lines to 291 "a=sendonly" allows the encoder limits to be expressed, whereas in 292 other cases codec attributes express the receive capabilities of a 293 media line. 295 It is possible that in future versions of this draft or its successor 296 this restriction will be relaxed. If a device does not feel there is 297 a benefit to expressing encode limitations, or if there are no 298 meaningful codec-specific limitations to express (such as with many 299 audio codecs) there are benefits to allowing bidirectional "m"-lines. 300 With bidirectional media lines recipients do not always need to 301 create a new offer to add their own "m"-lines to express their send 302 capabilities; if they can produce an equal or lesser number of 303 streams to send then they may not need additional "m"-lines. 305 However, at present the need to express encode limitations and the 306 wish to simplify the offer/answer procedure means that for the time 307 being only unidirectional media lines are allowed for CLUE-controlled 308 media. The highly asymmetric nature of CLUE means that the 309 probability of the recipient of the initial offer needing to make 310 their own offer to add additional "m"-lines is significantly higher 311 than it is for most other SIP call scenarios, in which there is a 312 tendancy for both sides to have similar numbers of potential audio 313 and video streams they can send. 315 4.4.1.1.2. Alternate encoding limit syntaxes 317 Note that while the expressing of CLUE encoding limits in SDP has 318 been discussed at some length by the working group and it has been 319 agreed that this is the current, working assumption, formal consensus 320 has not been agreed on this. Alternatives include placing encoding 321 limits in the CLUE ADVERTISEMENT message, or by using alternate SDP 322 syntax, such as is suggested in [I-D.groves-clue-latent-config]. 324 4.4.1.2. Receiving CLUE-controlled media 326 As well as including sendonly media lines to send CLUE-controlled 327 media, the sender of the initial SDP offer MAY also include 328 "a=recvonly" media lines to preallocate "m" lines to receive media; 329 these are described in more detail in the next section. 331 4.4.1.3. Interoperability with non-CLUE devices 333 A CLUE-enabled device sending an initial SDP offer SHOULD NOT include 334 any "m" line for CLUE-controlled media beyond the "m" line for the 335 CLUE data channel, and SHOULD include at least one non-CLUE- 336 controlled media "m" line. 338 If the device has evidence that the receiver is also CLUE-enabled, 339 for instance due to receiving an initial INVITE with no SDP but 340 including a 'sip.telepresence' media feature tag, the above 341 recommendation is waived, and the initial offer MAY contain "m" lines 342 for CLUE-controlled media. 344 4.4.2. Generating the Answer 346 4.4.2.1. Negotiating use of CLUE and the CLUE data channel 348 If the recipient wishes to enable CLUE for the call, they MUST 349 negotiate data channel support for an "m" line, and include the "mid" 350 of that "m" line in a corresponding TELEPRESENCE group. 352 4.4.2.2. Negotiating receipt of CLUE capture encodings in SDP 354 A receiver who wishes to receive a CLUE stream via a specific 355 encoding requires an "a=recvonly" "m" line that matches the 356 "a=sendonly" encoding. 358 These "m" lines are CLUE-controlled and hence MUST include an "mid" 359 the corresponding TELEPRESENCE group corresponding to the encoding 360 they wish to send. 362 In the case of RTCP for RTP media or any other media type that 363 includes a bidirectional flow of packets for unidirectional media 364 streams, such bidirectional packets MUST NOT be sent until the media 365 consumer has received acknowledgement that the media provider has 366 received a valid CLUE CONFIGURE message specifying the capture to be 367 used for this stream. 369 4.4.3. Processing the initial Offer/Answer negotiation 371 In the event that both offer and answer include a data channel "m" 372 line with a mid value included in corresponding TELEPRESENCE groups 373 CLUE has been successfully negotiated and the call is now CLUE- 374 enabled, otherwise the call is not CLUE enabled. 376 4.4.3.1. Successful CLUE negotiation 378 In the event of successful CLUE enablement of the call, devices MUST 379 now begin negotiation of the CLUE channel, see 380 [I-D.ietf-clue-datachannel] for negotiation details. If negotiation 381 is successful, sending of CLUE protocol [I-D.presta-clue-protocol] 382 messages can begin. 384 A CLUE-enabled device MAY choose not to send media on the non-CLUE- 385 controlled channels during the period in which control of the CLUE- 386 controlled media lines is being negotiated. However, a CLUE-enabled 387 device MUST still be prepared to receive media on non-CLUE-controlled 388 media lines as defined in [RFC3264]. 390 If either side of the call wishes to add additional CLUE-controlled 391 "m" lines to send or receive CLUE-controlled media they MAY now send 392 a SIP request with a new SDP offer. Note that if BUNDLE has been 393 successfully negotiated and a Bundle Address Synchronization offer is 394 required, the device to receive that offer SHOULD NOT generate a new 395 SDP offer until it has received that BAS offer. 397 4.4.3.2. CLUE negotiation failure 399 In the event that the negotiation of CLUE fails and the call is not 400 CLUE enabled in the initial offer/answer then CLUE is not in use in 401 the call, and the CLUE-capable devices MUST either revert to non-CLUE 402 behaviour or terminate the call. 404 4.4.4. Modifying the session 406 4.4.4.1. Enabling CLUE mid-call 408 A CLUE-enabled device that receives an initial SDP offer from a non- 409 CLUE-enabled device SHOULD include a new data channel "m" line and 410 corresponding TELEPRESENCE group in any subsequent offers it sends, 411 to indicate that it is CLUE-enabled. 413 If, in an ongoing non-CLUE call, one or both sides of the call add 414 the CLUE data channel "m" line to their SDP and places the "mid" for 415 that channel in corresponding TELEPRESENCE groups then the call is 416 now CLUE-enabled; negotiation of the data channel and subsequently 417 the CLUE protocol begin. 419 4.4.4.2. Disabling CLUE mid-call 421 If, in an ongoing CLUE-enabled call, an SDP offer-answer negotiation 422 completes in a fashion in which either the CLUE data channel was not 423 successfully negotiated or one side did not include the data channel 424 in a matching TELEPRESENCE group then CLUE for this channel is 425 disabled. In the event that this occurs, CLUE is no longer enabled 426 and sending of all CLUE-controlled media associated with the 427 corresponding TELEPRESENCE group MUST stop. 429 Note that this is distinct to cases where the CLUE data channel fails 430 or an error occurs on the CLUE protocol; see 431 [I-D.presta-clue-protocol] for details of media and state 432 preservation in this circumstance. 434 5. Interaction of CLUE protocol and SDP negotiations 436 Information about media streams in CLUE is split between two message 437 types: SDP, which defines media addresses and limits, and the CLUE 438 channel, which defines properties of capture devices available, scene 439 information and additional constraints. As a result certain 440 operations, such as advertising support for a new transmissible 441 capture with associated stream, cannot be performed atomically, as 442 they require changes to both SDP and CLUE messaging. 444 This section defines how the negotiation of the two protocols 445 interact, provides some recommendations on dealing with intermediary 446 stages in non-atomic operations, and mandates additional constraints 447 on when CLUE-configured media can be sent. 449 5.1. Independence of SDP and CLUE negotiation 451 To avoid complicated state machines with the potential to reach 452 invalid states if messages were to be lost, or be rewritten en-route 453 by middle boxes, the current proposal is that SDP and CLUE messages 454 are independent. The state of the CLUE channel does not restrict 455 when an implementation may send a new SDP offer or answer, and 456 likewise the implementation's ability to send a new CLUE 457 ADVERTISEMENT or CONFIGURE message is not restricted by the results 458 of or the state of the most recent SDP negotiation. 460 The primary implication of this is that a device may receive an SDP 461 with a CLUE encoding it does not yet have capture information for, or 462 receive a CLUE CONFIGURE message specifying a capture encoding for 463 which the far end has not negotiated a media stream in SDP. 465 CLUE messages contain an EncodingID which is used to identify a 466 specific encoding in SDP. The non-atomic nature of CLUE negotiation 467 means that a sender may wish to send a new ADVERTISEMENT before the 468 corresponding SDP message. As such the sender of the CLUE message 469 MAY include an EncodingID which does not currently match an extant id 470 in SDP. 472 5.2. Recommendations for operating with non-atomic operations 474 Generally, implementations that receive messages for which they have 475 incomplete information SHOULD wait until they have the corresponding 476 information they lack before sending messages to make changes related 477 to that information. For instance, an implementation that receives a 478 new SDP offer with three new "a=sendonly" CLUE "m" lines that has not 479 received the corresponding CLUE ADVERTISEMENT providing the capture 480 information for those streams SHOULD NOT include corresponding 481 "a=recvonly" lines in its answer, but instead should make a new SDP 482 offer when and if a new ADVERTISEMENT arrives with captures relevant 483 to those encodings. 485 Because of the constraints of offer/answer and because new SDP 486 negotiations are generally more 'costly' than sending a new CLUE 487 message, implementations needing to make changes to both channels 488 SHOULD prioritize sending the updated CLUE message over sending the 489 new SDP message. The aim is for the recipient to receive the CLUE 490 changes before the SDP changes, allowing the recipient to send their 491 SDP answers without incomplete information, reducing the number of 492 new SDP offers required. 494 5.3. Constraints on sending media 496 While SDP and CLUE message states do not impose constraints on each 497 other, both impose constraints on the sending of media - media MUST 498 NOT be sent unless it has been negotiated in both CLUE and SDP: an 499 implementation MUST NOT send a specific CLUE capture encoding unless 500 its most recent SDP exchange contains an active media channel for 501 that encoding AND the far end has sent a CLUE CONFIGURE message 502 specifying a valid capture for that encoding. 504 6. Multiplexing of CLUE-controlled media using BUNDLE 506 6.1. Overview 508 A CLUE call may involve sending and/or receiving significant numbers 509 of media streams. Conventionally, media streams are sent and 510 received on unique ports. However, each seperate port used for this 511 purpose may impose costs that a device wishes to avoid, such as the 512 need to open that port on firewalls and NATs, the need to collect ICE 513 candidates [RFC5245], etc. 515 The BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] extension can be 516 used to negotiate the multiplexing of multiple media lines onto a 517 single 5-tuple for sending and receiving media, allowing devices in 518 calls to another BUNDLE-supporting device to potentially avoid some 519 of the above costs. 521 While CLUE-capable devices MAY support the BUNDLE extension for this 522 purpose supporting the extension is not mandatory for a device to be 523 CLUE-compliant. 525 6.2. Usage of BUNDLE with CLUE 527 This specification imposes no additional requirements or restrictions 528 on the usage of BUNDLE when used with CLUE. There is no restriction 529 on combining CLUE-controlled media lines and non-CLUE-controlled 530 media lines in the same BUNDLE group or in multiple such groups. 531 However, there are several steps an implementation may wish to 532 ameliorate the cost and time requirements of extra SDP offer/answer 533 exchanges between CLUE and BUNDLE. 535 6.2.1. Generating the Initial Offer 537 BUNDLE mandates that the initial SDP offer MUST use a unique address 538 for each m-line with a non-zero port. Because CLUE implementations 539 generarlly will not include CLUE-controlled media lines with the 540 exception of the data channel CLUE devices that support large numbers 541 of streams can avoid ever having to open large numbers of ports if 542 they successfully negotiate BUNDLE. 544 6.2.2. Bundle Address Synchronization 546 When using BUNDLE the initial offerer may be mandated to send a 547 Bundle Address Synchronisation offer. If the initial offerer also 548 followed the recommendation of not including CLUE-controlled media 549 lines in their offer, they MAY choose to include them in this 550 subsequent offer. In this circumstance the BUNDLE specification 551 recommends that the offerer does not "modify SDP parameters that 552 could get the answerer to reject the BAS offer". Including new CLUE- 553 controlled media lines using codecs and other attributes used in 554 existing media lines should not increase the chance of the answerer 555 rejecting the BAS offer; implementations should consider carefully 556 before including new codecs or other new SDP attributes in these 557 CLUE-controlled media lines. 559 6.2.3. Multiplexing of the data channel and RTP media 561 BUNDLE-supporting CLUE-enabled devices MAY include the data channel 562 in the same BUNDLE group as RTP media. In this case the device MUST 563 be able to demultiplex the various transports - see section 7.2 of 564 the BUNDLE draft [I-D.ietf-mmusic-sdp-bundle-negotiation]. If the 565 BUNDLE group includes other protocols than the data channel 566 transported via DTLS the device MUST also be able to differentiate 567 the various protocols. 569 7. Example: A call between two CLUE-capable endpoints 571 This example illustrates a call between two CLUE-capable endpoints. 572 Alice, initiating the call, is a system with three cameras and three 573 screens. Bob, receiving the call, is a system with two cameras and 574 two screens. A call-flow diagram is presented, followed by an 575 summary of each message. 577 To manage the size of this section only video is considered, and SDP 578 snippets only illustrate video 'm' lines. ACKs are not discussed. 579 Note that BUNDLE is not in use. 581 +----------+ +-----------+ 582 | Alice | | Bob | 583 | | | | 584 +----+-----+ +-----+-----+ 585 | | 586 | | 587 | SIP INVITE 1 (BASIC SDP+COMEDIA) | 588 |--------------------------------->| 589 | | 590 | | 591 | SIP 200 OK 1 (BASIC SDP+COMEDIA) | 592 |<---------------------------------| 593 | | 594 | | 595 | SIP ACK 1 | 596 |--------------------------------->| 597 | | 598 | | 599 | | 600 |<########### MEDIA 1 ############>| 601 | 1 video A->B, 1 video B->A | 602 |<################################>| 603 | | 604 | | 605 | | 606 |<================================>| 607 | CLUE CTRL CHANNEL ESTABLISHED | 608 |<================================>| 609 | | 610 | | 611 | CLUE ADVERTISEMENT 1 | 612 |*********************************>| 613 | | 614 | | 615 | CLUE ADVERTISEMENT 2 | 616 |<*********************************| 617 | | 618 | | 619 | SIP INVITE 2 (+3 sendonly) | 620 |--------------------------------->| 621 | | 622 | | 623 | CLUE CONFIGURE 1 | 624 |<*********************************| 625 | | 626 | | 627 | CLUE RESPONSE 1 | 628 |*********************************>| 629 | | 630 | | 631 | SIP 200 OK 2 (+2 recvonly) | 632 |<---------------------------------| 633 | | 634 | | 635 | SIP ACK 2 | 636 |--------------------------------->| 637 | | 638 | | 639 | | 640 |<########### MEDIA 2 ############>| 641 | 2 video A->B, 1 video B->A | 642 |<################################>| 643 | | 644 | | 645 | SIP INVITE 3 (+2 sendonly) | 646 |<---------------------------------| 647 | | 648 | | 649 | CLUE CONFIGURE 2 | 650 |*********************************>| 651 | | 652 | | 653 | CLUE RESPONSE 2 | 654 |<*********************************| 655 | | 656 | | 657 | SIP 200 OK 3 (+2 recvonly) | 658 |--------------------------------->| 659 | | 660 | | 661 | | 662 | SIP ACK 3 | 663 |<---------------------------------| 664 | | 665 | | 666 | | 667 |<########### MEDIA 3 ############>| 668 | 2 video A->B, 2 video B->A | 669 |<################################>| 670 | | 671 | | 672 | | 673 v v 675 In INVITE 1, Alice sends Bob a SIP INVITE including in the SDP body 676 the basilar audio and video capabilities ("BASIC SDP") and the 677 information needed for opening a control channel to be used for CLUE 678 protocol messages exchange, according to what is envisioned in the 679 COMEDIA approach ("COMEDIA") for DTLS/SCTP channel 680 [I-D.ietf-mmusic-sctp-sdp]. A snippet of the SDP showing the 681 grouping attribute and the video m-line are shown below (mid 3 682 represents the CLUE channel): 684 ... 685 a=group:CLUE 3 686 ... 687 m=video 6002 RTP/AVP 96 688 a=rtpmap:96 H264/90000 689 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 690 a=sendrecv 691 a=mid:2 693 Bob responds with a similar SDP (200 OK 1); due to their similiarity 694 no SDP snippet is shown here. Alice and Bob are each able to send a 695 single audio and video stream (whether they choose to send this 696 initial media before CLUE has been negotiated is implementation- 697 dependent). This is illustrated as MEDIA 1. 699 With the successful initial O/A Alice and Bob are also free to 700 negotiate the CLUE channel. Once this is successfully established 701 CLUE negotiation can begin. This is illustrated as CLUE CHANNEL 702 ESTABLISHED. 704 Alice now sends her CLUE Advertisement (ADVERTISEMENT 1). She 705 advertises three static captures representing her three cameras. She 706 also includes switched captures suitable for two- and one-screen 707 systems. All of these captures are in a single capture scene, with 708 suitable capture scene entries to tell Bob that he should either 709 subscribe to the three static captures, the two switched capture view 710 or the one switched capture view. Alice has no simultaneity 711 constraints, so includes all six captures in one simultaneous set. 712 Finally, Alice includes an encoding group with three encoding IDs: 713 "enc1", "enc2" and "enc3". These encoding ids aren't currently 714 valid, but will match the next SDP offer she sends. 716 Bob received ADVERTISEMENT 1 but does not yet send a Configure 717 message, because he has not yet received Alice's encoding 718 information, so as yet he does not know if she will have sufficient 719 resources to send him the two streams he ideally wants at a quality 720 he is happy with. 722 Bob also sends his CLUE ADVERTISEMENT (ADVERTISEMENT 2). He 723 advertises two static captures representing his cameras. He also 724 includes a single composed capture for single-screen systems, in 725 which he will composite the two camera views into a single video 726 stream. All three captures are in a single capture scene, with 727 suitable capture scene entries to tell Alice that she should either 728 subscribe to the two static captures, or the single composed capture. 729 Bob also has no simultaneity constraints, so includes all three 730 captures in one simultaneous set. Bob also includes a single 731 encoding group with two encoding IDs: "foo" and "bar". 733 Similarly, Alices receives ADVERTISEMENT 2 but does not yet send a 734 CONFIGURE message, because she has not yet received Bob's encoding 735 information. 737 Alice now sends INVITE 2. She maintains the sendrecv audio, video 738 and CLUE m-lines, and she adds three new sendonly m-lines to 739 represents the maximum three encodings she can send. Each of these 740 m-lines has a label corresponding to one of the encoding ids from 741 ADVERTISEMENT 1. Each also has its mid added to the grouping 742 attribute to show they are controlled by the CLUE channel. A snippet 743 of the SDP showing the grouping attribute and the video m-lines are 744 shown below (mid 3 represents the CLUE channel): 746 ... 747 a=group:CLUE 3 4 5 6 748 ... 749 m=video 6002 RTP/AVP 96 750 a=rtpmap:96 H264/90000 751 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 752 a=sendrecv 753 a=mid:2 754 ... 755 m=video 6004 RTP/AVP 96 756 a=rtpmap:96 H264/90000 757 a=fmtp:96 profile-level-id=42e016 758 a=sendonly 759 a=mid:4 760 a=label:enc1 761 m=video 6006 RTP/AVP 96 762 a=rtpmap:96 H264/90000 763 a=fmtp:96 profile-level-id=42e016 764 a=sendonly 765 a=mid:5 766 a=label:enc2 767 m=video 6008 RTP/AVP 96 768 a=rtpmap:96 H264/90000 769 a=fmtp:96 profile-level-id=42e016 770 a=sendonly 771 a=mid:6 772 a=label:enc3 774 Bob now has all the information he needs to decide which streams to 775 configure. As such he now sends CONFIGURE 1. This requests the pair 776 of switched captures that represent Alice's scene, and he configures 777 them with encoder ids "enc1" and "enc2". This also serves as an ack 778 for Alice's ADVERTISMENT 1. 780 Alice receives Bob's message CONFIGURE 1 and sends RESPONSE 1 to ack 781 its receptions. She does not yet send the capture encodings 782 specified, because at this stage Bob hasn't negotiated the ability to 783 receive these streams in SDP. 785 Bob now sends his SDP answer as part of 200 OK 2. Alongside his 786 original audio, video and CLUE m-lines he includes two active 787 recvonly m-lines and a zeroed m-line for the third. He adds their 788 mid values to the grouping attribute to show they are controlled by 789 the CLUE channel. A snippet of the SDP showing the grouping 790 attribute and the video m-lines are shown below (mid 100 represents 791 the CLUE channel): 793 ... 794 a=group:CLUE 11 12 100 795 ... 796 m=video 58722 RTP/AVP 96 797 a=rtpmap:96 H264/90000 798 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 799 a=sendrecv 800 a=mid:10 801 ... 802 m=video 58724 RTP/AVP 96 803 a=rtpmap:96 H264/90000 804 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 805 a=recvonly 806 a=mid:11 807 m=video 58726 RTP/AVP 96 808 a=rtpmap:96 H264/90000 809 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 810 a=recvonly 811 a=mid:12 812 m=video 0 RTP/AVP 96 814 On receiving 200 OK 2 from Bob Alice is now able to send the two 815 streams of video Bob requested - this is illustrated as MEDIA 2. 817 The constraints of offer/answer meant that Bob could not include his 818 encoder information as new m-lines in 200 OK 2. As such Bob now 819 sends INVITE 3 to generate a new offer. Along with all the streams 820 from 200 OK 2 Bob also includes two new sendonly streams. Each 821 stream has a label corresponding to the encoding ids in his 822 ADVERTISEMENT 2 message. He also adds their mid values to the 823 grouping attribute to show they are controlled by the CLUE channel. 824 A snippet of the SDP showing the grouping attribute and the video 825 m-lines are shown below (mid 100 represents the CLUE channel): 827 ... 828 a=group:CLUE 11 12 13 14 100 829 ... 830 m=video 58722 RTP/AVP 96 831 a=rtpmap:96 H264/90000 832 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 833 a=sendrecv 834 a=mid:10 835 ... 836 m=video 58724 RTP/AVP 96 837 a=rtpmap:96 H264/90000 838 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 839 a=recvonly 840 a=mid:11 841 m=video 58726 RTP/AVP 96 842 a=rtpmap:96 H264/90000 843 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 844 a=recvonly 845 a=mid:12 846 m=video 0 RTP/AVP 96 847 m=video 58728 RTP/AVP 96 848 a=rtpmap:96 H264/90000 849 a=fmtp:96 profile-level-id=42e016 850 a=sendonly 851 a=label:foo 852 a=mid:13 853 m=video 58730 RTP/AVP 96 854 a=rtpmap:96 H264/90000 855 a=fmtp:96 profile-level-id=42e016 856 a=sendonly 857 a=label:bar 858 a=mid:14 860 Having received this Alice now has all the information she needs to 861 send CONFIGURE 2. She requests the two static captures from Bob, to 862 be sent on encodings "foo" and "bar". 864 Bob receives Alice's message CONFIGURE 2 and sends RESPONSE 2 to ack 865 its receptions. Bob does not yet send the capture encodings 866 specified, because Alice hasn't yet negotiated the ability to receive 867 these streams in SDP. 869 Alice now sends 200 OK 3, matching two recvonly m-lines to Bob's new 870 sendonly lines. She includes their mid values in the grouping 871 attribute to show they are controlled by the CLUE channel. A snippet 872 of the SDP showing the grouping attribute and the video m-lines are 873 shown below (mid 3 represents the CLUE channel): 875 ... 876 a=group:CLUE 3 4 5 7 8 877 ... 878 m=video 6002 RTP/AVP 96 879 a=rtpmap:96 H264/90000 880 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 881 a=sendrecv 882 a=mid:2 883 ... 884 m=video 6004 RTP/AVP 96 885 a=rtpmap:96 H264/90000 886 a=fmtp:96 profile-level-id=42e016 887 a=sendonly 888 a=mid:4 889 a=label:enc1 890 m=video 6006 RTP/AVP 96 891 a=rtpmap:96 H264/90000 892 a=fmtp:96 profile-level-id=42e016 893 a=sendonly 894 a=mid:5 895 a=label:enc2 896 m=video 0 RTP/AVP 96 897 m=video 6010 RTP/AVP 96 898 a=rtpmap:96 H264/90000 899 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 900 a=recvonly 901 a=mid:7 902 m=video 6012 RTP/AVP 96 903 a=rtpmap:96 H264/90000 904 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 905 a=recvonly 906 a=mid:8 908 Finally, on receiving 200 OK 3 Bob is now able to send the two 909 streams of video Alice requested - this is illustrated as MEDIA 3. 911 Both sides of the call are now sending multiple video streams with 912 their sources defined via CLUE negotiation. As the call progresses 913 either side can send new ADVERTISEMENT or CONFIGURE or new SDP 914 negotiation to add, remove or change what they have available or want 915 to receive. 917 8. Example: A call between a CLUE-capable and non-CLUE endpoint 919 In this brief example Alice is a CLUE-capable endpoint making a call 920 to Bob, who is not CLUE-capable, i.e., it is not able to use the CLUE 921 protocol. 923 +----------+ +-----------+ 924 | EP1 | | EP2 | 925 | | | | 926 +----+-----+ +-----+-----+ 927 | | 928 | | 929 | SIP INVITE 1 (BASIC SDP+COMEDIA) | 930 |--------------------------------->| 931 | | 932 | | 933 | 200 0K 1 (BASIC SDP+*NO*COMEDIA) | 934 |<---------------------------------| 935 | | 936 | | 937 | ACK 1 | 938 |--------------------------------->| 939 | | 940 | | 941 | | 942 |<########### MEDIA 1 ############>| 943 | 1 video A->B, 1 video B->A | 944 |<################################>| 945 | | 946 | | 947 | | 948 | | 949 v v 951 In INVITE 1, Alice sends Bob a SIP INVITE including in the SDP body 952 the basilar audio and video capabilities ("BASIC SDP") and the 953 information needed for opening a control channel to be used for CLUE 954 protocol messages exchange, according to what is envisioned in the 955 COMEDIA approach ("COMEDIA") for DTLS/SCTP channel 956 [I-D.ietf-mmusic-sctp-sdp]. A snippet of the SDP showing the 957 grouping attribute and the video m-line are shown below (mid 3 958 represents the CLUE channel): 960 ... 961 a=group:CLUE 3 962 ... 963 m=video 6002 RTP/AVP 96 964 a=rtpmap:96 H264/90000 965 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 966 a=sendrecv 967 a=mid:2 969 Bob is not CLUE capable, and hence does not recognize the "CLUE" 970 semantic for the grouping attribute, not does he support the CLUE 971 channel. He responds with an answer with audio and video, but with 972 the CLUE channel zeroed. 974 From the lack of the CLUE channel Alice understands that Bob does not 975 support CLUE, or does not wish to use it. Both sides are now able to 976 send a single audio and video stream to each other. Alice at this 977 point begins to send her fallback video: in this case likely a 978 switched view from whichever camera shows the current loudest 979 participant on her side. 981 9. CLUE requirements on SDP O/A 983 The current proposal calls for a new "CLUE" semantic for the SDP 984 Grouping Framework [RFC5888]. 986 Any other SDP extensions required to support CLUE signaling should 987 also be specified here. Then we will need to take action within 988 MMUSIC to make those happen. This section should be empty and 989 removed before this document becomes an RFC. 991 NOTE: The RTP mapping document [I-D.even-clue-rtp-mapping] is also 992 likely to call for SDP extensions. We will have to reconcile how to 993 coordinate these two documents. 995 10. SIP Signaling 997 (Placeholder) This may be unremarkable. If so we can drop it. 999 11. CLUE over RTCWEB 1001 We may want to rule this out of scope for now. But we should be 1002 thinking about this. 1004 12. Open Issues 1006 Here are issues pertinent to signaling that need resolution. 1007 Resolution will probably result in changes somewhere in this 1008 document, but may also impact other documents. 1009 o While the preference is to multiplex multiple capture encodings 1010 over a single RTP session, this will not always be desirable or 1011 possible. The factors that prevent multiplexing may come from 1012 either the provider or the consumer. So the extent of 1013 multiplexing must be negotiated. The decision about how to 1014 multiplex affects the number and grouping of m-lines in the SDP. 1015 The endpoint of a CLUE session that sends an offer needs to know 1016 the mapping of capture encodings to m-lines for both sides. 1018 AFAIK this issue hasn't yet been considered at all. 1019 o The current method for expressing encodings in SDP limits the 1020 parameters available when describing H264 encoder capabilities to 1021 those defined in Table 6 in [RFC6184] 1023 13. What else? 1025 14. Acknowledgements 1027 The team focusing on this draft consists of: Roni Even, Rob Hansen, 1028 Christer Holmberg, Paul Kyzivat, Simon Pietro-Romano, Roberta Presta. 1030 Christian Groves has contributed detailed comments and suggestions. 1032 The author list should be updated as people contribute substantial 1033 text to this document. 1035 15. IANA Considerations 1037 TBD 1039 16. Security Considerations 1041 TBD 1043 17. Change History 1044 -00: Revision by Rob Hansen 1045 * Submitted as -00 working group document 1046 draft-kyzivat-08: Revisions by Rob Hansen 1047 * Added media feature tag for CLUE support ('sip.telepresence') 1048 * Changed grouping semantic from 'CLUE' to 'TELEPRESENCE' 1049 * Restructured document to be more centred on the grouping 1050 semantic and its use with O/A 1051 * Lots of additional text on usage of the grouping semantic 1052 * Stricter definition of CLUE-controlled m lines and how they 1053 work 1054 * Some additional text on defining what happens when CLUE 1055 supports is added or removed 1056 * Added details on when to not send RTCP for CLUE-controlled "m" 1057 lines. 1058 * Added a section on using BUNDLE with CLUE 1059 * Updated data channel references to point at new WG document 1060 rather than indivual draft 1061 draft-kyzivat-07: Revisions by Rob Hansen 1062 * Removed the text providing arguments for encoding limits being 1063 in SDP and encoding groups in the CLUE protocol in favor of the 1064 specifics of how to negotiate encodings in SDP 1065 * Added normative language on the setting up of a CLUE call, and 1066 added sections on mid-call changes to the CLUE status. 1067 * Added references to [I-D.ietf-clue-datachannel] where 1068 appropriate. 1069 * Added some terminology for various types of CLUE and non-CLUE 1070 states of operation. 1071 * Moved language related to topics that should be in 1072 [I-D.ietf-clue-datachannel] and [I-D.presta-clue-protocol], but 1073 that has not yet been resolved in those documents, into an 1074 appendix. 1075 draft-kyzivat-06: Revisions by Rob Hansen 1076 * Removed CLUE message XML schema and details that are now in 1077 draft-presta-clue-protocol 1078 * Encoding limits in SDP section updated to note that this has 1079 been investigated and discussed and is the current working 1080 assumption of the WG, though consensus has not been fully 1081 achieved. 1082 * A section has also been added on the current mandation of 1083 unidirectional "m"-lines. 1084 * Updated CLUE messaging in example call flow to match 1085 draft-presta-clue-protocol-03 1086 draft-kyzivat-05: Revisions by pkyzivat: 1087 * Specified versioning model and mechanism. 1088 * Added explicit response to all messages. 1089 * Rearranged text to work with the above changes. (Which 1090 rendered diff almost useless.) 1092 draft-kyzivat-04: Revisions by Rob Hansen: ??? 1093 draft-kyzivat-03: Revisions by pkyzivat: 1094 * Added a syntax section with an XML schema for CLUE messages. 1095 This is a strawhorse, and is very incomplete, but it 1096 establishes a template for doing this based on elements defined 1097 in the data model. (Thanks to Roberta for help with this!) 1098 * Did some rewording to fit the syntax section in and reference 1099 it. 1100 * Did some relatively minor restructuring of the document to make 1101 it flow better in a logical way. 1102 draft-kyzivat-02: A bunch of revisions by pkyzivat: 1103 * Moved roberta's call flows to a more appropriate place in the 1104 document. 1105 * New section on versioning. 1106 * New section on NAK. 1107 * A couple of possible alternatives for message acknowledgment. 1108 * Some discussion of when/how to signal changes in provider 1109 state. 1110 * Some discussion about the handling of transport errors. 1111 * Added a change history section. 1112 These were developed by Lennard Xiao, Christian Groves and Paul, 1113 so added Lennard and Christian as authors. 1114 draft-kyzivat-01: Updated by roberta to include some sample call 1115 flows. 1116 draft-kyzivat-00: Initial version by pkyzivat. Established general 1117 outline for the document, and specified a few things thought to 1118 represent wg consensus. 1120 18. References 1122 18.1. Normative References 1124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1125 Requirement Levels", BCP 14, RFC 2119, March 1997. 1127 [I-D.ietf-clue-framework] 1128 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 1129 for Telepresence Multi-Streams", 1130 draft-ietf-clue-framework-14 (work in progress), 1131 February 2014. 1133 [I-D.presta-clue-data-model-schema] 1134 Presta, R. and S. Romano, "An XML Schema for the CLUE data 1135 model", draft-presta-clue-data-model-schema-03 (work in 1136 progress), March 2013. 1138 [I-D.presta-clue-protocol] 1139 Presta, R. and S. Romano, "CLUE protocol", 1140 draft-presta-clue-protocol-03 (work in progress), 1141 November 2013. 1143 [I-D.ietf-clue-datachannel] 1144 Holmberg, C., "CLUE Protocol Data Channel", 1145 draft-ietf-clue-datachannel-00 (work in progress), 1146 March 2014. 1148 [I-D.groves-clue-latent-config] 1149 Groves, C., Yang, W., and R. Even, "CLUE and latent 1150 configurations", draft-groves-clue-latent-config-00 (work 1151 in progress), January 2014. 1153 [I-D.ietf-mmusic-sctp-sdp] 1154 Loreto, S. and G. Camarillo, "Stream Control Transmission 1155 Protocol (SCTP)-Based Media Transport in the Session 1156 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-06 1157 (work in progress), February 2014. 1159 [I-D.tuexen-tsvwg-sctp-dtls-encaps] 1160 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 1161 Encapsulation of SCTP Packets for RTCWEB", 1162 draft-tuexen-tsvwg-sctp-dtls-encaps-01 (work in progress), 1163 July 2012. 1165 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1166 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1168 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1169 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1171 18.2. Informative References 1173 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1174 with Session Description Protocol (SDP)", RFC 3264, 1175 June 2002. 1177 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1178 UPDATE Method", RFC 3311, October 2002. 1180 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1181 (ICE): A Protocol for Network Address Translator (NAT) 1182 Traversal for Offer/Answer Protocols", RFC 5245, 1183 April 2010. 1185 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1186 Session Initiation Protocol (SIP)", RFC 4353, 1187 February 2006. 1189 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1190 Protocol (XMPP): Core", RFC 6120, March 2011. 1192 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1193 Payload Format for H.264 Video", RFC 6184, May 2011. 1195 [I-D.even-clue-sdp-clue-relation] 1196 Even, R., "Signalling of CLUE and SDP offer/answer", 1197 draft-even-clue-sdp-clue-relation-01 (work in progress), 1198 October 2012. 1200 [I-D.even-clue-rtp-mapping] 1201 Even, R. and J. Lennox, "Mapping RTP streams to CLUE media 1202 captures", draft-even-clue-rtp-mapping-05 (work in 1203 progress), February 2013. 1205 [I-D.hansen-clue-sdp-interaction] 1206 Hansen, R., "SDP and CLUE message interactions", 1207 draft-hansen-clue-sdp-interaction-01 (work in progress), 1208 February 2013. 1210 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1211 Holmberg, C., Alvestrand, H., and C. Jennings, 1212 "Multiplexing Negotiation Using Session Description 1213 Protocol (SDP) Port Numbers", 1214 draft-ietf-mmusic-sdp-bundle-negotiation-06 (work in 1215 progress), April 2014. 1217 Appendix A. CLUE Signalling and data channel concerns 1219 [The specifics of the CLUE signaling protocol are in the process of 1220 being defined in [I-D.presta-clue-protocol], while the negotiation of 1221 the CLUE data channel is being defined in 1222 [I-D.ietf-clue-datachannel]. As such, considerable text originally 1223 in this section have been transitioned to these document. The 1224 following text relates to issues that are no longer the focus of this 1225 document, but remain important and unresolved, and so have been 1226 preserved here.] 1228 A.1. Protocol Versioning and Options 1230 A.1.1. Versioning Objectives 1232 The CLUE versioning mechanism addresses the following needs: 1234 o Coverage: 1235 * Versioning of basic behavior and options, 1236 * CLUE message exchange, 1237 * CLUE message exchange, 1238 * coordinated use of SIP and SDP, 1239 * required media behavior. 1240 o Remain fixed for the duration of the CLUE channel 1241 o Be extensible for configuration of new options. 1242 o Be sufficient (with extensions) for all envisioned future 1243 versions. 1245 A.1.2. Versioning Overview 1247 An initial message exchange on the CLUE channel handles the 1248 negotiation of version and options. 1250 o Dedicated message types are used for this negotiation. 1251 o The negotiation is repeated if the CLUE channel is reestablished. 1253 The version usage is similar in philosophy to XMPP: 1255 o See [RFC6120] section 4.7.5. 1256 o A version has major and minor components. (Each a non-negative 1257 integer.) 1258 o Major version changes denote non-interoperable changes. 1259 o Minor version changes denote schema changes that are backward 1260 compatible by ignoring unknown XML elements, or other backward 1261 compatible changes. 1262 o If a common major version cannot be negotiated, then CLUE MUST NOT 1263 be used. 1264 o The same message exchange also negotiates options. 1265 o Each option is denoted by a unique XML element in the negotiation. 1267 Figure 1 shows the negotiation in simplified form: 1269 | Supported Supported | 1270 |------------\ /------------| 1271 | X | 1272 |<-----------/ \----------->| 1273 | | 1274 | Required Required | 1275 |------------\ /------------| 1276 | X | 1277 |<-----------/ \----------->| 1278 | | 1279 | Advertise/Configure/... | 1280 |<------------------------->| 1282 Figure 1: Basic Option Negotiation (simplified) 1284 Dedicated message types are used for the negotiation because: 1286 o The protocol can then ensure that the negotiation is done first, 1287 and once. Not changing mid-session means an endpoint can plan 1288 ahead, and predict what may be used and what might be received. 1289 o This provides extensible framework for negotiating optional 1290 features. 1291 o A full option negotiation can be completed before other messages 1292 are exchanged. 1294 Figure 2 and Figure 3 are simplified examples of the Supported and 1295 Required messages: 1297 1298 1299 1301 1302 1303 ... 1304 1306 Figure 2: Supported Message (simplified) 1308 1309 1310 1311 1312 1313 ... 1314 1315 Figure 3: Required Message (simplified) 1317 A.1.3. Version Negotiation 1319 The Supported message includes one or more elements, each 1320 denoting a major/minor version combination that the sender of the 1321 message is capable of supporting. 1323 The element contains both a major and minor version. Each 1324 is a non-negative integer. Each element in the message 1325 MUST contain a unique major version number, distinct from the major 1326 version number in all the other elements in the message. 1327 The minor version in a element denotes the largest minor 1328 version the sender supports for the corresponding major version. 1329 (Minor versions are always backwards compatible, so support for a 1330 minor version implies support for all smaller minor versions.) 1332 Each endpoint of the CLUE channel sends a Supported message, and 1333 receives the Supported message sent by the other end. Then each end 1334 compares the versions sent and the versions received to determine the 1335 version to be used for this CLUE session. 1337 o If there is no major version in common between the two ends, 1338 negotiation fails. 1339 o The elements from the two ends that have the largest 1340 matching major version are selected. 1341 o After exchange each end determines compatible version numbers to 1342 be used for encoding and decoding messages, and other behavior in 1343 the CLUE session. 1344 * The elements from the two ends that have the largest 1345 matching major version are selected. 1346 * The side that sent the smaller minor version chooses the one it 1347 sent. 1348 * The side that sent the larger minor version may choose the 1349 minor version it received, or the one it sent, or any value 1350 between those two. 1351 o Each end then sends a Required message with a single 1352 element containing the major and minor versions it has chosen. 1354 [[Note: "required" is the wrong semantic for this. Might want a 1355 better message name.]] 1356 o Each end then behaves in accord with the specifications denoted by 1357 the version it chose. This continues until the end of the CLUE 1358 session, or until changed as a result of another version 1359 negotiation when the CLUE channel is reestablished. 1361 [[Note: The version negotiation remains in effect even if the CLUE 1362 channel is lost.]] 1364 A.1.4. Option Negotiation 1366 Option negotiation is used to agree upon which options will be 1367 available for use within the CLUE session. (It does not say that 1368 these options must be used.) This may be used for both standard and 1369 proprietary options. (As used here, and option could be either a 1370 feature described as part of this specification that is optional to 1371 implement, or a feature defined in a separate specification that 1372 extends this one.) 1374 Each end includes, within the Supported message it sends, elements 1375 describing those options it is willing and able to use with this CLUE 1376 session. 1378 Each side, upon receiving a Supported message, selects from that 1379 message those option elements that it wishes the peer to use. (If/ 1380 when occasion for that use arises.) It then includes those selected 1381 elements into the Required message that it sends. 1383 Within a received Supported message, unknown option elements MUST be 1384 ignored. This includes elements that are of a known type that is not 1385 known to denote an option. 1387 A.1.5. Option Elements 1389 Each option is denoted, in the Supported and Required messages, by an 1390 XML element. There are no special rules for these elements - they 1391 can be any XML element. The attributes and body of the element may 1392 carry further information about the option. The same element type is 1393 used to denote the option in the Supported message and the 1394 corresponding Required message, but the attributes and body may 1395 differ according to option-specific rules. This may be used to 1396 negotiate aspects of a particular option. The ordering of option 1397 elements is irrelevant within the Supported and Required messages, 1398 and need not be consistent in the two. 1400 Only one option element is defined in this document: . 1402 A.1.5.1. 1404 The element, when placed in a Supported message, 1405 indicates that the sender is willing and able to send ADVERTISEMENT 1406 messages and receive CONFIGURE messages. When placed in a Required 1407 message, the element indicates that the sender is 1408 willing, able, and desirous of receiving ADVERTISEMENT messages and 1409 sending CONFIGURE messages. If an endpoint does not receive 1410 in a Required message, it MUST NOT send ADVERTISEMENT 1411 messages. For common cases should be supported and 1412 required by both endpoints, to enable bidirectional exchange of 1413 media. If not required by either end, the CLUE session is useless. 1414 This is an error condition, and SHOULD result in termination of the 1415 CLUE channel. 1417 The element has no defined attributes or body. 1419 A.1.6. Version & option negotiation errors 1421 The following are errors that may be detected and reported during 1422 version negotiation: 1424 o Version incompatibility 1426 There is no common value between the major version numbers sent in 1427 a Supported message and those in the received Supported message. 1428 o Option incompatibility 1430 This can occur if options supported by one endpoint are 1431 inconsistent with those supported by the other endpoint. E.g., 1432 The option is not specified by either endpoint. 1433 Options SHOULD be specified so as to make it difficult for this 1434 problem to occur. 1436 This error may also be used to indicate that insufficient options 1437 have been required among the two ends for a useful session to 1438 result. This can occur with a feature that needs to be present on 1439 at least one end, but not on a specific end. E.g., The 1440 option was Supported by at least one of the 1441 endpoints, but it was not Required by either. 1443 This may also be used to indicate that an option element in the 1444 Required message has attributes or body content that is 1445 syntactically correct, but in inconsistent with the rules for 1446 option negotiation specified for that particular element. The 1447 definition of each option must specify the negotiation rules for 1448 that option. 1449 o Unsupported option 1451 An option element type received in a Required message did not 1452 appear in the corresponding Supported element. 1454 (Unsupported options received in a Supported message do not 1455 trigger this error. They are ignored.) 1457 These errors are reported using the normal message error reporting 1458 mechanism. 1460 Other applicable error codes may also be returned in response to a 1461 Supported or Required message. 1463 Errors that occur at this stage result in negotiation failure. When 1464 this occurs, CLUE cannot be used until the end of the SIP session, or 1465 until a new CLUE channel is negotiated and a subsequent version 1466 negotiation succeeds. The SIP session may continue without CLUE 1467 features. 1469 A.1.7. Definition and Use of Version Numbers 1471 [[NOTE: THIS IS AWKWARD. SUGGESTIONS FOR BETTER WAYS TO DEFINE THIS 1472 ARE WELCOME.]] 1474 This document defines CLUE version 1.0 (major=1, minor=0). This 1475 denotes the normative behavior defined in this document and other 1476 documents upon which it normatively depends, including but is not 1477 limited to: 1479 o the schema defined in [I-D.presta-clue-protocol]; 1480 o the schema defined in [clue-data-model]; 1481 o the protocol used to exchange CLUE messages; 1482 o the protocol defined herein that defines valid sequence of CLUE 1483 messages; 1484 o the specific rules defined herein for employing SIP, SDP, and RTP 1485 to realize the CLUE messages. 1487 Given two CLUE versions Vx and Vy, then Vx is backward compatible 1488 with Vy if and only if: 1490 o All messages valid according to the schema of Vx are also valid 1491 according to the schemas of Vy 1492 o All messages valid according to the schema of Vy can be made valid 1493 according to the schemas of Vx by deleting elements undefined in 1494 the schemas of Vx. 1496 [[NOTE: THIS PROBABLY NEEDS WORK!]] 1497 o All normative behaviors defined for Vx are defined consistently 1498 for Vy. 1500 [[NOTE: SOME HAND WAVING HERE.]] 1502 Revisions, updates, to any of the documents denoted by Version 1.0 1503 MAY result in the definition of a new CLUE version. If they do, then 1504 this document MUST be revised to define the new version. 1506 The CLUE version to be defined in a revision to this document MUST be 1507 determined as follows: 1509 o If the revision and the document being revised are mutually 1510 backward compatible (they are functionally equivalent), then the 1511 CLUE version MUST remain unchanged. 1512 o Else if the revision is backward compatible with the document 1513 being revised, then the CLUE major version MUST remain unchanged, 1514 and the CLUE minor version MUST be increased by one (1). 1515 o Else the CLUE major version must be increased by one (1), and the 1516 CLUE minor version set to zero (0). 1518 When a CLUE implementation sends a Supported message, it MUST include 1519 the CLUE versions it is willing and able to conform with. 1521 A.1.8. Version & Option Negotiation Examples 1523 A.1.8.1. Successful Negotiation - Multi-version 1525 | Supported Supported | 1526 | Version 2.0 | 1527 | Version 1.2 Version 1.1 | 1528 | mediaProv mediaProv | 1529 |------------\ /------------| 1530 | X | 1531 |<-----------/ \----------->| 1532 | | 1533 | OK response OK response | 1534 |------------\ /------------| 1535 | X | 1536 |<-----------/ \----------->| 1537 | | 1538 | Required Required | 1539 | Version 1.2 Version 1.1 | 1540 | mediaProv mediaProv | 1541 |------------\ /------------| 1542 | X | 1543 |<-----------/ \----------->| 1544 | | 1545 | OK response OK response | 1546 |------------\ /------------| 1547 | X | 1548 |<-----------/ \----------->| 1549 | | 1550 | Advertise | 1551 |<------------------------->| 1552 | | 1553 | Configure | 1554 |<------------------------->| 1556 The endpoint on the left can support versions 1.2 and 2.0, and 1557 because of backward compatibility can support versions 1.0 and 1.1. 1558 The endpoint on the right supports only version 2.0. Both endpoints 1559 with to both provide and consume media. They each send a Supported 1560 message indicating what they support. 1562 The element on the left, upon receiving the Supported message, 1563 determines that it is permitted to use version 1.2 or 1.1, and 1564 decides to use 1.2. It sends a Required message containing version 1565 1.2 and also includes the mediaProvider option element, because it 1566 wants its peer to provide media. 1568 The element on the right, upon receiving the Supported message, 1569 selects version 1.1 because it is the highest version in common to 1570 the two sides. It sends a Required message containing version 1.1 1571 because that is the highest version in common. It also includes the 1572 mediaProvider option element, because it wants its peer to provide 1573 media. 1575 Upon receiving the Required messages, both endpoints determine that 1576 they should send ADVERTISEMENTs. 1578 ADVERTISEMENT and CONFIGURE messages will flow in both directions. 1580 A.1.8.2. Successful Negotiation - Consumer-Only Endpoint 1581 | Supported Supported | 1582 | Version 1.0 Version 1.0 | 1583 | mediaProv (no opts) | 1584 |------------\ /------------| 1585 | X | 1586 |<-----------/ \----------->| 1587 | | 1588 | OK response OK response | 1589 |------------\ /------------| 1590 | X | 1591 |<-----------/ \----------->| 1592 | | 1593 | Required Required | 1594 | Version 1.0 Version 1.0 | 1595 | (no opts) mediaProv | 1596 |------------\ /------------| 1597 | X | 1598 |<-----------/ \----------->| 1599 | | 1600 | OK response OK response | 1601 |------------\ /------------| 1602 | X | 1603 |<-----------/ \----------->| 1604 | | 1605 | Advertise | 1606 |-------------------------->| 1607 | | 1608 | Configure | 1609 |<--------------------------| 1611 The endpoint on the right consumes media, but doesn't provide any so 1612 it doesn't include the mediaProvider option element in the Supported 1613 message it sends. 1615 The element on the left would like to include a mediaProvider option 1616 element in the Requirements message it sends, but can't because it 1617 did not receive one in the Supported message it received. 1619 ADVERTISEMENT messages will only go from left to right, and CONFIGURE 1620 messages will only go from right to left. 1622 A.1.8.3. Successful Negotiation - Provider-Only Endpoint 1623 | Supported Supported | 1624 | Version 1.0 Version 1.0 | 1625 | mediaProv mediaProv | 1626 |------------\ /------------| 1627 | X | 1628 |<-----------/ \----------->| 1629 | | 1630 | OK response OK response | 1631 |------------\ /------------| 1632 | X | 1633 |<-----------/ \----------->| 1634 | | 1635 | Required Required | 1636 | Version 1.0 Version 1.0 | 1637 | (no opts) mediaProv | 1638 |------------\ /------------| 1639 | X | 1640 |<-----------/ \----------->| 1641 | | 1642 | OK response OK response | 1643 |------------\ /------------| 1644 | X | 1645 |<-----------/ \----------->| 1646 | | 1647 | Advertise | 1648 |-------------------------->| 1649 | | 1650 | Configure | 1651 |<--------------------------| 1653 The endpoint on the left provides media but does not consume any so 1654 it includes the mediaProvider option element in the Supported message 1655 it sends, but does't include the mediaProvider option element in the 1656 Required message it sends. 1658 ADVERTISEMENT messages will only go from left to right, and CONFIGURE 1659 messages will only go from right to left. 1661 A.1.8.4. Version Incompatibility 1662 | Supported Supported | 1663 | Version 1.2 Version 2.1 | 1664 |------------\ /------------| 1665 | X | 1666 |<-----------/ \----------->| 1667 | | 1668 | Version Version | 1669 | Incompat. Incompat. | 1670 |------------\ /------------| 1671 | X | 1672 |<-----------/ \----------->| 1673 | | 1674 | close clue channel | 1675 |<------------------------->| 1676 | | 1677 | legacy mode or BYE | 1678 |<------------------------->| 1680 Upon receiving the Supported message, each endpoint discovers there 1681 is no major version in common, so CLUE usage is not possible. Each 1682 sends an error response indicating this and then ceases CLUE usage. 1684 A.1.8.5. Option Incompatibility 1686 | Supported Supported | 1687 | Version 1.0 Version 1.0 | 1688 | mediaProv mediaProv | 1689 |------------\ /------------| 1690 | X | 1691 |<-----------/ \----------->| 1692 | | 1693 | Required Required | 1694 | (no opts) (no opts) | 1695 |------------\ /------------| 1696 | X | 1697 |<-----------/ \----------->| 1698 | | 1699 | Option Option | 1700 | Incompat. Incompat. | 1701 |------------\ /------------| 1702 | X | 1703 |<-----------/ \----------->| 1704 | | 1705 | close clue channel | 1706 |<------------------------->| 1707 | | 1708 | legacy mode or BYE | 1709 |<------------------------->| 1711 Neither of the endpoints is willing to provide media. It makes no 1712 sense to continue CLUE operation in this situation. Each endpoint 1713 realizes this upon receiving the Supported message, sends an error 1714 response indicating this and then ceases CLUE usage. 1716 A.1.8.6. Syntax Error 1718 | Supported !@#$%^ | 1719 |------------\ /------------| 1720 | X | 1721 |<-----------/ \----------->| 1722 | | 1723 | syntax error OK response | 1724 |------------\ /------------| 1725 | X | 1726 |<-----------/ \----------->| 1727 | | 1728 | close clue channel | 1729 |-------------------------->| 1730 | | 1731 | legacy mode or BYE | 1732 |<------------------------->| 1734 A.2. Message Transport 1736 CLUE messages are transported over a bidirectional CLUE channel. In 1737 a two-party CLUE session, a CLUE channel connects the two endpoints. 1738 In a CLUE conference, each endpoint has a CLUE channel connecting it 1739 to an MCU. (In conferences with cascaded mixers [RFC4353], two MCUs 1740 will be connected by a CLUE channel.) 1742 A.2.1. CLUE Channel Lifetime 1744 The transport mechanism used for CLUE messages is DTLS/SCTP as 1745 specified in [I-D.tuexen-tsvwg-sctp-dtls-encaps] and 1746 [I-D.ietf-mmusic-sctp-sdp]. A CLUE channel consists of one SCTP 1747 stream in each direction over a DTLS/SCTP session. The mechanism for 1748 establishing the DTLS/SCTP session is described in 1749 [I-D.ietf-clue-datachannel]. 1751 The CLUE channel will usually be offered during the initial SIP 1752 INVITE, and remain connected for the duration of the CLUE/SIP 1753 session. However this need not be the case. The CLUE channel may be 1754 established mid-session after desire and capability for CLUE have 1755 been determined, and the CLUE channel may be dropped mid-call if the 1756 desire and/or capability to support it is lost. 1758 There may be cases when it becomes necessary to "reset" the CLUE 1759 channel. This by be as a result of an error on the underlying SCTP 1760 association, a need to change the endpoint address of the SCTP 1761 association, loss of CLUE protocol state, or something else TBD. 1763 The precise mechanisms used to determine when a reset is required, 1764 and how to accomplish it and return to a well defined state are TBS. 1766 A.2.2. Channel Error Handling 1768 We will need to specify behavior in the face of transport errors that 1769 are so severe that they can't be managed via CLUE messaging within 1770 the CLUE channel. Some errors of this sort are: 1771 o Unable to establish the SCTP association after signaling it in 1772 SDP. 1773 o CLUE channel setup rejected by peer. 1774 o Error reported by transport while writing message to CLUE channel. 1775 o Error reported by transport while reading message from CLUE 1776 channel. 1777 o Timeout - overdue acknowledgement of a CLUE message. 1778 (Requirements for now soon a message must be responded to are 1779 TBD.) 1780 o Application fault. CLUE protocol state lost. 1781 The worst case is to drop the entire CLUE call. Another possibility 1782 is to fall back to legacy compatibility mode. Or perhaps a "reset" 1783 can be done on the protocol. E.g. this might be accomplished by 1784 sending a new O/A and establishing a replacement SCTP association. 1785 Or a new CLUE channel might be established within the existing SCTP 1786 association. 1788 A.3. Message Framing 1790 Message framing is provided by the SCTP transport protocol. Each 1791 CLUE message is carried in one SCTP message. 1793 Authors' Addresses 1795 Paul Kyzivat 1796 Huawei 1798 Email: pkyzivat@alum.mit.edu 1799 Lennard Xiao 1800 Huawei 1802 Email: lennard.xiao@huawei.com 1804 Christian Groves 1805 Huawei 1807 Email: Christian.Groves@nteczone.com 1809 Robert Hansen 1810 Cisco Systems 1812 Email: rohanse2@cisco.com