Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Status of WebRTC across Asia by Alan Quayle +++

115 vues

Publié le

Status of WebRTC across Asia by Alan Quayle, and a group of leading experts contributing to the reality, not the hype, of WebRTC.

It’s 2020, WebRTC (Web Real Time Communications) became known in 2011 when Google open sourced intellectual property it had bought in previous years. Gossip about those acquisitions began in 2009. The IETF (Internet Engineering Task Force) was already laying the groundwork with Opus (voice codec) officially in 2010, and back in 2009 the discussion process started that became WebRTC. It’s been roughly one decade. Did WebRTC change everything? Is WebRTC everywhere?

WebRTC myths and misconceptions. Understanding the two components of WebRTC, the open source project, and the standards track.
Reviewing the achievements of WebRTC across Asia.
Understanding why ‘WebRTC’ companies such as Vidyo and Tokbox did not achieve big exits.
What is the current status of WebRTC, where are the standards, where is the innovation edge?
What is happening across Asia on WebRTC? Understanding the difference service providers adoption of WebRTC. Across telcos, CPaaS, UCaaS. CCaaS, in-app communication platforms, and enterprises.
Case studies on WebRTC implementation across Asia.
Recommendations for WebRTC in Asia.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Status of WebRTC across Asia by Alan Quayle +++

  1. 1. Let’s go back in time, to April 22nd 2013
  2. 2. WebRTC Workshop The HTML5 Real-Time Web April 22nd 2013 Pre-conference Workshop for the IMS World Forum Alan Quayle alan@alanquayle.com www.alanquayle.com/blog Jose de Castro jdecastro@voxeolabs.com www.voxeolabs.com 5/7/20 © 2013 Alan Quayle Business and Service Development 2
  3. 3. Objectives • Bring together deep technical and deep business thought leadership on WebRTC with Jose de Castro, Alan Quayle, and many of the audience to providing attendees with a unique independent workshop. • Provide a deep-dive quantified analysis of the WebRTC status, enabling attendees to understand what is likely to emerge over the next 18 months to 2 years, in this complex rapidly emerging ecosystem and what it will mean to their business. • Provide attendees with a series of WebRTC demonstrations, to share their experiences on implementing WebRTC, and provide ample networking opportunities at the end of the workshop to discuss and consolidate what has been learned through the day. 5/7/20 © 2013 Alan Quayle Business and Service Development 3
  4. 4. Structure (1 of 6) • Registration • 09:30 - Introduction to WebRTC and Initial Market Review o What is it and what it is not, o Cutting through the mis-information and hype o Non-technical introduction o Web browser implementation status o Taxonomy of suppliers / service providers o Codecs and devices - is certification necessary? o What is Google's aim? • 10:30 Standardization deep dive o Standardization process o Current status o Battles and likely outcomes o IETF and RTCWEB documents
  5. 5. Structure (2 of 6) • 11:30Technology deep dive o Peer connect API o Setting up local media and media flow o Protocols o WebRTC triangle / trapezoid o SIP, Jingle and the PSTN. • 13:00-14:00 Lunch • 14:00 What WebRTC means to Service Providers and IMS: o Extending enhanced communications services to web browsers o Impact on OTT (Over The Top) and existing voice, messaging, video and VAS o Impact of device compliance o Customer experiences and behaviors o Revenue, churn and relevance impacts • 14:30 What WebRTC means to enterprises: o Impact on Unified Communication and the Contact Center o Impact on company's website o Security and operational issues o Potential cost savings and innovations
  6. 6. Structure (3 of 6) DEMO TIME 15:00-17:00+ • Demo Time will be divided into 2 sessions, its aim is to be informal and provide ample networking opportunities for attendees to consolidate their learning from the workshop: • Demo presentation to the group: each demo will be 5 minutes long, and 5 minutes for questions; and • Demo one-on-one: attendees can chat one-on-one with the demo presenters, notionally 30 minutes but can run on into discussions at the bar through the evening.
  7. 7. Structure (4 of 6) DEMO TIME 15:00-17:00 • Zingaya ('Call' button for websites) o Embed a 'Call' button into the website. Visitors can click that button and the call is forwarded to the website operator's preferred land-line or mobile phone. All that is required is a website; all the visitors need is a browser and microphone. • Voxeo Labs (Ameche (new IMS/Web services), Tropo (leading call control API), Phono (Web comms innovation)). They will demo Phono’s three types of identity: o Anonymous Identity: user lands on web site and is able to call directly into the contact center o Web Identity: use your web identity (twitter, foursquare, etc) to call each other. o Telco Identity: Phono sessions can attach to the telco network and assume the real identity (phone number) of the subscriber, allowing calls to be routed to both the mobile and the browser simultaneously. • Telestax o Provides a complete stack from the client-side with Javascript JAIN SIP JS and WebRTC as well as the server side with our SIP Over WebSockets. The demo will be a WebRTC video conferencing and IM.
  8. 8. Structure (5 of 6) DEMO TIME 15:00-17:00 • Solaiemes WebRTC to Rich Communication Suite demo o Demonstration of RCS messaging and WebRTC to access to media components of devices to revamp the value of PSTN (and also mobile) lines. Shows how Unified Communications could be built just a mash-up of standards and APIs. • Quobis o Their approach to WebRTC is based on QoffeeSIP, a complete open source Javascript SIP stack that can be used in a website to exploit all the multimedia capabilities of WebRTC technology. Thanks to QoffeeSIP they have developed a corporate WebRTC webphone that can interop with different network devices; this webphone is going to be released at IMS World Forum event. • Huawei leading NEP o WebRTC / RCS insurance application demo
  9. 9. Structure (6 of 6) DEMO TIME 15:00-17:00 • Drum by NetDev (conference calls and online meetings) o Allows providers of fixed, mobile and next generation VoIP services to deliver audio conferencing as a direct, branded service. Hosted within your IP network on your servers, Drum audio conferencing is a standalone software solution with an integrated media server. • Bistri (Social Video) o Video chat with fun video effects, take screenshots of calls, share them with friends or social networks. Bistri runs in the browser, so there's no need to install additional software or plugins. • apidaze.io o Is a cloud communications API for developers with tools for building web or mobile communication services, with a special focus on WebRTC. The demo will show how a web developer can easily use the regular WebRTC API to place calls to external numbers and audio conference rooms accessible from the PSTN too, using a simple raw WebSocket connection that carries JSON text.
  10. 10. Introduction to WebRTC and Initial Market Review
  11. 11. What The Geeks Say Open, Nothing Proprietary No Plugs-Ins Multi Platform / Device
  12. 12. Real-time stuff for your browser with no plug-ins
  13. 13. M2M and Telematics
  14. 14. Surveillance & Monitoring
  15. 15. Lots & Lots & Lots of Devices
  16. 16. Embedding Communications Everywhere!
  17. 17. Warning we’re about to do quite a bit of time travel
  18. 18. Travelling thru’ time to 2020
  19. 19. Jumping to 2020 for a slide Massively oversimplifies the political landscape, as most vendors are in both standards bodies, but it shows the general bias. Browser vendors dominate Consensus oriented so browser vendors can not dominate
  20. 20. Travelling thru’ time to 2013
  21. 21. Codec Wars Opus, VP8 G.711, AMR- WB, EVS, H.264
  22. 22. Travelling thru’ time to 2020
  23. 23. Codec Wars Jumping to 2020 for a slide VP9AV1
  24. 24. Travelling thru’ time to 2013
  25. 25. Browser GetUserMedia PeerConnection DataChannel Chrome Yes Yes Q2 ‘13 Chrome for mobile Yes (March ‘13) Yes (March ‘13) Q2 ‘13 Firefox (desktop) Yes Yes Yes (first one) Firefox (mobile) Yes Yes Yes (first one) Opera Yes H2 ‘13 2014 Opera Mini H2 ‘13 2014 2014 IE (desktop) Chrome Frame / 2014 Chrome Frame / 2014 Chrome Frame / 2014 IE (mobile) 2014/2015 2014/2015 2014/2015 Safari (desktop) 2014/2015 2014/2015 2014/2015 Safari (mobile) 2014/2015 2014/2015 2014/2015 WebRTC is NOT Everywhere
  26. 26. Travelling thru’ time to 2020
  27. 27. Jumping to 2020 for a slide https://wpt.fyi/interop/webrtc?label=master&lab el=stable&aligned
  28. 28. Travelling thru’ time to 2013
  29. 29. Lies, Damned Lies, and Statistics
  30. 30. Travelling thru’ time to 2020
  31. 31. Jumping back to 2020 for a slide
  32. 32. Travelling thru’ time to 2013
  33. 33. Mobile is Even More Complex Native browser Natively in OS 2nd browser 3rd party SDK
  34. 34. Travelling thru’ time to 2020
  35. 35. Jumping to 2020 for a slide 80% 20%
  36. 36. Travelling thru’ time to 2013
  37. 37. Are you feeling travel sick yet?
  38. 38. There’s No Approval Process
  39. 39. In The Limit Which Browser Gives you the Best Experience?
  40. 40. WebRTC is a car without wheels!
  41. 41. WebRTC Triangle • Both browsers running the same web application from web server • Peer Connection media session is established between them • Signaling is not standardized, could be SIP, Jingle, MQTT, proprietary. Uses HTTP or WebSockets for transport Web Server (Application) Browser M (Running HTML5 Application from Web Server) Browser L (Running HTML5 Application from Web Server) Peer Connection (Audio, Video, and/or Data) 47Intro to WebRTC February 2013 The wheels!
  42. 42. We’re back in the 2020 from now on
  43. 43. But, but, but……. • Back in 2013 it seemed pretty baked, you showed all those cool demos running and working in multiple browsers • And in November 2017, the WebRTC 1.0 specification transitioned from Working Draft to Candidate Recommendation. Why hasn't it moved onto a Proposed Recommendation (PR) and final endorsement and a W3C Recommendation (REC)?
  44. 44. WebRTC is Trapped in Interoperability Pareto Jail: 5% of the features are taking 95% of the time to complete interoperability testing
  45. 45. WebRTC is Trapped in Interoperability Pareto Jail • WebRTC set the success criteria – it MUST BE INTEROPERABLE https://www.w3.org/2018/07/webrtc-charter.html o To advance to PR, each spec is expected to have two independent implementations of each feature defined in the specification. o To advance to PR, interoperability between the independent implementations (that is, bidirectional audio and video communication as well as data transfer between the implementations) should be demonstrated. • WebRTC 1.0 only “matters” to to a niche of governments or bodies that need standards for purchasing • But key features are still far from being interoperable. Server side needs to work hard at interoperability while browsers change (“enhance”) implementations all the time. • We’re still playing whack-a-mole on interop: SFU developers (Selective Forwarding Unit (WebRTC Uber geeks)) are always chasing after the latest browser or libwebrtc version, sometimes finding the changes only because something stops working.
  46. 46. When will WebRTC 1.0 be released from Pareto Jail? Maybe H2 2021, maybe…. Definitely 2022!
  47. 47. But, but, but……. • Why are WebRTC companies like Vidyo being sold at valuations below revenue? The recent CallStats.io acquisition is considered to contribute negligible revenue to 8X8.
  48. 48. Endurance Hunting: WebRTC by itself is difficult to make money, but its critical to the Future of Communications. You have to be in it to win it.
  49. 49. But, but, but……. • Why is WebRTC so complex? o Just look at https://www.w3.org/2011/04/webrtc/
  50. 50. Real Time Communications in the real world is complex AND Time has moved on, almost a decade • Original idea was to take pieces that were working in other services and reuse: SDP, DTLS, RTP, ICE, … This led to a very complex protocol layer and architecture. • Some of those existing pieces were quite immature and are being battle tested only with WebRTC. Others were simply a bad idea (SDP). • WebRTC required other standard bodies to develop specific pieces for it, such as how to use RTP for simulcast, etc. o It has taken a very long time and opens another field for political infighting, the companies that could not influence W3C had a field day at IETF. • Specs were not closed fast enough, so it took too many features that make components like SFUs brittle, hard to debug and test; and browsers even worse. • And it’s getting more complex: o RIPT, QUIC, AV1 codec, o End to end encryption: will Apple and Google for example agree on a common API so a platform can set that up for Chrome, Safari and a native iOS app? Not a WebRTC issue per se, but it will need to be resolved to deliver on the vision.
  51. 51. Yep, WebRTC is going to get even more complex
  52. 52. There are some great open source projects to help abstract some of that complexity
  53. 53. WOW! So what should I do? 1. Develop your own WebRTC-like system; 2. Build on your own using open source pieces and developing your own orchestration and management; 3. System integrators using open source and proprietary extensions and management platforms; 4. CPaaS with no professional services; 5. CPaaS partner; 6. Use one of the few vertically integrated specialized solutions fitting your use case.
  54. 54. 1. Develop your own WebRTC-like system • Example Zoom o Speculation: WebAssembly for their current web implementation, likely native application uses C/C++ optimized code. o Speculation: not only has customized encoder optimizing for specific screen sharing and camera resolutions. BUT MOST IMPORTANTLY: very tight feedback loop so encoder closely follows network changing conditions. o I know there are many Zoom-haters, I remain impressed how their video just works given my experience of many other services. • Pros o Control o Differentiated experience, e.g. video call continues to work, when other services would have stalled. Recorded sessions look surprisingly good. o Deliver built for purpose experiences o Avoids libwebrtc dependence - libwebrtc is the de facto standard implementation for WebRTC compliant clients, its behind Chrome, Firefox, Safari, Edge, etc. • Cons o Requires rare expertise – a few hundreds of people in the world can do this o May not be able to take advantage of device hardware acceleration (web implementation only) o Significant maintenance burned o Needs strong company culture: product discipline, fighting feature creep, and execution focus
  55. 55. 1. Seeing more more projects to avoid the libwebrtc dependency • There are a few independent implementations, personal projects, in languages like Python, Go. Can be used for custom applications, IoT, etc. o https://github.com/pion/webrtc o https://github.com/aiortc/aiortc o Tim Panton’s |pipe| stack now shares no code with libwebrtc, since they moved to a pure java opus implementation • https://twitter.com/steely_glint/status/1247442124385202177 • We are witnessing some breaking the dependency from libwebrtc o Especially for projects using data channels, and those not needing a browser. o Definitely potential for embedding inside applications on focused use cases.
  56. 56. 2. Build on your own using open source pieces and developing your own orchestration and management • Example: Building your own conference system using Janus or Jitsi server. Simwood have just launched their conferencing app with some customizations. • Pros o Jitsi and Janus are excellent open source projects, with smart teams o Jitsi – video conferencing with end to end encryption, funded by 8X8 o Janus – general purpose WebRTC Server developed by Meetecho (in Napoli) o Leverage expertise of Jitsu and Janus teams o Lots of other open source projects including for recording, whiteboarding, integration with PBX/PSTN, etc o If successful, it can make your organization target for M&A as reservoir for rare skills • Cons o Have to build own redundancy and scaling – which if the service is used internationally gets complex fast. High availability for real time communication services (very small hiring universe) is very different of high availability for web apps (larger expertise pool to hire from) o Relationship with the Janus and Jitsi teams is critical. Jitsi is funded by 8X8, so may need to have the capacity to fork the project. o Product culture and specific expertise on real time end-to-end communications, product, and UI/UX o Still dependent on WebRTC in the browser needs to be tracking Chrome and libwebrtc main bugs, features continuously – rare skills o Dependency on open source projects for tracking and fixing. They detect most of the high-risk issues, but their bandwidth is limited. What do you do if a high impact bug requires a Jitsi or Janus change but they take longer to fix than your service can afford?
  57. 57. 3. System integrators using open source and proprietary extensions and management platforms • Example: Quobis (remember them from 2013?) • Pros o Integrator tracks and manages open source projects, libwebrtc and browser o WebRTC and related complexity hidden (somewhat) behind a SDK o Integrator ready made components used as building blocks, tested and supported. Faster time to deployment and reduced risk. • Cons o Scaling concern reduced, partially relying on integrator, but still need a DevOps team and high availability expertise o Product culture and specific expertise on real time end-to-end communications, product, and UI/UX o Dependency on integrator, it could be a strategic or business concern. Likely M&A of rare skills providers (acquihire / endurance hunting) o Limited by custom components feature set and roadmap
  58. 58. 4. CPaaS with no professional services • Example: Uber with multiple CPaaS providers • Pros o CPaaS responsible for working around bugs and keeping compatibility between browsers and libwebrtc versions o WebRTC and related complexity hidden (somewhat) behind a SDK o CPaaS provide additional services: recording, integration with other services, etc o CPaaS provide certifications (HiPAA), critical for some verticals o Rely on the CPaaS provider to implement redundancy and scaling o Use a couple of CPaaS providers given abstraction, dual-source to reduce risk from CPaaS acquisition, like Uber • Cons o Cost of CPaaS o Dependency on CPaaS team and likely M&A of CPaaS providers (also on the roadmap and delay on implementing features) o Product culture and specific expertise on real time end-to-end communications, product, and UI/UX o Prioritizing your issues/wishes vs rest of customers in a large CPaaS can be difficult
  59. 59. 5. CPaaS partner • Example: Customers of Twilio, Nexmo (Vonage), VoIP Innovations (Apidaze), Simwood, etc. • Pros o CPaaS responsible for working around bugs and keeping compatibility between browsers and libwebrtc versions o WebRTC and related complexity hidden (somewhat) behind a SDK o CPaaS provide additional services: recording, integration with other services, etc o CPaaS provide certifications (HiPAA), critical for some verticals o Rely on the CPaaS provider to implement redundancy and scaling o Use a couple of CPaaS providers given abstraction, dual-source to reduce risk from CPaaS acquisition, like Uber o Partner can help with specific expertise on real time end-to-end communications, product, regulation, and UI/UX • Cons o Cost of CPaaS o Dependency on CPaaS team and likely M&A of CPaaS providers (also on the roadmap and delay on implementing features) o Product culture and specific expertise on real time end-to-end communications, product, and UI/UX o Prioritizing your issues/wishes vs rest of customers in a large CPaaS can be difficult o Very strong dependency on partner, if the service is critical for the company, the partner would become one of the strategic partners o Likely M&A of rare skills providers (acquihire / endurance hunting) o They can do a ‘Twilio’ on you and become a global competitor, ask Talkdesk
  60. 60. 6. Use one of the few vertically integrated specialized solutions fitting your use case. • Example: Zoom SDK, GoToMeeting API, etc • Pros o Ready-to-use service o Focus on customer experience o Removes need to rare skills • Cons o Vertical services are, by far, not as flexible as the other options. Very limited customization and differentiation within the RTC service. o Business proposition must be strong enough to differentiate from the vertical service itself (otherwise would be customers will directly use Zoom, or GoToMeeting) o Expensive based on cost per session or per minute. However, removes all the costs and risks associated to the previous options
  61. 61. Is WebRTC the right choice for my RTC project?
  62. 62. Any Questions? • Go to the TADSummit weblog on this presentation for a public discussion: http://blog.tadsummit.com/2020/05/20/status-of- webrtc-across-asia/ • Contact me directly alan@alanquayle.com

×