RTCWeb WG M. Yan Internet-Draft X. Chen Intended status: Informational Huawei Technologies Co., Ltd. Expires: March 16, 2013 September 12, 2012 WebRTC Realization in Desktop Cloud draft-yan-rtcweb-desktop-cloud-00.txt Abstract The Web Real-time Communications (WebRTC) provides the communication capabilities for real-time and peer-to-peer web-based applications. This draft is meant to provide the structure for an idea of how WebRTC works on the desktop cloud solution and gives guidance on how to overcome the issues and challenges in implementing and deploying. Also as discussed in the mail archive before, the use case for desktop cloud or remote desktop sharing is suggested to be delayed after WebRTC version 1. So this draft is very early and far from done. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 16, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Yan & Chen Expires March 16, 2013 [Page 1] Internet-Draft WebRTC Realization in Desktop Cloud September 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Common desktop cloud device and their properties . . . . . . . 3 3. Specific issues and how to deal with them . . . . . . . . . . . 4 3.1. RTP lag . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Data channel . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. SDP negotiation . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Yan & Chen Expires March 16, 2013 [Page 2] Internet-Draft WebRTC Realization in Desktop Cloud September 2012 1. Introduction The Web Real-time Communications (WebRTC) provides the communication capabilities for real-time and peer-to-peer web-based applications. This document describes how WebRTC can be implemented in the desktop cloud solution, including support for WebRTC application separating, data channel between remote peer and local system and SDP negotiation for two remote peers. The desktop cloud enables users to access cross-platform applications and even the entire desktop through the remote peer which known as thin clients (TCs) or any other devices connected to the Internet. In many cases users use the browser in TCs to visit the local system which known as network computers (NCs) in the desktop cloud servers. WebRTC should be supported in this scene. For the "Web Real-Time Communication Use-cases and Requirements" 4.2.8 has illustrated the screen sharing for simple video communication service, this document focuses on the remote desktop sharing for audio and video in the cloud desktop solution. Section 2 of this document gives an overview of the characteristics of common desktop cloud device as background for further discussion. Section 3 introduces the specific issues that WebRTC protocols and applications should take into consideration in implementing the desktop cloud. The current version of the document misses all references and lot of details. It may have some errors. Its purpose is to get attention to the topics it raises and start discussion about them. 2. Common desktop cloud device and their properties The most relevant desktop cloud device for WebRTC is the desktop cloud terminal and the applications running on it. Many characteristics of the desktop cloud device are covered in Section 3 in the context of the particular issues under discussion. The following is the very brief description of common desktop cloud device and the applications running on it. The desktop cloud terminal built on the basis of virtual networking technology can be divided into two parts: the network computers (NCs) which can be considered as local system and thin clients (TCs) which can be considered as the remote peer. The remote peer can control the local system through kind of remote desktop sharing protocol by one or more input types such as mouse and keyboard. Thus the browser or other system resources on local system can be accessed by the remote peer. Yan & Chen Expires March 16, 2013 [Page 3] Internet-Draft WebRTC Realization in Desktop Cloud September 2012 When a native VoIP application installed on NCs, it offers the audio and video features to users by using the input/output device on the TCs. The virtualization tier of NCs can encode the RTP stream which is sent to TCs through the remote desktop sharing protocol. The virtualization tier of TCs then decodes the RTP stream to export to its output device. The SDP negotiation could be done between two NCs for their own TCs. 3. Specific issues and how to deal with them 3.1. RTP lag In the desktop cloud solution, the media stream would have one extra codec operation from NCs to TCs as described in Section 2. NCs will decode the RTP stream received from the other NCs and encode it through its virtualization tier before sending to TCs. The one extra codec operation will cause the obvious lag between the data transfer and media transfer. +--------+ +--------+ | TC1 | | TC2 | +--+--+--+ +--+--+--+ media tracks | ^ media tracks media tracks ^ | media tracks (before coding)| |(after decoding) (after decoding)| |(before coding) V | | V +--+--+--+ media steam +--+--+--+ | NC1 | (after coding) | NC2 | |(WebRTC)|< ----------------------- >|(WebRTC)| +--------+ +--------+ Figure 1: Data and media Non-seperating Architecture Thus, to make the WebRTC application used on cloud desktop terminal appropriately, we need to separate the WebRTC application into two parts: part1 on the TCs is the presentation tier and the interface tier, and part2 on the NCs is the business logic tier. Here TCs do the media stream transferring through their browsers, while NCs do the other stream transferring through their browsers, like data, files or session negotiation control signals. Yan & Chen Expires March 16, 2013 [Page 4] Internet-Draft WebRTC Realization in Desktop Cloud September 2012 +----------------+ Media Stream +----------------+ | TC1 | (after coding) | TC2 | | (WebRTC part1) |< -------------------- > | (WebRTC part1) | +----------------+ +----------------+ ^ ^ | Message | Message | exchange between | exchange between | two part of | two part of | WebRTC | WebRTC V V +----------------+ +----------------+ | NC1 | Other Stream | NC2 | | (WebRTC part2) |< -------------------- > | (WebRTC part2) | +----------------+ +----------------+ Figure 2: Data and media Seperating Architecture 3.2. Data channel Some interactive messages are needed between NCs and TCs. These messages could be divided into two types. One is control message, which is used by NCs to control the multi-media communication process in TCs and get feedback from WebRTC application in TCs. The other is negotiation message, which is used for negotiating the media and transporting information between two TCs. In WebRTC, these messages are encapsulated in SDP. TCs should exchange SDP through NCs, because WebRTC application in TCs is acted as a part of WebRTC application in NCs. It is not suggested for TCs to communicate with each other by themselves. So the data channel between TCs and NCs is necessary. Now the data channel in the desktop cloud between TC and NC are the remote desktop sharing protocols such as VNC/ICA/PCoIP/RDP etc. These remote desktop sharing protocols are open-sourced or private protocols which are not suggested to be used for messages transferring between WebRTC applications. So here is the second issue for two WebRTC applications on cloud desktop: the data channel establishment between the two part of WebRTC applications in TCs and NCs. The SCTP based data channel in WebRTC could be used for this requirement. There are some optional methods to use the data channel. One is establishing a new data channel between NCs and TCs. That means a new WebRTC application is needed in both NCs and TCs. This new WebRTC application is just responsible for the message exchange between NCs and TCs. Another one is integrating the data channel between TCs and NCs into the WebRTC ability. Although the WebRTC application in NCs and TCs are two different entities, the WebRTC application in TCs is under the Yan & Chen Expires March 16, 2013 [Page 5] Internet-Draft WebRTC Realization in Desktop Cloud September 2012 control of the WebRTC application in NCs. They should be considered as a whole application, but have been divided to two parts and run in two browsers. If the WebRTC can support to establish an additional data channel between these two applications, it will be a better way to solve the message exchange issue between NCs and TCs. 3.3. SDP negotiation The deployment of separated WebRTC applications on cloud desktop device provides two methods for SDP negotiation between TCs. One is to keep TCs and NCs as entire entity that TC1/TC2's SDP information should be transferred to NC1/NC2 through the data channel mentioned in 3.2. NCs do the negotiation under the proxy of WebRTC Web server. Another is TCs do the SDP negotiation by themselves which is not suggested because TCs only allowed for media stream transferring. +----------------+ +----------------+ | TC1 | | TC2 | | (WebRTC part1) | | (WebRTC part1) | +----------------+ +----------------+ ^ ^ | Session | Session | Negotitaion message | Negotitaion message | between | between | TC1 and TC2 | TC1 and TC2 V V +----------------+ +----------------+ | NC1 | | NC2 | | (WebRTC part2) | | (WebRTC part2) | +----------------+ +----------------+ \ / \ / \ Relay Session / \ Negotitaion / \ message / +-----------------+ | Web Server | +-----------------+ Figure 3: SDP Negotiation Between TCs 4. IANA Considerations This document contains no IANA considerations. Yan & Chen Expires March 16, 2013 [Page 6] Internet-Draft WebRTC Realization in Desktop Cloud September 2012 5. Security Considerations Not explicitly covered in this version. 6. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Michael Yan Huawei Technologies Co., Ltd. Hangzhou, P.R.China Email: michael.yan@huawei.com Chen Xin Huawei Technologies Co., Ltd. Hangzhou, P.R.China Email: hangzhou.chenxin@huawei.com Yan & Chen Expires March 16, 2013 [Page 7]