RTCWeb Working Group G. Mandyam Internet Draft Qualcomm Innovation Center Intended status: Informational Vijay Suryavanshi Expires: January 30, 2013 Qualcomm July 30, 2012 RTCWeb Data Stream and RTP Synchronization draft-mandyam-rtcweb-data-synch-00.txt Abstract The RTCWeb working group in the IETF is tasked with developing standards that will ensure interoperability between web browsers establishing rich communications sessions. This working group is tasked with delivering the specifications necessary to establish real-time transport sessions between browsers (e.g. those based on real-time protocol, i.e. RTP). Moreover, the group is also tasked with providing a means for application data streaming between browsers (i.e. opaque data streaming). Much like RTP synchronization sources (SSRC's) can be temporally synchronized, there are use cases that require opaque data stream synchronization with the real-time communications stream between browsers in an RTCWeb session. This document provides some options for temporally associating an opaque data stream with a voice/video stream as part of RTCWeb communications. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 30, 2013. Mandyam & Suryavanshi Expires January 30, 2013 [Page 1]
Internet-Draft RTCWeb Data Stream and RTP Synchronization July 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................2 2. SCTP-Based Data Streaming......................................3 2.1. SCTP Multi-Channel Impacts................................4 3. Opaque Data Synchronization and In-band RTP Signaling..........5 4. Security Considerations........................................7 5. IANA Considerations............................................7 6. Conclusions....................................................7 7. References.....................................................7 7.1. Normative References......................................7 7.2. Informative References....................................8 8. Acknowledgments................................................8 1. Introduction The RTCWeb effort seeks to define the necessary interoperability specifications required for real-time peer-to-peer communications sessions between browsers. These communications sessions normally involve multimedia data transmission (audio, video, or both). However, RTCWeb will also include the ability for web applications to initiate data streaming sessions between browsers. One of the recommended transports for audio or video in RTCWeb sessions is real-time protocol (RTP) [I-D.-rtcweb-rtp-usage]. An RCTWeb session can include one or more RTP streams, each stream identified by an SSRC (synchronization source) included in the RTP frame header. There has been some concern about whether existing mechanisms in RTP standards allow an RTP session endpoint to be able to render Mandyam & Suryavanshi Expires January 30, 2013 [Page 2]
Internet-Draft RTCWeb Data Stream and RTP Synchronization July 2012 multiple SSRC's in a time-synchronized manner [I-D.-draftalvestrand- rtcweb-msid]. As a result, several mechanisms have been proposed that would allow an RTCWeb endpoint to definitively determine which SSRC's are temporally synchronized and must be rendered as such. Assuming the problem of associating temporally-synchronized SSRC's will be solved by one of the proposed mechanisms, there still can be cases where an SSRC may have a temporal relationship with application-generated data that would also be streamed as part of the RTCWeb session. An example is video overlay based on web touch events during a video telephony session. In this case, a web application detects an animation over the video preview window (based on the end user drawing an image using the device touch surface), and is required to send such information to the RTCWeb endpoint so that the animation can be rendered. This document discusses three approaches to synchronization of data streams, along with associated recommendations. 2. SCTP-Based Data Streaming [I-D.-jesup-rtcweb-data-protocol] describes an approach that could be adopted in RTCWeb for data streaming, leveraging the Stream Control Transmission Protocol (SCTP), and [I-D.ietf-mmusic-sctp-sdp] provides the necessary extensions to Session Description Protocol (DSP) to describe an SCTP stream. SDP is the mechanism by which multimedia sessions are described RTCWeb, usually as part of the invite or call announce. The m-line in the SDP message (as per [I-D.ietf-mmusic-sctp-sdp]) should include sufficient information to describe the SCTP session (e.g. plain SCTP, SCTP over DTLS, etc.). For example, an SDP message from an offerer at address xxx.xx.xx.xx using port yyyyy for SCTP communication, then a possible SDP offer would include m=application yyyyy SCTP * c=IN IP4 xxx.xx.xx.xx If there is an additional RTP-based media source sent by the offerer that needs synchronization with the SCTP stream, the ideal case would be to leverage existing SDP grouping mechanisms. The mid attribute of RFC 5888 could potentially be leveraged: c=IN IP4 xxx.xx.xx.xx Mandyam & Suryavanshi Expires January 30, 2013 [Page 3]
Internet-Draft RTCWeb Data Stream and RTP Synchronization July 2012 a=group:LS 1 2 m=application yyyyy SCTP * a=mid:1 m=video zzzzz RTP/AVP a=mid:2 There are some issues with this approach, as highlighted in [I-D.draft- alvestrand-rtcweb-msid] (e.g. multiple SSRC's in each RTP stream). Nevertheless, SDP grouping can provide a sufficient solution to synchronizing the SCTP stream to an RTP stream as long as there is one SSRC per RTP stream. SDP grouping should also be applicable in the case where multiple SSRC's are part of the offer and are associated with a canonical name (CNAME), using the attribute guidelines of RFC 5576 (e.g. "a=ssrc:<ssrc-id> cname:<cname>" along with "a=mid:..."). 2.1. SCTP Multi-Channel Impacts [I-D.-jesup-rtcweb-data-protocol] provides an SCTP-encapsulated control protocol for the RTCWeb data channel that takes advantage of the multistreaming capabilities of SCTP. SCTP allows for individual stream identifiers and associated sequence numbers for any given data chunk. This allows for flow control on individual streams within an SCTP session. Streams are also further identified by a label attribute as defined in [I-D.-jesup-rtcweb-data-protocol] as part of the logical channel request. Since the streams are dynamic, to associate an SCTP stream at any given instant in time with an RTP session is not straightforward. In addition, SCTP can be multihomed, i.e. endpoints can be associated with more than one IP address. Some of the current unresolved issues are: a. Should the SDP attribute describing the data channel stream be based on logical channel label or SCTP stream ID? b. What is the required receiver behavior if the data channel stream identifier provided in the SDP offer does not match with information sent in-band? Note that a comparable issue also exists for RTP streams using CNAME and SSRC. In order to address these issues in a simpler manner, the following guideline is proposed for RTCWeb: the SDP grouping mechanism should not address individual streams within an SCTP session. In other words, once a temporal relationship is established between an RTP stream and an SCTP session, that relationship will apply to all streams in the SCTP session. Mandyam & Suryavanshi Expires January 30, 2013 [Page 4]
Internet-Draft RTCWeb Data Stream and RTP Synchronization July 2012 3. Opaque Data Synchronization and In-band RTP Signaling Web application generated data may have a temporal relationship with an RTP-based media stream, but if is relatively infrequent and therefore requires much less throughput than the media stream itself it could make more sense to multiplex the application-specific data into the RTP stream. Sec. 5.3.1 of RFC 3550 describes the RFC Header Extension mechanism, by which an application-specific payload can be inserted into an existing RTP stream without affecting the media flow. In the RTP header, and extension bit X can be set. This indicates the existence of an extension header. 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | defined by profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extension | | .... | Figure 1 : RTP Extension Header Referring to Figure 1, the value of 16-bit profile field in the extension header is implementation specific. This field could be used in place of the channel label in the SCTP-based data channel. Otherwise, this field can be ignored by the receiver. The signaling of the use of an extension header as the means of opaque data transfer could be agreed upon by the two RTCWeb endpoints by means of an offer/answer protocol like SDP. The outof- band signaling channel can be used to indicate to the receiver to create a data channel based on the RTP extension header. RFC 5576 can also be leveraged in this case using a new source-specific attribute 'data': a=ssrc:<ssrc-id> data The SDP exchange is not strictly required, however. This is because the SSRC of the RTP stream has already been negotiated, and the extension header is in fact really part of the RTP media stream data. Mandyam & Suryavanshi Expires January 30, 2013 [Page 5]
Internet-Draft RTCWeb Data Stream and RTP Synchronization July 2012 Ideally, a message-based Data Channel API from the WebRTC specification (see [W3C.WD-webrtc-20120530]) would be leveraged by the web application in such a way that the underlying user agent would multiplex application data onto an existing RTP stream using the RTP extension header. Borrowing from the JSEP messaging flow [ID.- rtcweb-jsep], the PeerConnection setup will proceed as normal from the offerer perspective: OffererJS->OffererUA: var pc = new PeerConnection(config, null); OffererJS->OffererUA: pc.onicecandidate = onIceCandidate; OffererJS->OffererUA: pc.addStream(stream); OffererJS->OffererUA: var offer = pc.createOffer(null); OffererJS->OffererUA: pc.setLocalDescription("offer", offer); ... Answerer creates PeerConnection and sends answer AnswererUA->OffererUA: <media> // Send opaque data from Offerer to Answerer OffererJS->OffererUA: var chan = pc.createDataChannel(10); // Numeric label means opaque data to be sent with extension header OffererJS->OffererUA: chan.send("Some Payload"); AnswererUA->OffererUA: <media> with extension header AnswererUA->AnswererJS: pc.ondatachannel = function({...}); // Answerer creates DataChannel listener on existing PeerConnection based upon firing of onDataChannel event OffererUA->OffererJS: datachannellistener.onmessage({}); Note that in the approach above, the creation of a data channel with a numeric label is what triggers the OffererUA to use the extension header. The numeric label can be directly sent as part of the profile field in the extension header (provided that the numeric label does not exceed 16 bits) The initial receipt of RTP data with an extension header triggers the onDataChannel event to fire from the AnswererUA. 3.1. Other Uses of the RTP Extension Header Section 5.2 of [I-D.-rtcweb-rtp-usage] clearly discusses (but does not call for requiring) additional uses of the RTP extension header. These uses include a rapid synchronization feature (which allows timing metadata to be inserted into the RTP stream), client-to-mixer audio level, and mixer-to-client audio level. The profile space Mandyam & Suryavanshi Expires January 30, 2013 [Page 6]
Internet-Draft RTCWeb Data Stream and RTP Synchronization July 2012 that may be consumed by these uses of the header extension can be avoided for RTCWeb logical data channels that also use the header extension. 4. Security Considerations TBD. 5. IANA Considerations TBD. 6. Conclusions The ability to send and receive opaque data streams that are syncronized to existing RTP media sessions will greatly enhance RTCWeb. It will open up a several new possibilities for user interactions around telephony sessions (video or voice). The existing specifications in both the W3C and IETF do not address how such a feature would be implemented. This document provided two methods for achieving this feature that leveraged as much as possible the specifications currently under consideration in RTCWeb and the W3C. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session DescriptionProtocol (SDP) Grouping Framework", RFC 5888, June 2010. Mandyam & Suryavanshi Expires January 30, 2013 [Page 7]
Internet-Draft RTCWeb Data Stream and RTP Synchronization July 2012 [RFC6222] Begen, A.,Perkins, C. and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names", RFC 6222, April 2011. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real Time Communications", RFC 3550, July 2003. [I-D.-rtcweb-rtp-usage] Perkins, C., Westerlund, M. and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-03, June 2012. [W3C.WD-webrtc-20120530] Bergkvist, A., Burnett, D., Narayanan, A., and C. Jennings, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc20120209, Editor's Draft, 30 May 2012. [I-D.-rtcweb-jsep] Uberti, J. and C. Jennings, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-01, June 2012. 7.2. Informative References [I-D.-jesup-rtcweb-data-protocol] Jesup, R., Loreto, S. and M. Tuexen, "WebRTC Data Channel Protocol", draft-jesuprtcweb- data-protocol-01, June 2012. [I-D.-draft-alvestrand-rtcweb-msid] Alverstand, H., "Cross Session Stream Identification in the Session Description Protocol", draft-alvestrand-rtcweb-msid-02, May 2012. [I-D.ietf-mmusic-sctp-sdp] Loreto, S. and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietfmmusic- sctp-sdp-01(work in progress), March 2012. 8. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Mandyam & Suryavanshi Expires January 30, 2013 [Page 8]
Internet-Draft RTCWeb Data Stream and RTP Synchronization July 2012 Authors' Addresses Giridhar Mandyam Qualcomm Innovation Center 5775 Morehouse Drive San Diego, CA 92121 USA Email: mandyam@quicinc.com Vijay Suryavanshi Qualcomm Inc. 5775 Morehouse Drive San Diego, CA 92121 USA Email: vsuryava@qualcomm.com Mandyam & Suryavanshi Expires January 30, 2013 [Page 9]