idnits 2.17.1 draft-even-clue-call-flows-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2014) is 3596 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 216, but not defined == Unused Reference: 'I-D.ietf-clue-data-model-schema' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-clue-protocol' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 359, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-clue-data-model-schema-05 == Outdated reference: A later version (-18) exists of draft-ietf-clue-datachannel-00 == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-00 == Outdated reference: A later version (-15) exists of draft-ietf-clue-signaling-01 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-06 -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CLUE WG R. Even, Ed. 2 Internet-Draft Huawei Technologies 3 Intended status: Informational June 22, 2014 4 Expires: December 24, 2014 6 CLUE protocol Call Flows 7 draft-even-clue-call-flows-00.txt 9 Abstract 11 This document provides some call flows examples using the CLUE 12 extensions for "telepresence" 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on December 24, 2014. 31 Copyright Notice 33 Copyright (c) 2014 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 3. Symmetric point to point Telepresence call . . . . . . . . . 2 51 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 52 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 54 7. Informative References . . . . . . . . . . . . . . . . . . . 9 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 57 1. Introduction 59 This document provides some call flows examples using the CLUE 60 extensions for "telepresence". The examples include a typical point 61 to point call between two endpoint with three cameras and screens. A 62 call from a telepresence endpoint to an endpoint that do not support 63 the CLUE telepresence extensions. An point to point call between a 64 three screens and three camera endpoint to a single screen and single 65 camera end point both support the CLUE telepresence extensions. 67 The examples will not include ICE and SRTP negotiations but the 68 actual usage SHOULD include ICE and SRTP. 70 2. Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC2119[RFC2119] and 75 indicate requirement levels for compliant RTP implementations. 77 3. Symmetric point to point Telepresence call 79 In this example both end points have three monitors and three cameras 80 and fully support the CLUE telepresence extensions. 82 The initial call is from Alice to Bob. The first offer includes an 83 audio and video channel, a data channel for CLUE and the CLUE feature 84 tag. 86 INVITE sip:bob@biloxi.example.com SIP/2.0 88 Via: SIP/2.0/TCP 89 client.atlanta.example.com:5060;branch=z9hG4bK74bf9 91 Max-Forwards: 70 93 From: Alice ;tag=9fxced76sl 94 Call-ID: 3848276298220188511@atlanta.example.com 96 CSeq: 1 INVITE 98 Contact: sip:alice@client.atlanta.example.com;transport=tcp; CLUE 99 (?) 101 Content-Type: application/sdp 103 Content-Length: xxx 105 v=0 107 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 109 s=- 111 c=IN IP4 192.0.2.101 113 t=0 0 115 m=audio 49172 RTP/AVP 0 117 a=rtpmap:0 PCMU/8000 119 m=video 49174 RTP/AVP 96 121 a=rtpmap:96 H264/90000 123 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 125 a=sendrecv 127 m=application 54111 DTLS/SCTP 54111 129 a=sctpmap:54111 webrtc-datachannel 131 SIP/2.0 200 OK 133 Via: SIP/2.0/TCP 134 client.atlanta.example.com:5060;branch=z9hG4bK74bf9 136 ;received=192.0.2.101 138 From: Alice ;tag=9fxced76sl 140 To: Bob ;tag=8321234356 141 Call-ID: 3848276298220188511@atlanta.example.com 143 CSeq: 1 INVITE 145 Contact: sip:bob@client.biloxi.example.com;transport=tcp; CLUE (?) 147 Content-Type: application/sdp 149 Content-Length: zzz 151 v=0 153 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 155 s=- 157 c=IN IP4 192.0.2.201 159 t=0 0 161 m=audio 3456 RTP/AVP 0 163 a=rtpmap:0 PCMU/8000 165 m=video 3458 RTP/AVP 96 167 a=rtpmap:96 H264/90000 169 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 171 a=sendrecv 173 m=application 54100 DTLS/SCTP 54111 175 a=sctpmap:54100 webrtc-datachannel 177 ACK sip:bob@client.biloxi.example.com SIP/2.0 179 Via: SIP/2.0/TCP 180 client.atlanta.example.com:5060;branch=z9hG4bK74bd5 182 Max-Forwards: 70 184 From: Alice ;tag=9fxced76sl 186 To: Bob ;tag=8321234356 188 Call-ID: 3848276298220188511@atlanta.example.com 189 CSeq: 1 ACK 191 Content-Length: 0 193 After establishing the initial SIP connection Alice and Bob need to 194 open the CLUE channel. 196 The CLUE data channel is based on the RTCweb data channel as 197 specified in http://tools.ietf.org/html/draft-ietf-clue-datachannel- 198 00. 200 The first step is to open the DTLS [RFC6347] connection . The DTLS 201 connection will be opened by Alice 203 Alice Bob 205 ClientHello --------> 206 ServerHello 207 Certificate* 208 ServerKeyExchange* 209 CertificateRequest* 210 <-------- ServerHelloDone 211 Certificate* 212 ClientKeyExchange 213 CertificateVerify* 214 [ChangeCipherSpec] 215 Finished --------> 216 [ChangeCipherSpec] 217 <-------- Finished 218 Application Data <-------> Application Data 220 After establishing the DTLS connection the SCTP association is 221 created as specified in [RFC4960]. The INIT and INITACK include the 222 number of channels that will be used. 224 Alice (A) Bob (Z) 226 INIT [I-Tag=Tag_A OS=1 MIS=1 227 I-TSN=0 & other info] ------> 228 INIT ACK [Veri Tag=Tag_A, 229 I-Tag=Tag_Z, 230 <------ Cookie_Z, & other info] 232 COOKIE ECHO [Cookie_Z] ----> 233 <---- COOKIE-ACK 235 The SCTP messages are carried in the DATA messages. 237 The next step is to open a web RTC channel 238 [I-D.ietf-rtcweb-data-protocol]. PPID 50 is the webRTC Data Channel 239 Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol]]. PPID 240 51 is the CLUE protocol ID [I-D.ietf-clue-datachannel]. 242 The SCTP DATA message is as follows, the Stream Sequence number will 243 progress. 245 DATA [TSN=initial TSN=0 246 Strm=0,Seq=0 247 ppid= 50; & user data]---------> SACK [TSN = 0, 248 <----------- Block=0] 250 The first SCTP data message from Alice will carry the 251 DATA_CHANNEL_OPEN message. This will open a bi-directional channel. 252 DATA_CHANNEL_OPEN [message type=3, DATA_CHANNEL_RELIABLE, Label 253 Length = 0, Protocol Length = 4, protocol=CLUE) 255 Bob Answers with DATA_CHANNEL_ACK [message type=2] 257 The next SCTP DATA messages will use PPID = 51 since it will carry 258 the CLUE protocol. The Clue Exchange starts from Alice 260 Question: do we want full XML for CLUE messages or just pseudo code 261 providing the parameters? 263 Alice Bob 264 Option [sequenceNr=1, 265 media provider=true, 266 media consumer=true]. -----------------------------> 267 OptionResponse 268 [sequenceNr=4 269 ResponseCode, 270 ResponseString, 271 media provider=true, 272 <-------------------- media consumer=true]. 274 Alice sends an advertisement to Bob, Alice will also send a new SIP 275 invite with the sendonly CLUE media streams. The SIP call flow is in 276 section 7 of [I-D.ietf-clue-signaling] (should it be moved here?) 278 Advertisement [sequenceNr =2, 279 mediacaptures, 280 encodinggroups, 281 captureScenes] --------------------> 283 Bob can now send a Configure message asking for the three cameras and 284 video, a SIP message that will specify receive only RTP streams for 285 the m-lines in the offer from ALICE with sendonly streams . The 286 advertisement acknowledge to Alice is in the configure message. 288 Bob will also send an Advertisement and a SIP INVITE with the send 289 only RTP media streams. 291 Configure [sequenceNr=6, 292 advsequenceNr=2 293 ack=true 294 <-------------- captureEncodings] 295 Configue Response [sequenceNr=3, 296 ResponseCode, 297 ResponseString, 298 confSequenceNr=6]-----------> 300 Advertisement 301 [sequenceNr =7, 302 mediacaptures, 303 encodinggroups, 304 <---------------- captureScenes] 306 Alice will now send the CONFIGURE message and the SIP Invite for 307 receiving the send only RTP streams from Bob 309 Configure [sequenceNr=4, 310 advsequenceNr=7 311 ack=true 312 captureEncodings] -------------------------------> 314 Configue Response 315 [sequenceNr=8, 316 ResponseCode, 317 ResponseString, 318 <------------- confSequenceNr=4] 320 4. Acknowledgements 322 5. IANA Considerations 324 This document contains no IANA considerations. 326 6. Security Considerations 328 While there are likely to be security considerations for any solution 329 for telepresence , this document has no security considerations. 331 7. Informative References 333 [I-D.ietf-clue-data-model-schema] 334 Presta, R. and S. Romano, "An XML Schema for the CLUE data 335 model", draft-ietf-clue-data-model-schema-05 (work in 336 progress), June 2014. 338 [I-D.ietf-clue-datachannel] 339 Holmberg, C., "CLUE Protocol Data Channel", draft-ietf- 340 clue-datachannel-00 (work in progress), March 2014. 342 [I-D.ietf-clue-protocol] 343 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 344 clue-protocol-00 (work in progress), June 2014. 346 [I-D.ietf-clue-signaling] 347 Kyzivat, P., Xiao, L., Groves, C., and R. Hansen, "CLUE 348 Signaling", draft-ietf-clue-signaling-01 (work in 349 progress), May 2014. 351 [I-D.ietf-rtcweb-data-protocol] 352 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 353 Establishment Protocol", draft-ietf-rtcweb-data- 354 protocol-06 (work in progress), June 2014. 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 360 Event Notification", RFC 3265, June 2002. 362 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 363 4960, September 2007. 365 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 366 Security Version 1.2", RFC 6347, January 2012. 368 Author's Address 370 Roni Even (editor) 371 Huawei Technologies 372 Tel Aviv 373 Israel 375 Email: roni.even@mail01.huawei.com