Internet DRAFT - draft-yan-rtcweb-desktop-cloud
draft-yan-rtcweb-desktop-cloud
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]
