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 [email protected]
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)
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