Overview
SA3-LI Oct. 2013
R. Taylor/J.Ing
Public Safety Canada
What is it
• Web Real-Time Communications
• Standards to enable browser based sessions (voice, video,
Collab, …) without the need of custom clients or plugins
• Builds on HTLM5 capabilities with JavaScript
• Standardized by W3C and IETF
– IETF RTCWeb WG ( Internet world, IP protocols)
– W3C WebRTC WG (web world, Browsers etc.)
• Intended for all browsers to support
– Chrome, Firefox, Safari, Opera, IE …
• MSFT being problematic
– Have their own CU-RTC-Web framework
• Apple (Safari) not at the table
4/8/2015
Unclassified
2
High Level Model
• Web Server/service based signaling brokering
– Offer/Answer model with SDP; protocol NOT defined
• Direct media flow, sometimes relayed due to NAT/NAPT
– SRTP/RTCP
4/8/2015
Unclassified
3
Evolving towards a convergence point
•
•
IMS
– In standards development for 13+ years
– 3GPP(2)/TISPAN resolved ambiguities and
created a SIP profile to meet extensive
requirements of fixed/cellular service
providers
WebRTC
– In standards development for ~2 year
– Requirements driven by “web” community
Operator requirements centric
PSTN/Cellular
NGN
IMS
Interworking & technology blending
WebRTC
•
•
WebRTC will evolve and interwork with IMS
IMS will adapt to support WebRTC
– 3GPP TR 23.701 V0.1.0 (2013-07)
– Web Real Time Communication (WebRTC)
Access to IMS; (IMS-WEBRTC)
– Rel 12 Technical Report
WebRTC maturing very quickly, goals
and priorities differ from IMS
4/8/2015
Unclassified
Proprietary real time
communications based
on Plug-ins
HTTP Web Browser
Internet requirements centric
4
Projected Adoption
“WebRTC will be available -- that is,
downloaded and installed -- on over
4 billion devices within the next
three years, according to the
International Telecommunication
Union (ITU)'s projections”
4/8/2015
Unclassified
5
WebRTC Peering
SDP Offer
SDP Answer
Signalling Path
Web Server
Application defined
interface (HTTPS /
Websockets based)
Protocol not defined
(possibilities include SIP,
Jingle, XMPP)
Web Server
Application defined
interface (HTTPS /
Websockets based)
JS/HTML/CSS
JS/HTML/CSS
JavaScript API
JavaScript API
Media Path
Browser
Browser
Peer to Peer - Transport
framework based on
SRTP
• Solution geared towards web community and deliberately left open
• Standardizing the required Browser behaviour, NOT the End-to-End solution
4/8/2015
Unclassified
6
Details
4/8/2015
Unclassified
7
Under the covers
Parts in blue
are “a” TSP’s
view, not part
of Standards
activities
4/8/2015
Unclassified
8
Solution Details
•
•
Web page invokes set of defined JavaScript's to request services from the browser
Interface/Protocol between scripts and browser: JSEP
– Java Session Establishment Protocol
– Create an Offer, Create an Answer, get media details (SDP), Invoke ICE, etc.
– Implements Offer/Answer model like used in SIP
•
Offers, Answers etc. sent to/via Web server
– Uses HTTPS or secure WebSockets (RFC 6455)
•
•
Provides full-duplex communications channels over a single TCP connection
Uses ICE for NAT traversal (RFC 5245)
– Interactive Connectivity Establishment (ICE):
•
A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
– Complicated set of procedures using STUN and TURN to discover best addresses to use for RTP
streams
•
Web server pushes notification to “called” party
– Requires browser to be open and excepting
– Inter -Server protocol not defined
•
Secure RTP for media exchange
– Using DTLS (Datagram TLS)
•
use of SDES (Session Description Protocol Security Descriptions) has been disallowed by the IETF
– RTP and RTCP multiplexed on same port (RTCP usually on RTP port plus one)
– A media relay service (TURN) may be required
4/8/2015
Unclassified
9
Now a word about Codecs
• G711a/u (RFC 3551)
– Mandated
– supported by all the devices
– Tends to use a lot of bandwidth
• DTMF tones (RFC 4733, updates RFC 2833)
– needed for interactions with legacy systems
– Voice mail, IVRs, …
• Opus (RFC 6716):
–
–
–
–
Mandated
Variable bitrate, low latency and high quality for human voice and music
Specifically designed for real time communications
Supposedly Patent unencumbered hence royalty free
• Ongoing battle in video VP8/9 vs H.264/265
– Royalty free ? vs. MPEG world
– No Flash
• Proposals to support other Codecs if available on the device
– E.g., AMR, AMR-wb
4/8/2015
Unclassified
10
WebRTC interworking
Signalling Path
Web Server
Signalling
Interworking
ICE-Lite*
Media
Interworking
JS/HTML/CSS
Browser
Media Path
(SRTP)
Interworking
Function
Interconnect
to IMS, NGN
and PSTN
networks
(RTP)
* ICE is key to determining a
viable media path and user
consent. ICE interworking
required at gateway if not
supported at downstream
endpoint.
The underlying offer/answer model and RTP based media assist with
interworking to IMS/SIP networks
4/8/2015
Unclassified
11
Possible Operator models
Scenario 1: Interconnect to 3rd party WebRTC
3rd Party
Web Domain
Web
Server
TAS
Signalling
Interworking
Media
Media
Interworking
Signalling
Interworking
Web
Server
IMS
IMS
/NGN
core
ICE-Lite
JS/HTML/CSS
Operator run
Web Service
I-SBC
WebRTC
Signalling
Scenario 2: WebRTC as pseudo IMS end point
JS/HTML/CSS
Media
UE
Browser
WebRTC
Signalling
Web Server
JS/HTML/CSS
JS/HTML/CSS
Media
Browser
4/8/2015
IMS
P-CSCF
Media
Media
Interwor
king
IMS core
Media
UE
IMS Network Operator
Scenario 3: Native support of WebRTC
Web Server
TAS
IMS SIP
Browser
IMS Network Operator
Operator run
Web Service
A-SBC
Operator product requirements depends
on commercial strategy:
• Border interconnect between
PSTN/NGN/IMS and WebRTC
• WebRTC end points as an
extension to an NGN/IMS
network
• Native support of WebRTC
Browser
Unclassified
12
W3C WebRTC deliverables
•
–
•
- Implementation Library: WebRTC
Native APIs
An extension of the Media Stream Functions to
process audio streams (e.g. automatic gain
control, mute functions and echo cancellation).
- Media Capture and Streams - Draft 16
May 2013
•
An extension of the Media Stream Functions to
process video streams (e.g. bandwidth limiting,
image manipulation or "video mute“).
Supported by Chrome and Firefox
NOW
- Pre-standard
Functional Component Functions
–
•
API specification Availability
- WebRTC 1.0: Real-time
Communication Between Browsers Draft 3 June 2013 available
Video Stream Functions
–
•
API for connecting processing functions to
media devices and network connections,
including media manipulation functions.
Audio Stream Functions
–
•
•
Media Stream Functions
API to query presence of WebRTC components
in an implementation, instantiate them, and
connect them to media streams.
P2P Connection Functions
–
API functions to support establishing signalling
protocol agnostic peer-to-peer connections
between Web browsers
4/8/2015
Unclassified
13
IETF Deliverables
•
•
•
•
•
•
•
•
•
Communication model
Security model
Firewall and NAT traversal
Media functions
Functionalities such as media
codecs, security algorithms, etc.,
Media formats
Transport of non media data between
clients
Input to W3C for APIs development
Interworking with legacy VoIP equipment
WG RFC
draft-ietf-rtcweb-audio-02
draft-ietf-rtcweb-data-channel-05
draft-ietf-rtcweb-data-protocol-00
draft-ietf-rtcweb-jsep-03
draft-ietf-rtcweb-overview-07
draft-ietf-rtcweb-rtp-usage-07
draft-ietf-rtcweb-security-05
draft-ietf-rtcweb-security-arch-07
draft-ietf-rtcweb-transports-00
draft-ietf-rtcweb-use-cases-and-reqs-11
Plus over 20 discussion RFC drafts
Date
2013-08-02
2013-07-15
2013-07-15
2013-02-27
2013-08-14
2013-07-15
2013-07-15
2013-07-15
2013-08-19
2013-06-27
• IETF currently 6-9 months
behind schedule
• Content prioritisation
starting to taking place
4/8/2015
Unclassified
14
Other SDO Activity
A
B
C
D
• ATIS ORCA
–
–
–
–
Open Real‐time Communications API
Open source project
Announced July 24, 2013
Provides client‐side call control APIs
• Simplifies the signaling to set up high quality
communication sessions between web applications
– Provides tools and JavaScript libraries
– Fits existing developer model
4/8/2015
Unclassified
15
The Tricky Bits
•
Identity resolution
– Ok if in a wall-garden solution (Facebook, Twitter, Google circles, …)
– Ok for “Call Now” button on Personal & Business Web pages
•
Assuming there’s someone manning the website
– But how can Alice “call” Bob just browser to browser ?
•
How to resolve Bob’s address to Web Server and Bob’s browser instance
– Public ENUM (Phone # to URL) failed
•
NAT/NAPT traversal
– ICE is heavy weight, not web developer “friendly”
– If media relay is required, who supplies the TURN servers ?
•
Security
– Lots of focus on the protocols
– But browsers and JavaScript ripe with potential/real exploits
– SPAM & Unwanted call control/mitigation
•
RTP stream multiplexing
– RTP + RTCP
– Multiple RTP streams
•
Interworking
–
–
–
–
4/8/2015
Between WebRTC solutions
With established OTT solutions (Skype, Viber, etc.)
With NGN/IMS
Legacy PSTN and PLMN
Unclassified
16
LI Concerns and/or Issues
•
Who’s providing the “Service”
– Regulated, Unregulated, Mix ?
– Depends a lot on the nature of the solution
• TSP IMS controlled vs. just a “Call Me” button on a web page
•
What Ids are being used/resolved ?
– By whom and how ?
– In a regulatory domain ?
•
Detecting the service
– Security posture is specifically around blocking man-in-the-middle (“The Man”-in-the-middle ?)
attacks
– Is the signaling reasonably detectable ?
– Protocols being used ??
– Encryption
•
Location not part of the solution space: Jurisdiction
– Where’s the client/browser vs. Web Server(s)
•
Media Interception
–
–
–
–
Where is the bearer really going, passing through ?
Forcing media relays when not required ?
RTP multiplexing
Media Encryption (DTLS)
• Who has the keys ?
•
No LEA influence over lead SDOs
– IETF and W3C not “LI friendly”
4/8/2015
Unclassified
17
Backup
4/8/2015
Unclassified
18
Browser Support
4/8/2015
Unclassified
19
End
4/8/2015
Unclassified
20