SlideShare a Scribd company logo
1 of 41
Download to read offline
WebRTC DataChannels Demystified
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.	
  
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
- Peer-to-Peer
•  Browser-cache sharing
- Encrypted by default
•  CDN
- Built-in NAT traversal
•  Distributed databases
•  Anonymous services
•  Other decentralized networks
•  e-Health
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

Data / DataChannel protocol

SCTP

provides congestion and flow control

DTLS

provides security

ICE/UDP

provides transport through NATs
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
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 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
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!

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
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
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
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
WebRTC DataChannels demystified
WebRTC DataChannels demystified

More Related Content

What's hot

User datagram protocol
User datagram protocolUser datagram protocol
User datagram protocol
Mohd Arif
 
Voice over IP (VoIP)
Voice over IP (VoIP)Voice over IP (VoIP)
Voice over IP (VoIP)
Peter R. Egli
 

What's hot (20)

Intro to Single / Two Rate Three Color Marker (srTCM / trTCM)
Intro to Single / Two Rate Three Color Marker (srTCM / trTCM)Intro to Single / Two Rate Three Color Marker (srTCM / trTCM)
Intro to Single / Two Rate Three Color Marker (srTCM / trTCM)
 
RIP RTCP RTSP
RIP RTCP RTSPRIP RTCP RTSP
RIP RTCP RTSP
 
RTP
RTPRTP
RTP
 
User datagram protocol
User datagram protocolUser datagram protocol
User datagram protocol
 
Rtsp
RtspRtsp
Rtsp
 
What Is User Datagram Protocol?
What Is User Datagram Protocol?What Is User Datagram Protocol?
What Is User Datagram Protocol?
 
RTCP
RTCPRTCP
RTCP
 
Voice over IP (VoIP)
Voice over IP (VoIP)Voice over IP (VoIP)
Voice over IP (VoIP)
 
Introduction into SIP protocol
Introduction into SIP protocolIntroduction into SIP protocol
Introduction into SIP protocol
 
SIP over TLS
SIP over TLSSIP over TLS
SIP over TLS
 
Chap 12 tcp
Chap 12 tcpChap 12 tcp
Chap 12 tcp
 
TCP congestion control
TCP congestion controlTCP congestion control
TCP congestion control
 
Transport Layer in Computer Networks (TCP / UDP / SCTP)
Transport Layer in Computer Networks (TCP / UDP / SCTP)Transport Layer in Computer Networks (TCP / UDP / SCTP)
Transport Layer in Computer Networks (TCP / UDP / SCTP)
 
TCP/IP Basics
TCP/IP BasicsTCP/IP Basics
TCP/IP Basics
 
BGP Update Source
BGP Update Source BGP Update Source
BGP Update Source
 
HTTP & HTTPS
HTTP & HTTPSHTTP & HTTPS
HTTP & HTTPS
 
WebRTC on Mobile
WebRTC on MobileWebRTC on Mobile
WebRTC on Mobile
 
Presentation on TCP/IP Model
Presentation on TCP/IP ModelPresentation on TCP/IP Model
Presentation on TCP/IP Model
 
Introduction To Webrtc
Introduction To WebrtcIntroduction To Webrtc
Introduction To Webrtc
 
HIGH SPEED NETWORKS
HIGH SPEED NETWORKSHIGH SPEED NETWORKS
HIGH SPEED NETWORKS
 

Viewers also liked

Viewers also liked (6)

WebRTC for Managers!
WebRTC for Managers!WebRTC for Managers!
WebRTC for Managers!
 
Setup ephemeral password for TURN, Learn RTC in less than 200 Lines of code
Setup ephemeral password for TURN, Learn RTC in less than 200 Lines of codeSetup ephemeral password for TURN, Learn RTC in less than 200 Lines of code
Setup ephemeral password for TURN, Learn RTC in less than 200 Lines of code
 
Overview of SCTP (Stream Control Transmission Protocol)
Overview of SCTP (Stream Control Transmission Protocol)Overview of SCTP (Stream Control Transmission Protocol)
Overview of SCTP (Stream Control Transmission Protocol)
 
Overview of SCTP (Stream Control Transmission Protocol)
Overview of SCTP (Stream Control Transmission Protocol)Overview of SCTP (Stream Control Transmission Protocol)
Overview of SCTP (Stream Control Transmission Protocol)
 
