WebRTC Realization in Desktop Cloud

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.

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. 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.

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)| +--------+ +--------+ 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.

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 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.

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.

This document contains no IANA considerations.

Not explicitly covered in this version.