Vidyo has made several announcements in the past couple of weeks. Time to see why the time is right for RTC across markets.
It has been a busy month for Vidyo. It has made two interesting announcements:
Vidyo has been known for their video routing technologies for many years. Well before WebRTC came into the ring. It is great to see how they have come in merging the two, along with how they are trying to fit their business model to the realities of WebRTC.Vidyo, WebRTC, VP9 and SVC
How do you compete in a world where WebRTC is becoming the dominant media engine? Especially when the baseline implementation is dictated by what you get by default in the browser?
Vidyo has always had its own proprietary codec implementations. Ones that are optimized for SVC – Scalable Video Coding. Alex Eleftheriadis guest posted here last year with an explanation of SVC. To simplify, SVC gives two big advantages:
In many cases, you can get these things done without SVC and the end result would be good enough. But there are times when this extra kick to quality and optimization of how the network gets used makes all the difference.
When it comes to current browser implementations of WebRTC, the only video codec that has any kind of SVC support is VP9 and that takes place in Chrome. To take advantage of SVC, there are only two routes a company can take:
Option (1) is great, but it assumes that:
Reality is that on Chrome, the VP9 implementation in WebRTC supports SVC on the decoder side, but it doesn’t yet supports WebRTC in the encoder side.
Vidyo took the middle ground here, trying to enjoy both worlds: It always had its own SVC implementation in H.264 but allowed using WebRTC. Now, with its VP9/SVC implementation, it gets the freedom to improve video quality of its sessions in ways that others can’t.
If you use Vidyo.io today (and its other products in the near future), then Vidyo will try and prioritize the use of VP9 over other video codecs. And if some of the users in the session are making use of Vidyo’s SDKs instead of the native browser WebRTC implementation (i.e – joining from mobile or a desktop app), they will encode VP9 with SVC capabilities, and Chrome will be able to decode the bitsream – though the browser’s own encoded bitstream won’t be using SVC (at least not for now).
This places Vidyo ahead of the pack in SVC support that plays well with WebRTC.Vidyo’s Product Line
Here’s the gist of the new product live view from Vidyo:
Vidyo has taken the approach of offering a single technical infrastructure to host and run all of its products. This is the right move forward and an embrace of the cloud. In a way, Vidyo is continuing its shift from on premise deployments towards a Vidyo hosted and managed cloud platform.
Vidyo.io can be defined as CPaaS, a Communication Platform as a Service; while its VidyoCloud can be defined as UCaaS, a Unified Communication Platform as a Service.
Vidyo started life in the UC business, moving to the cloud and then adding an API platform. In many other cases, UC / UCaaS vendors take the approach of adding an API on top of their UCaaS product and then just calling it CPaaS. Vidyo decided on “separating” the two which feels to me as the better approach. It casts a wider net over the potential target market and the types of use cases that Vidyo can now cater for.
To this product line, Vidyo has added earlier this year VidyoEngage, its answer to video based contact centers.
The end result? Vidyo can now be used in the 3 biggest domains for visual communications:
You can use Vidyo.io to build a UC or a CC application if that’s your need, or you can just pick up VidyoCloud or VidyoEngage to get there.What’s Next?
The challenge for Vidyo will be in competing in 3 different fronts at the same time, and the threat of losing focus. I am guessing this is one of the reasons for this streamlining – it is meant to simplify its internal infrastructure that is used in these 3 products on the technical level.
Managing these separate businesses and keeping abreast in all 3 markets will be hard, but Vidyo is off to a good start here.
When it comes to Vidyo.io, the addition of VP9/SVC support positions Vidyo as the technology leader in its space with the ability to offer the best media quality. Its competitors will require
Jitsi is getting a boost in its development.
When a developers focused company gets acquired it is time to start worrying.
Was the acquisition due to the technology, the customers or the business model?
Will the product continue to grow and flourish in the new regime?
Are the current signed agreements going to be renewed?
For open source, there are even more questions.
How will the community that was created around the open source project be treated?
Will existing business models around support, customization and dual licensing be maintained or will they be killed?
Two and a half years ago or so we had 3 popular open source media servers for WebRTC: Janus, Jitsi and Kurento.
The progress made around Kurento since its acquisition was minimal at best. My guess is that Twilio is just too busy in getting its own multiparty video ready for GA to focus on the Kurento open source project itself. It also haven’t quite acquired everything that is Kurento – parts of it were left for the community and the original parent company Naevatec. The time passed is making a lot of the Kurento adopters frustrated and in search of different alternatives.Best time to join my WebRTC Course? Today. Office hours are starting next week, and there’s a great bonus ebook of how meet.jit.si built its scalable infrastructure.
So time to ask –
How did Jitsi fair since its acquisition?
And it seems to be getting a lot more interesting lately.
In the past 4 months, I’ve been adding almost on a weekly basis a post about Jitsi into the WebRTC Weekly. The team there has been continuously churning out new features into the project.
Here’s what was announced on the Jitsi blog since June when it comes to new features:
There’s a mix of announcements here. They range from addition of UX feature to some deep optimizations of the media server itself. And part of it is due to GSoC, Google Summer of Code, a project started by Google some years ago where university students can join open source projects as interns. Jitsi has been part of this project for some time now.UX Improvements
In a way, these are the least interesting features when it comes to a media server, but the ones that makes it easier to use.
What Jitsi did in this round was tweak the UI to be a bit more modern and easier to use. For video layouts, there was a decision to better cater for 1:1 scenarios and to move video thumbnails from the bottom of the page to the right side of the page. This is also what Google decided to do once they shifted away from Hangouts to Meet. This makes for a more modern approach that sits well with the wider displays we have in recent years.
An audio only button was added to the UI. I am assuming it is just a shortcut to muting incoming and outgoing video. Having this UI element there makes it easier for users to operate (and easier for adopters of the Jitsi Videobridge to customize).
The interesting addition to me is the speaker times one.
I am intrigued in this case to know how easy would it be for an application to get that information from the Jitsi Videobridge – is this supported via the signaling offered by Jitsi towards the web client or is it also available as a backend-to-backend REST API? I can see this being used later in various ways, assuming the API is detailed enough and easy to use.Integrations
A WebRTC media server is but a part of what you need to run a full application. While central and important, there are other aspects to it. In recent months, Jitsi have added a few additional integrations, making it easier to use and connect to.
Three such integration points were announced:1. Mobile SDK
Jitsi had mobile applications for quite some time. While nice, it is different than having a mobile SDK.
Something I’ve been telling media server vendors for a few years now, is that they should offer a mobile SDK as part of their media server. In WebRTC, it is an important part of their offering and one that is hard to ignore.
In the case of Jitsi, users had to use the mobile application as a reference and modify it to their heart’s content. The problem with this approach starts when you need to maintain the codebase in the long run. When a new version of the mobile app comes out – how do you know which parts are critical to upgrade (=without them the app will break with the new Jitsi Videoserver) and which ones are just UI fixes that you can ignore or just pass since you’ve created your own UI experience already?
This is exactly why an SDK is such an important aspect of the solution:
With a mobile SDK, application developers can now just use the Jitsi Meet mobile application as a reference or even write something from scratch on top of the mobile SDK itself. Each is independently updated and maintained, making it easier to upgrade to newer releases.2. Speech to text
Translation and NLP seems all the rage these days.
The way you get these things connected to WebRTC varies, but follows a similar approach for media servers:
You somehow collect the audio streams on the media server, mix and process them to the format supported by a 3rd party speech-to-text engine (Google Cloud speech-to-text seems quite popular these days), and once you get the resulting text, you do something with it.
In the case of Jitsi, this was a GSoC project. Information about its current status can be found on the developer’s website – Nik Vaessen.
This probably requires some more improvements and polish, but offers a good starting point for developers.
I’d wager that in GSoC 2018, the Jitsi team is planning on adding translation and text-to-speech to it.3. Telephony
Telephony was already available in Jitsi before. It is implemented via a Jigasi server (JItsi GAteway to SIP). Now Atlassian is eating its own dogfood and not only with its internal HipChat service but in its free meet.jit.si showcase service.
In the case of meet.jit.si, the length of calls was limited to 2 minutes, enabling hunting down meeting participants who haven’t joined the session.
This serves two purposes:
At the heart of Jitsi is the media server itself. This is what developers aim for to begin with and the additions there are quite interesting.
The first one is that Jitsi now supports peer to peer media traversal for 1:1 sessions – in effect – no media server. The reasoning being that many of the calls end up being 1:1 and it is far easier and cost effective to share media directly between the participants.
In the past, supporting such a thing with Jitsi required running a separate signaling mechanism for 1:1 sessions and then once the need arise to grow, shift and renegotiate everything in front of Jitsi. It was tedious at best.
The other work effort is way more interesting.
Bandwidth estimation is nasty. Network conditions are varying and dynamic. You can start a session with 2Mbps and have it considerably drop throughout the session, coming back up again and changing characteristics.
To get that right, WebRTC (and any other VoIP alternative) needs to use bandwidth estimation. This is a process where the device tries to understand how much bandwidth is available to him at any given point in time. The algorithm can be naive, smart, complex, whatever. And a lot of the perceived quality of a call would rely on the quality of the algorithm used for bandwidth estimation.
WebRTC has its own built in bandwidth estimation mechanism. It works. But you need your own algorithm in a media server. Jitsi has its algorithm, and it is work in progress.
The Jitsi team are now taking it to the next level, trying to not only understand availability of bandwidth but also what the best course of action should be – it is trying to discern if it is better to reduce bitrate or add forward error correction instead.
It also does that with the coolest set of tech tools available to us today – Tensor Flow and Machine Learning.
Here’s what Emil Ivov shared during our Kranky Geek event last month:Where to Next?
Looking for an open source alternative for your media server?
The most popular approaches out there for you are Janus and Jitsi.
Which one to pick out of the two seems to be based on personal taste more than anything else.Best time to join my WebRTC Course? Today. Office hours are starting next week, and there’s a great bonus ebook of how meet.jit.si built its scalable infrastructure.
Kranky Geek 2017 has been a roller coaster event for me. Time to discuss what I learned about the WebRTC last week.
Yap. We had a full room.
Well… More like 2 full rooms.
When talking to Lawrence some time in the afternoon, he joked with me, saying that apparently we have a problem – the overflow room is overflowing.
The best problem an event organizer could ever ask for.
If you are looking for the event videos, then they are already on YouTube.
I want to share some of my thoughts prior to the event and during to the event. And if possible, try and shed some light on where we’re headed from here.Want to keep abreast of the WebRTC ecosystem? Join the WebRTC Weekly Challenges Abound
Putting up an event is a stressful undertaking. There are a lot of aspects that needs to be covered with this constant worry that you’ll end up forgetting something or that something will screw you over. Both are guaranteed to happen no matter how much planning and effort you put into it.
This time, our challenges started early on. It was somewhat harder than usual to decide how to price the event to make it worthwhile doing. Kranky Geek events are expensive to run. From the beginning, we’ve aimed for events that are free to attend (I consider a $10 admission fee that gets donated as a free to attend event). This left us with covering our expenses and making some revenue out of it something that relies on sponsors.
Kranky Geek is all about quality content. High quality content. Top notch. The best you can find.
Which means that we select the topics we want. We then hunt for the speakers that fit into that. And we work with our speakers to make them shine.
This process doesn’t always work with sponsors… it is sometimes hard to explain how we operate and why. And at times, sponsors can focus on hard selling their warez, which doesn’t fit into the Kranky Geek spirit (and definitely not to our audience).
This time, it took us slightly longer than usual to get the sponsors onboard and to be certain that we can pull off the event.
We don’t always agree, but somehow we fit well together, each one covering the other one’s shortcomings. We make a good team for getting these events done. I hope
Why am I sharing all this?
To set the stage to what comes next for Kranky Geek, but also to explain the amount of work, effort,time, stress, pain and love that has been put into the Kranky Geek events in general and to this one in particular.
It hasn’t been all happy, but I am proud of the result and happy that we did this.We Had a Fire Drill!
During the day, we’ve had our share of technical challenges.
The projectors in the main room didn’t work at the beginning (that was before we started the day), and then a few other issues cropped up on us.
Doing this event in Google’s San Francisco office meant we had the best A/V team in the world on site to help us. The crew Google is working with there is top notch. The best I worked with. They made the problems seem easy to solve.
We had this to deal with…
— Lawrence Byrd (@LawrenceByrd) October 27, 2017
A week before the event we were told we will have a fire drill in the building on the day of the event. The time kept moving around, settling at 2pm. We’ve scheduled our breaks and sessions around it, with a huge worry of having people leave once the fire drill started.
(that’s Kranky going down the staircase during the drill)
We decided to embrace the fire drill and tried to celebrate it with our audience, and I hope we succeeded. Back from the fire drill, we had almost everyone back.
We should probably make fire drills an integral part of Kranky Geek events.
Time to stop rambling.The Event Recordings
The recordings are available online.
You can find them here.
We’ve had to reorder the sessions from our original agenda due to constraints we had with some of our speakers – late arrivals and early exits.
So I’ve reordered the sessions here. Following this, are the 13 sessions we had, in the original order we wanted (not that it really mattered).
I added some of my commentary on what I liked and learned in each of the sessions.Kranky Geek Team
Nothing to say here really, besides the fact that I envy Chad’s ability to create slides and present them.Facebook
This is the first time we had Facebook join us and share a story at Kranky Geek. We had the pleasure to have Li-Tal Mashiach an Engineering Manager at Facebook do the talk.
The numbers there are impressive as hell. 400 million monthly active users doing voice and video calls on Facebook Messenger using WebRTC. 400 million.
The next one who asks me if WebRTC is being adopted – I’ll just say 400 million. And then he’ll complain that this isn’t an enterprise application…
Anyways, what I found really interesting is how Facebook is dealing with optimization. The effort placed in the decision making process around video codecs, bitrates, etc.
WebRTC comes in a neat open source package that anyone can use. But it needs a lot more love and care when it comes to making it work at scale – just like any other technology.TokBox
Badri Rajasekar, CTO of TokBox, shared an experiment that TokBox has been running recently. It was about using head tracking technology to improve video quality.
The idea behind it is that you can scale up a region of interest in an image sacrificing other regions, which ends up putting more pixels encoded for these regions.
The great thing here, that you do it without touching the encoder or the decoder. Why do we want that? Because the more generic you can make an encoder, the easier it is to implement it in hardware.VoiceBase
Walter Bachtiger, Co-founder and CEO of VoiceBase talked about NLP (Natural Language Processing), and how great insights can be derived out of voice.
It was a bit of creepy, understanding how accurate machine learning can be at scale in a contact center.
The part I liked best in this one was how a contact center can decide within 30 seconds how likely you are to buy – if only the people who call me would have used it… it would have saved me a lot of time as a customer.Atlassian
Emil Ivov, Chief Video Architect at Atlassian, and a serial speaker at Kranky Geek gave a very interesting talk about machine learning and bandwidth estimation.
The team at Jitsi now use Tensor Flow to sift through metadata they have of calls to try and understand how the network behaves and what strategy would work best in improving network quality.
It seems like reducing bitrate doesn’t always have the necessary effect on things, and FEC might end up working better.Vidyo
Roi Sasson, CTO of Vidyo, talked about scale.
This wasn’t about how to scale a service, but rather how to scale a single call. Want 10 people on a call? You may not need to worry, but if you go to a 100 or a 1,000 – you need to think differently about it.
Which is where taking SFUs and cascading them, both within a single data center and geographically, starts making a lot of sense.WebKit
For the first time, we had a representative from Safari. We got to hear what Apple’s default browser does with WebRTC and how from Youenn Fablet, a contributor to WebKit.
It was great to have WebKit join us at Kranky Geek, and to hear their fresh thinking about privacy in WebRTC and how they’ve taken care of that in Safari.Peer5
Hadar Weiss, Co-founder and CEO of Peer5 talked about P2P CDN and using the WebRTC data channel.
We never did have a focused talk at the data channel in Kranky Geek, so this was a first.
I found really interesting how Peer5 does things differently than the rest of the WebRTC community. Mostly because they care less about call setup times and TURN connectivity and a lot more about throughput.
Hadar showed a few techniques I really liked, like the simple compression of SDP messages (which starts to make sense when you process and send millions of these a day).Slack
From Slack we had Lynsey Haynes and Andrew MacDonald.
Two things interesting about this session:
During the Q&A (which didn’t make it to the recording), Slack were asked about their support of Firefox. Andrew answered that support for Firefox is unlikely to come due to the shift of Slack towards focusing on less browsers and on their Electron-based desktop application. I see this thought process taking place elsewhere as well – it doesn’t bode well to the future of browsers.Twilio
Rob Brazier from Twilio showed an AR (Augmented Reality) use case.
I’ve never been a fan of these acronyms such as IOT, AR, VR. Marrying them with WebRTC always seemed to me somewhat forced.
That said, Rob did a great job in making a case for AR in communication interactions. I am sure more exist.Frozen Mountain
Anton Venema, CTO of Frozen Mountain was there to give an interesting demo.
He cobbled up text to speech, translation and speech to text to their media server platform, doing a demo of live language translation taking place in a WebRTC session.Google
Niklas Blum, Huib Kleinhout and Justin Uberti from Google shared the progress made in WebRTC towards WebRTC 1.0.
This one had a lot of details for developers about things they need to know with the latest versions of Chrome and what to prepare for moving forward.Appear.in
This year’s closing session was given by Philipp Hancke of appear.in. He’s a repeat speaker at Kranky Geek.
Philipp delved into NSFW (Not Safe For Work) related technologies, experimenting with recognizing such content and deciding what to do with it.
It was an interesting mix of technologies, human behavior and compromises.Our Event Sponsors
Did I already say that Kranky Geek relies of its sponsors?
This year we had 6 of them:
I’d like to again thank our sponsors.Diversity and Kranky Geek
For the first time, we had female speakers. Great female speakers.
I want more of this.
If you are a woman, or know of a woman. One that has technical WebRTC chops. And a desire to share your experiences. Contact me…What’s Next for Kranky Geek?
We weren’t sure if we will have another Krank Geek event. But due to the success of the one we just had, there’s high probability that we will do another one next year.
Get ready for Kranky Geek 2018.
With more great content, and maybe – a fire drill.
And while at it, if you increase your visibility in the market, know that sponsoring a Kranky Geek is a great way to go about it. So put some budget aside for it. Q3/Q4 2018 is where it will take place.Want to keep abreast of the WebRTC ecosystem? Join the WebRTC Weekly
The post Kranky Geek 2017: What Does the Pulse of WebRTC Tells Us? appeared first on BlogGeek.me.
How can you make a living from WebRTC? You offer WebRTC developer tools.
One of the interesting questions is around monetizing WebRTC. The truth is, it is hard to monetize a concept, or a piece of technology. Kranky said it well over 3 years ago – WebRTC Market Size (is 0).
What does this mean? That you can either make money by selling tools to developers who need WebRTC. Or you make money by offering a service that makes use of WebRTC, but we can now debate if that’s WebRTC or not.
Anything that isn’t WebRTC developer tools talls into other market niches – healthcare, education, gaming, … all these compete and create business far from the WebRTC core itself.Want to learn who’s offering WebRTC Developer Tools? Check out my WebRTC Developer Tools Landscape infographic.
WebRTC developer tools though – that’s where a small WebRTC market niche exist. And there are several ways to make money in this market. Here are 6 different types of services you can offer to sell WebRTC to developers – some will offer multiple services.#1 – Sell a Managed Service (SaaS)
You can sell a managed service.
Find something that developers need.
Create a service that offers that solution.
Sell it in XaaS model.
This market is rather challenging, as the name of the game is scale, and getting there is hard. For some reason, this is also where most customers end up penny pinchin.#2 – License Software
You can develop a product that others need and offer it under a commercial license.
There are those who want or need to run their own service, not relying on managed services. And at times, they are happy to pay for a commercial license that comes with an SLA and someone you can shout at and threaten.
The best thing about most commercially licensed software is that the people behind it work on that software. And once they have paying customers, they are bound by contracts to support and maintain it, usually for long periods of time.
Open Source doesn’t mean free.
People need to be able to make money out of their work – even if they are idealists who are just contributing to the community as a whole.
The way to go about doing that is by writing software that then gets distributed freely under an open source license. This allows anyone to take that software, use it, modify it and even try and contribute back to it and improve upon it.
For popular open source projects, this creates a nice feedback loop that everyone enjoys. For the most obscure projects, it remains the work of a single maintainer.
So how can someone make a living out of open source? By offering one of three different alternatives (usually a mix of them):
Jitsi, for example, was distributed under an LGPL license. This allowed the team behind it to make a living through all 3 approaches: support contracts, customization work and offering commercial licenses. After its acquisition by Atlassian, it switched from LGPL to a more lenient APL license. The main reason? Atlassian had other objectives for Jitsi and they weren’t about deriving direct monetary value from it. The Jitsi team no longer offers paid support or customization – it doesn’t mean they don’t support the code base, it just means that you can’t pay them for priority support.
Kurento got acquired by Twilio. Naevatec, the company behind Kurento made most of its direct revenue from Kurento by offering support and customization work. After the acquisition, Naevatec was left without its engineers that were experienced with Kurento and has since been struggling to maintain the Kurento codebase.
Janus is still an open source project. The company behind it offers support and customization work if someone needs it.
To be able to make a living out of an open source project, it needs to be one that is mission critical to the companies who use it, and it needs to be popular enough. If you plan on taking that route, remember that maintaining such a project can make you proud at the number of companies that end up adopting it, but may well frustrate you if you look at how many of these companies won’t be willing to pay for it at all.#4 – Conduct Analysis
This is something I wasn’t aware of up until several months ago.
There’s this interesting market niche in WebRTC, and I am not sure how prevalent it is with other technologies.
It is of companies and enterpreneurs who set out building a product with not enough knowledge and experience in WebRTC. They try to learn as they go along, floundering while at it. Many reasons why this happens:
When this happens, companies start looking for alternatives. And there really are only 4 things to do here:
Salvage is somewhat different from fixing, as it focuses on analyzing the whole architecture along with the implementation instead of just diving right in and continuing with the same approach that brought you to where you are in the first place.
You’re good with coding and know WebRTC?
Outsource it to others.
Many of the people who contact me are after developers with WebRTC experience. Some of them want to have these developers work as freelancers. Others want to outsource to a company. Others still are looking to recruit skilled workers, but understand they may end up outsourcing anyway.
There are quite a few companies and individuals who offer their outsourcing services around WebRTC.
The known freelancers who do WebRTC work are usually fully booked. It is hard to get their attention and time for new projects, but it is worth a try.
The outsourcing companies come in different shapes and sizes. Many don’t have the relevant skillset. Some will place inexperienced developers on your project. Some will do the best work for you.
Quality here varies greatly, so you should take the time to pick the right outsourcing vendor to work with.
In many cases, my role in such projects is to assist in deciding on the exact requirements, selecting the outsourcing vendor and “translating” the requirements between the company and the outsourcing vendor.#6 – Consult
There are those who simply offer consulting (I do that by the way).
Their role is to assist in the thought processes – be it the initial phases of helping in fleshing out the product’s roadmap and differentiation, assisting in the competitive analysis, in writing down the RFPs (or the response to an RFP), selecting vendors, suggesting architecture, etc.
Many of the experienced outsourcing vendors will usually add a consulting component into their service, and their customers will usually benefit from that consulting.What’s Next?
Looking to start a WebRTC project? Trying to understand how to get that done? Know that the market is dynamic and always changes.
Which is why I am in the process of updating two resources on my site:
Yes. We do need WebRTC events. Which is why you should join us at Kranky Geek next week.
I’ve been asked a few times in the past several months by people about events to go to.
Should I go to that event? Will it help me with my current WebRTC project?
What event should I go to, considering I am in need of WebRTC technology?
Where can I travel to learn about WebRTC? Is there a specific event?
Which event will guide me towards what I need with WebRTC? Have me understand the market dynamics? Be a place to mingle with the industry?Register for a Kranky Geek AMA webinar – a week ahead of our event, Chad Hart will be joining me to discuss WebRTC statistics and what to expect from this year’s Kranky Geek event
If you’re in telecom, then this is how you see WebRTC:
For telecom, WebRTC is just a piece of telecom. An evolution of it. Some way of getting the telecom and VoIP infrastructure into a web browser.
If you’re in web development, then this is how you see WebRTC:
For web developers, WebRTC seems just like another piece of the HTML5 technology stack. You learn a few JS APIs. Maybe some nifty CSS and a few HTML5 tags and you’re done.
And this is how I see WebRTC:
Now, most WebRTC related events so far have been initiated by people in the telecom industry. The end result is usually a very narrow prism of what WebRTC is what it is capable of achieving. And the side tracks done in the web related events? Most of them end up explaining what WebRTC is, not going nearly deep enough.
The end result has been unsatisfying. At least for me.
4 years into it, the question starts to crop up – do we still need WebRTC events?Why do we still need WebRTC events?
Is there still room with a WebRTC centric theme to it?
Shouldn’t WebRTC just be wrapped into all the telecom, communications and web events out there and be done with it?
I mean, we’ve got enough meetup groups around the world for this technology, but who wants to attend a longer event on WebRTC?
I think it boils down to that illustration up there – the one where WebRTC is smack in the middle of VoIP (telecom) and the web (internet). In a way, we’re still figuring out what that means exactly. How does the infrastructure of such a thing needs to be designed; how do you scale it; what kind of monitoring mechanisms do you need to have in place; what’s the team sizes, resources and time needed to get something from a proof of concept to production.
WebRTC might not be new, but the fact that it relies on a mix of technologies and disciplines make for a rather complex and interesting ecosystem.Join us at Kranky Geek SF 2017
Our next Kranky Geek event takes place on October 27 in San Francisco.
Kranky Geek is about WebRTC developers. Our role is to educate and share the experience coming from developers to developers.
The theme we’ve selected this time is twofold: implementation and beyond RTC.
We reached out to Youenn Fablet, who works on the WebKit WebRTC implementation. He will be speaking about iOS and Safari support of WebRTC.
Google will talk about their progress and roadmap of WebRTC.
Talking about Implementations, we will have Atlassian, Facebook, Peer5, Slack and Vidyo- each talking about different aspects of implementations and scaling.
Affectiva, TokBox, Twilio and VoiceBase will cover issues beyond RTC.
For our end-of-day session, we will have a repeat speaker at Kranky Geek – Philipp Hancke from appear.in – working his way around NSFW. Knowing Philipp (and seeing his draft slides), you definitely want to stick around for this one.Register for a Kranky Geek AMA webinar – a week ahead of our event, Chad Hart will be joining me to discuss WebRTC statistics and what to expect from this year’s Kranky Geek event
There’s a token admission fee in place, to control headcount and showups (free events tend to be under-attended, and we’re shifting away from that). The way this event ends up being funded is by our sponsors, who make this thing happen at all. They are part of our speakers and play an important role in the event itself.
See you at Kranky Geek.
How does Twilio Studio fit into Twilio’s Ask Your Developer campaign?
Last month I participated in Twilio’s Signal event that took place in London. I was invited to speak there on test automation in WebRTC. You can watch my video session on YouTube. That isn’t the point of this article though.
Signal is where Twilio announces most of its major new releases. Last time, earlier this year, it was all about the engagement cloud – a restructuring of how Twilio explains its services – and a migration from a single channel world into an omnichannel one. I’ve written at length about it in Is Twilio Redefining CPaaS (hint: it is). I wrote there:
Twilio has introduced a new paradigm for the way it is layering its product offerings.
In the process, it repositioned all of its higher level APIs as the Engagement Cloud. It stitched these APIs to use its lower Programmable Communications APIs, adding business logic and best practices. And it is now looking into machine learning as well.
It is a powerful package with nothing comparable on the market.
Twilio are the best of suite approach of CPaaS – offering the largest breadth of support across this space. And it is making sure to offer powerful building blocks to make developers think twice before going for an alternative.
I think that at Signal London 2017, they outdid that with the introduction of Twilio Studio.
Trying to figure out the best approach for developing your application? Check out this free WebRTC Development Paths Matrix to understand your alternatives
Get your WebRTC Development Paths MatrixBefore We Begin
You might want to take the time to watch Signal London 2017 keynote by Jeff Lawson.
A large part of the London keynote was a rehash of what was said in San Francisco earlier this year. It was about the shift towards omnichannel and the engagement cloud. The words that struck to to me when explaining the engagement cloud were BEST PRACTICES, BUSINESS PROCESSES, REINVENT THE WHEEL (=what not to do).
I’d like to touch in this articles a few main themes and approaches that Twilio is taking, which are shaping its vision and execution at the moment.“Ask Your Developer” is The Wrong Approach
I’ll start with where I think Twilio is missing the mark.
Ask Your Developer took center stage. Jeff Lawson wanted companies and the business people inside it to go ask their developers what they can do. How they can improve the business.
It gives us developers a great feeling of being in control. Of being valued. But for the most part, and for most developers, this is probably the wrong approach.
Most developers would be happy to work by spec.
The few that aren’t will be promoted quite fast to system architects, managerial roles in development or god forbid to product managers. Why? Because they can see the big picture.
They are the people that get asked. Or the people that answer without asking.
We should be asking our developers, but it should not be our strategy.
Which is where the miss came.
Twilio announced later on in the keynote Twilio Studio. A tool that takes some of that control from developers, putting it at the hands of decision makers.
You no longer have to ask your developer. You can work with him. Together.
More about this later.The Code that Counts
Some 20 minutes into the keynote, Jeff Lawson invited Patrick Malatack. He started with this:
It was core to how Twilio approaches its customers. Patrick explained that this is the most important code – it is the code that counts.
The idea being that your life as a developer should be made easy, so Twilio is adding not only APIs that serve the functions you need, but also a runtime behind it to facilitate rapid development and deployment – from helper libraries, to logging and debugging facilities, the new Twilio Functions, etc.
I think the code that counts here is developers focusing on their specific business problem – abstracting everything else.
It ended up being a concept of what Twilio Runtime is:
The yellow parts in that screenshot above are the newest announcements. The rest were there earlier. Twilio isn’t only adding more features to its platform – it is beefing up its runtime, making it another competitive advantage in front of many others where it comes to pure SMS and voice capabilities.
The message here is an interesting one, but it wasn’t polished enough. I think this is where we will see more in future Signal events from Twilio.Twilio Studio
It starts by explaining that building is fun but maintaining isn’t (he is correct).
The goal, based on Jeff Lawson, is to massively accelerate roadmaps of Twilio’s customers.
I think it is a lot more than that.
Because this is so new and fresh, still in developer preview (and something I’ve started playing with a bit), it is hard to write this in an ordered fashion. Which means I’ll be going for a bulleted list instead
This tool can do to contact centers what marketing automation is doing to email newsletters. If I were a contact center vendor… I’d consider Twilio Studio my biggest threat moving forward.Pricing
There were 3 price points for Studio:
Then there’s the question of what an Engagement is exactly. Is it a flow of a single event in a Flow? Is it a widget being accessed inside a Flow? In a 2-way bot conversation, each message exchange is probably an exchange I am assuming – the more talkative your app – the more Engagements it will eat up.
Not sure if I am missing a tier between PLUS and ENTERPRISE here. There seems to be too big of a gap in there.Positioning
One last thing – Twilio Studio has been positioned by Jeff Lawson inside the Engagement Cloud, below all of its current logical components:
I’d place it as a vertical bar next to the whole Twilio stack. Probably adding Functions write next to it:
My guess? Product management had a lot of internal discussions on this one, trying to decide where to place Studio – inside the engagement cloud, above it, right next to it. They ended up picking inside it.A Word About GDPR
GDPR stands for General Data Protection Regulation. It is a piece of legislation that will become effective May 2018, in less than a year. A period of two years of grace has been given to reach that date.
It deals with the protection and processing of private information of citizens of the EU, which practically covers any global player out there, and even many who aren’t.
In a nutshell, it is a headache. Especially if you’re making use of analytics, personalization, automation, chat bots, AI or any other big data related technology. It is also relevant if you just hold an SQL database of your customers.
If you were working in a specific regulated vertical, such as healthcare or finance, then you might be used to such things. If you’re not, then you should start paying attention. Especially with the communication part of whatever it is that you do – this is where personal information gets passed along with the metadata that needs to be handled with care.
Twilio pushing GDPR this early on means two things to me:
It also means that communication – telecom or IP based – is becoming slightly harder to handle. Something that works well for a vendor like Twilio whose purpose in life is simplifying complexity (=the more complexity the more value derived by Twilio).Where do we go from here?
Twilio was and still is the undisputed CPaaS king. They are bigger than anyone else by a large margin and they are working hard on maintaining a technology edge on everyone else.
The two main announcements here were Studio and GDPR. Studio brings Twilio to a larger audience and increases their vendor lock-in, whereby reducing the effectiveness of their competition. GDPR is put in place as another headache Twilio solves for its customers – the more regulatory and bureaucracy like GDPR the better for a company like Twilio – it reduces the competition from in-house developers – which is doubly important now.
These two announcements are there to deal with its perceived vulnerability. They make developing using Twilio easier than ever – almost risk-free. And it makes it harder for competition to succeed in future land grabs trying to go after Twilio’s bigger accounts.
It will be interesting to see how competitors would react to this in the long run, and even more interesting to see what will Twilio Studio grow into.
Trying to figure out the best approach for developing your application? Check out this free WebRTC Development Paths Matrix to understand your alternatives
Get your WebRTC Development Paths Matrix
The post Thoughts about Twilio Studio and the Future of CPaaS appeared first on BlogGeek.me.
No simple answer.
Apple recently announced that Safari will be supporting WebRTC. That support isn’t there yet to the point where it is stable enough, but we already know one thing:
Safari supports only the H.264 video codec.
Codec wars are over? 2 MTI (mandatory to implement) codecs in the form of VP8 and H.264?
Reality is that Apple decided at this stage not to support VP8 – and it hasn’t said anything about plans to support or not support VP8 in the future. That said, all signals indicate that support for VP8 in Safari is unlikely to happen.
This brings us to a simple yet challenging question:
When writing a WebRTC application. Should you make use of VP8 or H.264?
The answer isn’t a simple one. Choosing VP8 will leave you without Safari. Choosing H.264 will leave you without other important features and capabilities, as well as create a potential legal headache.
This is why I decided to create a new free video mini course – to guide you through the process and help you make the best decision here.
This video course, Picking a WebRTC Video Codec, is free and includes 4 lessons and a cheat sheet.
Find out which codec to use: VP8 or H.264
Looking for a WebRTC training? Search no more. My online WebRTC course is here.
I will be relaunching my Advanced WebRTC Architecture Course next week, so it is time to see what you’ll find in this WebRTC training program I’ve created and fine-tuned for over a year now.
Prefer watching and listening more than reading? Join my free webinar on Wednesday for a quick lesson on WebRTC architecture related topics, where I’ll also be explaining the WebRTC training course and its contents.
The sections below explain the various parts of this unique WebRTC training. These are decidedly focused on delivering the best learning experience possible.WebRTC Training Main Modules
The course is designed and built around 7 main modules:
Each module includes multiple lesson, and each lesson is a recorded video session of anywhere between 10-40 minutes of length. Most lessons also include additional links and some written content in them.
Module 1 gives you the baseline information about what WebRTC is. Consider it your introduction to the topic.
Modules 2-3 focus on signaling. They’ll take you from an understanding of UDP and TCP up to deciding what signaling protocol to use in each case and why.
Modules 4-5 are all about media. They explain voice and video codecs – in the context of their relevance to WebRTC. They also deal with the various media architectures available in group calling and recording scenarios.
Module 6 is all about the ecosystem. It lists the different strategies developers have in front of them when designing a WebRTC application, and then goes into details of each one of these.
Module 7 brings it all together. It takes different scenarios and use cases, analyzes them and builds the necessary architectures to support each use case. This is where the theory comes into practice.
The total length of the recordings in all modules and lessons? Over 15 hours.
You progress with the material at your own pace, jumping between lessons as you see fit, or through the original order they were laid out in.
If you’re looking for something to print and share, there’s a PDF version of the WebRTC course syllabus available.Get Your WebRTC Questions Answered in the Course Forum
The course itself is supplemented with an online forum.
I’ve been contemplating making that forum a Slack channel or a Facebook group. Decided against it. While that may change with time, the course does have a forum built into it.
When you enroll to the course, you also gain access to the forum, which is where you can ask questions and get answers to them.
At any point in time.
Be it about a specific lesson, or a challenge you have in what you’re currently doing at work with WebRTC.
And if sharing openly isn’t your thing, you can always just email me directly.WebRTC Training Office Hours
Twice a year, a series of office hours are provided for the course.
There are 12 such live sessions, taking place on roughly a weekly basis. They happen in 2 different times of the day, to fit different timezones.
These office hours include two parts in them:
The office hours are recorded and available for playback as well, so if you miss a session – you can always return to it and play it back.WebRTC Course Bonus Materials
Besides all the 7 course module, I’ve added a bonus module.
This one contains some extra lessons as well as cheat sheets and templates that are spread all over my site in an easy to reach location.
What lessons are in the bonus materials?
4 recorded lessons
The media algorithms lesson is really important. It covers topic that I touch only lightly during the course such as echo cancellation and jitter buffer.
2 recorded guest lessons
In my last round of the course, appear.in, who took the corporate plan, were also kind enough to share two new guest lessons:
Philipp Hancke and Bradley T. Hughes were the instructors for these two and I found myself learning a lot in these lessons as well. Now, they are part of the course bonus materials.What’s New in This Round of the WebRTC Course?
This is the third time I am running this course, and the second round of updates to it.
I am now adding an option to take my WebRTC training as part of every consulting project I take. Sometimes, the customer takes me up on the offer, and other times they don’t. There are questions that get asked almost all the time about the course by these customers, so I decided to answer the most common ones here.How long will it take to work through the WebRTC course?
It is entirely up to you.
There’s over 15 hours of recorded content in the course. More if you start going through the links, external slide decks and videos that I share in the course lessons.
But at the end of the day:
If you take a lesson in each working day, then 2 months is approximately what you’ll need to get from start to end.Is there any prerequisite to taking this WebRTC training?
This WebRTC training program assumes you have some good understanding of technology. The rest – it fills in with the various modules of the course.
You don’t need to have knowledge in VoIP to take this course. You don’t need to be a web developer either. What you do need, is to have some technical grasp and understanding.
If you already have prior knowledge, then that’s fine – this WebRTC course isn’t forcing you to take its modules and lessons by their order, so you can skip to the relevant topics that interest you.Is there a certificate?
As most online learning courses go, so too the WebRTC course offers a certificate.
Once you’ve completed the course, you will be receiving a WebRTC certificate indicating you’ve passed the course.
For companies, there’s a separate plan, which enables them to hold a badge of the WebRTC course. You can find the vendors that have taken this plan in the corporate partners page.What’s Next?
Want to learn more about media in WebRTC? Join this free webinar to see an analysis of a real case study I came across recently. What did the company had in mind to build and how they botched their architecture along the way.
And if you’re really serious, enroll to my Advanced WebRTC Architecture Course.