WebRTC + Socket.io: building a skype-like video chat with native javascript
WebRTC + Socket.io: building a skype-like video chat with native javascriptWebRTC + Socket.io: building a skype-like video chat with native javascript
WebRTC + Socket.io: building a skype-like video chat with native javascript
 
Alegações finais de Dilma Rousseff no TSE
Alegações finais de Dilma Rousseff no TSEAlegações finais de Dilma Rousseff no TSE
Alegações finais de Dilma Rousseff no TSE
 

Similar to WebRTC DataChannels demystified

Web technologies: recap on TCP-IP
Web technologies: recap on TCP-IPWeb technologies: recap on TCP-IP
Web technologies: recap on TCP-IP
Piero Fraternali
 
ETE405-lec9.pdf
ETE405-lec9.pdfETE405-lec9.pdf
ETE405-lec9.pdf
mashiur
 
ETE405-lec7.pdf
ETE405-lec7.pdfETE405-lec7.pdf
ETE405-lec7.pdf
mashiur
 
D1-3-Signaling
D1-3-SignalingD1-3-Signaling
D1-3-Signaling
Oleg Levy
 
An Insight Into The Qos Techniques
An Insight Into The Qos TechniquesAn Insight Into The Qos Techniques
An Insight Into The Qos Techniques
Katie Gulley
 

Similar to WebRTC DataChannels demystified (20)

WebRTC
WebRTCWebRTC
WebRTC
 
Web technologies: recap on TCP-IP
Web technologies: recap on TCP-IPWeb technologies: recap on TCP-IP
Web technologies: recap on TCP-IP
 
WebRTC Seminar Report
WebRTC  Seminar ReportWebRTC  Seminar Report
WebRTC Seminar Report
 
ETE405-lec9.pdf
ETE405-lec9.pdfETE405-lec9.pdf
ETE405-lec9.pdf
 
ETE405-lec7.pdf
ETE405-lec7.pdfETE405-lec7.pdf
ETE405-lec7.pdf
 
Assignment on data network
Assignment on data networkAssignment on data network
Assignment on data network
 
Assignment on data network
Assignment on data networkAssignment on data network
Assignment on data network
 
Architecting Low Latency Applications Alberto Gonzalez
Architecting Low Latency Applications Alberto GonzalezArchitecting Low Latency Applications Alberto Gonzalez
Architecting Low Latency Applications Alberto Gonzalez
 
ITN_Module_3.pptx
ITN_Module_3.pptxITN_Module_3.pptx
ITN_Module_3.pptx
 
WebRTC. Yet Another Overview, for IT Technicians.
WebRTC. Yet Another Overview, for IT Technicians.WebRTC. Yet Another Overview, for IT Technicians.
WebRTC. Yet Another Overview, for IT Technicians.
 
Unit 4.pptx
Unit 4.pptxUnit 4.pptx
Unit 4.pptx
 
TCP/IP Protocols
TCP/IP ProtocolsTCP/IP Protocols
TCP/IP Protocols
 
IT8602 Mobile Communication - Unit V
IT8602 Mobile Communication - Unit V IT8602 Mobile Communication - Unit V
IT8602 Mobile Communication - Unit V
 
Protocol and Interfaces - IPv4, IPv6, X.25 Protocol, X.75 Protocol
Protocol and Interfaces - IPv4, IPv6, X.25 Protocol, X.75 ProtocolProtocol and Interfaces - IPv4, IPv6, X.25 Protocol, X.75 Protocol
Protocol and Interfaces - IPv4, IPv6, X.25 Protocol, X.75 Protocol
 
Protocols and Interfaces - IPv4, IPv6, X.25, X.75
Protocols and Interfaces - IPv4, IPv6, X.25, X.75Protocols and Interfaces - IPv4, IPv6, X.25, X.75
Protocols and Interfaces - IPv4, IPv6, X.25, X.75
 
BWE in Janus
BWE in JanusBWE in Janus
BWE in Janus
 
D1-3-Signaling
D1-3-SignalingD1-3-Signaling
D1-3-Signaling
 
Multicast QUIC for video content delivery
Multicast QUIC for video content deliveryMulticast QUIC for video content delivery
Multicast QUIC for video content delivery
 
An Insight Into The Qos Techniques
An Insight Into The Qos TechniquesAn Insight Into The Qos Techniques
An Insight Into The Qos Techniques
 
AusNOG 2023: A quick look at QUIC
AusNOG 2023: A quick look at QUICAusNOG 2023: A quick look at QUIC
AusNOG 2023: A quick look at QUIC
 

