Overview

SA3-LI Oct. 2013R. 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

04/18/23 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

04/18/23 Unclassified 3

Evolving towards a convergence pointOperator requirements centric

Internet requirements centric

HTTP Web Browser

Proprietary real time communications based

on Plug-ins

WebRTC

PSTN/Cellular

NGN IMS

Interworking & technology blending

WebRTC maturing very quickly, goals and priorities differ from IMS

04/18/23 Unclassified 4

Projected Adoption

04/18/23 Unclassified 5

“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”

WebRTC Peering

Web Server Web Server

JS/HTML/CSS JS/HTML/CSS

Browser Browser

JavaScript API JavaScript API

Media Path

Peer to Peer - Transport framework based on SRTP

Signalling Path

Protocol not defined (possibilities include SIP, Jingle, XMPP)

Application defined interface (HTTPS / Websockets based)

Application defined interface (HTTPS / Websockets based)

• Solution geared towards web community and deliberately left open• Standardizing the required Browser behaviour, NOT the End-to-End solution

SDP OfferSDP Answer

04/18/23 Unclassified 6

Details

04/18/23 Unclassified 7

Under the covers

04/18/23 Unclassified 8

Parts in blue are “a” TSP’s view, not part of Standards activities

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

04/18/23 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

04/18/23 Unclassified 10

WebRTC interworking

Web ServerSignalling

Interworking

JS/HTML/CSS

ICE-Lite*

Browser

Media Interworking

Media Path(SRTP)

Interconnect to IMS, NGN and PSTN networks(RTP)

Signalling Path

Interworking Function

The underlying offer/answer model and RTP based media assist with interworking to IMS/SIP networks

* ICE is key to determining a viable media path and user consent. ICE interworking required at gateway if not supported at downstream endpoint.

04/18/23 Unclassified 11

Possible Operator models

Web Server

Signalling Interworking

JS/HTML/CSS

ICE-Lite

Browser

Media Interworking

Media

WebRTCSignalling

I-SBC3rd PartyWeb Domain

IMS /NGN core

TAS

UE

IMS Network Operator

Scenario 1: Interconnect to 3rd party WebRTC

Web Server

P-CSCF

JS/HTML/CSS

Browser

Media Interwor

kingMedia

IMS SIP

A-SBC

IMS core

TAS

UE

IMS Network Operator

Web Server Web Server

JS/HTML/CSS JS/HTML/CSS

Browser Browser

IMS IMS

Media

Scenario 2: WebRTC as pseudo IMS end point

Scenario 3: Native support of WebRTC

Operator run Web Service

Signalling Interworking

Operator run Web Service WebRTC

Signalling

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

Media Media

04/18/23 Unclassified 12

W3C WebRTC deliverables• Media Stream Functions

– API for connecting processing functions to media devices and network connections, including media manipulation functions.

• Audio Stream Functions – An extension of the Media Stream Functions to

process audio streams (e.g. automatic gain control, mute functions and echo cancellation).

• Video Stream Functions – An extension of the Media Stream Functions to

process video streams (e.g. bandwidth limiting, image manipulation or "video mute“).

• Functional Component 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

• API specification Availability- WebRTC 1.0: Real-time

Communication Between Browsers - Draft 3 June 2013 available

- Implementation Library: WebRTC Native APIs

- Media Capture and Streams - Draft 16 May 2013

• Supported by Chrome and Firefox NOW- Pre-standard

04/18/23 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

• IETF currently 6-9 months behind schedule

• Content prioritisation starting to taking place

Unclassified04/18/23 14

WG RFC Datedraft-ietf-rtcweb-audio-02 2013-08-02 draft-ietf-rtcweb-data-channel-05 2013-07-15 draft-ietf-rtcweb-data-protocol-00 2013-07-15 draft-ietf-rtcweb-jsep-03 2013-02-27 draft-ietf-rtcweb-overview-07 2013-08-14 draft-ietf-rtcweb-rtp-usage-07 2013-07-15 draft-ietf-rtcweb-security-05 2013-07-15 draft-ietf-rtcweb-security-arch-07 2013-07-15 draft-ietf-rtcweb-transports-00 2013-08-19 draft-ietf-rtcweb-use-cases-and-reqs-11 2013-06-27Plus over 20 discussion RFC drafts

AB

CD

Other SDO Activity

• 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

04/18/23 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– Between WebRTC solutions– With established OTT solutions (Skype, Viber, etc.)– With NGN/IMS– Legacy PSTN and PLMN

04/18/23 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”

04/18/23 Unclassified 17

Backup

04/18/23 Unclassified 18

Browser Support

04/18/23 Unclassified 19

End

04/18/23 Unclassified 20