WebRTC DataChannels demystified

102,193 views
101,767 views

Published on

WebRTC DataChannels demystified

Published in: Technology
0 Comments
18 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
102,193
On SlideShare
0
From Embeds
0
Number of Embeds
299
Actions
Shares
0
Downloads
159
Comments
0
Likes
18
Embeds 0
No embeds

No notes for slide

WebRTC DataChannels demystified

  1. 1. WebRTC DataChannels Demystified
  2. 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. 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. 4. The uncomfortable question Please, raise your hand if you think that WebRTC is only about voice and video communication on the web
  5. 5. 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
  6. 6. The Web Architecture Client-to-Client communication is in fact Client-to-Server-to-Client
  7. 7. WebRTC goes beyond voice and video As well as audio and video, WebRTC supports real-time communication for other types of data
  8. 8. 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’)
  9. 9. •  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
  10. 10. 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
  11. 11. 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
  12. 12. Takeaway #1 “As well as audio and video, WebRTC supports real-time communication for other types of data”
  13. 13. Data Channel Architecture Data / DataChannel protocol SCTP provides congestion and flow control DTLS provides security ICE/UDP provides transport through NATs
  14. 14. 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
  15. 15. Takeaway #2 “SCTP over DTLS over ICE provides a NAT traversal solution together with confidentiality, source authentication, and integrity protected transfers”
  16. 16. 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)
  17. 17. Takeaway #3 “ICE provides NAT traversal and enables peer-to-peer connections”
  18. 18. 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
  19. 19. Takeaway #4 “DTLS is the TLS version for datagram-based protocols (e.g. UDP)”
  20. 20. 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).
  21. 21. 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
  22. 22. Takeaway #5 “SCTP combines the best of TCP with the best of UDP”
  23. 23. 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
  24. 24. Takeaway #6 “WebRTC defines a simple in-band method to open symmetric data channels”
  25. 25. Case study: e-health
  26. 26. We have a better plan!
  27. 27. Sounds cool but… how about my appointment?
  28. 28. 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
  29. 29. Takeaway #7 “Data Channel enables implementation of use cases going beyond voice and video”
  30. 30. 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)
  31. 31. MORE   INFORMATION   VICTOR  PASCUAL   Chief  Strategy  Officer   victor.pascual@quobis.com   TwiLer:    @victorpascual  
  32. 32. BACKUP SLIDES
  33. 33. How does it work? Let’s take a simple use-case Source code: https://github.com/samdutton/simpl/blob/master/rtcdatachannel/js/main.js
  34. 34. 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
  35. 35. 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

×