More from Victor Pascual Ávila

WebRTC standards update (April 2014)
WebRTC standards update (April 2014)WebRTC standards update (April 2014)
WebRTC standards update (April 2014)
Victor Pascual Ávila
 
IMS Value in a World of WebRTC and Mobile -- WebRTC Expo, Santa Clara, CA (No...
IMS Value in a World of WebRTC and Mobile -- WebRTC Expo, Santa Clara, CA (No...IMS Value in a World of WebRTC and Mobile -- WebRTC Expo, Santa Clara, CA (No...
IMS Value in a World of WebRTC and Mobile -- WebRTC Expo, Santa Clara, CA (No...
Victor Pascual Ávila
 
Realistic Future Service Provider Opportunities -- WebRTC Expo, Santa Clara, ...
Realistic Future Service Provider Opportunities -- WebRTC Expo, Santa Clara, ...Realistic Future Service Provider Opportunities -- WebRTC Expo, Santa Clara, ...
Realistic Future Service Provider Opportunities -- WebRTC Expo, Santa Clara, ...
Victor Pascual Ávila
 
WebRTC Standards -- The 10 Minutes guide
WebRTC Standards -- The 10 Minutes guideWebRTC Standards -- The 10 Minutes guide
WebRTC Standards -- The 10 Minutes guide
Victor Pascual Ávila
 
WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)
WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)
WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)
Victor Pascual Ávila
 

More from Victor Pascual Ávila (20)

IETF98 - 3rd-Party Authentication for SIP
IETF98 - 3rd-Party Authentication for SIPIETF98 - 3rd-Party Authentication for SIP
IETF98 - 3rd-Party Authentication for SIP
 
IETF meeting - SIP OAuth use cases
IETF meeting - SIP OAuth use casesIETF meeting - SIP OAuth use cases
IETF meeting - SIP OAuth use cases
 
WebRTC standards overview -- WebRTC Barcelona Meetup MWC16
WebRTC standards overview -- WebRTC Barcelona Meetup MWC16WebRTC standards overview -- WebRTC Barcelona Meetup MWC16
WebRTC standards overview -- WebRTC Barcelona Meetup MWC16
 
WebRTC standards update (April 2015)
WebRTC standards update (April 2015)WebRTC standards update (April 2015)
WebRTC standards update (April 2015)
 
Upperside WebRTC conference - WebRTC intro
Upperside WebRTC conference - WebRTC introUpperside WebRTC conference - WebRTC intro
Upperside WebRTC conference - WebRTC intro
 
WebRTC standards update - November 2014
WebRTC standards update - November 2014WebRTC standards update - November 2014
WebRTC standards update - November 2014
 
Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)
Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)
Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)
 
DTLS-SRTP Handling in SIP B2BUAs
DTLS-SRTP Handling in SIP B2BUAsDTLS-SRTP Handling in SIP B2BUAs
DTLS-SRTP Handling in SIP B2BUAs
 
WebRTC from the service provider prism
WebRTC from the service provider prismWebRTC from the service provider prism
WebRTC from the service provider prism
 
WebRTC Standards Update (October 2014)
WebRTC Standards Update (October 2014)WebRTC Standards Update (October 2014)
WebRTC Standards Update (October 2014)
 
IETF 90 - DTLS-SRTP Handling in SIP B2BUAs
IETF 90 - DTLS-SRTP Handling in SIP B2BUAsIETF 90 - DTLS-SRTP Handling in SIP B2BUAs
IETF 90 - DTLS-SRTP Handling in SIP B2BUAs
 
IETF 90 -- Guidelines to support RTCP end-to-end in SIP Back-to-Back User Age...
IETF 90 -- Guidelines to support RTCP end-to-end in SIP Back-to-Back User Age...IETF 90 -- Guidelines to support RTCP end-to-end in SIP Back-to-Back User Age...
IETF 90 -- Guidelines to support RTCP end-to-end in SIP Back-to-Back User Age...
 
WebRTC standards update (Jul 2014)
WebRTC standards update (Jul 2014)WebRTC standards update (Jul 2014)
WebRTC standards update (Jul 2014)
 
Digital Services Congress - OTT track - WebRTC panel: "Will WebRTC Mean a Mor...
Digital Services Congress - OTT track - WebRTC panel: "Will WebRTC Mean a Mor...Digital Services Congress - OTT track - WebRTC panel: "Will WebRTC Mean a Mor...
Digital Services Congress - OTT track - WebRTC panel: "Will WebRTC Mean a Mor...
 
