What is WebRTC and What is it Good For? This 7-minute video provides a quick introduction to WebRTC and demonstrates why it is growing in importance and popularity.
Covered in this video:
WebRTC is an HTML5 specification that you can use to add real time media communications directly between browser and devices.
WebRTC enables for voices and video communication to work inside web pages.
And you can do that without the need of any prerequisite of plugins to be installed in the browser.
WebRTC was announced in 2011 and since then it has steadily grown in popularity and adoption.
By 2016 there has been an estimate from 2 billion browsers installed that are enabled to work with WebRTC. From traffic perspective, WebRTC has seen an estimate of over a billion minutes and 500 terabytes of data transmitted every week from browser communications alone. Today, WebRTC is widely popular for video calling but it is capable of so much more.
A few things worth mentioning:
It is important to understand from where we are coming from: If you wanted to build anything that allowed for voice or video calling a few years ago, you were most probably used C/C++ for that. This means long development cycles and higher development costs.
WebRTC today is available in most modern browsers. Chrome, Firefox and Microsoft Edge support it already, while Apple is rumored to be in the process of adding WebRTC to Safari.
You can also take WebRTC and embed it into an application without the need of browser at all.Media and access
What WebRTC does is allow the access to devices. You can access the microphone of your device, the camera that you have on your phone or laptop – or it can be a screen itself. You can capture the screen of the user and then have that screen shared or recorded remotely.
Whatever WebRTC does that does in the real time, enabling live interactions.
WebRTC isn’t limited to voice and video. It allows sending any type of data any arbitrary dataThere are several reasons WebRTC is a great choice for real time communications
So what other choice do you really have besides using WebRTC?
The idea around WebRTC and what you can use it for are limitless. So go on start building whatever you need and use WebRTC for that.
Embed this video on your own site for free! Just copy and paste the code below…<iframe src="https://player.vimeo.com/video/217448338" width="640" height="360" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
Contact centers are the main adopters of WebRTC still. This is clearly reflected by my infographic of the WebRTC state of the market 2017.
Motto:“This ‘telephone’ has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us.”
Western Union telegraph company memo, 1877.
Think you know how WebRTC fits in a contact center? Check out with The Complete WebRTC Contact Center Uses SwipefileGet the swipefile
Recently, Jaroslav from iCORD, told me the stats they now see from the contact center deployment they have in O2 Czech Republic, who also happen to be their parent company.How is O2 CZ making use of WebRTC in their Contact Center?
What they did isn’t the classic approach you will see to WebRTC in contact centers, but rather something slightly different. If you are a customer of O2 CZ and you are thinking of making a purchase on their website, you have the option to leave a number for them to immediately get back to you:
And yes – there is also an “exit intent” on that sales page, so if try to leave this page, it will appear as a popup.
How is a phone call related to WebRTC you ask? Well… it isn’t. Unless you factor in the fact that we now know what web page the user is on.
What happens next, is that a contact center agent will call back to the user, and the user will see something new on his browser – a shared space between him and the agent that just called him.
This shared space will enable the agent to browse the same page the customer was on, and move on from there elsewhere. It also includes annotations – the agent can draw or mark things on the screen. One last thing – the user will see the video of the agent, but will not share his video.
See? They even haggle and write down discount prices right on the webpage.
Now, if the interaction started with a phone call, the agent in the contact center can instruct the customer to go to the O2 CZ website and enter a PIN code there – and magically get to the same experience.
Here’s a diagram to show the communication channels we now have between the customer and the contact center agent:
Why this approach?
But was this effective? Was it worth the effort?
O2 CZ have been running this contact center service throughout 2016, and took the time to analyze the results. They did so only for sales related calls – the money makers.
Here’s what they found out:
Using this approach is much more efficient than a simple phone call.
Let’s stop right here for a second and soak that statement.
We’re talking about a contact center.
Of a mid-sized European carrier (4 million subscribers).
The type of those where I am told over and over would NOT adopt WebRTC because it does not support Internet Explorer 4. Oh. And this specific service falls back to Flash if the customer’s browser doesn’t support WebRTC and even decreases further in feature set to static screenshot and PDF file sharing for those who don’t even support Flash.
And they are already doing it for a full year.
In front of live customers.
Who would have thought a non-startup company that isn’t located in Silicon Valley and operated by 16-year olds would be able of doing such a ridiculous thing like deploy WebRTC in production directly to where money gets negotiated with customers.
— end of rant —
Back to the results.Call length on average dropped
It takes 30% less time to negotiate and close a deal than a regular phone call and considerably shorter than text chat. This may seem a bit backwards – the fact that chat takes the longest and a video session the shortest, but that’s the experience of this contact center.
How about succeeding to close a deal and make a sale? WebRTC gets closed deals 25% more than regular phone calls. Chat is slightly less successful than WebRTC but more successful as phone. These values were measured on session landing at sales agents’ desk once those irrelevant and redirected were filtered out.
And the customer satisfaction? Over 20% rate the service 5 stars at the end of the interaction and 7% left positive textual evaluation of the service. Compared to the traditional IVR system that’s really high.Where does this lead us?
And if you are looking for more information about the O2 CZ deployment details – especially the technical ones, Jaroslav will be happy to have a conversation with you.
The post What to Expect when Deploying WebRTC in Contact Centers? appeared first on BlogGeek.me.
How do you find good WebRTC outsourcing talent?
At least once a week.
That’s about the current rate in which I bump into a hiring or talent question related to WebRTC.
Recently, I got a few calls with companies that went through the process of working with an outsourcing vendor who developed their app and got stuck.
Sometimes it was due to bad blood going between the two companies. But more often than not it was because the company that approached me wasn’t happy with the delivered results. The application that was developed just didn’t really work as expected. Looking at some of these apps, it was easily apparent to see that the developers were clueless about WebRTC. Things like wrong NAT traversal configurations (or none at all), or the use of mesh media delivery for large multiparty video sessions are the most obvious warning signs here.
If I had to think why this is so, my guess it boils down to three reasons:
When you go and ask from an outsourcing vendor to build you a service, the answer you will get is “sure thing”. And then a price and a timeline. That’s their business, and most would often use that project as their jumping board towards another domain of expertise for them. Many of these outsourcing vendors won’t invest in learning new technologies without a customer paying for that investment.
This means that a lot of the market for WebRTC outsourcing is a market of lemons. Which is why it is so important you check and validate your prospective WebRTC outsourcing vendor before signing an agreement with him.
Picked a WebRTC outsourcing vendor? Here are a few quick telltale signs that will help you determine just how knowledgeable he is about WebRTC:Get the WebRTC Outsourcing Vendor Signals swipefile
Here are 6 questions to ask yourself before you hire a WebRTC outsourcing vendor.#1 – Do I know my own requirements?
There are two parts to knowing your requirements from the product:
For that, I suggest you use something like my WebRTC requirements template.
This is a biggie.
Try. Not. To be. Their FIRST. Customer. That does. WebRTC.
Don’t be their first customer doing WebRTC.
Make sure you’re not the first one they build a WebRTC product for.
Their first WebRTC project? You shouldn’t be the one they do it for.
Got the point?
One more time if you missed it:
I knew that picture (and font) would come in handy some day.#3 – Is the team working for me built a WebRTC product before?
This one is somewhat tricky, and I must say – a bit new in my list of top questions to a WebRTC outsourcing vendor.
If you’ve been reading this from the start instead of skimming through, you might have seen the number 12,000. This number is higher than the number of profiles in LinkedIn that have the term WebRTC in them anywhere. It means that with some of these WebRTC outsourcing vendors, the people put in place on your project might not be the ones who know WebRTC – these are already fully booked by other clients – or they might have gone elsewhere (with the demand of WebRTC developers, I wouldn’t be surprised to see them learn the trade in one vendor and move on to the next).
I’ve seen it happen once or twice before.
So make sure that not only does the vendor knows WebRTC well – he is also placing the right people on your project. And understand that there are times when not the whole team must know WebRTC to develop a successful project.#4 – Can I validate what they build for me?
Developers who don’t know and understand WebRTC won’t be able to deliver a commercial product for you.
If they don’t understand the server side of WebRTC and its implications (check my free mini course on WebRTC server side), then the end result will run great between you and your pal sitting next to you, but when you take it to production it will fail spectacularly.
Things to look for:
While some of these can be solved just by more testing (and focused testing – one where the tester actually knows what to look for), there are times when the architecture selected for the product is just all wrong. It should have been apparent from the get go that it won’t hold water.
But anyways – make sure you’ve got a plan in place on what and how to test to validate that that thing that was given to you as the finished good is actually the finished good and not finished for good.#5 – Should I ask for something On Premise or CPaaS based?
This goes back to #1, but slightly different. Probably should have placed it as #2.
Developing your own product from scratch will be more expensive than using a CPaaS vendor. CPaaS vendors are those vendors that take the whole hassle of real time communications, wrap it with their nice API and manage it all for you (and yes, I wrote a report about them).
Whenever I sit down with an entrepreneur that wants a product I start there when it comes to vendor and technology stack selections. Trying to understand his restrictions and requirements. Oftentimes, entrepreneurs are deterred by the seemingly high pricing of CPaaS vendors. Especially at the beginning – when they believe they will get to a million monthly active subscribers within a month. Well… it won’t happen to you. And if it does, a VC or two will probably be happy to foot that bill, understanding you probably found a real boon.
What should you do?
Someone needs to be the owner of this project on your end.
Yes. You have a WebRTC outsourcing vendor developing this thing for you, but you need someone to have that vendor behave and deliver.
That someone needs to understand WebRTC well enough to handle the requirements, the discussions with the vendor for all the issues that will arise along the way.
I’d also recommend having that someone on the payroll and not external.
If you don’t have such a someone then you effectively selected you for that job. Congrats!Do Your Homework
If you plan on starting a project that makes use of WebRTC, and you plan on using a WebRTC outsourcing vendor for it, start by doing your homework.
Make sure you have the answers to the questions above.
And if you need help along the way – with the requirements, the architecture, the vendor to select, the process – you know where to find me.
Picked a WebRTC outsourcing vendor? Here are a few quick telltale signs that will help you determine just how knowledgeable he is about WebRTC:Get the WebRTC Outsourcing Vendor Signals swipefile
The post 6 Questions to Ask Yourself BEFORE Hiring a WebRTC Outsourcing Vendor appeared first on BlogGeek.me.
My physical machine runs Debian Jessie, and it has several LXC containers (mostly Debian and Ubuntu). Now I needed to test some software under CentOS, and I bumped into the following error when installing Apache HTTP server:Downloading packages: httpd-2.4.6-45.el7.centos.4.x86_64.rpm | 2.7 MB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : httpd-2.4.6-45.el7.centos.4.x86_64 1/1 Error unpacking rpm package httpd-2.4.6-45.el7.centos.4.x86_64 error: unpacking of archive failed on file /usr/sbin/suexec;590112cd: cpio: cap_set_file Verifying : httpd-2.4.6-45.el7.centos.4.x86_64 1/1 Failed: httpd.x86_64 0:2.4.6-45.el7.centos.4
The thing is, that by default “/usr/share/lxc/config/centos.common.conf” defines the following capability drops:lxc.cap.drop = mac_admin mac_override setfcap setpcap lxc.cap.drop = sys_module sys_nice sys_pacct lxc.cap.drop = sys_rawio sys_time
So, setfcap capability is required in order to install Apache. Use the following lines in your “/var/lib/lxc/NAME/config” to drop previously defined drops and set up a new list:# flush all defined drops and define a new list lxc.cap.drop = lxc.cap.drop = mac_admin mac_override setpcap lxc.cap.drop = sys_module sys_nice sys_pacct lxc.cap.drop = sys_rawio sys_time
then restart the container, and “yum install httpd” should run as expected.
Security is… complex. Even with WebRTC.
I’ve always been one to praise the security measures placed in WebRTC.
While WebRTC is a secure protocol by nature, it seems that browsers take different approaches to who needs to take responsibility of any additional means of security.
The gist of it:
Seriously – what’s not to like?
Recently though, I started thinking about it. How do browser vendors think about security? How much do they take it upon themselves to be the guardians of their users? His trusted guide in the big bad world that is the Internet?
Which brings me to the big one –
Are browser vendors responsible to the actions of their users when it comes to WebRTC?
It seems that they have different approaches and concepts to this one.Google Chrome
Moto: Users are stupid and should be protected
That’s how I’d put their mindset to words.getUserMedia
Chrome has long been one to clamp down on where and when can WebRTC be used.
They started off with voice and video working on HTTP and HTTPS, while HTTP access granting to the camera and microphone were forgotten, and required a user’s approval each and every time.
They shifted towards HTTPS only. You can’t access the microphone or the camera in an HTTP page.Persistence
The decision a user made is persistent. If you granted a domain access to your microphone or camera – Chrome remembers it – for eternity. Your only way of revoking that is by clicking the camera icon on the address bar (if you can even notice it):
Oh, and for persistency – Chrome offers you two choices:
No middle-ground here.Screen sharing
You can share your screen with Chrome.
But it will ask the user each time for his permission.
And to enable screen sharing, you will first need to create a Chrome Extension for your web app and have the user install it. Not a biggie, but a hurdle.
Now, to publish a Chrome Extension on the Chrome Web Store, you’ll need to pay a small $5 fee.
Why? Fraud – obviously:
You see, screen sharing is considered by Google (and most other browsers) as more of a security threat than camera and microphone access.
By forcing the Chrome Extension, Google raises the bar against abuse, and can theoretically remove any abusive accounts and extensions with better tracability to their source.
The only real downside of it? I have over 10 icons on my toolbar now in Chrome, and most of them are for screen sharing on different services. Once a move I remove a few of them to declutter my browser. Yuck.Mozilla Firefox
Moto: Users are intelligent
Maybe. But not all of humanity. Or even the billion or two that use browsers.getUserMedia
In Firefox, getUserMedia will work in HTTP.
Not sure if persistence can be configured for Firefox for HTTP websites. I guess it is akin to herd immunity in vaccination. Since Chrome is THE browser, developers make sure their WebRTC service works on Chrome (lets call it Chrome first?) so their service starts by running only on HTTPS anyway.Persistence
Anyways, Philipp Hancke wrote a great post about getUserMedia and timing with browsers. Here’s how timing looks for appear.in from the moment getUserMedia is called and until it is completed:
Firefox tend to take longer to complete its getUserMedia calls. Philipp attributes it to this little UI design in Firefox:
In Firefox, if you want to decision (allow/disallow) to be persisted, you need to opt in for it. And for appear.in, most people don’t opt in.
This is great, especially for the Don’t Allow option (it is quite a hassle to remove that restriction from Chrome once you decided not to allow such access in a session).Screen sharing
For screen sharing, Firefox used to have a whitelist of domains you had to register on to get screen sharing to work.
From Firefox 52, this restriction has been removed. Mozilla wrote a post about it, explaining their millions of users around the world about the dangers.
I am not sure about you, but I’ve learned early on as a developer catering to developers that other developers are stupid (if you are a developer, then I am sorry, but bear with me – and read this one while you’re at it). So when I wrote code for developers, I made sure that if they screw things up, we crash spectacularly. The reasoning was, the sooner we crash the faster our customers (who are developers) will fix their bugs – and do that during development – so they won’t get into deadlocks or weird crashes in production that are way harder to find. These were the good old days of C programming.
Now… if developers are stupid, then what would mere users do about their understanding of security and threats?
In Firefox, they need to read and understand that yellowish warning when all they want to do is share their screen now – after all – people are waiting for them to do so in the session already.
With such a warning… I am not sure I am going to be in a trusting mood no matter the site.
While I mostly prefer Firefox approach for getUserMedia permissions, I think Chrome does a better job at it with the extensions mechanism.Microsoft Edge
Microsoft Edge has started to support WebRTC (finally).
While I a, in the process of installing my Creators update (where I am promised proper support for WebRTC), this will take more time than I have to get some nice screenshots of what Edge is doing.
So I asked Philipp Hancke (like I do about these things).
Here’s what I got:
Download the WebRTC Device Cheat Sheet to learn more on how to get WebRTC to as many devices and environments as possible.Are Browser Vendors Responsible for Our WebRTC Actions?
Yes they are.
In the same approach that browser vendors are taking in HTTPS everywhere, removing Flash from the web, protecting against known phishing sites, etc; they need to also protect users from the abuse of WebRTC.
The first step is by not allowing developers to do stupid (by forcing encryption and DTLS-SRTP for example). The second one and just as important is by not allowing users to do stupid.
The post Should Browser Vendors be Responsible for their User’s WebRTC Actions? appeared first on BlogGeek.me.
And I have a couple of bonuses waiting for you in this WebRTC course launch.
I’ve been thinking lately on how to make this course available throughout the year, but still “launch” it as a live program once or twice every year. The idea here is to get as many people as possible into the course and improve our current market state (which is rather abysmal):
I always say that WebRTC sits between Web and VoIP, but I guess this says it best.
You can find a million people whose profile contain either “VoIP” or “HTML5”. If you go into specifics, you’ll have hundred of thousands of people with either “SIP” or “Node.js”. But “WebRTC”? Only 11,874 righteous people. We’re a pretty small industry. And those with enough understanding and knowledge of WebRTC? Probably less than that.What are people challenged with?
The request that comes up almost every time someone contacts me through the blog? It is about finding an experienced WebRTC developer. Here are a few “sound bites” from these emails I am getting:
if we were to hire someone to build our own platform – what qualifications in a programmer would I need to look for?!!
We are needing to develop video chat and having a difficult time finding a qualified developer to create this
I am seeking a WebRTC engineer to do a peer review on a WebRTC app I had developed in oversees (west Russia.)
A couple of thoughts about this
And since the market is so slim on resources (around 12,000 people know WebRTC out of a million who know VoIP – when all VoIP projects are adding WebRTC these days), demand and supply don’t match.My WebRTC course and its bonuses
Tomorrow, my Advanced WebRTC Architecture course officially launches. If you haven’t enrolled already, then you should seriously consider doing so.
The previous round had almost 100 students going through it with some very positive feedback.
There are going to be a few bonus materials that I will be giving for anyone who enrolls today (or already enrolled):#1 – 2 live lessons
There are going to be 2 special live lessons taking place. They will be recorded for those who can’t join live. But the lessons as well as the recordings will only be available as part of the course bonuses.
LIVE Lesson 1: Philipp Hancke – Video Quality in WebRTC: The audio and video quality WebRTC provides is amazing. Well, most of the time at least. Sometimes, the video gets pixelated and audio starts dropping out even. What is going on here and why is bandwidth estimation still a problem?
LIVE Lesson 2: Bradley T. Hughes – How to deploy TURN on AWS? TURN servers are boring. They do nothing but relay data. However, they are necessary in WebRTC. Here’s how appear.in’s global TURN infrastructure works – and how you should think of when deploying your own.
2 live lessons.
With top industry experts.
Recorded and available only for you.#2 – The Perfect WebRTC Developer Profile ebook
Recently I’ve been asked multiple times about CVs and profiles and stuff. It goes both ways:
I had my own thoughts about it, but decided to take a different route on this one. I went and asked top developers and “recruiters” who work with WebRTC for quite some time now. I asked them about the ideal WebRTC developer and what they’d look for in a CV. Collected the answers and created an ebook out of it:
Who’s in there? Amir Zmora, Arin Sime, Chad Hart, Emil Ivov, Gustavo García, Iñaki Baz Castillo and Philipp Hancke.
You’ll get to see what they think about WebRTC developers and what it means to be a WebRTC professional.#3 – WebRTC Course FAQ
There are a lot of popular questions out there about WebRTC. You can find them lurking on webrtc-discuss forum, stackoverflow, Quora and elsewhere. But what are the answers? And how should you go about finding them?
What I did in the past few weeks was collect questions and map them to the course lessons. To these questions I provided short and clear answers for you, packaging it all in a neat document.
Now, you can use these questions to tackle specific issues you bump into – or to check how much you understood of the lessons of the course. Hell – if you need to recruit someone – you might as well use it as some good questions to ask to gauge experience.What if you are not sure?
Besides looking at the testimonials from previous students, I can suggest checking out two things:
Bonuses will go away in 48 hours.
After that, the only price plan available for the course will be the Plus price plan and it will only include the Office Hours for the initial duration of this course.
NanoPi NEO2 by FriendlyElec is a new sub-$20 Linux microcomputer, built on Allwinner H5 SoC, providing a Gigabit Ethernet and USB 2.0 interface. Also additional interfaces are possible via expansion headers (needs some soldering work). The board is equipped with 512MB DDR3 RAM.
It is highly recommended to buy the heatsink alongside with the board. The CPU is heating up quite significantly, and it needs cooling. With “stress -c 4” CPU load test, “armbianmonitor -m” shows the core temperature rising up to 75C. The board sustains long-term load under such conditions. But with a fan, the core temperature drops below 40C, and the power consumption drops significantly too.
The plastic 3D-printed enclosure is of little use. First, it’s quite easy to break when you insert the board. Also it does not fixate the heatsink properly.
So, I ended up in using the original cardboard packaging as a base for the board, just to avoid extra touching of electronic circuits, and to fixate the USB power cable:
Armbian nightly image booted without problems. Up to now, I noticed the following minor problems with it:
All in all, this board looks much more reliable than Orange Pi Zero: it can work for long hours with an USB Wifi dongle, whereas OPI0 was hanging up after few minutes of work (using the same USB power cable and power source and the dongle).
Have questions about my course? Here’s a WebRTC Course AMA for you.
Later this week, I will be opening my Advanced WebRTC Architecture course for enrollment again.
Last year, I decided to launch a course to teach WebRTC. Something different than just going through the WebRTC APIs or explaining the network specification. The end result? A 100 people enrolled and when through the course (!) And more than that – people seemed to be genuinely satisfied with it (!!)
It was fun, so it is time to do it again.
While I am changing and adding stuff to the course, the baseline material is going to stay the same – most of it is “timeless” anyway.
I am adding to this round a couple of things, and this one I want to mention two of them:#1 – Corporate Plans
The course now has a corporate plan, for larger teams who need to use WebRTC. I’ve got a couple of companies already enrolled to it, which is great.
Corporate plans include a private Slack forum for Q&As alongside the course’ forum. They also include a corporate badge that you can use on your own site, along with their logo on my own site as Corporate Partners.
If you want to learn more about the corporate plans, check out the course syllabus (PDF).#2 – Course AMA
Philipp forced my hands on this one…
— Philipp Hancke (@HCornflower) April 7, 2017
Only thing left to do is…
I am trying to make this the best place for people to get their WebRTC education.
For those who aren’t sure yet, I’ll be hosting a WebRTC Course AMA, where you can Ask Me Anything. About the course. About WebRTC. About me. About the weather (though I know nothing interesting about the weather).
The WebRTC Course AMA is free to attend. It will be part webinar, part Q&A, but mostly fun.
Philipp – you are hereby cordially invited to join as well
Register to the WebRTC Course AMA – and even write down your questions on the event’s page right now – no need to wait until the 19th for that!#3 – A few more launch bonuses
For those who end up enrolling early, I’ll have a few additional launch bonuses, but that’s for later.
On a personal note, today is Passover here in Israel. If I seemed somewhat “off” in the past couple of days (or will seem like that in the coming days), then it probably has to do with me eating too much food and spending some time with my family.
The post My Advanced WebRTC Architecture Course is back with an AMA appeared first on BlogGeek.me.
No such thing as free lunch. Or a free TURN server.
It is now 2017 and WebRTC has been with us for over 5 years now. You’d think that by now people would know enough about WebRTC so that noob questions won’t be with us anymore. But that just isn’t the case.Want to learn more about WebRTC server requirements and specifications? Enroll now to my 3-part video mini-course for free:
One question that comes up from time to time is why doesn’t Google (or anyone else for that matter) offer a free TURN server?
Besides the fact that you shouldn’t be using free STUN or TURN servers that are out there simply because you have zero way to control them when things go wrong, lets first understand what’s the difference between these two servers – or more accurately protocols, since STUN and TURN usually end up being deployed together.How STUN works
The illustration below should give you the gist of how STUN works:
When STUN is used, the browser or any other WebRTC enabled device sends out a message to the STUN server asking him “who am I?”. The idea here that STUN is used to find out your public IP address. This is something your machine doesn’t know on its own as this “allocation” happens by the NAT you are behind (and you will almost always be behind a NAT). That information is also dynamic in nature – you can’t really rely on the same answer being received each time – or that the pinhole generated by the query itself will stay open.
This is a simple question that the STUN can provide a single answer for. Furthermore, this takes place over UDP, making it lightweight and quick – not even requiring establishing a longstanding connection or having context in place.
Once the browser has the answer, he can share it, and if all else works as expected, he will be receiving media directly.
The STUN’s role here was limited to this single question at the beginning.How TURN works
Here’s how TURN works:
When it comes to TURN, we start with a request for binding – our browser is practically asking the TURN server if he can be used as a relay point. And if the TURN server obliges, then it can now be used to receive all media from the other device on the session and relay that to our own browser.
While the initial binding request isn’t taxing (though still more expensive on our TURN server than the query sent to the STUN server), the real issue is the media that gets relayed.
If you take a simple WebRTC video session that gets limited to 500kbps or so, then a 15 minute session will end up eating…
That ends up being over 50MB in traffic. Assuming we do only 10 sessions an hour on average on that TURN server, we end up with 360GB in traffic per month. And that for quite a small service. It isn’t really expensive, but it does if you scale it up: use more bandwidth per session, have more sessions per hour on average – and you’re going to end up with lots of data traffic.
Here’s how a recent stress run we’ve had on testRTC ended up:
For a stress test with 500 participants, split into group of 5 browsers per multiparty call, running for only 6.5 minutes, we ended up with 52Gb of media traffic in each direction. Less than 10 minutes.
Now think what happens if all that traffic need to go through a TURN server. And that TURN server is free for all.Putting it all together
STUN and TURN are drastically different from each other. We need both in real production WebRTC services. And we usually think of them of a single server entity deployed in the backend – for STUN we simply don’t fret about the resource needs it has and focus on what we need to get TURN running in scale and in multiple geographical locations.
It is also standard practice to clamp down on your TURN server and have credentials configured for it. For WebRTC, these credentials need to be ephemeral in nature – created per session on demand and not per user (as often is the case in SIP).
Tomorrow, I will be launching a free video mini-course. This course explains what servers you will need to deploy for your WebRTC product, what are their machine specifications and what are the tools that are out there to assist you developing them faster.Want to learn more about WebRTC server requirements and specifications? Enroll now to my 3-part video mini-course for free: