WebRTC DataChannels demystified

1. WebRTC DataChannels Demystified

2. About QUOBIS
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.

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

4. The uncomfortable question
Please, raise your hand if you
think that
WebRTC is only about voice
and video communication on
the web

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

7. The Web Architecture
Client-to-Client communication is in fact Client-to-Server-to-Client

8. WebRTC goes beyond voice and video
As well as audio and video, WebRTC supports real-time
communication for other types of data

9. 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’)

11. • 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
- Peer-to-Peer
• Browser-cache sharing
- Encrypted by default
• CDN
- Built-in NAT traversal
• Distributed databases
• Anonymous services
• Other decentralized networks
• e-Health

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

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

15. Takeaway #1
“As well as audio and video, WebRTC
supports real-time communication for other
types of data”

16. Data Channel Architecture
Data / DataChannel protocol
SCTP
provides congestion and flow control
DTLS
provides security
ICE/UDP
provides transport through NATs

17. 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 draftietf-tsvwg-sctp-dtls-encaps
• SDP negotiation of this transport is defined in draft-ietfmmusic-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

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

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

20. Takeaway #3
“ICE provides NAT traversal
and enables peer-to-peer connections”

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

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

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

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

25. Takeaway #5
“SCTP combines the best of TCP
with the best of UDP”

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

27. Takeaway #6
“WebRTC defines a simple in-band
method to open symmetric data
channels”

28. Case study: e-health

29. We have a better plan!

30. Sounds cool but… how about my appointment?

31. You can do that remotely!
Voice and Video
Screensharing, file transfer, presence
and IM
Data
Management and
exchange of
sensor-captured
data over a peer-topeer, secure and
reliable channel

32. Takeaway #7
“Data Channel enables implementation
of use cases going beyond voice and
video”

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

34. MORE
INFORMATION
VICTOR
PASCUAL
Chief
Strategy
Officer
victor.pascual@quobis.com
TwiLer:
@victorpascual

35. BACKUP SLIDES

36. How does it work? Let’s take a simple use-case
Source code: https://github.com/samdutton/simpl/blob/master/rtcdatachannel/js/main.js

38. SDP Offer
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

39. SDP Answer
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