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