-
Notifications
You must be signed in to change notification settings - Fork 22
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
initial draft for evaluating Data Channel as the transport protocol.
- Loading branch information
Showing
1 changed file
with
174 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,174 @@ | ||
# Data Channel | ||
|
||
[Data Channel](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13) | ||
is a non-media transport protocol in WebRTC framework, designed for exchanging | ||
data from peer to peer. It advertises the following benefits: | ||
|
||
- Implemented in major browsers (except Safari) | ||
- Supports heterogeneous network environment e.g. NAT, firewall. | ||
- Easily supports media transport for remote playback | ||
- Data framing format is already defined | ||
|
||
# Design and Specification | ||
|
||
- [WebRTC overview](https://tools.ietf.org/html/draft-ietf-rtcweb-overview-18) | ||
- IETF draft: [WebRTC Data Channel Establishment Protocol](https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09) | ||
- IETF draft: [Data Channel](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13) | ||
|
||
# Presentation API functionality | ||
|
||
Data Channel is designed to be a non-media transport for WebRTC, with built-in | ||
sub protocol negotiation mechanism defined. | ||
|
||
A Data Channel is built on top of SCTP/DTLS/UDP protocol stack, which supports | ||
reliable data transmition. Each Data Channel has a unique integer ID and a label. | ||
Mutiple Data Channels can share the same DTLS connection. | ||
|
||
Assume that a single Data Channel is used as a control channel to transmit control | ||
messages between the controller and receiver and one Data Channel is created for each | ||
connected Presentation Connection for transmitting application data. | ||
|
||
An extra signalling channel and protocol for exchanging ICE candidates is required | ||
to bootstrap the control channel. The bootstrapping procedure needs to be executed | ||
for the first connecting to that receiver before the Presentation Initiation. | ||
|
||
## Presentation Initiation | ||
|
||
1. Send a control message on control channel from the controller to the display to | ||
start the presentation with ID and URL for the initial presentation connection. | ||
2. Receiver spawn a Data Channel on the same RTC connection of control channel, with | ||
presentation ID as label. | ||
3. Get a reply on control channel with the ID and URL to confirm success | ||
(or report an error). | ||
|
||
## Presentation Resumption | ||
|
||
1. Send a control message on control channel from the controller to the display | ||
reconnect to a presentation with ID and URL for the initial presentation connection. | ||
2. Receiver spawn a Data Channel on the same RTC connection of control channel, with | ||
presentation ID as label, if there is a corresponding presentation to be resumed. | ||
2. Get a reply on control channel with the ID, URL, and stream ID to confirm success | ||
(or report an error). | ||
|
||
## Presentation Connections | ||
|
||
Multiple connections from a controller can be handled by creating unique Data | ||
Channels for each peer. Unique stream ID will be selected for muxing/demuxing | ||
messages on the underlying SCTP transport, see | ||
[draft-ietf-rtcweb-data-protocol-09](https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09#section-6). | ||
|
||
## Presentation Connection Messaging | ||
|
||
Binary or text messages can be sent on the Data Channel corresponding to the | ||
presentation connection. The framing of these messages is defined in | ||
[draft-ietf-rtcweb-data-channel](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.6). | ||
|
||
Either side may close the Presentation Connection by following procedure: | ||
1. Send a control message with close reason on control channel to remote peer. | ||
2. While receiving the control message, initiate the | ||
[Data Channel close procedure](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.6) | ||
3. Consider Presentation Connection is closed while Data Channel is closed. | ||
|
||
## Presentation Termination | ||
|
||
For controller initiated termination: | ||
1. A controller send a control message with URL and ID on control channel to | ||
instruct a display to terminate a presentation. | ||
2. The receiver sends a reply to all associated control channels to inform all | ||
remote peers that a presentation is about to be terminated. | ||
|
||
For receiver initiated termination: | ||
1. The receiver directly sends out reply to all associated control channels to | ||
inform all remote peers that a presentation is about to be terminated. | ||
|
||
# Remote Playback API functionality | ||
|
||
WebRTC framework supports media codec negociation and real-time media transport. | ||
|
||
**TODO:** Fill in when Remote Playback equirements are known. | ||
See [Issue #3](https://github.com/webscreens/openscreenprotocol/issues/3). | ||
|
||
# Reliability | ||
|
||
WebRTC is designed to be operated on heterogeneous network environment, using | ||
ICE for address discovery and built-in negotiation/re-negotiation mechanism. | ||
|
||
*TODO:* Get reliability data. | ||
|
||
# Latency to establish a new connection | ||
|
||
There are three sources of latency: | ||
1. Connecting a reliable channel the first time for for ICE negotiation. | ||
2. Establishing the first Data Channel. | ||
3. Adding an additional Data Channel on top of an existing peer-to-peer connection. | ||
|
||
*TODO:* Get connection latency data. | ||
|
||
# Latency to transmit a messages | ||
|
||
Data on latency of message transmission. | ||
|
||
Data Channel is based on SCTP, which allows for out of order packet delivery and | ||
may improve the latency to deliver presentation connection messages on a | ||
congested or lossy network. | ||
|
||
*TODO:* Get supporting data. | ||
|
||
# Ease of implementation / deployment | ||
|
||
Four major browsers (Chrome/Firefox/Edge/Opera) already implement and ship in | ||
the latest release version. An open source library [WebRTC.org](https://webrtc.org/) | ||
is ready with production level quality. | ||
|
||
A common signaling channel/protocol for exchanging ICE candidates needs to be defined. | ||
|
||
# Privacy | ||
|
||
By relying on UDP, the IP addresses of both endpoints are visible to network | ||
observers. | ||
|
||
DTLS is used for transport level security. Once DTLS is established, all the | ||
control message and data will be encrypted. | ||
|
||
# IPv4 and IPv6 support | ||
|
||
Data Channel depends on SCTP over UDP, which is supported for both IPv4 and IPv6. | ||
|
||
# Hardware requirements | ||
|
||
Major desktop, laptop, and high-end mobile phone should be able to create single | ||
RTC connection since major browser on desktop and mobile already ship WebRTC. | ||
|
||
*TODO*: Obtain data on hardware requirements | ||
|
||
# Network and power efficiency | ||
|
||
Maintain a long-lived Data Channel might not be power efficiency. | ||
|
||
*TODO*: Obtain data on network and power efficiency | ||
|
||
# Standardization status | ||
|
||
Data Channel has a standards track specification in the | ||
IETF [RTCWEB Working Group](https://datatracker.ietf.org/wg/rtcweb/charter/). | ||
|
||
Major browsers already implement and ship with interoperability tested. | ||
|
||
# Security | ||
|
||
Describe security architecture and what encryption and authentication mechanisms | ||
are supported. | ||
|
||
A general security study has be done by IETF RTCWEB working group, see | ||
[Security Overview](https://tools.ietf.org/html/draft-ietf-rtcweb-overview-18#section-5) | ||
|
||
Signaling channel for exchanging SDP must be encrypted to prevent man-in-the-middle | ||
attack. | ||
DTLS handshake for exchanging encryption key and setup encrypted channel for SCTP. | ||
STUN keepalive can be introduced for consent freshness. | ||
Identity Provider can be introduced for external authentication. | ||
|
||
|
||
# User Experience | ||
|
||
*TODO*: To be evaluated |