WebRTC standards update (13 Nov 2013)

WebRTC: Standards Update – Where are we?

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 QUOBIS

About Me ([email protected])

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

http://tools.ietf.org/wg/straw/charters

http://www.sipforum.org/content/view/415/293/

Technology Angle

“No need to install upgrade/configure software”

A browser-embedded media engine

Business Angle

- global business – browsers are connected to the Internet → it's time to go OTT

- expand footprint – extend existing services to new subscribers- decrease churn – enhance current services to existing subscribers- new service revenues – create new services and subscribers

Is WebRTC something disruptive or simply yet another access framework? BOTH!

RTC → WebWeb → RTC

Not only Web browsers but also native support via apps or OS(e.g. set-top boxes, FirefoxOS)

Pure Web vs Interworked

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/

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

WebRTC does not define signaling

Don’t panic, it’s not a bad thing!

Signaling plane

WebRTC has no defined signaling method. JavaScript app downloaded from web server. Popular choices are:

● SIP over Websockets

– Standard mechanism (draft-ietf-sipcore-sip-websocket) – soon to be RFC

– 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

– GSMA/OMA extending RCS “standard” API 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/

each deployment/vendor is implementing its own proprietary signaling mechanism

(1/3)

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

WebRTC signaling and media is NOT compatible with existing VoIP deployments – gateways are required to bridge the two

worlds

(2/3)

The video codec battle

Some discussion on the topic: http://webrtchacks.com/cisco-openh264/

Result of the discussion?

Room participants: 30/50 in favor of H.264Remote participants (minority): 75/25 in favor of VP8→ No clear consensus

No decision

Some discussion on the topic: http://webrtchacks.com/ietf-finally-made-decision-mandatory-implement-mti-video-codec-webrtc/

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 localmedia

Setup PeerConnection

Attach mediaor Data

CloseConnection

← getUserMedia(), etc.

← RTCPeerConnection(), etc.

← addStream(), createOffer(),etc.

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

iswebrtcreadyyet.com

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/

the WebRTC API can have different flavors

(3/3)

WebRTC Access to IMS (r12)

SA1 (requirements): reusing IMS client security credentials and/orpublic identities/credentials; how IMS clients communicate withWebRTC clients connected to IMS; IMS services to the WebRTCclient; 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”

Alliance for Telecom Solutions

”Device Solutions Initiative (DSI), an initiative that will host a range of projects to develop network- and protocol-agnostic, client-side bindings that will make real-time communications more accessible to web developers”

“The tools being created by the Initiative will offer developers a code-once, run anywhere approach, replacing the need for carrier-specific coding to add functions such as basic call signaling and network control to applications. DSI will focus initially on call signaling but is expected to advance from there to address other network-specific functions”

“The DSI’s formation and launch was led by Alcatel-Lucent, AT&T, CenturyLink, Ericsson, Sprint and Verizon”

“The first project under the DSI has already started. In July, ATIS launched ORCA, which stands for Open Real-Time Communications APIs, an open source project that will mask the complexity of end-to-end signaling for real-time communication, allowing developers to focus on embedding innovative new functionality to their applications, such as high-quality voice and/or video calls. ORCA has successfully developed initial client-side software called orca.js, with the “.js” denoting creation of a JavaScript library. The client-side binding is network- and protocol- independent, linking to supporting implementation libraries to allow developers consistent access to the robust services provided by IMS networks”

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”

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

MORE INFORMATION

VICTOR PASCUALChief Strategy Officer

[email protected]: @victorpascual

WebRTC standards update (13 Nov 2013)

Technology

Transcript of WebRTC standards update (13 Nov 2013)