WebRTC is dramatically changing the face of communications by making real-time voice and video just another feature available on websites and mobile applications.
This presents a tremendous opportunity for telcos... not by monetizing WebRTC directly but by *using* WebRTC to deliver new compelling products to their subscribers and enterprise customers.
This presentation offers a brief overview of WebRTC, the various identity models and some suggestions on go-to-market strategy.
2. CTO, Voxeo Labs
Software Developer for 15 years
10 Years Designing Telco APIs
@loopingrage
jose@voxeolabs.com
3. Headquartered in Menlo Park, California
Creators of Tropo.com
We bridge the gap between Telco and Web
Editors of the WebRTC Specification
http://voxeolabs.com
4. WebRTC is a new API for embedding real-time
communications into web sites and browser-based applications
Voice, Video and even Screen Sharing become
standard capabilities of the modern web browser
7. API or VoIP 2.0?
WebRTC is more than an API...
It’s a simplified profile for real-time communications on the Web
Expect a wave of ‘WebRTC-compatible’ devices and non-browser platforms
Mobile, desktop embedded systems will soon begin shipping with compatible
stacks, thereby increasing the already staggering number of RTC-ready platforms
and devices.
8. Impact of WebRTC
✓ ‘Calling’ becomes a common feature within social networks and business
applications like Facebook, LinkedIn, and SalesForce.com
✓ Company websites become the contact center (i.e. real click to call)
✓ Tons of new collaboration and ‘virtual meeting’ sites will give products like
GoToMeeting and WebEx a run for their money.
✓ Mobile games makers will further incorporate live video and real-time image
processing to provide immersive augmented-reality experiences
✓ Home surveillance and remote monitoring are more convenient and affordable as
sensors, video codecs and network stacks become commoditized
✓ Expect terms like ‘life streaming’ and ‘crowd vision’ to enter the our lives
12. ROAP vs JSEP
ROAP was the initial attempt at providing an offer/answer model for
WebRTC. After some experimentation the working group
concluded that ROAP put too much state in the browser making it
difficult, and in some cases impossible, to implement a variety of
advanced use cases and failover models.
JSEP was introduced in Feb‘2012 to address these shortcomings
and is now the standard model for setting up PeerConnections
A great retrospective can be found in the JSEP proposal:
http://tools.ietf.org/html/draft-uberti-rtcweb-jsep-02
17. Putting it all together...
Caller creates new PeerConnection
• Invokes getUserMedia()
• Adds Stream to PeerConnection
• Sends stream ‘description’ to remote party
Callee received description and invokes createAnswer()
• Sends his own description to caller
Caller uses remote description to complete the connection
20. Signaling?!?
I thought WebRTC was P2P!
This is a common misunderstanding
WebRTC enables peer-to-peer media but the connection
must still be setup via some form of signaling.
Typical signaling involves the help of a web server with
enough context to route session descriptions to each
participating browser or network.
22. So what’s the protocol?
It’s whatever you want :-)
WebRTC does not specify a signaling protocol
The reasons are simple:
• WebRTC is a media technology (i.e. not just for calls)
• SIP is flexible but way too complicated
• Many sites like Facebook already do signaling
25. Picking a Web-signaling protocol
Web signaling introduces new challenges not generally
addressed by traditional signaling protocols
Some dimensions to consider when shopping for a
WebRTC stack:
✓ Single Sign-on
✓ Connection Resume
✓ Multi-endpoint Registration
✓ Mobile Notifications / App ‘Background’ Support
✓ Chattiness / Battery Life
31. Social Network Social Network
http://socialsite.cool Google http://socialsite.cool Google
Bob Alice
San Francisco New York
32. Web Identity = Web Context
Google
Jorge Rodriguez Acct #772635
Please describe the accident: “Hello Mr. Rodriguez, I see you
Call Now
Call Now got into a fender bender... “
Need help? Click to speak with an agent.
Call Now
37. Google
WebRTC Client SDK
WebRTC Gateway
SBG
Mobile
GW
HSS CSCF
38. WebRTC Frameworks
The lack of signaling coupled with incompatibilities between
WebRTC implementations has created a need for libraries and
frameworks to accelerate development and lower the barrier of
entry for new applications.
Just as jQuery normalized HTML rendering and event models
between browsers, this new wave of WebRTC frameworks will
provide longevity and backwards compatibility for developers;
allowing them to focus on features and creating value for their
users.
40. WebRTC Gateways
WebRTC Gateways are server-side nodes that bridge Web clients into an existing
network (e.g. Telco or Enterprise)
WebRTC Gateways will often perform basic protocol conversion and media
adaptation to ensure that both side can communicate without modification (e.g.
converting from SRTP to RTP)
However, not all gateways are created equal. Simply delivering SIP to the browser
and performing basic media conversion does not make for a quality user or
developer experience (especially on mobile).
Be sure to find a vendor with equal Web and Telco experience.
41. Gateway Evaluation Criteria
What is the signaling protocol? How well does it work on mobile connections and what is
the impact on battery life?
Does it was with both IMS and legacy MSC/CS network?
What identity models are supported? Telco only? Is that OK?
What codecs are supported? Opus to the endpoints is key for a quality experience.
What happens when users close their browser tab? How long does it take the network to
realize it’s gone?
How are users authenticated? Do they have to log in twice? How are credentials treated in
the browser? Are DTLS certificates used to verify identity?
What about mobile? How are incoming calls signaled when the app or browser is in the
background?
And most importantly: how quick can my vendor apply fixes and updates? WebRTC is still
evolving but the telco industry can’t afford to sit and wait. Gateway vendors must be able to
adapt quickly to web browser changes, regressions and incompatibilities.
50. Strategy #1 - Network Exposure
This is the most common API approach being taken by carriers
The idea is simple: open the network and charge for transactions and usage.
The main targets for this model are:
• 3rd Party Developers - Long Tail and Enterprise Customers
• 2nd Party Developers - Cloud Partners and System Integrators
• 1st Party Developer - Internal Teams use APIs to launch services
The challenge with this approach is that the focus is on the network instead of users
Networks are becoming commoditized. Aligning a strategy around the network does
not create incremental value for end users.
52. Strategy #2 - User Centric
Rather that build a platform around the network, start with amazing services and then
build a platform / developer ecosystem around your users
Model repeatedly proven by Internet companies
• Facebook was a website before it was a platform
• LinkedIn was a website before it was a platform
• Apple set out to build the world’s coolest phone before even considering an App Store
Happy users attract developers. Developers and apps attract more users.
53. User-Centric Network Effect
Users are the operator’s most valuable asset
Users represent data and potential customers for developers
In other words... users attract developers
Ameche enables developers to enhance the mobile experience thereby creating value
Value comes in the form of user satisfaction, new users and new revenue
Happy users produce more users; which attracts more developers
The cycle creates a positive network effect
Developer Developer Portal Operator CMO Network Apps Catalog Subscriber
Users Attract Developers
* AT&T logo used as a placeholder for demonstration purposes