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.
About Me (firstname.lastname@example.org) 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 @victorpascual
Technology Angle A browser-embedded media engine “No need to instal upgrade/configure software”
Business Angle Is WebRTC something disruptive or simply yet another access framework? BOTH! - global business – browsers are connected to the Internet → it's time to RTC → Web go OTT Web → RTC Pure Web vs Interworked - expand footprint – extend existing services to new subscribers - decrease churn – enhance current Not only Web browsers but also native support via apps or OS services to existing subscribers (e.g. set-top boxes, FirefoxOS) - new service revenues – create new services and subscribers
- Audio codecs – G.711, Opus - Video codecs – H.264 vs. VP8 - Media codecs are negotiated with SDP (for now at least) - Requires Secure RTP (SRTP) – DTLS-SRTP (SDES is prohibited) - Requires Peer-2-peer NAT traversal tools (STUN, TURN, ICE) – trickle ICE - Multiplexing: RTPs & RTP+RTCP - Tools for firewal traversal - DataChannel - Etc. NEW PROTOCOL PROFILE FOR MEDIA
WebRTC does not define signaling Don’t panic, it’s not a bad thing!
(1/3) each deployment/vendor is implementing its own proprietary signaling mechanism
Interworking? ● A browser-embedded media engine – Best-of-breed echo canceler – Video jitter buffer, image enhancer – Audio codecs – G.711, Opus are MTI – Video codecs – H.264 vs. VP8 (MTI TBD - IPR discussion) – Media codecs are negotiated with SDP (for now at least) – Requires Secure RTP (SRTP) – DTLS – Requires Peer-2-peer NAT traversal tools (STUN, TURN, ICE) – trickle ICE – Multiplexing: RTPs & RTP+RTCP ● Yes, your favorite SIP client implementation is compatible with most of this. But, the vast majority of deployments – Use plain RTP (and SDES if encrypted at al ) – Do not support STUN/TURN/ICE – Do not support multiplexing (ok, not real y an issue) – Use different codecs that might not be supported on the WebRTC side
(2/3) WebRTC signaling and media is NOT compatible with existing VoIP deployments – gateways are required to bridge the two worlds
WebRTC WG “The mission of the W3C WebRTC WG is to define client-side APIs to enable Real-Time Communications in Web-browsers. These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers (unless needed for firewall traversal).” Discussion: provides the current API in its form (e.g. based on SDP O/A) the Obtain local flexibility Web developers need? media ← getUserMedia(), etc. Answer: well, not really but it's good enough for most of the use cases we have Setup Peer today Connection ← RTCPeerConnection(), etc. Competing proposals: Microsoft's CU- RTC-WEB (Aug'12), WebRTC Object API (ORTC) (Aug'13) Attach media or Data ← addStream(), Next step: “Done is better than perfect”, createOffer(), Let's finish WebRTC 1.0, Let the industry etc. adopt it Close Future work: “fix/improve things in Connection WebRTC 2.0”, Backward interoperability?
How do applications access the media engine? ● W3C API – Currently working on 1.0 – 2.0: Backward compatibility? ● Competing API: CU-RTC-Web (Microsoft) ● Competing API: ORTC (Microsoft and others) ● Apple? ● Since last week Opera includes some support Some discussion on the topic: http://webrtchacks.com/why-the-webrtc-api- has-it-wrong-interview-with-webrtc-object-api- ortc-co-author-inaki-baz-3-2/ iswebrtcreadyyet.com
(3/3) the WebRTC API can have different flavors
WebRTC Access to IMS (r12)
SA1 (requirements): reusing IMS client security credentials and/or public identities/credentials; how IMS clients communicate with WebRTC clients connected to IMS; IMS services to the WebRTC client; regulatory functions and charging; offer IMS services to users interacting with a 3rd party website, etc. SA2 (architecture): expand the IMS architecture and stage 2 procedures as required by the support of WebRTC clients access to IMS; media plane aspects; PBX emulation; signalling; only UNI covered, NNI out of scope. SA3 (security): WebRTC client authentication mechanisms, media plane security
SIP Forum WebRTC Task Group “the initial focus of the Task Group is to determine what the needs are for successful interoperability of WebRTC- to-SIP deployments” covering both Enterprises and Service Providers “recommendations, Reference Architecture Documents, Certifications, and/or White Papers”
WebRTC interop Activity Group “focuses on interoperability issues relating to the use of WebRTC” “the group is focused on enterprise WebRTC , interworking of WebRTC and other carrier technologies, and other existing videoconferencing systems” “develop an interoperability test framework and prepare for IOT events”
● each deployment/vendor is implementing its own proprietary signaling mechanism ● WebRTC signaling and media is incompatible with existing VoIP deployments – gateways are required to bridge the two worlds ● the WebRTC API can have different flavors
MORE INFORMATION VICTOR PASCUAL Chief Strategy Officer email@example.com Twitter: @victorpascual
MORE INFORMATION BACKUP SLIDES
WebRTC client app: SIPPO from Quobis Corporate endpoint fully-interoperable with SIP networks and 3rd party WebRTC gateways Main features: - Audio/video - Interactive chat - Presence - Contact list - File transfer - Screen sharing - Dialpad - etc. Signaling agnostic - Browser agnostic - API to build your own apps.
How to make things work?
Reference Architecture SIPPO: Client + Server component
3GPP architecture (under discussion) SIPPO Server = WebRTC Portal + more things Third Party WebRTC-SIP gateway
SIPPO Server: Control, provision, configure and customize your WebRTC Clients ● RESTful APIs for management of users and web clients ● Seven modules: Authentication, Authorization, Accounting, Contact mgmt, Branding, File sharing, Statistics. ● Connection to LDAP/AD for Authentication, Authorization and Contact Management. ● Integration with Facebook, Gmail, etc. ● Support for identity federation ● Diameter for integration with backend. ● Etc.