WebRTC DataChannels Demystified

Quobis is a leading european company in the delivery of carrier-class unified communication solutions with a special focus on security, interconnection and identity management for service providers and enterprises.

 Seven  years  working  on  VoIP  projects.  Three  years  developing  own  products.  

About QUOBIS

About Me victor.pascual@quobis.com

Victor Pascual – Chief Strategy Officer (CSO) at Quobis Main focus: help make WebRTC happen – involved in WebRTC standardization, development and first industry deployments (on-going RFX's, PoC's and field trials) Side activities: - IETF contributor (SIP, Diameter and WebRTC areas) - IETF STRAW WG co-chair - SIP Forum WebRTC Task Group co-chair - WebRTCHacks.com co-founder and blogger - Independent Expert at European Commission and several industry boards

@victorpascual

The uncomfortable question

Please, raise your hand if you think that

WebRTC is only about voice and video communication on

the web

Agenda for today

•  How WebRTC changes the nature of the web

•  WebRTC Data Channel Use Cases

•  WebRTC Data Channel API (W3C)

•  WebRTC Data Channel architecture and protocols (IETF)

•  Case study: e-health

•  Conclusions and observations from early experimentation

The Web Architecture

Client-to-Client communication is in fact Client-to-Server-to-Client

WebRTC goes beyond voice and video

As well as audio and video, WebRTC supports real-time communication for other types of data

WebRTC enables peer-to-peer data transfer

WebRTC Client-to-Client communication is Peer-to-Peer (sure, your service might need a server to do initial ‘user discovery’)

•  Enables peer-to-peer exchange of arbitrary (non-media) data

•  Secure way •  with low latency •  high throughput

•  Use-cases •  Gaming •  Real-time text chat •  Remote desktop applications •  File-sharing •  Browser-cache sharing •  CDN •  Distributed databases •  Anonymous services •  Other decentralized networks •  e-Health

- Peer-to-Peer - Encrypted by default - Built-in NAT traversal

W3C Peer-to-Peer data API (1/2)

•  The API for sending and receiving data models the behavior of WebSockets

•  The WebRTC Peer Connection makes a direct connection between two browsers so they can pass data between them

•  The Data Channel allows the passing of arbitrary data across this connection

•  A RTCDataChannel is created via a factory method on an RTCPeerConnection object

•  There are two ways to establish a connection with RTCDataChannel

•  in-band vs out-of-band •  Each RTCDataChannel has an associated underlying data

transport that is used to transport actual data to the other peer •  The transport properties of the underlying data transport,

such as in order delivery settings and reliability mode, are configured by the peer as the channel is created

W3C Peer-to-Peer data API (2/2)

•  A RTCDataChannel can be configured to operate in different reliability modes

•  A reliable channel ensures that the data is delivered at the other peer through retransmissions

•  An unreliable channel is configured to either limit the number of retransmissions (maxRetransmits) or set a time during which retransmissions are allowed (maxRetransmitTime)

•  These properties can not be used simultaneously •  Reliable channel default mode

•  Supports most generic forms of data including strings, blobs, and array data

•  Ability to use with or without audio or video

Takeaway #1

“As well as audio and video, WebRTC supports real-time communication for other

types of data”

Data Channel Architecture

SCTP

DTLS

ICE/UDP

provides congestion and flow control

provides security

provides transport through NATs

Data / DataChannel protocol

Data Channel considerations

•  Considerations for the transfer of WebRTC data that is not in RTP format is described in draft-ietf-rtcweb-data-channel

•  draft-ietf-rtcweb-data-protocol defines a light protocol for ‘setup’

•  the usage of SCTP on top of DTLS is specified in draft-ietf-tsvwg-sctp-dtls-encaps

•  SDP negotiation of this transport is defined in draft-ietf-mmusic-sctp-sdp

•  This data transport service operates in parallel to the media transports, and all of them can eventually share a single transport-layer port number

