Overview SA3-LI Oct 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/29/2015Unclassified2

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/29/2015Unclassified3

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 WebRTC will evolve and interwork with IMS IMS will adapt to support WebRTC – 3GPP TR V0.1.0 ( ) – Web Real Time Communication (WebRTC) Access to IMS; (IMS-WEBRTC) – Rel 12 Technical Report Operator 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 4/29/2015 Unclassified4

Projected Adoption 4/29/2015Unclassified5 “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 JS/HTML/CSS Browser 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) Solution geared towards web community and deliberately left open Standardizing the required Browser behaviour, NOT the End-to-End solution SDP Offer SDP Answer 4/29/2015Unclassified6

Details 4/29/2015Unclassified7

Under the covers 4/29/2015Unclassified8 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 4/29/2015Unclassified9

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/29/2015Unclassified10

WebRTC interworking Web Server Signalling 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. 4/29/2015Unclassified11

Possible Operator models Web Server Signalling Interworking JS/HTML/CSS ICE-Lite Browser Media Interworking Media WebRTC Signalling I-SBC 3 rd Party Web Domain IMS /NGN core TAS UE IMS Network Operator Scenario 1: Interconnect to 3 rd party WebRTC Web Server P-CSCF JS/HTML/CSS Browser Media Interwor king Media IMS SIP A-SBC IMS core TAS UE IMS Network Operator Web Server JS/HTML/CSS Browser 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 4/29/2015Unclassified12

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 4/29/2015Unclassified13

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 Unclassified4/29/ WG RFC Date draft-ietf-rtcweb-audio draft-ietf-rtcweb-data-channel draft-ietf-rtcweb-data-protocol draft-ietf-rtcweb-jsep draft-ietf-rtcweb-overview draft-ietf-rtcweb-rtp-usage draft-ietf-rtcweb-security draft-ietf-rtcweb-security-arch draft-ietf-rtcweb-transports draft-ietf-rtcweb-use-cases-and-reqs Plus over 20 discussion RFC drafts

A B C D 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 4/29/2015Unclassified15

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 4/29/2015Unclassified16

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/29/2015Unclassified17

Backup 4/29/2015Unclassified18

Browser Support 4/29/2015Unclassified19

End 4/29/2015Unclassified20