WebRTC standards update (April 2014)
4 likes•16,895 views
Victor Pascual Ávila provides an update on WebRTC standards from April 2014. He discusses that WebRTC defines media standards like audio and video codecs but does not define a signaling protocol, so each deployment implements its own. WebRTC is also incompatible with existing VoIP deployments requiring gateways. While the W3C provides a WebRTC API, competing proposals exist and the API may evolve. Browser support for WebRTC is increasing. Standardization groups are working on WebRTC interoperability issues.
WebRTC standards update (April 2014)
- 1. WebRTC standards update (April 2014) Victor Pascual Ávila – Technology, Innovation & Strategy Consultant
- 2. About Me Technology, Innovation & Strategy Consultant Main focus: help make WebRTC happen – involved in WebRTC standardization, development and first industry deployments (on-going RFX's, PoC's and field trials) Other activities: - Chief Strategy Officer (CSO) - 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
- 4. What is WebRTC? A browser-embedded media engine
- 5. WebRTC standards (Media) (Signaling) (Signaling) “Set or RTC APIs for Web Browsers” “New protocol profile” Some discussion on the topic: http://webrtchacks.com/a-hitchhikers-guide-to-webrtc-standardization/
- 6. RTCWeb WG (and others) - 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 firewall traversal - DataChannel - Etc. NEW PROTOCOL PROFILE FOR MEDIA
- 7. WebRTC does not define signaling Don’t panic, it’s not a bad thing!
- 8. Signaling plane WebRTC has no defined signaling method. JavaScript app downloaded from web server. Popular choices are: ● SIP over Websockets – Standard mechanism (RFC7118) – Extend SIP directly into the browser by embedding a SIP stack directly into the webpage – typically based on JavaScript – WebSocket create a full-duplex channel right from the web browser – Popular examples are jsSIP, sip-js, QoffeeSIP, or sipML5 ● Call Control API – proprietary signaling scheme based on more traditional web tools and techniques – “standard” APIs enhanced to include WebRTC support • Other alternatives based on XMPP, JSON or foobar Some discussion on the topic: http://webrtchacks.com/signalling-options-for-webrtc- applications/
- 9. each deployment/vendor is implementing its own proprietary signaling mechanism (1/3)
- 10. Interworking towards legacy? ● 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 all) – Do not support STUN/TURN/ICE – Do not support multiplexing (ok, not really an issue) – Use different codecs that might not be supported on the WebRTC side
- 11. WebRTC signaling and media is NOT compatible with existing VoIP/IMS deployments – gateways are required to bridge the two worlds (2/3)
- 12. The video codec battle Some discussion on the topic: http://webrtchacks.com/cisco-openh264/
- 14. Result of the discussion? Room participants: 30/50 in favor of H.264 Remote participants (minority): 75/25 in favor of VP8 → No clear consensus
- 15. No decision Some discussion on the topic: http://webrtchacks.com/ietf-finally-made-decision- mandatory-implement-mti-video-codec-webrtc/
- 16. 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 flexibility Web developers need? Answer: well, not really but it's good enough for most of the use cases we have today Competing proposals: Microsoft's CU- RTC-WEB (Aug'12), WebRTC Object API (ORTC) (Aug'13) Next step: “Done is better than perfect”, Let's finish WebRTC 1.0, Let the industry adopt it Future work: “fix/improve things in WebRTC 2.0”, Backward interoperability? Obtain local media Setup Peer Connection Attach media or Data Close Connection ← getUserMedia(), etc. ← RTCPeerConnection(), etc. ← addStream(), createOffer(), etc.
- 18. 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/
- 20. the WebRTC API can have different flavors (3/3)
- 21. WebRTC Access to IMS (r12) http://webrtchacks.com/ims-approach-webrtc/
- 22. Adding new wheels to IMS with WebRTC
- 23. 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
- 24. 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”
- 25. Alliance for Telecom Solutions
- 26. 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”
- 27. GSMA How does WebRTC relate to VoLTE and RCS?
- 28. Summary ● 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