•  multiplexing of DTLS and RTP over the same port pair

Takeaway #2

“SCTP over DTLS over ICE provides a NAT traversal solution together with confidentiality, source authentication, and integrity protected transfers”

ICE/UDP: provides transport through NAT

•  Interactive Connectivity Establishment •  RFC 5245 •  Protocol for Network Address Translator

(NAT) traversal for UDP-based multimedia sessions established with the offer/answer model

•  makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN)

•  ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP)

Takeaway #3

“ICE provides NAT traversal and enables peer-to-peer connections”

DTLS: provides security

•  Datagram Transport Layer Security •  Provides communications privacy for

datagram protocols

•  RFC 6347 defines DTLS v1.2 protocol •  Based on Transport Layer Security (TLS) and

provides equivalent security guarantees •  confidentiality, source authenticated, and

integrity protected transfers •  prevent eavesdropping, tampering, or

message forgery

Takeaway #4

“DTLS is the TLS version for datagram-based protocols (e.g. UDP)”

SCTP: provides congestion and flow control

•  Stream Control Transmission Protocol (RFC 4960)

•  Originally designed by the Signaling Transport (SIGTRAN) group of IETF for Signalling System 7 (SS7) transport over IP-based networks

•  It is a reliable transport protocol operating on top of unreliable connectionless service, such as IP

•  It provides acknowledged, error-free, non-duplicated transfer of messages through the use of checksums, sequence numbers, and selective retransmission mechanism

•  Used as a transport for SIGTRAN, BICC, SIP (well, SIP-I) and Diameter protocols

•  SCTP supports multiple streams known as multi-streaming within an association (prevents TCP’s HOLB problem), and hosts with multiple network addresses known as multi-homing (not used in WebRTC).

SCTP: provides congestion and flow control

•  It has inherited much of its behavior from TCP; provides association (connection) setup, congestion control and packet-loss detection algorithms

•  SCTP delivers discrete application messages within multiple logical streams in a single association.

•  This approach to data delivery is more flexible than the single byte-stream used by TCP, as messages can be ordered, unordered or even unreliable within the same association

•  SCTP congestion control mechanism includes slow start, congestion avoidance, and fast retransmit

•  the initial congestion window (cwnd) is set to the double of the maximum transmission unit (MTU) while in TCP, it is usually set to one MTU.

•  In SCTP, cwnd increases based on the number of acknowledged bytes, rather than the number of acknowledgements in TCP.

•  The larger initial cwnd and the more aggressive cwnd adjustment contribute the larger average congestion window and, hence, better throughput performance of SCTP than TCP

Takeaway #5

“SCTP combines the best of TCP with the best of UDP”

DataChannel protocol

•  Simple protocol for establishing symmetric data channels between the peers over an SCTP association

•  reliable vs unreliable (full vs partial reliability) •  in-order vs out-of-order •  outgoing SCTP stream •  optional label and protocol

•  Specified in draft-ietf-rtcweb-data-protocol •  It uses a two way handshake

•  DATA_CHANNEL_OPEN •  DATA_CHANNEL_ACK

•  It allows sending of user data without waiting for the handshake to complete

•  Channels are closed by reseting the stream

Takeaway #6

“WebRTC defines a simple in-band method to open symmetric data

channels”

Case study: e-health

We have a better plan!

Sounds cool but… how about my appointment?

You can do that remotely!

Data Management and exchange of sensor-captured data over a peer-to-peer, secure and reliable channel

Screensharing, file transfer, presence and IM

Voice and Video

Takeaway #7

“Data Channel enables implementation of use cases going beyond voice and

video”

Conclusions

•  Traditional web architecture is client-to-server

•  WebRTC changes the nature of the web •  Using datachannel one can send arbitrary data between browsers •  Peer-to-Peer (ICE) •  Secure (DTLS) •  Reliable or unreliable transport (SCTP) •  Simple WebSocket-style API

