idnits 2.17.1 draft-mandyam-rtcweb-data-synch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 5) being 69 lines == 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 3 instances of too long lines in the document, the longest one being 30 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended status: Informational Vijay Suryavanshi', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (July 30, 2012) is 4260 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: 'RFC2119' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC5576' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC5888' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC6222' is defined on line 317, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'I-D.-rtcweb-jsep' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'I-D.-draft-alvestrand-rtcweb-msid' is defined on line 347, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 6222 (Obsoleted by RFC 7022) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-03 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-01 -- No information found for draft-jesuprtcweb-data-protocol - is the name correct? -- No information found for draft-ietfmmusic-sctp-sdp - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RTCWeb Working Group G. Mandyam 2 Internet Draft Qualcomm Innovation Center 3 Intended status: Informational Vijay Suryavanshi 4 Expires: January 30, 2013 Qualcomm 5 July 30, 2012 7 RTCWeb Data Stream and RTP Synchronization 8 draft-mandyam-rtcweb-data-synch-00.txt 10 Abstract 12 The RTCWeb working group in the IETF is tasked with developing 13 standards that will ensure interoperability between web browsers 14 establishing rich communications sessions. This working group is 15 tasked with delivering the specifications necessary to establish 16 real-time transport sessions between browsers (e.g. those based on 17 real-time protocol, i.e. RTP). Moreover, the group is also tasked 18 with providing a means for application data streaming between 19 browsers (i.e. opaque data streaming). Much like RTP 20 synchronization sources (SSRC's) can be temporally synchronized, 21 there are use cases that require opaque data stream synchronization 22 with the real-time communications stream between browsers in an 23 RTCWeb session. This document provides some options for temporally 24 associating an opaque data stream with a voice/video stream as part 25 of RTCWeb communications. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. This document may not be modified, 31 and derivative works of it may not be created, and it may not be 32 published except as an Internet-Draft. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. 46 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on January 30, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................2 67 2. SCTP-Based Data Streaming......................................3 68 2.1. SCTP Multi-Channel Impacts................................4 69 3. Opaque Data Synchronization and In-band RTP Signaling..........5 70 4. Security Considerations........................................7 71 5. IANA Considerations............................................7 72 6. Conclusions....................................................7 73 7. References.....................................................7 74 7.1. Normative References......................................7 75 7.2. Informative References....................................8 76 8. Acknowledgments................................................8 77 1. Introduction 78 The RTCWeb effort seeks to define the necessary interoperability 79 specifications required for real-time peer-to-peer communications 80 sessions between browsers. These communications sessions normally 81 involve multimedia data transmission (audio, video, or both). 82 However, RTCWeb will also include the ability for web applications 83 to initiate data streaming sessions between browsers. 85 One of the recommended transports for audio or video in RTCWeb 86 sessions is real-time protocol (RTP) [I-D.-rtcweb-rtp-usage]. An 87 RCTWeb session can include one or more RTP streams, each stream 88 identified by an SSRC (synchronization source) included in the RTP 89 frame header. 91 There has been some concern about whether existing mechanisms in RTP 92 standards allow an RTP session endpoint to be able to render 93 multiple SSRC's in a time-synchronized manner [I-D.-draftalvestrand- 94 rtcweb-msid]. As a result, several mechanisms have been 95 proposed that would allow an RTCWeb endpoint to definitively 96 determine which SSRC's are temporally synchronized and must be 97 rendered as such. 99 Assuming the problem of associating temporally-synchronized SSRC's 100 will be solved by one of the proposed mechanisms, there still can be 101 cases where an SSRC may have a temporal relationship with 102 application-generated data that would also be streamed as part of 103 the RTCWeb session. An example is video overlay based on web touch 104 events during a video telephony session. In this case, a web 105 application detects an animation over the video preview window 106 (based on the end user drawing an image using the device touch 107 surface), and is required to send such information to the RTCWeb 108 endpoint so that the animation can be rendered. 110 This document discusses three approaches to synchronization of data 111 streams, along with associated recommendations. 113 2. SCTP-Based Data Streaming 114 [I-D.-jesup-rtcweb-data-protocol] describes an approach that could 115 be adopted in RTCWeb for data streaming, leveraging the Stream 116 Control Transmission Protocol (SCTP), and [I-D.ietf-mmusic-sctp-sdp] 117 provides the necessary extensions to Session Description Protocol 118 (DSP) to describe an SCTP stream. SDP is the mechanism by which 119 multimedia sessions are described RTCWeb, usually as part of the 120 invite or call announce. 122 The m-line in the SDP message (as per [I-D.ietf-mmusic-sctp-sdp]) 123 should include sufficient information to describe the SCTP session 125 (e.g. plain SCTP, SCTP over DTLS, etc.). For example, an SDP 126 message from an offerer at address xxx.xx.xx.xx using port yyyyy for 127 SCTP communication, then a possible SDP offer would include 128 m=application yyyyy SCTP * 129 c=IN IP4 xxx.xx.xx.xx 131 If there is an additional RTP-based media source sent by the offerer 132 that needs synchronization with the SCTP stream, the ideal case 133 would be to leverage existing SDP grouping mechanisms. The mid 134 attribute of RFC 5888 could potentially be leveraged: 136 c=IN IP4 xxx.xx.xx.xx 137 a=group:LS 1 2 138 m=application yyyyy SCTP * 139 a=mid:1 140 m=video zzzzz RTP/AVP 141 a=mid:2 143 There are some issues with this approach, as highlighted in [I-D.draft- 144 alvestrand-rtcweb-msid] (e.g. multiple SSRC's in each RTP 145 stream). Nevertheless, SDP grouping can provide a sufficient 146 solution to synchronizing the SCTP stream to an RTP stream as long 147 as there is one SSRC per RTP stream. SDP grouping should also be 148 applicable in the case where multiple SSRC's are part of the offer 149 and are associated with a canonical name (CNAME), using the 150 attribute guidelines of RFC 5576 (e.g. "a=ssrc: 151 cname:" along with "a=mid:..."). 153 2.1. SCTP Multi-Channel Impacts 154 [I-D.-jesup-rtcweb-data-protocol] provides an SCTP-encapsulated 155 control protocol for the RTCWeb data channel that takes advantage of 156 the multistreaming capabilities of SCTP. SCTP allows for individual 157 stream identifiers and associated sequence numbers for any given 158 data chunk. This allows for flow control on individual streams 159 within an SCTP session. Streams are also further identified by a 160 label attribute as defined in [I-D.-jesup-rtcweb-data-protocol] as 161 part of the logical channel request. Since the streams are dynamic, 162 to associate an SCTP stream at any given instant in time with an RTP 163 session is not straightforward. In addition, SCTP can be 164 multihomed, i.e. endpoints can be associated with more than one IP 165 address. Some of the current unresolved issues are: 167 a. Should the SDP attribute describing the data channel stream be 168 based on logical channel label or SCTP stream ID? 169 b. What is the required receiver behavior if the data channel stream 170 identifier provided in the SDP offer does not match with 171 information sent in-band? Note that a comparable issue also 172 exists for RTP streams using CNAME and SSRC. 173 In order to address these issues in a simpler manner, the following 174 guideline is proposed for RTCWeb: the SDP grouping mechanism should 175 not address individual streams within an SCTP session. In other 176 words, once a temporal relationship is established between an RTP 177 stream and an SCTP session, that relationship will apply to all 178 streams in the SCTP session. 180 3. Opaque Data Synchronization and In-band RTP Signaling 181 Web application generated data may have a temporal relationship with 182 an RTP-based media stream, but if is relatively infrequent and 183 therefore requires much less throughput than the media stream itself 184 it could make more sense to multiplex the application-specific data 185 into the RTP stream. Sec. 5.3.1 of RFC 3550 describes the RFC 186 Header Extension mechanism, by which an application-specific payload 187 can be inserted into an existing RTP stream without affecting the 188 media flow. 190 In the RTP header, and extension bit X can be set. This indicates 192 the existence of an extension header. 194 01234567890123456789012345678901 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | defined by profile | length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | header extension | 204 | .... | 206 Figure 1 : RTP Extension Header 208 Referring to Figure 1, the value of 16-bit profile field in the 209 extension header is implementation specific. This field could be 210 used in place of the channel label in the SCTP-based data channel. 211 Otherwise, this field can be ignored by the receiver. 213 The signaling of the use of an extension header as the means of 214 opaque data transfer could be agreed upon by the two RTCWeb 215 endpoints by means of an offer/answer protocol like SDP. The outof- 216 band signaling channel can be used to indicate to the receiver to 217 create a data channel based on the RTP extension header. RFC 5576 218 can also be leveraged in this case using a new source-specific 219 attribute 'data': 221 a=ssrc: data 223 The SDP exchange is not strictly required, however. This is because 224 the SSRC of the RTP stream has already been negotiated, and the 225 extension header is in fact really part of the RTP media stream 226 data. 228 Ideally, a message-based Data Channel API from the WebRTC 229 specification (see [W3C.WD-webrtc-20120530]) would be leveraged by 230 the web application in such a way that the underlying user agent 231 would multiplex application data onto an existing RTP stream using 232 the RTP extension header. Borrowing from the JSEP messaging flow [ID.- 233 rtcweb-jsep], the PeerConnection setup will proceed as normal 234 from the offerer perspective: 236 OffererJS->OffererUA: var pc = new PeerConnection(config, null); 237 OffererJS->OffererUA: pc.onicecandidate = onIceCandidate; 238 OffererJS->OffererUA: pc.addStream(stream); 239 OffererJS->OffererUA: var offer = pc.createOffer(null); 240 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 242 ... Answerer creates PeerConnection and sends answer 244 AnswererUA->OffererUA: 246 // Send opaque data from Offerer to Answerer 248 OffererJS->OffererUA: var chan = pc.createDataChannel(10); 249 // Numeric label means opaque data to be sent with extension 250 header 252 OffererJS->OffererUA: chan.send("Some Payload"); 254 AnswererUA->OffererUA: with extension header 256 AnswererUA->AnswererJS: pc.ondatachannel = function({...}); 257 // Answerer creates DataChannel listener on existing 258 PeerConnection based upon firing of onDataChannel event 260 OffererUA->OffererJS: datachannellistener.onmessage({}); 262 Note that in the approach above, the creation of a data channel with 263 a numeric label is what triggers the OffererUA to use the extension 264 header. The numeric label can be directly sent as part of the 265 profile field in the extension header (provided that the numeric 266 label does not exceed 16 bits) The initial receipt of RTP data with 267 an extension header triggers the onDataChannel event to fire from 268 the AnswererUA. 270 3.1. Other Uses of the RTP Extension Header 271 Section 5.2 of [I-D.-rtcweb-rtp-usage] clearly discusses (but does 272 not call for requiring) additional uses of the RTP extension header. 273 These uses include a rapid synchronization feature (which allows 274 timing metadata to be inserted into the RTP stream), client-to-mixer 275 audio level, and mixer-to-client audio level. The profile space 276 that may be consumed by these uses of the header extension can be 277 avoided for RTCWeb logical data channels that also use the header 278 extension. 280 4. Security Considerations 281 TBD. 283 5. IANA Considerations 284 TBD. 286 6. Conclusions 287 The ability to send and receive opaque data streams that are 288 syncronized to existing RTP media sessions will greatly enhance 289 RTCWeb. It will open up a several new possibilities for user 290 interactions around telephony sessions (video or voice). The 291 existing specifications in both the W3C and IETF do not address how 292 such a feature would be implemented. This document provided two 293 methods for achieving this feature that leveraged as much as 294 possible the specifications currently under consideration in RTCWeb 295 and the W3C. 297 7. References 298 7.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 303 Syntax Specifications: ABNF", RFC 2234, Internet Mail 304 Consortium and Demon Internet Ltd., November 1997. 306 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 307 Description Protocol", RFC 4566, July 2006. 309 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 310 Media Attributes in the Session Description Protocol 311 (SDP)", RFC 5576, June 2009. 313 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session 314 DescriptionProtocol (SDP) Grouping Framework", RFC 5888, 315 June 2010. 317 [RFC6222] Begen, A.,Perkins, C. and D. Wing, "Guidelines for 318 Choosing RTP Control Protocol (RTCP) Canonical Names", RFC 319 6222, April 2011. 321 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 322 Media Attributes in the Session Description Protocol 323 (SDP)", RFC 5576, June 2009. 325 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 326 Jacobson, "RTP: A Transport Protocol for Real Time 327 Communications", RFC 3550, July 2003. 329 [I-D.-rtcweb-rtp-usage] Perkins, C., Westerlund, M. and J. Ott, "Web 330 Real-Time Communication (WebRTC): Media Transport and Use 331 of RTP", draft-ietf-rtcweb-rtp-usage-03, June 2012. 333 [W3C.WD-webrtc-20120530] Bergkvist, A., Burnett, D., Narayanan, A., 334 and C. Jennings, "WebRTC 1.0: Real-time Communication 335 Between Browsers", World Wide Web Consortium WD WD-webrtc20120209, 336 Editor's Draft, 30 May 2012. 338 [I-D.-rtcweb-jsep] Uberti, J. and C. Jennings, "Javascript Session 339 Establishment Protocol", draft-ietf-rtcweb-jsep-01, June 340 2012. 342 7.2. Informative References 343 [I-D.-jesup-rtcweb-data-protocol] Jesup, R., Loreto, S. and M. 344 Tuexen, "WebRTC Data Channel Protocol", draft-jesuprtcweb- 345 data-protocol-01, June 2012. 347 [I-D.-draft-alvestrand-rtcweb-msid] Alverstand, H., "Cross Session 348 Stream Identification in the Session Description 349 Protocol", draft-alvestrand-rtcweb-msid-02, May 2012. 351 [I-D.ietf-mmusic-sctp-sdp] Loreto, S. and G. Camarillo, "Stream 352 Control Transmission Protocol (SCTP)-Based Media Transport 353 in the Session Description Protocol (SDP)", draft-ietfmmusic- 354 sctp-sdp-01(work in progress), March 2012. 356 8. Acknowledgments 357 This document was prepared using 2-Word-v2.0.template.dot. 359 Authors' Addresses 361 Giridhar Mandyam 362 Qualcomm Innovation Center 363 5775 Morehouse Drive 364 San Diego, CA 92121 365 USA 367 Email: mandyam@quicinc.com 369 Vijay Suryavanshi 370 Qualcomm Inc. 371 5775 Morehouse Drive 372 San Diego, CA 92121 373 USA 375 Email: vsuryava@qualcomm.com