1 / 20

Overview

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

hazelv
Download Presentation

Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Overview SA3-LI Oct. 2013 R. Taylor/J.Ing Public Safety Canada

  2. 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 Unclassified

  3. 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 Unclassified

  4. Evolving towards a convergence point Operator requirements centric PSTN/Cellular • IMS • In standards development for 13+ years • 3GPP(2)/TISPAN resolved ambiguities and created a SIP profile to meet extensiverequirements 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 23.701 V0.1.0 (2013-07) • Web Real Time Communication (WebRTC) Access to IMS; (IMS-WEBRTC) • Rel 12 Technical Report NGN IMS Interworking & technology blending Internet requirements centric WebRTC Proprietary real time communications based on Plug-ins HTTP Web Browser WebRTC maturing very quickly, goals and priorities differ from IMS Unclassified

  5. 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” Unclassified

  6. WebRTC Peering SDP Offer SDP Answer Signalling Path Web Server Web Server Protocol not defined (possibilities include SIP, Jingle, XMPP) Application defined interface (HTTPS / Websockets based) Application defined interface (HTTPS / Websockets based) JS/HTML/CSS JS/HTML/CSS JavaScript API JavaScript API Browser Browser Media Path 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 Unclassified

  7. Details Unclassified

  8. Under the covers Parts in blue are “a” TSP’s view, not part of Standards activities Unclassified

  9. 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 Unclassified

  10. 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 Unclassified

  11. WebRTC interworking Signalling Path Signalling Interworking Web Server ICE-Lite* Interconnect to IMS, NGN and PSTN networks (RTP) Media Interworking JS/HTML/CSS Interworking Function Browser Media Path (SRTP) * 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 Unclassified

  12. Possible Operator models Scenario 1: Interconnect to 3rd party WebRTC Scenario 2: WebRTC as pseudo IMS end point Operator run Web Service A-SBC I-SBC 3rd Party Web Domain TAS TAS WebRTC Signalling IMS SIP IMS P-CSCF IMS Signalling Interworking Signalling Interworking IMS core Web Server IMS /NGN core Web Server ICE-Lite Media Interworking Media Interworking Media JS/HTML/CSS Media JS/HTML/CSS Media Media UE Browser UE Browser IMS Network Operator IMS Network Operator Scenario 3: Native support of WebRTC • 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 Operator run Web Service WebRTC Signalling Web Server Web Server JS/HTML/CSS JS/HTML/CSS Media Browser Browser Unclassified

  13. W3C WebRTC deliverables • 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 • 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 Unclassified

  14. IETF Deliverables WG RFCDate draft-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-27 Plus over 20 discussion RFC drafts • 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 Unclassified

  15. 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 A C B D Unclassified

  16. 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 Unclassified

  17. 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” Unclassified

  18. Backup Unclassified

  19. Browser Support Unclassified

  20. End Unclassified

More Related