•  All the above enables innovative use cases •  note WebRTC is not only about web

•  Observations from early datachannel experimentation

•  Inmature implementations (work-in-progress) •  Might represent an implementation overkill (SCTP/DTLS/ICE) in some

scenarios •  interworked scenario where WebRTC GW is terminating datachannel and

using TCP in the core (e.g. MSRP or BFCP access for 3GPP IMS networks)

•  WebSockets (over TCP/TLS) is a more pragmatic approach for client-server •  it works also with non-webrtc browsers •  but one needs to implement some features (e.g. H-NAT traversal)

MORE  INFORMATION  

VICTOR  PASCUAL  Chief  Strategy  Officer  

victor.pascual@quobis.com  TwiLer:    @victorpascual  

BACKUP SLIDES

How does it work? Let’s take a simple use-case

Source code: https://github.com/samdutton/simpl/blob/master/rtcdatachannel/js/main.js

252.208: Offer from localPeerConnection v=0 o=- 2569489027771196355 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio data a=msid-semantic: WMS m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:EBhn9VwjB72R+j0q a=ice-pwd:6cmpfp4+4MiFIDGrKN7CD+W6 a=ice-options:google-ice a=fingerprint:sha-256 7C:56:6F:B3:0C:78:D8:AC:02:80:BE:B1:26:A4:3E:ED:4A:B1:DB:2C:0B:0D:2A:24:92:C1:10:A7:49:61:71:5E a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=recvonly a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:C9emVPDdM4e+z8ZWdpOWqB07GsDMqoD8Al79K+Gl a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 m=application 1 RTP/SAVPF 101 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:EBhn9VwjB72R+j0q a=ice-pwd:6cmpfp4+4MiFIDGrKN7CD+W6 a=ice-options:google-ice a=fingerprint:sha-256 7C:56:6F:B3:0C:78:D8:AC:02:80:BE:B1:26:A4:3E:ED:4A:B1:DB:2C:0B:0D:2A:24:92:C1:10:A7:49:61:71:5E a=setup:actpass a=mid:data a=sendrecv b=AS:30 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:C9emVPDdM4e+z8ZWdpOWqB07GsDMqoD8Al79K+Gl a=rtpmap:101 google-data/90000 a=ssrc:4081518990 cname:OJgRdybEn9VgrK+1 a=ssrc:4081518990 msid:sendDataChannel sendDataChannel a=ssrc:4081518990 mslabel:sendDataChannel a=ssrc:4081518990 label:sendDataChannel

SDP Offer

252.217: Answer from remotePeerConnection v=0 o=- 4013528059489252062 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio data a=msid-semantic: WMS m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:bCGmBz4uhZNjkHGX a=ice-pwd:C7J0D7g04jxXQRWerTDHGs0o a=fingerprint:sha-256 7C:56:6F:B3:0C:78:D8:AC:02:80:BE:B1:26:A4:3E:ED:4A:B1:DB:2C:0B:0D:2A:24:92:C1:10:A7:49:61:71:5E a=setup:active a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendonly a=rtcp-mux a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 m=application 1 RTP/SAVPF 101 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:bCGmBz4uhZNjkHGX a=ice-pwd:C7J0D7g04jxXQRWerTDHGs0o a=fingerprint:sha-256 7C:56:6F:B3:0C:78:D8:AC:02:80:BE:B1:26:A4:3E:ED:4A:B1:DB:2C:0B:0D:2A:24:92:C1:10:A7:49:61:71:5E a=setup:active a=mid:data a=sendrecv b=AS:30 a=rtcp-mux a=rtpmap:101 google-data/90000 a=ssrc:2117514729 cname:5NJts5L7OsoxZGm9 a=ssrc:2117514729 msid:sendDataChannel sendDataChannel a=ssrc:2117514729 mslabel:sendDataChannel a=ssrc:2117514729 label:sendDataChannel

SDP Answer