HTTP/2 is too good to pass.
If you don’t know much about HTTP/2 then check this HTTP/2 101 I’ve written half a year ago.
In essence, it is the next version of how we all get to consume the web over a browser – and it has been standardized and deployed already. My own website here doesn’t yet use it because I am dependent on the third parties that host my service. I hope they will upgrade to HTTP/2 soon.
Watching this from the sidelines, here are 4 good reasons why you should be using HTTP/2. Not tomorrow. Today.#1 – Page Load Speed
This one is a no-brainer.
A modern web page isn’t a single resource that gets pulled towards your browser for the pleasure of your viewing. Websites today are built with many different layers:
- The core of the site itself, comprising of your good old HTML and CSS files
- Images and videos. These may be served from your server or via a CDN
At the time of writing, my own website’s homepage takes 116 requests to render. These requests don’t come from a single source, but rather from a multitude of them, and that’s when I am using weird hacks such as CSS sprites to reduce the number of resources that get loaded.
There’s no running away from it – as we move towards richer experiences, the resources required to render them grows.
A small HTTP/2 demo that CDN77 put in place shows exactly that different – they try loading 200 small images to a page in either HTTP/1.1 or HTTP/2 shows the improved load times of the page.
HTTP/2 has some more features that can be used to speed up web page serving – we just need to collectively start adopting it.#2 – Avoiding Content Injection
In August, AT&T was caught using ad injection. Apparently, AT&T ran a pilot where people accessing the internet via its WiFi hotspots in airports got ads injected to the pages they browsed over the internet.
This means that your website’s ads could be replaced with those used by a third party – who will get the income and insights coming from the served ads. It can also mean that your website, that doesn’t really have ads – now shows them. The control freak that I am, this doesn’t sound right to me.
While HTTP/2 allows both encrypted and unencrypted content to be served, only the encrypted variant is supported by browsers today. You get the added benefits of encryption when you deploy HTTP/2. This makes it hard to impossible to inject 3rd party ads or content to your site.#3 – Granularity
During that same August (which was the reason this post was planned to begin with), Russia took the stupid step of blocking Wikipedia. This move lasted less than a week.
The reason? Apparently inappropriate content in a Wikipedia page about drugs. Why was the ban lifted? You can’t really block a site like Wikipedia and get away with it. Now, since Wikipedia uses encryption (SPDY, the predecessor of HTTP/2 in a way), Russia couldn’t really block specific pages on the site – it is an all or nothing game.
When you shift towards an encrypted website, external third parties can’t see what pages get served to viewers. They can’t monetize this information without your assistance and they can’t block (or modify) specific pages either.
And again, HTTP/2 is encrypted by default.#4 – SEO Juice
Three things that make HTTP/2 good for your site’s SEO:
- Encrypted by default. Google is making moves towards giving higher ranking for encrypted sites
- Shorter page load times translate to better SEO
- As Google migrates its own sites to HTTP/2, expect to see them giving it higher ranking as well – Google is all about furthering the web in this area, so they will place either a carrot or a stick in front of business owners with websites
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
Some aspects are now table stakes for WebRTC API Platforms.
There are 20+ vendors out there who are after your communications. They are willing to take up the complexity and maintenance involved with running real time voice and video that you may need in your business or app. Some are succeeding more than others, as it always has been.
So how do you as a potential customer going to choose between them?
Here are a few things I’ve noticed in the two years since I first published my report on this WebRTC API space:
- Vendors are finding it hard to differentiate from one another. Answering the question to themselves of what they do better than anyone else in this space (or at least from the vendors they see as their main competitors) isn’t easy
- Vendors often times don’t focus. They try to be everything to everyone, ending up being nothing to most. You can see what they are good for if you look from the sidelines, feel how they pitch, operate, think – but they can’t see it themselves
- Vendors attempt to differentiate over price, quality and ease of use. This is useless.
Most vendors today have pretty decent quality with a set of APIs that are easy. Pricing varies, but usually reasonable. While some customers are sensitive to pricing, others are more focused on getting their proof of concept or initial beta going – and there, the price differences doesn’t matter in the short to medium term anyway.
The problem is mainly vendor lock-in, where starting to use a specific vendor means sticking with it due to high switching costs later on. But then, savvy developers use multiple vendors or prepare adapter layers to abstract that vendor lock-in.
Vendors need to think more creatively at how they end up differentiating themselves. From carving a niche to offering unique value.My Virtual Coffee
This is the topic for my first Virtual Coffee session, which takes place on October 14.
It is something new that I am trying out – a monthly meeting of sorts. Not really a webinar. But not a conference either.
Every month, I will be hosting an hour long session:
- It will take place over a WebRTC service – I am dogfooding
- It will cover a topic related to the WebRTC ecosystem (first one will be differentiation of WebRTC API Platform vendors)
- It will include time for Q&A. On anything
- Sessions will be recorded and available for playback later on
- It is open to my consulting customers and those who purchased my report in the past year
If you are not sure if you are eligible to join, just contact me and we’ll sort things out.
I’d like to thank the team at Drum for letting me use their ShareAnywhere service for these sessions – they were super responsive and working with them on this new project was a real joy for me.Virtual Coffee #1 Title: WebRTC PaaS Growth Strategies How WebRTC API vendors differentiate and attempt to grow their business When: Oct 14. 13:30 EDT (add to calendar) Where: Members only What’s next?
Want to learn more about this space? The latest update of my report is just what you need
Some people are fidgeting on their chairs now, while others are happier than they should be.
I’ll start by a quick disclaimer: I like Google. They know when you acquire companies to fit my schedule – just got back from vacation – so I actually have time to cover this one properly.
Let’s start from the end:
Google and Apple are the only companies that can make RCS a reality.
To all intent and purpose, Google just gave RCS the kiss of life it needed.
Google just acquired Jibe Mobile, a company specializing in RCS. The news made it to the Android official blog. To understand the state of RCS, just look at what TechCrunch had to say about it – a pure regurgitation of the announcement, with no additional value or insights. This isn’t just TechCrunch. Most news outlets out there are doing the same.
* Dataset subscribers have the acquisitions table updated with this latest information
Why on earth is Google investing in something like RCS?RCS
RCS stands for Rich Communication Suite. It is a GSMA standard that has been around for a decade or so. It is already in version 5.2 or so with little adoption around the world.
What is has on offer is an OTT-style messaging capabilities – you know the drill – an address book, some presence information, the ability to send text and other messages between buddies. Designed by committee, it has taken a long time to stabilize – longer than it took Whatsapp to get from 0 to 800. Million. Monthly active users.
The challenge with RCS is the ecosystem it lives in – something that mires other parts of our telecom world as well.
Put simply, in order to launch such a service that needs to take any two devices in the world and connect them, we need the following vendors to agree on the need, on the priority, on the implementation details and on the business aspects:
- Chipset vendors
- Handset vendors
- Mobile OS vendors
- Telco vendors
Call it an impossible feat.
In a world where Internet speeds dictate innovation and undercut slower players, how can a Telco standard succeed and thrive? The moment it gets out the door it feels old.Google and Messaging
Google has many assets today related to messaging:
- Android, the OS powering 1.4 billion devices, where 1 billion of them call home to Google’s Play service on a monthly basis
- Hangouts, their own chat/voice/video service that is targeted at both consumers and enterprises. It is part of Android, but also works as an app or through the browser virtually everywhere
- Firebase, a year-old acquisition that is all about powering messaging (and storage) for developing apps
As Kranky puts it, they were missing an iMessage service. But not exactly.
Google thrives from large ecosystems. The larger the better – these are the ones you can analyze, optimize and monetize. And not only by building an AdWords network on top of it.
The biggest threats to Google today, besides regulators around the globe, would be:
- Apple, who is doing its darnedest today to show off their better privacy policies compared to Google
- Facebook, who is vying after Google’s AdWords money with its own social network/ads empire
- Telcos, who can at a whim decide to shut off Google’s ambitions – by not promoting Android, making it hard for YouTube or other services to run, etc.
Getting into RCS and committing to it, as opposed to doing a half witted job at an RCS client on vinyl Andorid, gives Google several advantages:
- It puts them at the good side of Telcos, which can’t be bad
- Improves Android’s standing as an ecosystem, and making it easier for Google to force the hands of handset manufacturers and chipset vendors in adjacent domains
- Maybe getting the codecs they want embedded as part of the device for example?
- Forcing improvements on mobile chipset designs that offer better power management/performance for all messaging apps
- Opens the door to deeply integrating Hangouts with RCS/Telco messaging
- Enabling Google to become the gateway to the telco messaging space
- Got a device running Android? An RCS client is already there and running
- Don’t have Android? Connect through your browser from everywhere
- Or just install that Google RCS app – it already has a billion downloads on it, as opposed to a measly 5,000 downloads of an operator-brand app
- Becoming the glue between consumer and enterprise
- Hangouts may well be a consumer type of a product, but it is part of the Google Apps offering to enterprises
- Carriers are struggling in monetizing consumer services these days besides connectivity, and Google is fine with giving consumers a free ride while making money elsewhere
- Google is struggling with getting into the enterprise space. Hangouts is marginal compared to Microsoft Lync/Skype and Cisco
- Offering direct connectivity to the carrier’s messaging for consumers can bridge that gap. It increases the value of RCS to the enterprise, making Google a player that can integrate better with it than competition
Beside being a nice signal to the market about seriousness, Jibe offers a few advantages for Google.
- They are already deployed through carriers
- Their service is cloud based, which sits well with Google. It means traffic goes through Jibe/Google – something which places Google as the gateway between the customer and the Telco – a nice position to be in
In a way, Jibe isn’t caught up in the old engineering mentality of telco vendors – it provides a cloud service to its customers, as opposed to doing things only on premise. While Google may not need the architecture or code base of Jibe Mobile, it can use its business contracts to its advantage – and grow it tenfold.
When your next RCS message will be sent out, Google will know about it. Not because it sits on your device, but because it sits between the device and the network.Why will Telcos Accept this?
They have no choice in the matter.
RCS has been dead for many years now. Standardization continues. Engineers fly around the world, but adoption is slow. Painfully slow. So slow that mid-sized OTT players are capable of attracting more users to their services. It doesn’t look well.
And the problem isn’t just the service or the UI – it is the challenge for a carrier to build the whole backend infrastructure, build the clients for most/all devices on its network and then launch and attract customers to it.
Google embedding the client front end directly into Android and a part of the devices means there’s no headache in getting the service to the hands of customers and putting it as their default means of communications.
Google offering the backend for telcos in a cloud service means they no longer have to deal with the nasty setup and federation aspects of deploying RCS.
Only thing they need to do is sign a contract and hit the ground running.
An easy way out of all the sunk costs placed in RCS so far. It comes at a price, but who cares at this point?The End Game
There are three main benefits for Google in this:
- Selling more Google devices
- If these devices come equipped with RCS, and their backend comes from the same Telco and operated by Google, then why should a Telco promote another device to its customers?
- It isn’t limited to Android versus an iOS device – it also relates to Chrome OS versus Windows 10
- When mobility needs will hit tablets and laptops and the requirement to be connected everywhere with these devices will grow, we might start seeing Telcos actually succeeding in selling such devices with connectivity to their network. Having RCS embedded in these devices becomes interesting
- The next billion
- Facebook and Google are furiously thinking of the next billion users. How to reach them and get them connected
- With RCS as part of the messaging service a Telco has on offer, they are less dependent on third party apps to connect
- With Google having both RCS and Hangouts, it increases the size of their applicable users base and the size of their ecosystem
- Carrier foothold
- Carriers are reluctant when it comes to Google. They aren’t direct competitors, but somehow, it can feel that way at times – Google Fiber and Google Fi are prime examples of what Google can do and is doing
- This is why having cloud services owned by Google and connected to the heart of a Telco is enticing to Google. It gives them a better foothold inside the carrier’s network
Not really here. Or almost not. It isn’t about WebRTC. It is about telecom and messaging. Getting federated access that really works to the billions of mobile handsets out there.
Jibe has its own capabilities in WebRTC, a gateway of sorts that enables communicating with the carrier’s own network from a browser. How far along is it? I don’t know, and I don’t think it even matters. Connecting Jibe RCS cloud offering to Google Hangouts will include a WebRTC gateway. If it will or won’t be opened and accessible to others is another question (my guess is that it won’t be in the first year or two).
An interesting and unexpected move by Google that can give RCS the boost it desperately needs to succeed.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
Lots of Node. Little of WebRTC.
It has been quite some time since my last WebRTC book review. So when I got an indication that there is another book with WebRTC inside it, I had to read it. Which is what got me to Multiplayer Game Development with HTML5 by Rodrigo Silveira.
The promise of WebRTC in this book? Learning to “create peer-to-peer gaming using WebRTC”. I was intrigued. Spent reading it a few hours – and was happy about it, even though the WebRTC part of it was limited in its value.
This book takes the reader into a “Hello World” implementation of an online HTML5 multiplayer game. It is done by taking a step by step approach to implementing the classic snake game. First in HTML5, using a backend. And then by building on top of it all the rest.
The book itself is focused on Node.js development of the game, taking care to explain and use concepts of authoritative game servers – servers that make the main decisions in a game. It connects that to responsiveness and fluidity of the game, etc.
To those interested in real time communications, this is an interesting book. It has a lot of the same thought processes of developing signaling protocols and implementing their backend, dealing with responsiveness, latency and causality of message passing. It also handles the game lobby – the place where you connect players – you can view this as a conferencing server (the signaling part of it).
Rodrigo mentions WebRTC almost in passing – as a way of reducing latency by making use of the data channel in WebRTC, but that’s about it. There’s no real discussion or example of how to integrate it in a multiplayer game where you have an authoritative server and clients that communicate directly with each other at the same time.
That said, I felt the book is an interesting one for those developing WebRTC – and it wasn’t because of the WebRTC parts of it.
If you are interested in architecture, design, signaling or just programming – this book is a really interesting read.
I warmly recommend it.
The post WebRTC Book Review: Multiplayer Game Development with HTML5 appeared first on BlogGeek.me.
An update to my WebRTC API Platforms report is now available.
The last time I published an update of my Choosing a WebRTC API Platform report was 6 months ago. Since that time the market has changed quite a bit. If I had to note the most important aspects of that change, they would be:
- AT&T and Unify getting into the game of WebRTC PaaS
- Twilio introducing video support, and then full portfolio of communication APIs
- Cisco acquiring Tropo
- Comverse acquiring/merging with Acision and then rebranding as Xura
These frequent changes made it into the latest update to my report, along with an addition of 4 vendors (AT&T, Bistri, Bit6 and Circuit). This with the updates of what vendors are doing didn’t seem enough to cover the market properly. Which is why I have decided to open a membership section on my website to go along with the report.New membership area (and tools)
What does this membership section includes?
- An online vendor matrix – one that will get updated a bit more frequently than the report itself. Purchasers of the report, under a valid subscription account will be able to access this online vendor matrix whenever they want and see what features companies have on offer. It should be a quick way to decide which vendors you should be looking at for the feature set you are looking for
- Visuals – I’ve taken the visuals and tables from the report, compiling them into a simple Powerpoint deck. You can download the deck and copy+paste from it whatever you need for your own presentations
- Monthly Virtual Coffee with Tsahi – a new monthly “webinar” of sorts open only to the report subscribers and my consulting clients, where I’ll be discussing the ecosystem as well as open the floor to any questions related to real time communications
So. If you purchased the report within the last year or have renewed your report’s subscription, you’ll be getting immediate access to the membership area and its tools – an email will be sent to you today with the necessary details.Overview and sample vendor
If you want to learn more about the report, you can download the report’s table of contents and introduction section.
This time, I also wanted to give people a taste of what they’ll find in the report itself. To that end, I’ve asked AT&T to sponsor the vendor analysis section covering their platform and WebRTC APIs and they accepted. There are 23 vendors covered in the report in detail. The AT&T one is now freely available to download – you can expect the same level of detail on all other vendors in the report.New pricing
This brings me to the last item, which is pricing.
There are now two price points for the report:
- Basic, at $1700, which is what was included until today for a higher price point (essentially, the report and any updates within a year from purchase)
- Premium, at $1950, which is the lowest earlier price point, which grants access to the new membership area
Want to learn more, or understand how the market is changing by non-API players? I am hosting a free webinar later today:
Development Approaches of WebRTC Based Services: There are many ways in which people approach adding real-time communications with WebRTC to their service. While the dominant approaches are probably self development and using a WebRTC PaaS vendor, there’s a wider range of approaches.
Got questions? Feel free to ask them in the comments area below or by contacting me directly.
The post My WebRTC API Platforms report Gains a Membership Portal appeared first on BlogGeek.me.
4K isn’t part of the current round of fighting.
A quick disclaimer: I own a Chromecast dongle. I don’t use it much. My daughter plays Just Dance Now every couple of days on it. And sometimes we watch our pictures on the large screen. So I can’t be called a true user of these devices.
That said, these devices are heavily used for streaming, which means video, which means a video codec. Which means I am a bit interested in them lately. Especially now with the H.265 crisis and the newly found Alliance for Open Media.
We had two launches lately and rumors of a third one. Let’s look at each one of them from the prism of codec support and resolution.Apple TV
Apple TV has its issues with the web. The spec of this upcoming device, from Apple’s website, include the following video formats:
H.264 video up to 1080p, 60 frames per second, High or Main Profile level 4.2 or lower
H.264 Baseline Profile level 3.0 or lower with AAC-LC audio up to 160 Kbps per channel, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats
MPEG-4 video up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Simple Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats
Running an A8 chip, it can be deduced that it might actually have H.265 capabilities, but Apple decided to not use them for the time being – the same way it removed H.265 from FaceTime on the iPhone 6.
They also aren’t going overboard with the resolution, sticking to 1080p, streamed with H.264. The nice thing here is their 60 fps support.
There’s no 4K though. And no H.265.Amazon Fire TV
Amazon announced its own response to the Apple TV a day after the Apple TV announcement. As with all classic after-Apple announcement, this had the two obvious features: lower price point and better hardware.
The better hardware part boils down to support for 4K resolutions.
The specs indicate the following content formats:
Video: H.265, H.264, Audio: AAC-LC, AC3, eAC3 (Dolby Digital Plus), FLAC, MP3, PCM/Wave, Vorbis, Dolby Atmos (EC3_JOC), Photo: JPEG, PNG, GIF, BMP
So higher resolutions probably get streamed at H.265 while everything else is H.264.
Here’s the rub though:
- Amazon is now part of the Alliance for Open Media – created to ditch royalty bearing codecs such as H.265
- The HEVC Advance announced their intent to leech ask payment based on streamed content and not only devices sold. How does that get calculated into a low margin retailer such as Amazon?
This is a hardware device. No real option to add or replace video codecs easily – at least not at such high resolutions. They worked on this one for over a year, so they couldn’t have foretold the mess that H.265 patents will be today. They didn’t want (or couldn’t) risk it with VP9. So now what?
Will this 4K device be useful for watching Amazon video movies at 4K? How higher will these need to be priced to deal with the royalty headaches of H.265?
Google’s YouTube service certainly isn’t going to support H.265 for its 4K streams anytime soon.
Can’t see 4K using H.265 on a hardware device in 2015 the right choice. Sorry.Google Chromecast
Only rumors for now, but it seems this one will be announced on September 29th. We will know soon enough how stupid my estimates really are.
Here we go – these are my own estimates:
- We really know little about the Chromecast’s specs. Even the one on the market – no clue on the video codec in it. It might be VP8 or H.264. My bet is on H.264 on the older model
- The new Chromecast won’t support H.265. It will have support for H.264 and VP9
- It won’t do 4K. It will focus on software related features to beat competition
- VP9 will be there to better work with YouTube’s new VP9 support and reduce bandwidth strains on both Google and the end customer
We will see in a a week how I fared on this one.Bottom Line
While 4K is a higher resolution than 1080p, it is too new and too niche at this point:
- There aren’t enough TVs out there supporting 4K
- There’s not enough content available
- No one decided way of compressing such resolutions (with a nice patents minefield to go along with it)
- And there aren’t many viewers who will be able to see the difference anyway
Kranky and I are planning the next Kranky Geek - Q1 2016. Interested in speaking? Just ping me through my contact page.
The post Apple TV, Amazon Fire TV or a new Google Chromecast Dongle – 4K Won’t Matter appeared first on BlogGeek.me.
Yes and no.
Microsoft just announced officially that they have added ORTC to Edge. ORTC is… well… it’s kind’a like’a WebRTC. But not exactly.
Someone is doing his best NOT to mention WebRTC in all this…
Here are a few random thoughts I had on the subject:
- It is more about WebRTC than it is about ORTC. Even though WebRTC was mentioned only half as much as ORTC in the text and never in the title (god forbid)
- Getting “Hello World” to work on ORTC is harder than with WebRTC. Or it might just be me knowing WebRTC betther than ORTC
- It was perfectly timed to coincide with Skype’s own support for it
- Voice using Opus is a win. I wonder when we will see interoperability for a voice call between Edge and Chrome
- Video using H.264UC (=proprietary) and later H.264 with no mention of VP8 or VP9 is a loss. Not for Microsoft but for the industry
- Codecs, especially video ones, are going to cause major headaches moving forward. I wonder how web developers will swallow this sour pill
- Will developers start using H.264 instead of VP8 now that it is apparent all browsers supporting WebRTC in 2016 will have H.264, but some won’t have VP8?
- While Windows 10 is showing promise in its adoption (and aggressive push by Microsoft), the adoption of Edge is worrying. If numbers don’t increase, will it even matter if ORTC is there or which codecs Microsoft chose to incorporate?
- The whole idea of getting Microsoft onboard is to get enterprises market share for WebRTC – where no other browser than Microsoft’s can penetrate. But if Edge isn’t there – then who really cares? It may well be like testing your service runs well on Opera (I am sure you did)
- Here’s the rub though:
- ORTC by the way isn’t a standard. It is a W3C Community Group
- To get things into the HTML5 spec, ORTC needs to contribute their proposals to the W3C WebRTC Working Group
- This process means that the APIs may change until it actually get standardized by W3C
- It makes ORTC APIs less stable than those of WebRTC, and we’ve seen how people complained about the frequent changes in the browser APIs of WebRTC
- Can Microsoft maintain this process?
- This means that the next version of Edge will have different APIs for ORTC than the current one, and that this will continue for at least a year if not longer
- Microsoft will need to release Edge at the same frequency that Google releases Chrome – every month or two
- It will also need to handle deprecation of APIs at a fast pace – can its target customers (enterprise) handle that?
All in all, another good indicator for the health of this community and real time communications in the web.
For a real analysis, read Alex’s ruminations on ORTC in Edge.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
There are a few side stories around Apple lately that relate to WebRTC. I wanted to share them here.
It seems that in the Apple TV reboot, there are going to be apps. But not ones that can make use of HTML5. Just native apps. John Gruber points to a post around that topic titled Everything but the Web, concluding that Web views won’t find their way to the TV screen if Apple has anything to do with it.
He doesn’t state the reason though. If you ask me, this has nothing to do to the Apple/Flash war of the past. It also has nothing to do with design or aesthetics. It has anything to do with ecosystem control. For Apple, the ability of cross platform development is an aberration. Why on earth enable developers to write their code once and then run it elsewhere? There’s nothing outside the closed garden of Apple, so why bother?
Killing HTML5 in Mac is impossible. Killing it on the iPhone or iPad is also rather hard – too many apps already use it, and there’s that pesky browser people use. But on the TV? That’s greenfield! So why not just forget about HTML5 altogether?
If you ask me, the good people in Apple see only one reason for HTML5 to exist – and that is for people to be able to go to apple.com website. Other than that? Useless.The future of WebKit
There have been a lot of back and forth lately about the future of the web. Should we run full steam ahead with it or sit and wait. People prefer having it change and progress less. I can’t see why – when every year thousands of new APIs are rained at us by Apple and WWDC and Google at I/O – why can’t the Web improve? Why should it stay static?
I’ve written before on how Microsoft Edge is getting way better. Mozilla is getting their act together and modernizing the older parts of their Firefox browser (extensions for example) and Google are speeding up and optimizing Chrome now that it has become huge. But Safari? Microsoft Edge will keep Google and Mozilla on edge and get them to improve. I don’t think the other browser vendors care too much about Safari getting too good anytime soon.
I wonder how much care and affection the Safari/WebKit team gets inside Apple these days. Probably not that much.
This goes somewhat counter intuitive to the positive assertions Alex made here about Apple and WebRTC.H.265 / VP9
Apple and H.265 take center stage in my video codec sessions lately. You can see the video codec wars session I gave at TokBox last week.
My usual spiel?
- Apple is a part of MPEG-LA
- Apple owns H.265 related patents. It may well wish to enforce them to make it difficult on others
- Apple builds hardware, so changing a video codec isn’t an easy feat – it requires time and getting old hardware off the market
- Apple has H.265 running on FaceTime in iPhone 5
- So Apple is on the H.265 camp
But then I get directed to this interesting post in 9to5Mac:
Another interesting detail: 4K videos are being recorded in H.264, and Apple is no longer making reference to H.265 support for any purpose, FaceTime or otherwise
Is it only me or did Apple just drop H.265 support and is shifting camps? Or at the very least, sitting on the fence. It might have something to do with the HEVC Advance stupidity that brought the gang to open up the Alliance of Open Media. They might be edging away from royalty bearing codecs and moving to the free alternative. Or they might try using it as leverage over HEVC Advance to make their licensing terms more palatable.
How do you do 4K video resolutions with a camera if not by using H.265? Use H.264? Ridiculous. But that’s exactly what seems to be happening now for the new iPhone 6.
Should they be moving to VP9 instead? Probably, but it will be hard on Apple. They rely heavily on hardware acceleration and they don’t seem to have it on their chipsets at the moment.
This is a loss to the H.26x camp at the moment.
Where is this all headed?
I am not sure, but here are a couple of things I’d plan if I had that task given to me.
- Rely on native development on mobile. Especially when it comes to anything Apple
- Use HTML5 for browser development. Wrap it using Chrome Embedded Framework if a standalone desktop app is needed
- Tread carefully in what I end up using on for my video codec. No simple answers there
WebRTC in the big screen
WebRTC on the large screen.[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]
I am not a fan of video calling in the living room. Not because I have real issues with it, but because I think it is a steep mountain to climb – I am more of the low-hanging-fruit kind of a guy.
That’s not the case with Tellybean, a company focused on TV video calling and recently doing that using WebRTC.
Cami Hongell, CEO of Tellybean, found the time to chat with me and answer a few questions about what they are doing and the challenges they are facing.
What is Tellybean all about?
Tellybean is all about easy video calling on the TV. My two co-founders are Aussies living in Finland and they had a problem. A software update or a forgotten password too often got in the way of their weekly Skype call with grandma Down Under. Once audio and video were finally working both ways, there were four people fighting for a spot in front of the 13” screen.
We realised that modern life tends to separate families and our problem was far from unique. That’s when we decided to build an easy video calling service for the TV. It had to be so easy that even grandma could use it from the comfort of her couch. At the same time as we worked hard to eliminate complexity, we also needed to keep it affordable and build a channel which would provide users an easy way of getting the service.
Today we have an app which allows easy video calls on Android TV devices of our TV and set-top box partners. Currently you can make calls between selected Tellybean enabled Android TV devices and our web app on www.tellybean.com. To make it as easy as possible to call somebody from your TV, we will release apps for Android and iOS mobiles and tablets in the future.
You started by building your TV solution using Skype. What made you switch to WebRTC?
When we founded Tellybean four years ago the tech landscape looked very different from today. WebRTC wasn’t there. Android TV and Tizen weren’t there – the TV operating systems were all over the place. So initially we set out to build an easy service which would run on our own dedicated Linux box. Our intention was to allow our service to connect with other existing services by putting our own UI on top of headless clients developed using the SDK’s provided by some of the existing services. We started with SkypeKit and had a first version of it ready a few years ago. We were going to continue by adding Gtalk.
However, Skype decided to wind down the support of 3rd party developers and Google stopped Gtalk development. This happened almost at the same time as WebRTC was starting to gain traction. Switching to WebRTC turned out to be an easy decision once we looked into it and moved over to working on Android and 3rd party hardware only.
What excites you about working in WebRTC?
Having tried different VoIP platforms in the past, we have learned to appreciate the fact that working with WebRTC has allowed us to focus our resources on the more important UX and UI development. Since WebRTC offers a plugin-free and no-download alternative for video calling with modern browsers, combined with our TV and upcoming mobile device approach we are able to provide easy use for a huge audience, with almost all entry barriers removed.
We are excited about having a great service which is getting a lot of interest from everybody in the Android TV value chain from the chip manufacturers to the TV and STB manufacturers as well as the operators. We’ve announced co-operation with TP Vision / Philips TVs and Nvidia and much more in the pipeline. The great support and resources available in the WebRTC community, coupled with the support from the hardware manufacturers means that WebRTC is truly becoming a compelling open source alternative for service developers, such as ourselves.
Can you tell me a bit about the challenges of getting WebRTC to operate properly in an embedded environment fit for the TV?
An overall problem has been that we are moving slightly ahead of the curve.
Firstly, we need access to a regular USB camera. Unfortunately the Android TV platform and most devices lack UVC camera support. So we have been pushing everybody, Google, the device manufacturers and the chip suppliers, to add camera support. The powerful Nvidia Shield Console has camera support and we already have a few of the other major players implementing it for us.
Secondly, there are still devices that are underpowered and/or lack support for VP8 HW encoding, meaning that it is hard for us to provide a satisfactory call quality. Luckily again, most of the devices launched this year can handle video calling and our app.
The third problem relates to fine tuning the audio for our use case where the distance between the USB camera’s mic and the TV’s speakers is not a constant. Third time lucky: WebRTC provides us pretty good echo cancellation and other tools to optimize this and produce good audio quality.
What signaling have you decided to integrate on top of WebRTC?
Wanting to support browsers for user convenience and to get going quickly, we started out building our own solution with Socket I/O, but we are transitioning to MQTT for two reasons. Firstly, we came to the conclusion that MQTT provided us much more efficient scalability. Secondly, MQTT is much easier on the battery for mobile devices.
Current implementations of MQTT also allow us to use websockets for persistent connections in browsers, so it suits our purposes well. Additionally, some transaction-like functionality is done using REST. We are writing our own custom protocol as we go, which allows us to grow the service organically instead of trying to match a specification set forth by another party that doesn’t match our requirements or introduces undue complexity in architecture or implementation.
Backend. What technologies and architecture are you using there?
We have server instances on Amazon Web Services, running our MQTT brokers and REST API, as well as the TURN/STUN service required for WebRTC. We use Node.JS on the servers and MongoDB from a cloud service which allows us easy distributed access to shared data.
Where do you see WebRTC going in 2-5 years?
The recent inclusion of H.264 will lead to broader adoption of WebRTC in online services, and also in dedicated hardware devices since H.264 decoders are readily available. Microsoft is also starting to adopt WebRTC in their new Edge browser, so it seems like there’s a bright future for rich communication using WebRTC once all the players have started moving. Like everybody else, we would naturally like full WebRTC support from Microsoft and Apple sooner rather than later, and it will be hard for them to ignore it with all the support it is already receiving. In this timeframe, at least high-end mobile devices should have powerful enough hardware to support WebRTC in the native browsers without issues. With this kind of background infrastructure a lot of online services will be starting to use WebRTC in some form, instead of more isolated projects. With everyone moving towards a new infrastructure, hopefully any interoperability issues between different endpoints have been sorted out, which allows service developers to focus on their core ideas.
If you had one piece of advice for those thinking of adopting WebRTC, what would it be?
WebRTC is still an emerging technology, that will surely have an impact for developers and businesses going forward, but it’s not completely mature yet. We’ve seen a lot of good development over time, so for a specific use case, it might be a plug-and-play experience or then in a more advanced case you may need a lot of development work.
Given the opportunity, what would you change in WebRTC?
WebRTC has been improving a lot during the time that we’ve worked with it, so we believe that current issues will be improved on and disappear over time. The big issue right now on the browser side is obviously adoption, with Microsoft and especially Apple not up to speed yet. We would also like to see good support for all WebRTC codecs from involved parties, to avoid transcoding and to be able to use existing hardware components for a great user experience.
What’s next for Tellybean?
We’ve recently launched our Android TV app and are seeing the first users on the Nvidia Shield console, the first compatible device. We are now learning a lot and have a chance to fine tune our app. From a business point of view we currently have full focus on building a partner network which will provide us the platform for 100+ million TV installations in the coming years. Next we are starting development of mobile apps for Android and iOS. Later we will need to decide if moving to other TV operating systems or e.g. enabling other video calling services to connect to Tellybean TVs will be the next most important step towards achieving our aim of becoming THE video calling solution for the TV.
The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.
The post Tellybean and WebRTC: An Interview With Cami Hongell appeared first on BlogGeek.me.
There are indications out there that soon we won’t be needing plugins to support WebRTC in some of the browsers out there.
[Alexandre Gouaillard decided to drop by here at BlogGeek.me offering his analysis on recent news coming out of Apple and Microsoft – news that affect how these two players will end up supporting WebRTC real soon.] Apple Safari news
- When the webrtc-in-webkit project was first announced through the voice of its main members: Stefan H. from Ericsson, and myself, not everybody was a believer.
- For some, it was even an exercise in Futility
- A further post was even written in webrtcHacks to explain how to let apple know about one’s interest in having webrtc on iOS
- In my November 2014 presentation (slide 20) with JO Hache about the Temasys Plugin, we indicated that the goal was indeed to have an implementation in the Apple version of things by end of August 2015, to have a chance to see it in the next version of Safari which traditionally is shipped along new OS in September/October, every year
- Early July the webrtc-in-webkit project has delivered the media streams fondation, and getusermedia in webkit, with a full functional implementation in the Linux browser WebKitgtk+
- Right after that, Apple put his own resources to support GetUserMedia in the Apple specific version of the code, and worked on it until mid-August. A detailed analysis of the code changes by Apple and their technical implications can be found here
It is still unknown when this (GetUserMedia only) will find its way into Safari, and more specifically in Safari on iOS. Hopefully before the end of the year. (high, but probably unrealistic, hopes for a Sept. 9 announcement).
We can also only hope that the WebView framework apps are forced to use to display web pages according to the Apple app store rules will be updated accordingly, which would open WebRTC to iOS apps directly, catching up a little bit with the WebView on android.
How much the webrtcinwebkit project helped making this happen is also open to debate but I want to believe it did (yes, I am uber-biased). It is also possible that the specifications for Device API being stable (last call status at W3C) motivated Apple to go for it.
In any case, what is important is that it is now undeniable that Apple is bringing WebRTC to its browsers and devices, and that answers a question left open for almost 4 years now!Microsoft Edge news
- In May 2015, the Edge team announced support for the same media streams and getuserMedia API we spoke about earlier
- In June 2015, philippe Hancke extended Google and Mozilla’s provided adapter.js to support Edge
- More recently, some action has been visible on the ORTC side of things, but with nothing testable so far (Release version 10525)
- Today (Sep. 1st) three separate announcements were made:
Here again, a lot of good news. For a long time, it was unsure if Microsoft would do anything at all, and even now, nobody is clear on exactly what API they are going to implement and how compatible it will be with the WebRTC specs. The convergence of the WebRTC Working Group and ORTC Community Group within w3c is raising hope of better interoperability, but it was not substantiated. Until today that is. There is no other web API that would use VP9 than WebRTC. Ok, it could be to provide a better YouTube experience, but Opus is WebRTC only.
So here again, while the exact date is unknown it is undeniable that Microsoft Edge is moving in the right direction. Moreover, it’s been moving faster than most expected lately.
All good news for the ecosystem, and surely more news to come on the Kranky Geek WebRTC Live event on september 11th where three browser vendors will be present to make their announcements.Toward a plugin free experience (finally)
During my original announcement of a plugin for IE and Safari I stated that the “goal [was] to remove the “what about IE and safari” question from the Devs and Investors’ table long enough for a native implementation to land.”
I also stated that “We hate plugins, with a passion. Some browser vendors put us in the situation where we do not have the luxury to wait for them to act on a critical and loudly expressed need from their user base. We sincerely hope that this is only a temporary solution, and we don’t want people to get the impression that plugins are the magical way to bypass what browser vendors do (or don’t do). Native implementation is always best.”
I truly believe that the day we can get rid of plugins for webrtc is now very very close. If I’m lucky, Santa Claus will bring it to me for Xmass (after all, I’ve been a good boy all year). There will still be a need for some help, but it will be in the form of a JS library and not a heavy duty plugin. Of course, you still have to support some older versions of Windows here and there, especially for enterprise market, but Microsoft, and I am writing this from Redmond, next to the Microsoft campus ;-), is putting a lot of ressources behind moving people to auto-updating versions of their software, be it Windows itself, or the browsers. Nowadays, the OS do not bring value per themselves, but bring in a lot of maintenance burden. It is in everybody’s interest to have short update cycles, and MS knows that.
For those who need to support older versions of IE for some time (Apple users will never be seen with an old Apple device :-D), there are today several options, all converging toward the same feature set, and a zero price tag. You can see more about this here.
Tsahi and I have this in common that we hate plug-ins, especially for video communication. I think we are seeing the end of this problem.
The post WebRTC Plugin Free World is Almost Here: Apple and Microsoft joining the crowd appeared first on BlogGeek.me.
A quick note.
Just wanted to list out the events and venues where you’ll be able to find me and meet with me in the next month or two.WebRTC Codec Wars: Rebooted
When? Wednesday, September 9, 18:00
Where? TokBox’ office – 501 2nd Street, San Francisco
TokBox were kind enough to invite me to their upcoming TechTok meetup event. Codecs are becoming a hot topic now – up to the point that I had to rearrange my writing schedule and find the time to write about the new Alliance for Open Media. It also got me to need to change my slides for this event.
Would be great to see you there, and if you can’t make it, I am assuming the video of the session will be available on YouTube later on.
Attendance is free, but you need to register.Kranky Geek WebRTC Show
When? Friday, September 11, 12:00
Where? Google – 6th floor 345 Spear St, San Francisco
This is our second Kranky Geek event in San Francisco, and we’re trying to make it better than the successful event we had a year ago.
Check out our roster of speakers – while registration has closed, we do have a waiting list, so if you still want to join – register for the waiting list and you might just make it to our event.Development Approaches of WebRTC Based Services
When? September 24, 14:00 EDT
It is becoming a yearly thing for me, having a webinar on the BrightTALK platform.
This time, I wanted to focus on the various development approaches companies take when building WebRTC based services. This has recently changed with one or two new techniques that I have seen.
The event is free and takes place online, so be sure to register and join.Video+Conference 2015
When? Thursday, October 15, 11:00
Where? Congress Centre Hotel “Alfa”, Moscow
I have never been to Russia before, and I won’t be this time. I will be joining this one remotely. TrueConf have asked me to give a presentation about WebRTC.
The topic selected for this event is WebRTC Extremes and how different vendors adopt and use WebRTC to fit their business needs.
If you happen to be in Moscow at that time, it would be great to virtually meet you on video.
The beginning of the end of HEVC/H.265 video codec.
On September 1st the news got out. There’s a new group called Alliance for Open Media. There have been some interesting coverage about it in the media and some ramifications that already got published. The three most relevant pieces of news I found are these:
- Stephen Shankland over at CNET makes the most intelligent and thorough review of this announcement out of all the large media outlets. Well worth the read
- Chris Kranky decided to pitch in and explain how patents work with codecs, and how this alliance is doomed to fail. I disagree with the conclusions, but the story is solid
- Microsoft already plans on supporting VP9 video codec in their Edge browser
I’ve written about the pending codec wars just a week ago on SearchUC, concluding that all roads lead to a future with royalty free video codecs. This was before I had any knowledge on the announcement of the open media alliance. This announcement makes this future a lot more possible.
What I’d like to do here, is to cover some aspects of where this is headed and what it tells us about the players in this alliance and the pending codec wars.The Press Release
Let’s start off with the alliance’ initial press release:
This initial project will create a new, open royalty-free video codec specification based on the contributions of members, along with binding specifications for media format, content encryption and adaptive streaming, thereby creating opportunities for next-generation media experiences.
So the idea is to invent a new codec that is royalty-free. As Chris pointed out, this is hard to impossible. Cisco in their own announcement of their new Thor codec made it quite clear what the main challenge is. As Jonathan Rosenberg puts it:
We also hired patent lawyers and consultants familiar with this technology area. We created a new codec development process which would allow us to work through the long list of patents in this space, and continually evolve our codec to work around or avoid those patents.
The closest thing to a “finished good” here is VP9 at the moment.
Is the alliance planning on banking on VP9 and use it as their baseline for the specification of this new codec, or will they be aiming at VP10 and a clean slate? Mozilla, a member company in this alliance, stated that they “believe that Daala, Cisco’s Thor, and Google’s VP10 combine to form an excellent basis for a truly world-class royalty-free codec.”
Daala takes a lot of its technologies from VP9. Thor is too new to count, and VP10 is just a thought compared to VP9. It makes more sense that VP9 would be used as the baseline; and Microsoft’s adoption of VP9 at that same timeframe may indicate just that intent. Or not.
The other tidbit I found interesting is the initial focus in the statement:
The Alliance’s initial focus is to deliver a next-generation video format that is:
- Interoperable and open;
- Optimized for the web;
- Scalable to any modern device at any bandwidth;
- Designed with a low computational footprint and optimized for hardware;
- Capable of consistent, highest-quality, real-time video delivery; and
- Flexible for both commercial and non-commercial content, including user-generated content.
Would be easier to just bio-engineer Superman.
Jokes aside, the bulleted list above are just table-stakes today:
- Interoperable and open
- Without interoperability a codec has no life
- Openness is what you do in an initiative like this one
- Optimized for the web
- People consume video over IP these days. This is where the focus should be
- It also hints for embedability in web browsers, and having Google, Microsoft and Mozilla on this alliance couldn’t hurt
- Scalable to any modern device at any bandwidth
- Scalability here means many things. SVC for one, but that’s just a single feature out of the list of necessary needs
- Modern devices means that anything that is built probably before 2012 or even 2014 is going to be ignored. With current lifecycle of smartphones, that seems reasonable
- Any bandwidth means it needs to support crappy internet connections but also 4K resolutions and above
- Designed with a low computational footprint and optimized for hardware
- This one is going to be tough. Each codec generation takes 2-3 times the computational footprint of its predecessor. I am not sure this can be met if the idea is to displace something like H.265
- Optimized for hardware is a wink to hardware vendors that they need to support this as well. Having Intel is nice, but they are almost the non-player in this market (more on that later)
- Capable of consistent, highest-quality, real-time video delivery
- Guess what? Everyone wants that for any time of a video codec
- Flexible for both commercial and non-commercial content, including user-generated content
- This talks about licensing and royalties. Free should be the business model to aim for, though the language may well translate to royalty payments, though at a lower rate than what MPEG-LA and HEVC Advance are trying to get
High goals for a committee to work on.
It will require Cisco’s “cookbook”: a team comprised of codec engineers and lawyers.The Members
What can we learn from the 7 initial alliance members? That this was an impossible feat and someone achieved just that. Getting these players into the same table while leaving the egos out of the room wasn’t easy.Amazon
Amazon is new to video codecs – or codecs and media. They have their own video streaming service, but that’s about it.
Their addition into this group is interesting in several aspects:
- The Amazon Instant Video service has its place. Not the dominant service, but probably big enough so it isn’t ignored. Added to Netflix and YouTube, it adds its weight
- More interestingly, how will AWS be affected? Their Amazon Elastic Transcoder for example, or the ability to host real time media processing services on top of AWS
Cisco is a big player in network gear and in unified communications. It has backed H.264 to date, mainly due to its own deployed systems. That said, it is free to pick and choose next generation codecs. While it supports H.265 in its high-end telepresence units, it probably saw the futility of the exercise continuing down this path.
Cisco though, has very little say over future codecs adoption.Google
Google needs free codecs. This is why it acquired On2 in the first place – to have VP8, VP9 and now VP10 compete with H.26x. To some extent, you can point the roots of this alliance to the On2 acquisition and the creation as webm as the first turning point in this story.
For Google, this means ditching the VPx codec branding, but having what they want – a free video codec.
The main uses for Google here are first and foremost YouTube and later on WebRTC. Chrome is the obvious vehicle of delivery for both.
I don’t see Google slowing down on their adoption of VP9 in WebRTC or reducing its use on YouTube – on the contrary. Assume the model played out here will be the same one Google played with SPDY and HTTP/2:
- SPDY was Google’s proprietary transport mechanism to replace HTTP/1.1. It was later used as the baseline of HTTP/2
- VP9 is Google’s proprietary video codec to replace H.26x. It is now being used as the baseline of the next generation video codec to displace H.265
To that end, Google may well increase their team size to try and speed up their technology advancement here.Intel
Intel is trying for years now to conquer mobile with little to show for its efforts. When it comes to mobile, ARM chipsets rule.
Intel can’t really help with the “any modern device” part of the alliance’s charter, but it is a good start. They are currently the only chipset vendor in the alliance, and until others join it, there’s a real risk of this being a futile effort.
The companies we need here are ARM, Qualcomm, Broadcom and Samsung to begin with.Microsoft
Microsoft decided to leave the H.26x world here. This is great news. It is also making the moves towards adopting WebRTC.
Having Google Chrome and Microsoft Edge behind this initiative is what is necessary to succeed. Apple is sorely missing, which will most definitely cause market challenges moving forward – if Apple doesn’t include hardware acceleration for this codec in their iOS devices, then a large (and wealthy) chunk of the consumer market will be missing.
Every day that passes it seems that Microsoft is acting like a modern company ready for this day and age as opposed to the dinosaur of the 90’s.Mozilla
Mozilla somehow manages to plug itself into every possible initiative. This alliance is an obvious fit for a company like Mozilla. It is also good for the alliance – 3 out of 4 major browser players behind this initiative is more than we’ve seen for many years in this area.Netflix
Netflix started by adopting H.265 for their 4K video streaming. It seemed weird for me that they adopted H.265 and not VP9 at the time. I am sure the latest announcements coming out of HEVC Advance about licensing costs for content streaming has caused a lot of headache at Netflix and tipped the scale towards them joining this alliance.
If you are a content provider operating at Netflix scale with their margins and business model, the greedy %0.5 gross revenue licensing of HEVC Advance becomes debilitating.
With YouTube, Amazon and Netflix behind this alliance, you can safely say that web video streaming has voiced their opinion and placed themselves behind this alliance and against HEVC/H.265.Missing in Action
We have 3 out of 4 browser vendors, so no Apple.
We have the web streaming vendors. No Facebook, but that is probably because Facebook isn’t as into the details of these things as either Netflix or Google. Yet.
We don’t have the traditional content providers – cable companies and IPTV companies.
We don’t have the large studios – the content creators.
We don’t have the chipset vendors.Apple
Apple is an enigma. They make no announcements about their intent, but the little we know isn’t promising.
- They have devices sold to think of. These devices support H.265 hardware acceleration, so they are somewhat committed to it. Hard to switch to another horse as a vertical integrator
- Safari and WebKit are lagging behind when it comes to many of the modern web technologies – WebRTC being one of them
- Apple owns patents in H.265 and are part of MPEG-LA. Would they place their bets in another alliance? In both at the same time? Contribute their H.265 patents to the Alliance for Open Media? Probably not
Once this initiative and video codec comes to W3C and IETF for standardization, will they object? Join? Implement? Ignore? Adopt?Content providers
Content providers are banking around H.265 for now. They are using the outdated MPEG2 video codec or the current H.264 video codec. For them, migrating to H.265 seems reasonable. Until you look at the licensing costs for content providers (see Netflix above).
That said, some of them, in Korea and Japan, actually own patents around H.265.
Where will they be headed with this?Content creators
Content creators wouldn’t care less. Or they would, as some of them are now becoming also content providers, streaming their own content direct-to-consumer in trials around unbundling and cord cutting.
They should be counting themselves as part of the Alliance for Open Media if you ask me.Chipset vendors
Chipset vendors are the real missing piece here. Some of them (Samsung) hold patents around H.265. Will they be happy to ditch those efforts and move to a new royalty free codec? Hard to say.
The problem is, that without the chipset vendors behind this initiative it will not succeed. One of the main complaints around WebRTC is lack of support for its codecs by chipsets. This will need to change for this codec to succeed. It is also where the alliance needs to put its political effort to increase its size.The Beginning of the End for HEVC/H.265
This announcement came as a surprise to me. I just finished writing my presentation for an upcoming TechTok with the same title as this post: WebRTC Codec Wars Rebooted. I will now need to rewrite that presentation.
This announcement if played right, can mean the end of the line for the H.26x video codecs and the beginning of a new effort around royalty free video codecs, making them the norm. The enormity of this can be compared to the creation of Linux and its effect on server operating systems and the Internet itself.
Making video codecs free is important for the future of our digital life.
I need your help to gain better visibility.
If you are developing something with WebRTC, there’s a good chance you are using existing tools and frameworks already. Be it signaling or messaging frameworks, a media engine in the backend, a third party mobile library.
As I work on my research around the tools enabling the vibrant ecosystem that is WebRTC, I find myself more than once wondering about a specific tool – how much is it used? What do people think about? Are they happy with it? What are its limitations? While I know the answers in some cases, in others not so much. This is where you come in.
If you are willing to share your story with a third party tool – one you purchased or an open source one – I’d like to hear about it. Even if it is only the name of the tool or a one liner.
Feel free to comment below or just use my contact form if you wish this to stay private between us.
I really appreciate your help in this.
What do you know? Peer assisted delivery a-la WebRTC data channel is acceptable.
Whenever write something about the potential of using WebRTC’s data channel for augmenting CDN delivery and getting peers who want to access content to assist each other, there are those who immediately push back. The main reasons? This eats up into data caps and takes up battery.
It was hard to give any real user story besides something like BitTorrent for consumers or how Twitter uses BitTorrent internally to upgrade its servers. Not enough to convince many of my readers here that P2P is huge and WebRTC will be a part of it.
The WebRTC will be a part of it has been covered on this blog many times. P2P is huge is a different story. At least until last month.
Windows 10 was officially released end of July. And with it, millions of PCs around the world got updated. I ran into this article on TheNextWeb by Owen Willions:
by default, Windows 10 uses your internet connection to share updates with others across the internet.
The feature, called Windows Update Delivery Optimization is designed to help users get updates faster and is enabled by default in Windows 10 Home and Pro editions. Windows 10 Enterprise and Education have the feature enabled, but only for the local network.
It’s basically how torrents work: your computer is used as part of a peer to peer network to deliver updates faster to others. It’s a great idea, unless your connection is restricted.
So. Microsoft decided to go for peer assisted delivery and not only a CDN setup to get Windows 10 installation across the wires to its millions of users. That’s 2-3 Gb of a download.
Probably the first large scale commercial use of P2P out there – and great validation for the technique.
I know – they received backlashes and complaints for doing so, but what I haven’t seen is Microsoft stopping this practices. This is another step in the Internet decentralization trend that is happening.
I wonder who will be next.
The post If Microsoft can Deliver Windows 10 P2P, Why Can’t we with WebRTC? appeared first on BlogGeek.me.
Grab your copy of my WebRTC PaaS report at a $450 discount.
If you are subscribed to my monthly newsletter, then you already know about this summer sale for two weeks:
- My Choosing a WebRTC API Platform is available at a discount
- $1,500 instead of $1,950
- Time limited until the 17th of August
- Which leaves you 48 hours to purchase it
- I am heading towards vacation, making August a short month for me
- In September, the an update to this report will be released
- This update will include a real membership/subscription service with a few interesting additions:
- Online vendor comparison matrix that will be updated periodically
- Monthly web meetings to discuss recent changes and any questions you may have on the subject
If you hurry and purchase it in the next two days, you’ll enjoy the lower price point as well as the membership perks – so why wait? Get your copy of the report now.
Telco vendor's offering
WebRTC at the hands of a telecom vendor.
The Telecom world has its own set of standards and needs. At times, they seem far remote from the way the Internet and WebRTC operates.
How do you bridge between the two? André Silva, Team Leader & WebRTC Product Manager at WIT Software tries to explain in this interview.
What is WIT Software all about?
WIT is a software development company specialized in advanced solutions for mobile telecommunications companies. The company has over 14 years of experience and a deep expertise in mobile communications and network technologies including IP Multimedia Subsystem (IMS), mobile voice (Mobile VoIP and Voice over LTE), messaging (SMS, MMS and IM), Rich Communication Suite (RCS) and Multimedia Telephony Services (MMTel). Located in Portugal, UK, Germany and California, the company has over 230 fulltime employees and a blue chip industry client base.
You’ve been working in the Telco space offering IMS and RCS products. What brought you towards WebRTC?
Back to 2008, WIT started the development of a Flash-to-SIP Gateway to support voice calls from web browsers to mobile phones. The first commercial deployment was done in 2011, enabling calls from a Facebook App to mobile subscribers connected to the Vodafone Portugal network. This first version included features like enhanced address-book, presence, IP messaging, IP voice calls and video calls.
When Google released the WebRTC project back in 2011, WIT started following the technology and as soon as it got stable we have implemented a new release of our Web Gateway with support for all the browsers in the market, including Chrome, Firefox and Opera that are WebRTC-compliant, but also Safari and IExplorer where we use the Flash-to-SIP capabilities.
How are your customers responding to the WebRTC capabilities you have?
Our customers are searching for ways to extend their mobile/fixed networks to web browsers and IP devices, either to extend voice calling with supplementary services and SMS, or to make more services available to off-net users. We are providing our WebRTC Gateway and our RCS capabilities to provide richer messaging and voice calling use-cases for the consumer and the enterprise market.
One of the facts that is much appreciated is the support for non-WebRTC browsers. The conversion of protocols (DTLS-SRTP and RTMP) to RTP is done by our Gateway and it is transparent for the network.
For codec transcoding, we support the standard JSR-309 to integrate with MRF’s in order to support extra codecs that are not natively available in WebRTC.
Recently we just announced a partnership with Radisys that is a leading provider of products and solutions, to address emerging media processing challenges for network operators and solution vendors.
What signaling have you decided to integrate on top of WebRTC?
We are using a proprietary JSON protocol over WebSockets. This is a lightweight protocol that exploits the best of asynchrony of WebSockets and provides the best security for Web Apps.
Backend. What technologies and architecture are you using there?
WIT WebRTC Gateway is a Java-based Application Server that can run in several containers. It can be scaled horizontally over several instances. The Gateway integrates with SIP Servlet Containers, for the integration with standard Media Servers, and with streaming servers, to make the media available over RTMP. Our Media engine copes with the WebRTC media and contains a STUN/TURN server to solve the NAT traversal issues.
Where do you see WebRTC going in 2-5 years?
I think WebRTC will become the standard for IP Communications that every VoIP application and server will support, either because they use the WebRTC native APIs, or because they will be improved to also support the extras brought by WebRTC specification.
On the negative side, I also expect browsers to continue having distinct implementations which will force developers to have specific code for each browser. Unfortunately, web development has always been like this.
If you had one piece of advice for those thinking of adopting WebRTC, what would it be?
WebRTC aims to enable VoIP without plugins. So you need to think about WebRTC alternatives for the cases where it is not available, because from our experience, the end user doesn’t really care what’s underneath the application, they just want it to work.
So, you should not filter the browsers or systems where your application will run and force the user to download a new browser.
Given the opportunity, what would you change in WebRTC?
Since H.264 is now one of the video codecs in the specification, a great step would be to add some audio codecs like AMR-WB and G.729 to avoid transcoding with some of the common codecs in existing services.
Also, I would give more focus to the advanced cases that depend on the renegotiation of the WebRTC sessions. We provide supplementary services like call hold, upgrade and downgrade and there are still some limitations in the APIs to allow us to have full control across browsers.
What’s next for WIT-Software?
We are creating WebRTC applications that will be launched later this year for the consumer market, and we are preparing a solution for the enterprise market that will leverage the best of WebRTC technology.
Our latest implementation adds support to voice calls between web browsers and VoLTE devices, and this is a major breakthrough for the convergence of Web Apps and new generation mobile networks.
For more information, please visit our product page at http://webrtc.gw
The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.
The post WIT Software and WebRTC: An Interview With André Silva appeared first on BlogGeek.me.
Smarphones are more laptops than phones.
What’s more important to you? That your smartphone is with you so people call call your phone number to reach you and you can call their phone numbers to reach them. Or the fact that you can have your apps and the internet available at your fingers due to that data package you have or the WiFi you are connected to?
For me the answer is simple. I don’t really care much about my phone number anymore. It is there. It is used. There are hours a month that I am “on the phone”, but it isn’t as important as it used to be. Oftentimes, the most important conversations I conduct are done elsewhere.
This special treatment smartphones give GSM calls is getting a bit tired. The notion of call waiting, hold and switching between calls – who cares anymore?
I had a meeting the other day. As usual, it took place on my desktop machine, with a video camera attached. In the middle, the person I talked to had to answer his phone. Say he is busy. On another call he received he decided not to answer. Apparently, that meeting with me was less important than his daughter and more important than the other person.
The other day, I had a meeting. Again, on my desktop. The house phone rang (a novelty here). When it stopped ringing, my smartphone rang. Call was from an international number. I didn’t answer. The current meeting I was already having was important enough. Whoever searched for me pinged me by email as well.
Interactions happen today not only no multiple apps and services. They also happen to us on multiple devices. The concept that we have one number or service, aggregating all of our communication, and needs to handle a calling queue and be prioritized over everything else is no longer valid. It doesn’t fit our world anymore.
Time to let go of that quaint idea of GSM call prioritization. Treat its notifications and app as just another smartphone app and be done with it.
Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.
The post It’s Time to Remove GSM Call Prioritization from Smartphones appeared first on BlogGeek.me.
WebRTC is but a technology. Its adoption happens at the edges.
It is interesting to see what people do with WebRTC – what use cases do they tackle and what kind of solutions do they come up with.
Here are a few opposite trends that are shaping up to be mainstream approaches to wielding WebRTC.1. Aggregation
In many cases, WebRTC is used to aggregate. The most common example is expert marketplaces.
Popexpert and 24sessions are good examples of such aggregators. You open up your own page on these services, state what services you offer and your asking price. People can search for you and schedule a video session with you. Interesting to see in this space LiveNinja who recently shutdown their aggregation service, shifting towards and embedability alternative.2. Embedablity
The opposite of aggregating everyone into a single domain is to enable embedding the service onto the expert’s own website.
Which one would be preferred, and to whom?
The Vendor in our case, has more power as an aggregator. He is in charge of all the interaction, offering the gateway into his domain. Succeeding here, places him in a position of power, usually way above the people and companies he serves.
The Expert may enjoy an aggregator when he is unknown. Having an easy way to manage his online presentation and being reachable is an advantage. For someone who is already known, or that have spent the time to make a brand of himself online, being aggregated on someone else’s site may dilute his value or position him too close to his competitors – not something you’d want doing.
The Customer on one hand, can easily find his way through an aggregator. But on the other hand, it places the expert or service he is reaching out to at a distance. One which may or may not be desired, depending on the specific industry and level of trust in it.
Ben Thompson has a good read about aggregation theory which I warmly suggest reading.
Most WebRTC services live in their own silo world. You envision a service, you build the use case with WebRTC, and that’s it. If someone needs to connect through your service – he must use your service – he can’t get connected from anywhere elsewhere. Unless you add gateways into the system, but that is done for specific needs and monetization.
I’ve talked about WebRTC islands two years ago. Here’s a presentation about it:
WebRTC makes it too easy to build your own island, so many end up doing so. Others are hung up to the idea of federations:4. Federation
Why not allow me to use whatever service I want to call to you, and you use whatever service you prefer to receive that call?
Think calling from Skype to WeChat. Or ooVoo to Hangouts. What a wonderful world that would be.
Apparently, it doesn’t happen because the business need of these vendors isn’t there – they rather be their own silos.
Who is federating then?
- Some connect to the PSTN in order to “federate” – or to enjoy the network effect of the legacy phone system
- Those who have a network already (federated or not), end up using WebRTC as an access point. That’s what Polycom did recently with their RealPresence Web Suite.
- Solutions such as Matrix, looking to offer a framework that enables federated signaling that is suitable for WebRTC as well
At the end of the day, WebRTC is a building block. A piece of technology. Different people and companies end up doing different things with it.
The post WebRTC’s Extremes. Aggregation or Embedability? Federated or Siloed? appeared first on BlogGeek.me.
WebRTC has more to offer in video conferencing than just an access point.
My roots are in video conferencing. I’ve been working in that industry for 13 years of my adult life, most of it spent dealing with signaling protocols and enabling others to build their VoIP solutions. You can say I have a special place in my heart for this industry.
This is why I immediately said yes when LifeSize wanted me to join them for a webinar. We’ve got a mouthful as a title:
Five Advantages WebRTC Brings to Your Video Conferencing Solution
Truth be told – there’s a lot that WebRTC has to offer in the video conferencing space than the mere “additional access point as a browser to our great video conferencing products”. It starts by taking cloud and video seriously, and continues with unlocking the value that a technology like WebRTC can bring to video conferencing solutions.
If you want to learn more, then be sure to join LifeSize and me in this webinar.
When? Aug 18 2015 11:00 am EDT
The post Upcoming Webinar: Five Advantages WebRTC Brings to Your Video Conferencing Solution appeared first on BlogGeek.me.