WebRTC standards update (April 2014)
WebRTC standards update (April 2014)WebRTC standards update (April 2014)
WebRTC standards update (April 2014)
 
IMS Value in a World of WebRTC and Mobile -- WebRTC Expo, Santa Clara, CA (No...
IMS Value in a World of WebRTC and Mobile -- WebRTC Expo, Santa Clara, CA (No...IMS Value in a World of WebRTC and Mobile -- WebRTC Expo, Santa Clara, CA (No...
IMS Value in a World of WebRTC and Mobile -- WebRTC Expo, Santa Clara, CA (No...
 
Realistic Future Service Provider Opportunities -- WebRTC Expo, Santa Clara, ...
Realistic Future Service Provider Opportunities -- WebRTC Expo, Santa Clara, ...Realistic Future Service Provider Opportunities -- WebRTC Expo, Santa Clara, ...
Realistic Future Service Provider Opportunities -- WebRTC Expo, Santa Clara, ...
 
WebRTC standards update (13 Nov 2013)
WebRTC standards update (13 Nov 2013)WebRTC standards update (13 Nov 2013)
WebRTC standards update (13 Nov 2013)
 
WebRTC Standards -- The 10 Minutes guide
WebRTC Standards -- The 10 Minutes guideWebRTC Standards -- The 10 Minutes guide
WebRTC Standards -- The 10 Minutes guide
 
WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)
WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)
WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)
 

Recently uploaded

Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Victor Rentea
 
Tales from a Passkey Provider Progress from Awareness to Implementation.pptx
Tales from a Passkey Provider  Progress from Awareness to Implementation.pptxTales from a Passkey Provider  Progress from Awareness to Implementation.pptx
Tales from a Passkey Provider Progress from Awareness to Implementation.pptx
FIDO Alliance
 
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
panagenda
 

Recently uploaded (20)

UiPath manufacturing technology benefits and AI overview
UiPath manufacturing technology benefits and AI overviewUiPath manufacturing technology benefits and AI overview
UiPath manufacturing technology benefits and AI overview
 
Working together SRE & Platform Engineering
Working together SRE & Platform EngineeringWorking together SRE & Platform Engineering
Working together SRE & Platform Engineering
 
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
 
Tales from a Passkey Provider Progress from Awareness to Implementation.pptx
Tales from a Passkey Provider  Progress from Awareness to Implementation.pptxTales from a Passkey Provider  Progress from Awareness to Implementation.pptx
Tales from a Passkey Provider Progress from Awareness to Implementation.pptx
 
JavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate GuideJavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate Guide
 
JohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptxJohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptx
 
Cyber Insurance - RalphGilot - Embry-Riddle Aeronautical University.pptx
Cyber Insurance - RalphGilot - Embry-Riddle Aeronautical University.pptxCyber Insurance - RalphGilot - Embry-Riddle Aeronautical University.pptx
Cyber Insurance - RalphGilot - Embry-Riddle Aeronautical University.pptx
 
Generative AI Use Cases and Applications.pdf
Generative AI Use Cases and Applications.pdfGenerative AI Use Cases and Applications.pdf
Generative AI Use Cases and Applications.pdf
 
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
 
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdfFrisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
Frisco Automating Purchase Orders with MuleSoft IDP- May 10th, 2024.pptx.pdf
 
ADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptxADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptx
 
WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024
 
Top 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development CompaniesTop 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development Companies
 
Microsoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - QuestionnaireMicrosoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - Questionnaire
 
Design Guidelines for Passkeys 2024.pptx
Design Guidelines for Passkeys 2024.pptxDesign Guidelines for Passkeys 2024.pptx
Design Guidelines for Passkeys 2024.pptx
 
Intro to Passkeys and the State of Passwordless.pptx
Intro to Passkeys and the State of Passwordless.pptxIntro to Passkeys and the State of Passwordless.pptx
Intro to Passkeys and the State of Passwordless.pptx
 
Vector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptxVector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptx
 
Introduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptxIntroduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptx
 
Design and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data ScienceDesign and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data Science
 
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
 

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
  • 5.
  • 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’)
  • 10.
  • 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
  • 14.
  • 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”
  • 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  
  • 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
  • 37.
  • 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