Yes.
In recent years, we’ve seen a lot of hysteria going on around WebRTC. Mainly it being unsafe to use. So much so, that there are tutorials out there explaining how to disable it in every conceivable browser out there.
This reminds me all of the past (and present?) hysteria around running JavaScript code inside the browser – and again – how to disable it.
If you are developing a WebRTC application AND you care about the security of your service and the privacy of your users, make sure to review my WebRTC Security Checklist.
Get the WebRTC Security Checklist
Why is WebRTC Perceived as Dangerous?WebRTC is a real time communication technology that is embedded in the browser. It can access your camera and your microphone as well as share the contents of your screen. As such, it enables a browser (and web developers) access to a lot more resources on the device of an end user.
This boils down to two main risks:
Here are a few scary ideas:
With all the goodness WebRTC brings, who wants to be spied on by his own device?
Now, that said, we also need to understand two things here:
This one I guess is mostly about tracking you over the internet. Which is what ad networks are doing most of the time.
WebRTC gives access to more elements that are unique, which makes fingerprinting of the device (and you) a lot more accurate. Or so they say.
The main concern here are around the exposure of private IP addresses to web servers. There are many out there who see these “IP leaks” as a serious threat. for most of humanity, I believe it isn’t, which is why I’ll gladly publish my private IP address here: 10.0.0.9.
There are other, more nuanced ways in which WebRTC can be used for fingerprinting, such enumerating the device list as part of your device’s unique identity. Which is a concern, until you review the accuracy of fingerprinting without even using WebRTC. Here are two resources for you to enjoy:
In this area, Apple with their new WebRTC support in Safari is leading the way in maintaining privacy. You can read about it in a recent article in the WebKit blog. Look specifically on the sections titled “ICE Candidate Restrictions” and “Fingerprinting”.
Why is WebRTC the Safest Alternative?If you are a developer looking for a real time communications technology to use in your application, or you are an IT person trying to decide what to deploy in your company, then WebRTC should be your first alternative. Always.
Here’s why.
1. Browser vendors take care security seriouslyThere are 4 major browser vendors: Apple, Google, Microsoft and Mozilla
All of these vendors are taking care of security and patching their browsers continuously. In some cases, they even roll out new versions at breakneck speeds of 6-8 weeks, with security patches in-between.
If a security threat is found, it gets fixed fast.
While many other vendors can say that they are fixing and patching security threats fast – do they deploy them fast? Do they have the means to do so?
Since browsers get updated and upgraded so frequently, and to hundreds of millions of users, getting a security patch to the field happens rather fast. Philipp Hancke showed and explained some Here are some browser upgrade stats last year. This is from real users conducting appear.in sessions. I asked him to share a more recent graph, and here’s what they’ve had in the last two large browser version cycles for Chrome:
Look at the point in time when each Chrome version got ramped up from less than 30% to over 80% in a span of a couple of days. Chrome 59 is especially interesting. Also note that there are at most 2 versions of Chrome out there with over 95%+ of use. Since they routinely do it, patching and deploying security issues is “easy”.
The only other vendors who can roll out and deploy patches so fast? Operating system vendors (again we end up with Apple, Google and Microsoft), and application developers, through mobile app stores (which sums up to Apple and Google).
Nothing comes close to it.
Takeaway: Assume there will be security breaches or at the very least the need to patch security issues. Which means you should also plan for upgrade policies. Browsers are the best at upgrading these days.
2. You don’t need to redeploy the client softwareLets face it – most users don’t disable the automatic update policy of their browsers. If you’re even remotely interested in security, you shouldn’t disable automatic update policies of ANYTHING.
Manual updates bring with them a world of pain:
(a) When do you upgrade?Here’s the thing.
How do you know an upgrade is in order? Are you on the list of threat alerts of all the software and middleware you are using in your company? Once a threat is announced and a patch is available – do you immediately upgrade?
When we leave this decision to a human, then he might just miss the alert. Or fail to upgrade. Or decide to delay. Just because… he’s human.
Most software can get updated, but usually won’t do it automatically or won’t do it silently. And automation in this area that is done externally, such as the Kaspersky Software Updater. It works, but up to a point and it also adds another headache to contend with and manage.
If a browser does that for you freely, why not use it?
(b) What if this fails?Did you ever get a software update to fail?
What about doing that in a company with 100+ employees?
If software fails to update 1% of the time, it means that every time you update something – someone will complain or just fail to update, making you revert back to a manual process.
There are tons of reasons why these processes fail, and most are due to the fact that we all have different firmware, software and device drivers on our machines (see fingerprinting above). This fact alone means that if a software isn’t running on millions of devices already, it will fail for some. I’ve seen this too many times when the company I worked for developed a plugin for browsers.
Anyone not using WebRTC and deploying via software installation will cause you grief here. If this is only in front of employees, then maybe that’s fine. But often times this is also with end user devices – and you don’t want to mess there.
Browser upgrades will fail a lot less often, so better use that and just make use of WebRTC instead of rolling your own proprietary solution.
(c) What about edge cases?You can’t control your employees and their whereabouts for your upgrades.
People working from home.
People traveling abroad.
People using BYOD and… not having tight enterprise policies on their own home laptop.
If you want less headache in this department, then again – using WebRTC will give you peace of mind that security patches get updated.
Why?Look at it this way, the engine of WebRTC will always stay secure when you rely on browser and browser updates.
You have control over the backend (or rely on a cloud service provider with an SLA you are paying for exactly for this reason). The backend gets updated for security patches all the time (or as much as you care). The browsers get updated automatically so you can think less about it.
Using proprietary software or legacy VoIP vendor software means you’ll need to patch both backend and client software. This is harder to do and maintain – and easier to miss.
3. WebRTC has inherent security measures in placeThis should probably be the first reason…
One thing you hear many complain about is questioning why WebRTC is always encrypted. Somehow, developers decided that sending media in the clear is a good thing. While there might be some reasons to do that, most of them are rather irrelevant for something like WebRTC, meant to be used on unmanaged networks.
WebRTC took the approach of placing its security measures first. This means:
Me? I’d rather rely on the security measures placed in browsers. These go through the scrutiny of lots of people who are all too happy to announce these security flaws. Software from vendors that is specific to communications? A lot less so.
And yes. This isn’t enough. WebRTC is the building block used to build an application. A lot of what goes to the security of the finished service will rely on the developers who developed the application – but at least they got a head start by using WebRTC.
Ads and WebRTCThere’s an angle that isn’t much discussed about WebRTC. And that’s the uses it finds in the ad business.
The BadTwo main scenarios that I’ve seen here:
There’s the second part of it. When ads are served today, the companies paying for these ads being served like to get their ROI. On the other hand, there are those who would like the money spent on ads to be wasted. So they use bots to click ads. Probably by automating selenium processes.
This is similar in concept to the “I am not a robot” type of entry measures and captchas out there. WebRTC gives another layer of understanding about the user and its behavior – and enables us to know if he is a human or a bot inside that browser. And yes. We can use it for things other than ad serving.
Where do we go from here?There are two main approaches to security:
WebRTC is in the second category (the first one – security by obscurity – is often criticized for being unsecure by nature).
With all the resources put into WebRTC from all angles, security is also being taken care of and not left behind.
WebRTC is safe to adopt as developers. IT and security people in the enterprise shouldn’t shy away from it either – just make sure the vendor you pick did a decent job with his implementation.
Are you doing what it takes to improve the security of your WebRTC application?
Get the WebRTC Security Checklist
The post Is WebRTC Safe? appeared first on BlogGeek.me.
When it comes to different verticals and market niches, it seems like WebRTC can fit anywhere.
6 years in, and there are many who still question if WebRTC is the way to go with their use case. This is one of the reasons why I started the WebRTC Dataset. The idea behind it all was to showcase all the variations and services where WebRTC is being used.
Here’s an example for you.
Musicians of all kinds make use of WebRTC. They have services today that are geared towards their specific needs. And I am not talking only about replacing Skype with a marketplace or a searchable directory of experts that can help you take private guitar lessons online.
When I bumped into Profound Studio, I knew this is an area I’d like to write a bit more about, so here it goes.
What I will be doing in this article, is go over some of the vendors found in the WebRTC Dataset, collected over the years, who are playing a role in the sound/music industry in one way or another.
I won’t be picking favorites here – my own experience with music is rather dull – I like to hear music just like anyone else, but I don’t consider myself an expert or a fan of anything really. This means that we’ll be going in alphabetic order of the vendors.
Care 2 RockCare 2 Rock is that we-teach-guitar-lessons use case with a twist.
The basic premise is having teaching music lessons of any kind online, through a video call. The twist is that this is a paid/voluntary act on the side of the teacher, who ends up teaching and mentoring a foster care kid in his community.
Profound StudioProfound Studio connects musicians with recording experts.
This is a marketplace for professionals – not for hobbyists. You can run live classes there or do consultation calls.
sofasessionsofasession is all about musicians making music together online. The majority of it is done asynchronously, where each musician contributes and edits tracks of the final masterpiece, but they don’t need to be live together at the same time. And still, this kind of a use case can use WebRTC.
Here’s a job posting they had from two years ago:
We will use Kurento as media server and extending the service for multitrack mixing and reducing latency by developing latency reducing algorithms for serving content to clients connected via the webRTC protocol.
For the layman, handling audio in realtime in the browser to handle that mixing module that’s inside sofasession requires low latency. The best way to get there is to have something like WebRTC manage it – we are talking about real time here.
I am not sure if and how far they went with their WebRTC support. They do support live jam sessions, but there’s a need to download dedicated software for that. It does use UDP to work, so there still might be some WebRTC in there.
SoundtrapSoundtrap is similar to sofasessions. It too focuses on musicians collaborating online.
Based in Stockholm, where some of the Google WebRTC team are located, even got it to appear at Google I/O in 2014:
StreetJellyStreetJelly is about live performances. It allows artists to stream their music live to a global audience.
At the moment, performing and viewing is free. Viewers can tip performers if they want.
On the technical side, StreetJelly uses HTML5 video playback for the viewers and either Flash (now dead) or WebRTC (the new method for StreetJelly) to be able to broadcast the performances. They explain this further here.
Shots in the darkOther vendors such as Rapt.fm and unltd.fm came and went.
As with any set of startups, the vendors in this space don’t always succeed.
How will others fair? Time will tell.
The AppealMusic and WebRTC. There’s an appeal there.
VoIP was crap most of the time up until recently. There were two main reasons for it:
WebRTC comes with Opus “out of the box”. A wideband codec suitable for music – not only speech, which is royalty free, low latency and error resilient. To top it all – it is mandatory in WebRTC and one of only two such codecs (the other one being the ridiculously crappy G.711). What’s not to like as a musician?
Why is this important?Well… here’s the kicker.
None of it is new.
VoIP and video calling could have done this all before WebRTC.
But it didn’t.
Why?
Costs. Barriers of entry. Finding talent.
WebRTC solves all that, which is why I categorize all of these vendors and many others as WebRTC vendors.
They don’t care about WebRTC as a technology – for them it is just means to an end, which is just fine.
But what about you?
Want to learn more about a specific market niche where real time communications be of use? Want to instantly find who’s there already and what they are doing?
You’d better take a look at the WebRTC Dataset. Especially today, before the earlybird discount ends.
Get access to the WebRTC Dataset
The post Sound Gurus Finding a Home in WebRTC appeared first on BlogGeek.me.
I am a big fan of Chrome’s webrtc-internals tool. It is one of the most useful debugging tools for WebRTC and when it was added to Chrome back in 2012 it made my life a lot easier. I even wrote a lengthy series of blog post together with Tsahi Levent-Levi describing how to use it […]
The post WebRTC Externals – the cross-browser WebRTC debug extension appeared first on webrtcHacks.
Knowledge=Power. Which is why the WebRTC Dataset might be just what you need.
A Quick History LessonYou see numbers flying around about WebRTC all the time. One of them is the number of vendors using WebRTC. 1,200 might sound familiar in that context. Well… it comes from the WebRTC Dataset that I am maintaining.
It all started ages ago. I think it was Alan Quayle who made a shortlist of the companies that were using WebRTC that he knew about. That was somewhere in 2012. Which made me start my own Excel sheet. Which was then converted into a Google sheet. Which was then converted into a whole operation of how to find, catalog and update a dataset.
The reason? One of the main companies who are influencers in WebRTC wanted access to it and were willing to pay, so I made it into a product. Since then it had a few more customers who got exclusive ongoing access to this dataset, and now, I decided to repackage it in a different fashion, making it more accessible to more companies.
What’s in the WebRTC Dataset?The WebRTC Dataset itself is a collection of vendors and projects who are making use of WebRTC in one way or another. It can be anything from a healthcare service to an outsourcing vendor to a live streaming service or a contact center.
The list includes today around 1,200 vendors and counting – it grows and gets updated on a monthly basis.
You’ll find in the dataset vendors large and small. Anything from Google, Cisco and Facebook to small startups and even individual projects that are popular or interesting enough.
You’ll find there acquisitions made in the industry, with reasons behind them and my own indication of how related they are to WebRTC.
You’ll find there vendors who have shut down. Those who have pivoted and changed their focus.
When the information is publicly known, available or can be found online – the suppliers that are used by a vendor are also indicated.
Here’s an example vendor’s information from the WebRTC Dataset:
The page is split into several parts:
All over the web.
Since I am actively working on projects like WebRTC Index and WebRTC Weekly, I got to keep tabs with anything related to WebRTC. I go over the blogs of all the vendors using WebRTC and investigate anything that looks like RTC that I bump into in whatever it is that I am reading. On top of that, I use additional sources like Google Alerts and a few other trade secrets
And I’ve been doing this since 2013.
The data in the WebRTC Dataset got created along the way. First as a resource for me to use whenever I need research information on certain domains. And then because it made sense to package it as a distinct product of its own.
Whatever is on the WebRTC Dataset it is something you can go and find out on your own. But it will take you time. Lots and lots of time.
What can you DO With the WebRTC Dataset?Lots of things actually. It all depends on what it is you’re trying to gain.
Here are a few ideas and uses that people have been using it for already:
The dataset enables me to understand where the WebRTC platform is going and make strategic roadmap decisions based on where the innovation and heavy usage lies. Being able to get an updated complete view of the market at any given point in time over a large set of criteria makes it easy to see trends in different industries and verticals that make use of WebRTC.
I am sure you’ll be able to find other ways to use it if you only think about it.
And me?
I use this WebRTC Dataset all the time. One of the things I use it for is my annual “WebRTC State of the Market” infographic.
Here’s the one for 2016 and the one for 2017 that I created.
How about a sneak peak?If you want to see how the WebRTC Dataset feels like to use, then here’s a short video:
I’m interested. Now what?Access to the WebRTC Dataset comes at $2,400.
The WebRTC Dataset access gives you 1 month of access to all the vendors there. You’ll be able to download the main worksheet and use it after that month is up.
You can decide to purchase it at any point in time, just head to the WebRTC Dataset page.
While we’re at it – if you decide to purchase before the end of July (even if you plan on using it later on), there’s an early bird discount of $400. Just use coupon code DATASET-EARLYBIRD.
The post Drilling into the WebRTC Dataset appeared first on BlogGeek.me.
SIMCom SIM7100E is a recent LTE modem released by Simcom. It’s approximately $20 cheaper than Huawei LTE modem, and also it provides USB voice function, so it could be integrated with FreeSWITCH mod_gsmopen module (this needs development).
My set of udev rules and chat scripts is updated with SIM7100E information, and here’s a copy:
cat >/etc/udev/rules.d/99-wwan.rules <<'EOT' # SIMCom SIM7100 SUBSYSTEM=="tty", ATTRS{idVendor}=="1e0e", ATTRS{idProduct}=="9001", SYMLINK+="ttyWWAN%E{ID_USB_INTERFACE_NUM}" SUBSYSTEM=="net", ATTRS{idVendor}=="1e0e", ATTRS{idProduct}=="9001", NAME="lte0" EOT cat >/etc/chatscripts/sunrise.SIM7100 <<'EOT' ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR TIMEOUT 10 '' 'AT+CFUN=1' OK 'AT+CMEE=0' OK 'AT+CGDCONT=1,"IP","internet"' OK '\dAT\$QCRMCALL=1,1' OK EOT cat >/etc/chatscripts/gsm_off.SIM7100 <<'EOT' ABORT ERROR TIMEOUT 5 '' 'AT\$QCRMCALL=0,1' OK AT+CFUN=0 OK EOT cat >/etc/network/interfaces.d/lte0 <<'EOT' allow-hotplug lte0 iface lte0 inet dhcp pre-up /usr/sbin/chat -v -f /etc/chatscripts/sunrise.SIM7100 >/dev/ttyWWAN02 </dev/ttyWWAN02 post-down /usr/sbin/chat -v -f /etc/chatscripts/gsm_off.SIM7100 >/dev/ttyWWAN02 </dev/ttyWWAN02 EOT
Where are we headed with WebRTC?
Google made an interesting announcement recently. It was about WebRTC 1.0 and Google’s own commitment to it. It seems we’ve come to a point in time when WebRTC is considered a done deal and the rest are just details – getting bugs fixed and polishing its performance.
I wanted to understand a bit more where we are headed, from the point of view of the company who lead the effort up until now. So I reached out to Niklas Blum, who is leading product management for WebRTC at Google, to answer a few of my questions.
How is it like to manage something like WebRTC at Google?
WebRTC is an exciting project. It is one of these kind of projects that are only possible at companies like Google and a few other places when you think of scale and impact of the technology. We started about 6 years ago as an open source project in Chrome and now WebRTC is providing the stack for an ecosystem for real-time communication services on Web. From a product management perspective there are tons of requirements impacting the platform – ranging from enterprise multi-party communications to p2p video calling on bad networks and even streaming services. It’s a very challenging and exciting time, with so many opportunities to further evolve the product.
What metrics do you use to gauge WebRTC’s success?
We have very practical metrics like number of API requests and amount of media/data being consumed in Chrome from users that opt-in to share this data with us. From a product perspective, I like to measure the impact of the technology on the Internet. You are tracking for example the number of projects and services that build with WebRTC. The latest update I got from you was around 1200 projects and companies. I think this is a great metric reflecting the success of WebRTC and the impact we achieved by open sourcing it.
You recently made an announcement in discuss-webrtc around WebRTC 1.0. Why now?
We have reaching our goal of having all the standards defined, and the technology is now stable enough for everyone to use. The web-based RTC ecosystem is becoming mature as more and more services that build on top of WebRTC are getting massive reach.
With Chrome, Edge, Firefox and Safari supporting WebRTC, about 80% of all installed browsers globally have now WebRTC build in. This is a big milestone for us as we are achieving our initial goal of making audio and video available in all browsers, through a uniform standardized set of APIs. Additionally, formerly application-focused communication services are transitioning towards the Web platform and adopting WebRTC.
About 80% of all installed browsers globally have now WebRTC build in
Click To Tweet
We believe that interoperability between different WebRTC browsers is now of key importance to continue growing the adoption of WebRTC. It’s also of key importance to provide stability and a common ground to services and companies for continue growing a user base and eventually a flourishing business.
6 years in. What would you say worked great with WebRTC and what needs some improvement?
Our original mission to bring secure p2p real-time communication to the web has become real. This by itself is major contribution to the Web platform and the team is incredibly proud of this achievement. Our current efforts can be split into two main categories:
We are working very hard on performance and to iron out remaining reliability issues in Chrome to make WebRTC the solution of choice for enterprise-grade communication services. These efforts address bugs like missing audio-input from the microphone or when the the camera is not detected. We are also getting close to launching a completely new echo canceller in Chrome for desktop. This should significantly improve the call quality when no headset is used on various devices. Additionally, we have major projects aiming at removing glitches in the audio and video capture and rendering processes. We are porting these time and resource critical processes to Mojo, a new process framework in Chrome. This will allow us to have a much better real-time performance in Chrome.
Looking 2 years ahead. What should we expect to see coming to WebRTC? AV1? Support for AR? …
Google is a founding member AOMedia and very active in defining the AV1 bitstream. Once AV1 is finalized we will start work on adding it to WebRTC. AR/VR/Mixed Reality is a completely new technology space with the potential to change how we consume services and media fundamentally. But the platform and overall product/market-fit is still unclear. But adding AR/VR functionality to WebRTC is definitely an interesting idea.
An interesting opportunity for evolving WebRTC is to replace RTP with QUIC. Experimenting with QUIC as media transport protocol could reduce the transport-layer protocol overhead and provide integrated congestion control. We also consider using QUIC for the DataChannel that is being used a lot by p2p CDNs for content distribution. Generally, we believe that there are still quite a few opportunities for reinventing real-time communications.
Looking a bit further ahead, a new mobile network generation (5G) is emerging. Which role WebRTC will play here still needs to be identified. But generally, having more bandwidth and lower latency available will open the door to explore video resolutions >4K and massive parallel connections. Additionally, having new software-defined networking functionality exposed to the application-layer seems to be an interesting option to improve real-time communication services. It will be very interesting to see the opportunities for WebRTC here.
During your time as the product manager of WebRTC at Google. What was the thing that surprised you the most?
I am still surprised every day by the creativity of developers building great services on top of WebRTC and the value those provide to users. A company called Qbtech, for example, uses WebRTC in a product that assess symptoms of ADHD. While traditional methods for assessing ADHD typically use subjective rating scales from physicians, Qbtech provides objective measurements by analyzing motion tracking over video. After implementing WebRTC, they went from specialized hardware to a web application that could run on a normal computer — opening up access to this technology to smaller clinics, schools, and even rural providers that might not have the resources for more specialized solutions.
Of course, there are many other great services that use WebRTC, but it’s this kind of out of the box thinking to apply WebRTC beyond its original audio/video calling use case and the value that is created by it that always surprises me.
How can developers contribute to WebRTC?
We have received thousands of user feedback reports and feature requests in the WebRTC and Chromium trackers from the growing WebRTC developer community. This feedback has been extremely valuable to improve WebRTC overall and especially to make it more stable for production usage. Generally, developers can provide feedback at bugs.webrtc.org by filing bugs or feature requests. And if you want to do more – you can become contributors and help us polishing the codebase – either as an individual or a company.
The post Google and WebRTC. An Interview with Niklas Blum appeared first on BlogGeek.me.
NanoPi NEO Plus2 is a brand new board released by FriendlyELEC. It’s slightly bigger than the NEO2 board, and packed with much more cool stuff: 1GB RAM, Wifi+Bluetooth module, and 8GB eMMC chip. It has also two USB2.0 port connected to independent USB controllers.
The NanoPi NEO Plus2 Basic Kit accompanies the board with an acrylic enclosure, and the first orders are delivered with an UART USB adapter. They also listed an antenna, but I did not receive it in my kit. Anyway I have a better option, a flat self-adhesive antenna like this one.
The acrylic enclosure is about two times thicker than that for NEO boards, and it also has a hole for antenna mount. I added 8 pieces of M2.5 washers and 4 M3 pillars to the original design, to make it more long-lasting. The photo below has the UART adapter plugged in.
Armbian still needs some work to be done to support this new board. But the Ubuntu image that is available from FriendlyELEC is quite enough to demonstrate all the hardware capabilities. Unlike Armbian, it does not mount /tmp and /var/log as tmpfs, so the SD card may experience a faster wearing.
Are you sure you’re ready with your WebRTC product launch?
Here’s the thing. If you want to have a successful launch at the end of the project, you should focus on the planning phase in the beginning. Oh – and your plan should be different if you are going to self develop it all in-house or have the communication parts of it outsourced to external vendors.
Too often people contact me when they have already budgeted the project, spent the money, have a “product” in hand but it is lacking.
Two extreme cases recently:
We see this even more at testRTC, where I am a co-founder. Companies come to us because they think the product a third party developed for them doesn’t work as expected, and too often it breaks in ways that are unacceptable (like stressing the service with 20 browsers).
The problem is finding these issues too late in the game, and paying dearly for them.
There are lots and lots of images out there that illustrate the issue. I’ll use the one from Raygun:
We can dispute the multipliers. They don’t really matter. But here’s how a typical WebRTC product with outsourced development takes place:
Here’s the problem. Steps (1), (2) and (3) are the Design phase. And no one took any real ownership of it in this scenario.
Step (4) is probably Development,Testing and Staging. And they were all left to an outsourcing vendor. Who is most likely looking at this project from a cost perspective as well – but he doesn’t really care if this gets launched or not. Not really.
The customer got to step (5) immediately. With no milestones along the way. No checkpoints to see if everything is done correctly.
And please don’t sell me the story of agile development and how that will save the day for this customer. With agile he sees the “results” every week or two. In every sprint. But does he really know if that first Design phase was done properly?
Do you think you are getting a stable product that can scale to the millions (or even thousands) of users you plan on having? Are you sure your contractor feels the same way and didn’t build you a proof of concept instead?
Two things to do NOW about your WebRTC project:
#1 – Make sure you have a solid WebRTC architectureDo you trust your vendor to build you the architecture you need?
Don’t.
You should do your homework or bring someone on “your side” that knows what he is doing.
Go now and look at the architecture you’ve been promised.
Take that architecture you’ve been given by the vendor and get a second opinion. It will be worth the time and effort.
#2 – Register to this free webinarAt testRTC we’ve decided to host a free webinar that deals with these issues exactly. And me? I decided to announce it here as well because I think it fits my readers AND it gets more people to know about testRTC, which is another thing I am a part of.
WebRTC: How NOT to Fail in Your BIG Launch
The webinar will take place on July 25 at 14:30 EDT.
It will be recorded and available for playback, so register now.
See you then!
The post Prepping for that Big WebRTC Product Launch appeared first on BlogGeek.me.
Time for someone to offer an updated view of the WebRTC Developer Tools Landscape.
Want to learn more about the WebRTC Developer Tools Landscape?
Register to my free Virtual Coffee session
As I am on vacation this week with my family (in Barcelona – ping me if you’re there this week and want to meet and say hi), I will keep this one short.
A few years back, Brad Bush of Genband released a WebRTC Landscape infographic. While he has updated it a couple of times, he since then stopped, leaving the WebRTC space altogether. His site was also lost in the abyss that is the Internet of un-renewed domain names, now hosting a Japanese website promising “services by married women” (Google’s translation).
I figured it was time to create another WebRTC Landscape infographic, but decided to be a bit more focused. Covering the whole WebRTC scene is rather hard, especially trying to do it on the first attempt. Which is why I decided to cover only the WebRTC Developer Tools Landscape in my infographic.
So without further ado, here it is:
I had to modify and update this twice already in the past few weeks – just to keep up with the changes in the industry (adding Safari and removing Tropo).
A few quick notes:
See you next week in my Virtual Coffee
The post Introducing the WebRTC Developer Tools Landscape appeared first on BlogGeek.me.
A Video chat widget is something you may want to add to your website. And while WebRTC is the only alternative at the moment, there are many ways in which this can get done.
For all intent and purpose, I will assume we’re going to focus on a WordPress site (like my own, which has no video chat widget because it isn’t needed for my business).
I will base this article on this Quora question and the brief answer I’ve given there:
Which 3rd party software should I use for a video conferencing feature in my company’s intranet?Company’s intranet using wordpress and we are looking for somehow a whitelabel solution (obviously not skype) which allow employee to be able to do video conferencing on their laptops and mobile devices. (Though it is intranet, it is hosted on the internet just that only for private use)
My answer on Quora:You need something based on WebRTC (more about WebRTC here).
One way to go, is to search the WordPress plugins directory – webrtc – WordPress Plugins
But – most of the plugins there are too old or dead already.
Here’s a suggestion of 3 different vendors that should work well (even if they don’t have a plugin for WordPress, these can be easily created for them – either by you, a freelancer or the vendor himself once you contact him):
These services are very different and very similar to one another at the same time.
Now, if you fail to find something that meet your exact needs, contact me directly and I’ll be able to help you further.
Intranet or Internet?The question itself is about a company’s intranet.
Two options here:
The question’s clarification mentions that this is of the second type, but… I don’t really think it matters. The answers here will apply to both.
Also remember that:
Video chat in a website can take different shapes and sizes.
Here are a few of these:
This list is probably missing a few more use cases – feel free to suggest them in the comments.
I intentionally left out the more glaring contact center use cases, as these got covered as part of the story of O2’s contact center from a few months ago.
What Features do you need?There are different requirements that you might be after.
Here are some for you to consider:
Not exhaustive, but should get you started.
If you need to write that down, then you can use my requirements template for it.
How do you want this done?There are a few WordPress plugins already available out there that use WebRTC and do “things”. Will these be suitable for your needs? I am not sure, but it is worth a shot.
If there aren’t, it doesn’t mean you can’t get it there. For a few 100’s of dollars, you can probably get a developer to wrap an existing solution as a WordPress plugin that is tailored for your needs.
And if you can’t find any existing solution that fits – you can have that developed for a larger sum of money and have it embedded as well.
I guess these are your choices if I had to put them on a graph:
Where do we go from here?Yes. WebRTC enables putting video chat into websites.
Yes. There are solutions for it.
But somehow, people have an appetite once they see the capabilities.
When you plan on adding WebRTC video chat into your website, decide on the features you need and the budget you have. If they don’t match, either increase the budget or accommodate to it by changing your feature set.
–
I will be talking later this month in my Virtual Coffee about the WebRTC Developer Tools Landscape. I won’t be touching WordPress directly, but this is something you don’t want to miss as it will touch the various development strategies and the tools out there at your disposal.
Join me for a free Virtual Coffee on the WebRTC Developer Tools Landscape. Register now
The post Video Chat for a Website with WebRTC. Where to Start? appeared first on BlogGeek.me.
It seems like we’re in an ongoing roller coaster when it comes to CPaaS. Tropo has just closed its doors. At least if you want to be a new customer (which is doubtful at best at this point in time).
Looking for the public announcement that got deleted? You can find it hereTropo and Cisco – Where it all started?
Two years ago (give or take a month), Cisco acquired Tropo. I’ve written about it at the time, trying to figure out what will Cisco focus on when it comes to Tropo’s roadmap. I guess I was quite wrong in where I saw this headed and where it went to…
The two questions I did ask in that article that were probably the most important were:
Will developers be attracted to Tropo or will they look for their solution elsewhere?
Was this acquisition about the technology? Was it about the existing customer base? Was it about the developer ecosystem?
We’ve got an answer to the first question – they went elsewhere. If this was a growing business, then developers would be attracted, but it wasn’t.
Looking back at my recent update to my WebRTC API report, it made perfect sense that this will be shut down soon enough. Just look at the investment made by Tropo and then Cisco into the platform:
Nothing serious was done for developers on the WebRTC part of the platform since September 2014, and then after the acquisition, focus of the Tropo developers went to Cisco Spark.
This answers my second question – this wasn’t about technology or customers or even the existing developer ecosystem of Tropo. It was about the developers of Tropo and their understanding of developer ecosystems. It was about talent acquisition for Cisco Spark. Why kill the running business that is Tropo? I really don’t know or understand. I also fail to see how such a signal can be a good one to developers who plan on using other Cisco APIs.
When an API vendor (CPaaS, WebRTC or other) discontinues its APIs or stops investing in developers. What…
Click To Tweet
I don’t know what was the rationale of Cisco to acquire Tropo in the first place. If all they wanted was the talent, then this seems like too big of a deal to make. If it was for the platform, then they sure didn’t invest in it the needed resources to make it grow and flourish.
Now, here’s why I think this move took place, and it probably happened at around the time of the acquisition and in parallel to it.
UCaaS or CPaaS? The Shifting FocusWe’ve got two worlds in a collision course.
UCaaS – Unified Communications as a Service – the “modern” day voice and video communications sold to enterprises.
CPaaS – Cloud Communications as a Service – the APIs used by developers to embed communications into their products.
UCaaS has a problem. Its problem is that it always saw the world in monochrome. If you were an organization, then ALL of your communication needs get met by UCaaS (or UC, or convergence or whatever name it had before). And it worked. Up to a point. Go to most UC or UCaaS vendors’ websites and look at their solutions or industries section.
The screenshot above was taken from Polycom’s homepage (couldn’t find one on Cisco since their move to Cisco Spark). Now, notice the industries? Education, Healthcare, …
All of these industries are now shifting focus. Many of the solutions found in these industries that used to go to expensive UC vendors are now going to niche vendors offering solutions specifically for these niches. And they are doing it by way of WebRTC. Here are a few examples from interviews I’ve had done over the years on this site:
You’ll even find some of these as distinct verticals in my updated WebRTC for Business People free report.
The result? The UCaaS market is shrinking because of WebRTC and CPaaS.
The UCaaS market is shrinking because of WebRTC and CPaaS
Click To Tweet
Why is this happening? Three reasons that come to play here:
With the rising popularity of the dominant CPaaS vendors, there’s a threat to UCaaS: at the end of the day, UCaaS is just a single example of a service that can be developed using CPaaS. And you start to see a few entrepreneurs actually trying to build UCaaS on top of CPaaS vendors.
If I had to draw the relationship here, I’d do it in this way probably:
Just the opposite of what UC vendors have imagined in the last two decades. And a really worrying possibility of how the future may look like.
What should a UCaaS vendor do in such a case?
Add APIs!
So now UCaaS vendors are trying to add APIs to serve as their CPaaS layer on top of their existing business. Most of them do it with the intent of making sure their UCaaS customers just don’t go elsewhere for communications.
Think of a bank that has an internal UCaaS deployment. He now wants to build a contact center. He has 3 ways of doing that:
If (3) happens, then great.
If (1) happens, then it is fine, assuming the UCaaS vendor offers contact center capabilities as well. And if he doesn’t, then there’s at least a very high probability that there’s no real competition between him and that CCaaS vendor
If (2) happens… well… that can be a threat in the long run.
And did we talk about Uber, Upwork and Airbnb? Yes. They have internal communications between their employees. Maybe there’s some UCaaS in there. But most of the communications generated by these companies don’t even involve their employees – only their customers and users. Where the hell do you fit UCaaS in there?
The APIs are there as a moat against the CPaaS vendors. Which is just where Cisco decided to place Tropo. As Cisco’s moat for its UCaaS offering – Cisco Spark. The Tropo team are there to make sure the APIs are approachable and create the buzz and developer ecosystem around it.
Quite an expensive moat if the end result was just killing Tropo in the process (the asset that was acquired).
The Surprise AnnouncementLast week, Tropo had a blog post published on their site and had it removed after a few hours.
Since Tropo publish the full post content into their RSS, and Feedly grabs the content and has it archived, the information in that post was not lost. I copied it from Feedly and placed it in a shared Google Doc – you can find it here.
The post is no longer on Tropo’s website. A few reasons why this may be:
That last one is what I think is the real reason. And that’s because after reading it more than once, I still find it rather confusing and not really clear.
This announcement from Tropo has two parts to it:
That first part is about CPaaS serving UCaaS. Cisco Spark is UCaaS with a layer of APIs that Cisco is now trying to grow.
It is also about damage control – if you’re a Tropo user, then this whole acquisition thing by Cisco probably ended bad for you. So they want to remind you about the alternatives they now offer.
The second part is about how they see current Tropo developers:
This reads to me like the acquisition of AddLive by Snapchat. First, the service was acquired and closed its doors to new customers. It honored existing contracts. And it shut down its platform to all existing customers this year – once all contracts have ended.
So –
Tropo was predominantly about voice and SMS.
It was also the biggest competitor of Twilio some 6-7 years ago, when both with comparable in size and focus. Or at least until Tropo shifted its focus from developers to carriers.
There are two places where Tropo customers can go:
The big winner here is Twilio.
The big losers are the developers who put their fate in Tropo.
CPaaS: Buyers BewareAs I always say, the CPaaS market is a buyers beware one.
Developers can and should use CPaaS to build their applications. It will reduce a lot of the upfront costs and the risks involved in starting a new initiative. It gives you the ability to explore an idea, fine tuning and tweaking it until you find the right path in the market. But it comes at a price. And I don’t mean the money you need to put in order to use CPaaS. I mean the risk involved in the fluidity of this market.
CPaaS and WebRTC APIs. A buyers beware market
Click To Tweet
The trick then, is to pick a CPaaS vendor that doesn’t only fit your feature requirements, but is also here to stay. And it is hard to do that.
Large companies are not necessarily the right approach – Cisco/Tropo as an example. Or AT&T shutting down its WebRTC APIs.
Small startups aren’t necessarily the answer either – they might shut down or pivot. SightCall pivoted. OpenClove has silently closed doors.
Dominant players might not be a viable alternative – if you consider Tropo such a player, and Cisco as a sure bet of an acquirer – and where it now ended.
You can reduce these risks if you know who these CPaaS vendors are and where they are headed. If you follow them for quite some time and understand if and what they are investing on. And if you need help with that, just follow my blog or contact me.
The post Another One Bites the Dust: Tropo Closes its Doors to New Customers appeared first on BlogGeek.me.
Long have WebRTC developers waited for the day Apple would come around to WebRTC. It has not been simple for web developers and Apple due to their policy that requires web browsing functionality to use the WebKit engine along with Safari. This mean no WebRTC in Safari, no Firefox or Chrome WebRTC on iOS, no native […]
The post Reeling in Safari on WebRTC – A Closer Look at What’s Supported appeared first on webrtcHacks.
Too many WebRTC open source projects. Not enough good ones.
Ever went to github to search for something you needed for your WebRTC project? Great. Today, there’s almost as many WebRTC github projects as there are WebRTC LinkedIn profiles.
Today, there’s almost as many WebRTC github projects as there are WebRTC LinkedIn profiles.
Click To Tweet
Some of these code repositories really are popular and useful while others? Less so.
Here’s the most glaring example for me –
When you just search for WebRTC on github, and let it select the “Best match” by default for you, you’ll get PubNub’s sample of using PubNub as your signaling for a simple 1:1 video call using WebRTC. And here’s the funny thing – it doesn’t even work any longer. Because it uses an old PubNub WebRTC SDK. And that’s for an area that requires less of an effort from you anyway (signaling).
Let’s assume you actually did find a WebRTC open source media server that you like (on github of course). How do you know that it is any good? Here are 10 different signals (not WebRTC ones) that you can use to make that decision.
Need to pick a WebRTC media server framework? Why not use my Free Media Server Framework Selection Worksheet when checking your alternatives?
Get the worksheet1. Do You Grok the Code?If you are going to adopt an open source media server for your WebRTC project then expect to need to dive into the code every once in awhile.
This is something you’ll have to do either to get the darn thing to work, fix a bug, tweak a setting or even write the functionality you need in a plugin/add-on/extension or whatever name that media server uses for making it work.
In many of the cases I see when vendors rely on an open source WebRTC media server framework, they end up having to dig in its code, sometimes to the point of taking full ownership of it and forking it from its baseline forever.
To make sure you’re making the right decision – check first that you understand what you’re getting yourself into and try to grok the code first.
My own personal preference would be a code that has comments in it (I know I have high standards). I just can’t get myself behind the notion of code that explains itself (it never does). So be sure to check if the non-obvious parts (think bandwidth estimation) are commented properly while you’re at it.
2. Is the Code Fresh?Apple just landed with WebRTC. And yes. We’re all happyyyyy.
But now we all need to shift out focus to H.264. Including that WebRTC media server you’ve been planning to use.
Oh – and Google? They just announced they will be migrating slowly from Plan B to Unified Plan. Don’t worry about the details – it just changes the way multiple streams are handled. Affecting most group calling implementations out there.
And there was that getstats() API change recently, since the draft specification of WebRTC finally decided on the correct definition of it, which was different than its Chrome implementation.
The end result?
Code written a year or two ago have serious issues in actually running.
Without even talking about upgrades, updates, security patches, etc.
Just baseline “make it work” stuff.
When you check that github page of the WebRTC media server you plan on adopting – make sure to look when it was last updated. Bonus points if you check what that update was about and how frequently updates take place.
3. Anyone Using It?Nothing like making the same mistakes others are making.
Err… wrong expression.
What you want is a popular open source WebRTC media server. Anything else has a reason, and that reason won’t be that you found a diamond in the rough.
Go for a popular framework. One that is battle tested. Preferably used by big names. In production. Inside commercial products.
Why? Because it gives you two things you need:
It gives you validation that this thing is worth something – others have already used it.
And it gives you an ecosystem of knowledge and experience around it. This can be leveraged sometimes for finding some freelancers who have already used it or to get assistance from more people in the “community”.
I wouldn’t pick a platform only based on popularity, but I would use it as a strong signal.
4. Is This Thing Documented?What you get in a media framework for WebRTC is a sort of an engine. Something that has to be connected to your whole app. To do that, you need to integrate with it somehow – either through its APIs when you link on it – or a lot more commonly these days by REST APIs (or GraphQL or whatever). You might need both if you plan on writing your own addon/extension to it.
And to do that, you need to know the interface that was designed especially for you.
Which means something written. Documentation.
When it comes to open source frameworks, documentation is not guaranteed to be of specific quality – it will vary greatly from one project to another.
Just make sure the one you’re using is documented to a level that makes it… understandable.
If possible, check that the documentation includes:
The more documentation the better off you will be a year down the road.
5. Is It Debuggable?WebRTC is real time and real time is hard to debug.
It gets harder still if what you need to look at isn’t the signaling part but rather the media part.
I know you just LOVE adding your own printf and cout statements in your C++ code and try reproducing that nagging bug. Or better yet – start collecting PCAP files and… err… read them.
It would be nice though if some of that logging, debugging, etc would be available without you having to always add these statements into the code. Maybe even have a mechanism in place with different log levels – and have sensible information written into the logs so the time you’ll need to invest in finding bugs will be reduced.
Also – make sure it is easy to plug a monitoring system to the “application” metrics of the media server you are going to use. If there is no easy way to test the health of this thing in production, it is either not used in production or requires some modifications to get there. You don’t want to be in that predicament.
While at it – make sure the code itself is well documented. There’s nothing as frustrating (and as stupid) as the self explanatory code notion. People – code can’t explain itself – it does what it does. I know that the person who wrote that media server was god incarnate, but the rest of us aren’t. Your programmers are excellent, but trust me – not that good. Pick something maintainable. Something that is self explanatory because someone took the time to write some damn good comments in the tricky parts of the code. I know this one is also part of grokking the code, but it is that important – check it twice.
For me, the ability to debug, troubleshoot and find issues faster is usually a critical one for something that is going to get into my own business. Just a thought.
6. Does it Scale?Media servers are resource hogs (check this video mini series for a quick explanation).
This means that in most likelihood, if your business will become successful in any way, you will need more than a single media server to run at “scale”.
You can always crank it up on Amazon AWS from m4.large up to m4.16xlarge, but then what’s next?
At the end of the day, scaling of media servers comes down to adding more machines. Which is simple enough until you start dealing with group calls.
Here’s an example.
Now… how do we scale this thing?
How many machines do we need to put out there? When do we decide that we don’t add new calls into a running machine? Do we cascade these machines when they are fully booked? Throw out calls and try to shift them to other machines?
I don’t know, but you should. At least if you’re serious about your product.
You probably won’t find the answers to this in the open source WebRTC media server’s documentation, but you should at least make sure you have some reasonable documentation of how to run it at scale, and not as a one-off instance only.
7. What Languages Does it Use?They wrote it in Kotlin.
Because that’s the greatest language ever. Here. Even Google just made it an official one for Android.
What can go wrong?
Two things I look for in the language being used:
Some of these things are Node.js based while other are written in Java. Which one are your developers more comfortable with? Which one fits better with your technology plans for your company in the next 5 years?
If you need to make a decision between two media servers and the main difference between them for you is the language – then go with the one that works better for your organization.
8. Does It Fit Your Signaling Paradigm?Three things you need in your WebRTC product:
That 3rd one isn’t mandatory, but it is if you’re reading this.
That media server needs to interact with the signaling server and the STUN/TURN server.
Sure. you can use the signaling capabilities of the media server, but they aren’t really meant for that, and my own suggestion is not to put the media server publicly out there for everything – have it controlled internally in your service. It just doesn’t make architectural sense for me.
So you’ll need to have it interacting with your signaling server. Check that they both share similar paradigms and notions, otherwise, this in itself is going to be quite a headache.
While at it – check that there’s easy integration between the media server you’re selecting and the STUN/TURN server that you’ve decided to use. This one is usually simple enough, but just make sure you’re not in for a surprise here.
9. Is the License Right For You?BSD? MIT? APL? GPL? AGPL?
What license does this open source WebRTC media server framework comes with exactly?
Interestingly, some projects switch their license somewhere along the way. Jitsi did it after its acquisition by Atlassian – moving from LGPL to a more permissive APL.
The way your business model looks like, and the way you plan to deploy the service are going to affect the types of open source licenses you will want and will be able to adopt inside your service.
There are different types of free when it comes to open source licenses.
Click To Tweet
Every piece of code you pick and use needs to adhere to these internal requirements and constraints that you have, and that also includes the media server. Since the media server isn’t something you’ll be replacing in and out of place like a used battery, my suggestion is to pick something that comes with a permissive open source license – or go for a commercial product instead (it will cost you, but will solve this nagging issue).
I’ve written about open source licenses before – check it out as well.
10. Is Anyone Offering Paid Support For It?Yes. I know.
You’re using open source to avoid paying anyone.
And yet. If you check many of the successful and well maintained open source projects – especially the small and mid-sized ones – you will see a business model behind them. A way for those who invest their time in it to make a living. In many cases, that business model is in support and custom development.
Having paid support as an option means two things:
If no one is offering any paid support, then who is maintaining this code and to what end? What would encourage them to continue with this investment? Will they just decide to stop investing in it next month? Last month? Next year?
Making the DecisionI am not sure about you, but I love making decisions. I really do.
Taking in the requirements and the constraints, understanding that there’s always unknowns and partial information. And from there distill a decision. A decisive selection of what to go with.
You can find more technical information on media servers in this great compilation made by Gustavo Garcia.
After you take the functional requirements that you have, and find a few suitable open source WebRTC media frameworks that can fit these requirements, go over this list.
See how each of them addresses the points raised. It should help you get to the answer you are seeking about which framework to go with.
Towards that goal, I also created a Media Server Framework Selection Sheet. Use it when the need comes to select an open source WebRTC media server framework for your project.
Get the worksheet
The post 10 Tips for Choosing the Right WebRTC Open Source Media Server Framework appeared first on BlogGeek.me.
Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.
Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.
Wow, this most certainly is a great a theme.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.