bloggeek

Subscribe to bloggeek feed
The leading authority on WebRTC
Updated: 7 min 56 sec ago

The Best WebRTC Security is Prone to the Stupidest Developer

Mon, 12/19/2016 - 12:00

WebRTC is the most secure technology for video communications. And yet – developers can screw this for you.

There is a rise in security breaches and data theft incidents in 2016. You see this from the amount of information out there. I’ve written about WebRTC and security for quite some time, but a recent post I’ve read compelled me to write about it again.

The post? Red Cross Blood Service in Australia leaks personal data.

The gist:

  • Site is secure
  • A contractor places database dump on the internet for backup
  • And that get found

It probably happens more often than not. You build a service. You take care of its security. And then, someone down the lines screws you over with his maintenance processes. To some extent, this is just as bad as social engineering, where a hacker tries to gain access by fooling people to believe he is someone else.

Make sure to download the WebRTC Security checklist. Print it and stick it on the wall behind your monitor so you don’t forget.WebRTC Security baseline

WebRTC comes with a few security concepts that are quite new and innovative in VoIP:

  1. In WebRTC, EVERYTHING is encrypted. Not only by default, but also in a way that can’t be modified – there is no way to send data over WebRTC in the clear
  2. WebRTC forces you to operate over HTTPS and WSS in your web application, so signaling gets encrypted as well
  3. Screensharing requires an additional layer of consent, be it whitelisting of your site or a creation of a browser extension
  4. Browsers today update frequently and automatically, so any security threat found gets patched faster than most enterprise and VoIP vendors react to their security breaches

The thing people forget is that WebRTC is just a piece of technology. A building block. It is up to the developers to decide how to use it in their own product. During that integration, security breaches can be created quite easily.

In the WebRTC course I launched two months ago, I’ve added a lesson dealing with WebRTC security. It goes through the mechanisms that exist in WebRTC and the areas that need to be further secured by the application.

Two big issues left to developers today are TURN passwords and access to backend server resources.

#1 – TURN passwords

TURN servers predate WebRTC. They are used by SIP (or at least are found in the spec), and there, the notion is that the user agent (=device/endpoint) is secure and “named”. So a username and password mechanism was created to get a TURN binding. The reason you want such a mechanism in the first place is because TURN servers are bandwidth hogs – they relay media, and by doing that they cost a lot in terms of bandwidth. So if you are paying for it, you don’t want others to piggyback on it.

The problem with this approach in WebRTC is that the username and password needs to be passed from your JavaScript code inside the browser to the server. Which means that information is available in the clear for many use cases – those where you don’t need or want the user to identify with the network at all.You also don’t want someone sniffing your code in the browser and then reusing these credentials elsewhere.

The current approach out there is to use temporary passwords (I like calling them ephemeral – it makes me sound intelligent). Ones that become useless in an hour or two.

This means that someone in your backend randomly creates a password that is short-lived and shares it with both the TURN server and the client.

The above illustrates how this is done.

  • The App Server, in charge of signaling in this case, creates a password. It updates the TURN server about said password and also gives that information to the User
  • The User then creates a peer connection, configuring the TURN server in it with the relevant temporary password

Great.

Now lets add a media server into the mix.

Who should be generating that password and passing it around to whom? Should the Media Server now be in charge of it, or is it up to the App Server still to take care of this?

Which leads me to the second important security aspect of WebRTC when it comes to your development – backend server resources you need to protect.

#2 – Backend server resources

In many cases, I find that when the work is outsourced, the end result tends to be a jumble of an architecture if things aren’t thought out properly from the beginning.

This usually causes the wrong servers to need to connect and communicate directly with the User. While not an issue on its own, it can easily turn into a headache:

  • Not having a clear picture of the state in your backend means you lose control – this can turn ugly when issues arise
  • Opening up more of your backend towards the internet means more points to secure against penetration
    • And yes – I know there’s a trend to treat servers in the cloud as if they are always open to the internet
    • Which means you need to think about how best to protect them in the first place anyway, which happens to be closing them as much as possible

What I suggest in many cases is:

  1. Media servers should never be controlled or accessed directly from the Internet
  2. Media servers should only pass media to and from the Internet
  3. Whenever they need to be controlled, you do that using backend-to-backend communication from other servers you have that are already managing the users on the Internet
What’s next?

I am not a security expert. I know a bit about it and try to stay informed, but I am by no means an expert in it.

You should make sure to take security into consideration when developing your service and don’t assume WebRTC does everything for you. It doesn’t, but it is the best starting point you’ll get.

If you want to learn more about WebRTC, I will be opening the course again for another round. Probably during April.

If you are a corporate looking to have an open access to course materials throughout the year for your workforce – I am going to announce such a plan soon, but feel free to reach out to me before that happens.

Just do me a favor – don’t leave WebRTC security to chance.

Need a reminder? Download the WebRTC Security checklist. Print it and stick it on the wall behind your monitor so you don’t forget.

The post The Best WebRTC Security is Prone to the Stupidest Developer appeared first on BlogGeek.me.

How to Write the WebRTC Requirements for Your New Product?

Mon, 12/12/2016 - 12:00

Got a requirements document to write for WebRTC? Here’s a step by step guide to doing just that.

Here is something that I do with my customers quite often. In many cases, when I consult vendors, they are in the process of building a new product or integrating an existing product with some new communication capabilities. This involves using WebRTC and outsourcing the actual development.

More often than not, I find myself writing the baseline of the requirements document for the customer, to server as a WebRTC RFP (Request For Proposals) that get used to communicate the requirements with the potential outsourcing vendors.

I wanted to share the process that I use in writing the first draft of this document. To make this a bit more useful, let’s assume that what we want to do is build a webinars service, where a few people can join as the speakers in the webinar and people online can “listen in”.

I’ve created a WebRTC requirements template and a sample webinars requirements document that you can use when you need to write the requirements for your own product.

Get the WebRTC Requirements Template and Sample Webinars Requirements Document

Here’s step by step how I’d go about doing that.

Step #1: Structure your document

First things first. To make sure I don’t forget anything, I like to split my requirements document into 4 sections:

  1. Overview
  2. Architecture
  3. Functional
  4. Non-functional

As you can see in above, I place TBD for each section in the document. I do that for all sub sections that I add to the document as well. This way, I can easily search the areas that haven’t been filled in properly yet when I work on it. Most often than not, writing these WebRTC requirements take a couple of hours and span a few days because they are collaborative in nature.

I tend to leave out the mechanics around the project – such as the price model I am looking for, or the timeline of the project. These tend to change between companies and they often better reflected elsewhere than in the technical requirements that I try to describe here.

Step #2: Write the overview

First thing I do once I have the template ready for my needs is write the overview part.

I try to keep the overview short and sweet, with a focus on making sure people understand what it is that I am trying to achieve in the service – what my challenges are and what I consider as success.

Usually, 2-3 paragraphs should be enough.

Step #3: Describe the architecture

Now it is time to start thinking about our architecture. By that, I don’t mean the architecture of the solution, what processes, servers and switches I want – I leave that for the vendor to fill in. What I mean is the entities I have in my service, trying to focus around the session – the types of media and signaling I want running there.

I do this by going analog, and just jot it down on my whiteboard and taking a picture of the end result. I find this more natural for me than using Powerpoint or Vizio. Later on, I might redo it as a Powerpoint diagram, but more often than not, I just leave it as is.

Above is the drawing I just did to describe the BlogGeek.me Webinar I just invented.

After the visual, I explain the different entities that are in the drawing and the relations between them. This part is really important, as oftentimes, it will reveal entities or flows that I haven’t thought about earlier.

In the case of the BlogGeek.me Webinar, we’ve got multiple potential Speakers who interact using audio and video with each other in the Webinar, which then gets sent to multiple Viewers and also to an external Storage.

I try to keep things focused and to the bare minimum that is necessary for the understanding of the service.

Step #4: Fill in the features

To some extent, this step is the main chunk of what the product does. For me, this is a brain dump of the things a user should be able to do in the system.

There are different types of features you might be needing. I focus on those that relate to the communication part of the product and nothing else.

Here’s a checklist of what I usually go through when doing this:

  • Is this a 1:1 service or multiparty?
  • Audio? Video?
  • Any screen sharing or other collaboration capabilities?
  • Messaging/chat?
  • How do users get authorized, authenticated and connected?
  • Any in-session controls users need to have?
  • Any indicators to show on their display?
  • Do we need recording capabilities?
  • Anything that we missed?

Make sure you answer all the questions above as requirements in the document if they make sense and add your own to the list.

Here are a few of the ones I’ve written for the webinars product:

Notice how I’ve indicated that connectivity via PSTN is optional in a future phase? This serves two purposes for me:

  1. It gives the vendor a hint of what architecture to put in place to support this later on down the road
  2. It also gives the vendor a feeling that this is a journey and not a one-off project. He will be more committed to its success if he knows you might call on him later on to improve and extend the service
Step #5: Handle the non-functional requirements

Now it is time to go over the non-functional requirements. These are the boring and ugly details that can make or break a service, so spend enough time on this one.

What do I mean by non-functional? These will usually be things you will take for granted, but the vendor won’t. To reduce friction and arguments in the future, I add these. In most likelihood, if you don’t write these down, a vendor will ask about a few of these things anyway – so just write them down to reduce the unnecessary round trips and to make sure you and the vendor are on the same page.

I tend to split this section to 5 subsections, each with its own focus:

1. Devices

Here I list all the devices I want to support. Browsers, operating systems, mobile devices, etc.

Each gets its own special treatment. Things I usually look at here are:

  • Which browsers to support natively?
  • Do I need an Electron PC app? If I do, then on which operating systems?
  • What versions of iOS to support? Which earliest devices?
  • What versions of Android API to support? How many specific devices do I want tested?

In many ways, I derive the requirements here based on the WebRTC Device Cheat Sheet that I published.

2. NAT traversal

NAT traversal is often overlooked. There are two areas where I cover NAT traversal – here and in the Security subsection below.

Here, I define who takes care of it – do I expect the vendor to bring a NAT traversal solution, will I be doing it, or should they use a third party hosted service (there are a few out there offering it).

The second part that I sometimes decide here, but not always, is where I want it deployed – along with the media servers or closer to the connecting user. It is a matter of architecture needs that I prefer leaving to the vendor to fill in but not always (can’t really say when in a definitive way).

In my webinar example, I decided to make things easy and just use a third-party hosting service:

3. Scalability

For scalability I make sure I cover a few areas:

  1. What’s the scale of a single session? Just make sure that if there are different types of users, you indicate how each can scale
  2. What’s the scale of the service as a whole? How many sessions can exist concurrently?
  3. Do I need to address any geographical locations when it comes to scaling?
  4. How are the different parts of the systems scale? Independently of each other?

Here’s how I fit it into our webinar example:

4. Security

The security part is slightly tricky. First, because I am not an expert. But also because almost nobody is.

What I usually place here is the basics of how I’d like to see the backend (encryption between the servers), but I do cover two important areas:

  1. Media servers. I prefer access to them to be limited to the application server only when it comes to control and have all signaling be routed through the application server or a signaling server. I don’t like giving access to my resource hog openly over the internet. Call me old fashioned
  2. TURN servers. Here I always state that I want ephemeral passwords. Otherwise, vendors usually do the short route of using a static username and password, which in WebRTC is like no password at all on the TURN server
5. DevOps

The DevOps section deals with things required to run this product on a daily basis. I tend to fill in three main things here:

  1. Hosting – is this planned to be deployed on premise? In a specific cloud provider? Using Docker or some other container technology?
  2. Reporting – what type of information do you want to collect to generate reports on the use of the system? These should be for offline use – think a daily email or something similar
  3. Events and statistics collection – this is what you want to be able to collect to monitor the health of the service in realtime
Step #6: Do a one-over and share

Now that we’ve written t all, time to go over the whole document to make sure things aren’t missing:

  1. Clean up any leftover TBDs
  2. Add clarifications where necessary
  3. Add things not in the template

Here’s what I decided to add to the webinar example:

As you can see, for me, open source was really important.

Now that you are done – go share the document with your colleagues, and once approved internally, it is time to share with potential outsourcing vendors.

Why so short?

To some, this approach may seem a bit shallow. It doesn’t include all corner cases or describe in a lot of detail what goes on. The thing is, that there is a balance between what you can effectively do and achieve as a small startup or even a big company with a new project than what you’d do on a long running multi-year millions of dollars project.

For me, this proves itself as a good way to capture the essence of what it is that needs to be developed and getting replies from potential vendors to building the product. Once I get the replies, it is time to go over them and see who makes the most sense – a lot based on how they replied to the RFP in the first place.

What’s next?

So here’s how you should write your next WebRTC requirements document:

Step #1: Structure the document to make sure all bases are covered

Step #2: Focus on the overview – explain what your product needs to achieve

Step #3: Draw the architecture and explain it

Step #4: Write down your functional requirements

Step #5: Write down all non-functional requirements

Step #6: Do a one-over to make sure you didn’t miss anything

I’ve built a WebRTC Requirements Template document for you. You can copy it and fill it in with the requirements of your own product. It already holds many of the questions you’ll need to answer, so it can serve as a guide for you.

Now, to write this article, I also had to create a real-world example (remember our webinar service?). This example is also shared so you can see how I write things down.

Get the WebRTC Requirements Template and Sample Webinars Requirements Document

Oh, and if you still need help – I do offer a consulting service, where a lot of the time invested is placed into writing these requirements documents, finding suitable potential vendors and going over their responses.

The post How to Write the WebRTC Requirements for Your New Product? appeared first on BlogGeek.me.

WebRTC and Education – the Webinar Edition (and a Bonus)

Mon, 12/05/2016 - 12:00

Want to learn more about WebRTC in education?

Next week, testRTC will be hosting a webinar titled How WebRTC ushers the next wave of e-Learning innovation. As a co-founder of testRTC, I am tasked with the actual creation and hosting of the webinar, which means I will be speaking about what vendors are doing WebRTC when it comes to education and where I see their challenges.

I haven’t done a webinar in quite some time, so this is going to be fun for me.

We’ve decided to use Crowdcast as our webinars platform for it. Partially because it is a WebRTC based service, and I do love dog fooding. But also because I received some good reviews about it.

If I had to pick two very active verticals in the domain of WebRTC, these would be healthcare and education. We see this also at testRTC, where we help these vendors in testing and deploying their services to production.

Next Wednesday

So here’s what we’re doing next Wednesday – me and you:

  • On December 14 at 14:30 EDT, we’re going to meet online
  • I am going to give a few interesting examples of how education looks like when it meets WebRTC
  • Then talk about some of the challenges involved
  • You will have time to ask questions. I’ll answer them to the best of my ability
  • And then I am going to give you a bonus
The examples

The examples part of the webinar is probably going to be the most interesting one.

I remember talking almost 3 years ago with a startup in India about their use case. It was related to education and it blew my mind. It was so starkly different than what I assumed a startup in India would do within their local market for education that I saw it as my own private lesson. Since then, I talked with tens of vendors in this space. Each doing his own thing. Each focusing on solving a problem in tutoring. They are so wide in variety that you can’t even look at them as a single market.

But this is exactly what we will try to do here. I am going to categorize them a bit – I wonder where you will find yourself in that categorization.

The challenges

Learning has its challenges for the student, the teacher and now also for the platform.

My intent is to look at the challenges of the platform – what are the things necessary to put these different education systems in production and how to make sure they work properly.

For the various types of education platforms, I’ll give you tips for where you should focus with your testing – what are the weak spots to look for – so you can find and deal with them before your customers do.

The bonus

I am not going to say what the bonus is now – it will ruin the surprise. I will say though, that this is something you’ll find immediately useful.

The bonus will be available only to those who will be with me during the webinar itself, so register now and save your place.

What’s next?Register of course!

And feel free to write down your questions in advance – Crowdcast allows for that.

The post WebRTC and Education – the Webinar Edition (and a Bonus) appeared first on BlogGeek.me.

WebRTC, TURN and Geolocation. How to Pick the Best Server to Work With?

Tue, 11/29/2016 - 12:00

Different ways to do the same thing.

One of the biggest problems is choice. We don’t like having choice. Really. The less options you have in front of you the easier it is to choose. The more options we have – the less inclined we are to make a decision. It might be this thing called FOMO – Fear Of Missing Out, or the fact that we don’t want to make a decision without having the whole information – something that is impossible to achieve anyway, or it might be just the fear of committing to something – commitment means owning the decision and its ramifications.

WebRTC comes with a huge set of options to select from if you are a developer. Heck – even as a user of this technology I can no longer say what service I am using:

  • I use Drum for my Virtual Coffee sessions (haven’t done one in some time. Should do one next month)
  • I now use Jitsi meet for my Office Hours
  • Google Hangouts for testRTC meetings with customers
  • Whatever a customer wants for my own consultation meetings, which varies between Hangouts, Skype, appear.in, talky, GoToMeeting, WebEx, … or the customer’s own service

In my online course, there’s a lesson discussing NAT traversal. One of the things I share there is the need to place the TURN server as close as possible to the edge – to the user with his WebRTC client. Last week, in one of my Office Hour sessions, a question was raised – how do you make that decision. And the answer isn’t clear cut. There are… a few options.

My guess is that in most cases, the idea or thought of taking a problem and scaling it out seems daunting. Taking that same scale out problem and spreading it across the globe to offer lower latency and geolocation support might seem paralyzing. At the end of the day, though it isn’t that complex to get a decent solution going.

The idea is you’ve got a user that runs on a browser or a mobile device. He is trying to reach out to your infrastructure (to another person probably, but still – through your infrastructure). And since your infrastructure is spread all over the globe, you want him to get the closest box to him.

How do we know what’s closest? Here are two ways I’ve seen this go down with WebRTC based services:

Via DNS

When your browser tries to reach out the server – be it the STUN or TURN server, the signaling server, or whatever – he ends up using DNS in most cases (you better use DNS than an IP address for these things in production – you are aware of it – right?).

Since the DNS knows where the request originated, it can make an informed decision as to which IP address to give back to the browser. That informed decision is done in the infrastructure side but by the DNS itself.

One of the popular services for it is AWS Route 53. From their website:

Amazon Route 53 Traffic Flow makes it easy for you to manage traffic globally through a variety of routing types, including Latency Based Routing, Geo DNS, and Weighted Round Robin.

This means you can put a policy in place so that the Route 53 DNS will simply route the incoming request to a server based on its location (Latency Based Routing, Geo DNS) or based on load balancing (Weighted Round Robin).

appear.in, for example, is making use of route53.

Amazon Route 53 isn’t the only such service – there are others out there, and depending on the cloud provider you use and your needs, you may end up using something else.

Via Geo IP

Another option is to use a Geo IP type of a service. You give your public IP address – and get your location in return.

You can use this link for exampleto check out where you are. Here’s what I get:

A few things that immediately show up here:

  • Yes. I live in Israel
  • Yes. My ISP is Bezeq
  • Not really… Tel-Aviv isn’t a state. It is just a city
  • And I don’t live in Bat Yam. I live in Kiryat Ono – a 20km drive

That said, this is pretty close!

Now, this is a link, but you can also get this kind of a thing programmatically and there are vendors who offer just that. I’ve head the pleasure to use MaxMind’s GeoIP. It comes in two flavors:

  1. As a service – you shoot them an API and get geo IP related information, priced per query
  2. As a database – you download their database and query it locally

There’s a kind of a confidence level to such a service, as the reply you get might not be accurate at all. We had a customer complaining at testRTC servers which jinxed his geolocation feature and added latency. His geo IP service thought the machine was in Europe while in truth it was located in the US.

The interesting thing is, that different such services will give you different responses. Here’s where I am located base (see here):

As you can see, there’s a real debate as to my exact whereabouts. They all feel I live in Israel, but the city thing is rather spread – and none of them is exact in my case.

So.

There are many Geo IP services. They will differ in the results they give. And they are best used if you need an application level geolocation solution and a DNS one can’t be used directly.

Telemetry

When inside an app, or even from a browser when you ask permission, you can get better location information.

A mobile device has a GPS, so it will know the position of the device better than anything else most of the time. The browser can do something similar.

The problem with this type of location is that you need permission to use it, and asking for more permissions from the user means adding friction – decide if this is what you want to do or not.

What’s next?

I am sure the DNS option is similar in its accuracy level to the geo IP ones, though it might be a bit more up to date, or have some learning algorithm to handle latency based routing. At the end of the day, you should use one of these options and it doesn’t really matters which.

Assume that the solution you end up with isn’t bulletproof – it will work most of the times, but sometimes it may fail – in which case, latency will suffer a bit.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

 

The post WebRTC, TURN and Geolocation. How to Pick the Best Server to Work With? appeared first on BlogGeek.me.

Kranky Geek 2016 SF: Mobile WebRTC

Mon, 11/21/2016 - 12:00

Kranky Geek last week was quite a rush.

Wow.

What can I say. Last week, our Kranky Geek event was so much fun.

I won’t bore you with the details. We’ve focused this time on WebRTC in mobile. Got the best speakers possible – really. And had a blast of an event. I received so much positive feedback that it warms my heart.

I’d like to thank our sponsors for this event: Google, Vidyo, Twilio and TokBox. Without them, this event wouldn’t have been possible.

The videos are available online, and below you’ll find the playlist of the event:

Tomorrow we’re doing another Kranky Geek event. This time in Sao Paulo, Brazil. Different theme. Different sessions. I am dead tired, but working hard with Chad and Chris to make that a huge success as well. See you soon!

 

The post Kranky Geek 2016 SF: Mobile WebRTC appeared first on BlogGeek.me.

My WebRTC Device Cheat Sheet

Mon, 11/14/2016 - 12:00

All you wanted to know but didn’t know how to ask.

2 billion Chrome browsers? 7 billion WebRTC enabled devices by 2017? 50 billion IoT devices?

At the end of the day, who cares? What you are really interested in is to make sure that the WebRTC product you develop will end up working for YOUR target customers. If these customers end up running Windows XP with Internet Explorer 6 then you couldn’t care less about Apple, Safari and iOS support. But if what you are targeting is a mobile app, then which browser supports webRTC is less of an issue for you.

To make things a bit simpler for you, I decided to create a quick Cheat Sheet. A one pager to focus you better on where you need to invest with your WebRTC efforts.

This cheat sheet includes all the various devices and browsers, and more importantly, how to get WebRTC to work on them.

So why wait? Grab your copy of the cheat sheet by filling out this form:

  • Name* First Last
  • Company*
  • Email*
  • CommentsThis field is for validation purposes and should be left unchanged.
jQuery(document).bind('gform_post_render', function(event, formId, currentPage){if(formId == 9) {} } );jQuery(document).bind('gform_post_conditional_logic', function(event, formId, fields, isInit){} );jQuery(document).ready(function(){jQuery(document).trigger('gform_post_render', [9, 1]) } );

 

 

The post My WebRTC Device Cheat Sheet appeared first on BlogGeek.me.

Desktop browsers support in WebRTC – a reality check

Mon, 11/07/2016 - 12:00

Time for a quick reality check when it comes to browsers and WebRTC.

I know you’ve been dying for Apple to support WebRTC in Safari. I am also aware that without WebRTC in your Microsft Internet Explorer 6 that you have deployed in your contact center there is no way for WebRTC to become ubiquitous or widely adopted. But hear me out please.

Browsers market share

The recent update by NetMarketShare on the desktop browsers market share is rather interesting:

It shows the trend between the various desktop browsers for the last year or so.

Here are some things that comes to mind immediately:

  • Google Chrome now has 55% market share. Its rise has stalled somewhat in the last couple of months
  • Microsoft Internet Explorer is still free falling. It will probably stop somewhere at 10% or so if you ask me
  • While Chrome gained the most users from Internet Explorer, it seems that Firefox has picked up users from Internet Explorer in the past two months
  • Microsoft Edge gained very little from the demise of Microsoft Internet Explorer. People who have adopted Windows 10 aren’t adopting Edge and are most probably opting to install and use Chrome or Firefox instead. I’ve mentioned it here in the past

What happens between Microsoft Edge and Apple Safari is even more interesting. Apple Safari is falling behind Microsoft Edge:

Something doesn’t add up here.

The Edge numbers should rise a lot higher, due to the successful upgrades we’ve seen for Windows 10 in the market. And it doesn’t. We already noticed how Chrome and to some extent Firefox enjoyed that switch to Windows 10.

I am not sure how the slip of Apple Safari market share from almost 5% in the beginning of this year to below 4% can be explained. Is it due to the slip in Mac sales in recent months or is it people who prefer using Chrome or Firefox on their Macs?

There’s one caveat here of course – these numbers are all statistics, and statistics do tend to lie. When going to specific countries, there will be a different spread across browsers, and to a similar extent, your service sees a different type of browser spread because your users are different. Here’s the stats from Google Analytics for this blog:

For me, it is titled towards browsers supporting WebRTC, and Safari is way higher than Edge and Internet Explorer put together.

Back to WebRTC

Every once in a while, someone would stand up and ask: “But what about Internet Explorer?” when I talk about WebRTC. It is becoming one of these questions I now expect.

Here’s what you need to think about and address:

  • Chrome is probably your go-to browser and the first one to support with your WebRTC product
  • Firefox comes next, and growing. So keep your tabs on it to see how it “performs” with your product
  • Edge. Useless for most. Add support to it if:
    • You do voice only (should work nicely), and you want that extra market share
    • You know for sure your users are on Edge
  • Internet Explorer. Ignore
    • Microsoft probably won’t invest in having WebRTC support in it, so don’t wait for them
    • Use a plugin or whatever if you must
  • Safari. Ignore for now. Nothing to do about it anyway
What’s next?

I am working on a quick cheat sheet for you. One which will enable you to make fast decisions for browser support. It will extend also into apps and mobile. Probably by next week.

Until then, if you plan on picking up browsers to support, think of your target audience first. Don’t come up with statements like “IE must be supported” or “Without Safari I can’t use this technology”. You are just hurting yourself this way.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

 

The post Desktop browsers support in WebRTC – a reality check appeared first on BlogGeek.me.

Get Ready for Kranky Geek San Francisco AND São Paulo

Mon, 10/31/2016 - 12:00

Kranky Geek is coming to town!

WebRTC is maturing. We’re 5 years into this roller coaster and it seems most companies have already understood that they need to use WebRTC in one way or another. To many, this is going to be an excruciatingly painful journey. They will need to change their business model, think differently about how they develop products and even rewrite their core values.

One of the reasons we decided to launch Kranky Geek over two years ago was to have a place where developers can teach developers about WebRTC. Somewhere that isn’t already “tainted” with the telecom views of the world – not because they are bad – just because WebRTC can accomplish so much more. What we are going to do next with WebRTC takes place in November and will happen in two separate locations:

Kranky Geek San Francisco

San Francisco is where Kranky Geek started and where I feel at home when it comes to this event. We will be doing our 3rd Kranky Geek event in San Francisco (and 4th in total).

It will take place on November 18, at Google’s office on Spear street.

Our focus this time around is going to be mobile. We’ve got sessions lined up that should cover most of the aspects related to WebRTC and mobile. Things like using React, cross platform development, video compression, specific aspects in iOS as well as specific aspects in Android related to WebRTC.

If you are into mobile development with real time communications – then this is an event you don’t want to pass up.

There is also a new attendance fee that was added – $10 that gets donated to Girl Develop It. You may notice we don’t have a woman speaker this time – it is hard to find women speakers in this domain, so if you are one or know one – make sure to let us know for our future events.

I’d like to thank our sponsors who made this thing possible:

  • Google – who brought us WebRTC in the first place and is instrumental to the success that is Kranky Geek
  • TokBox – sponsoring both the San Francisco and São Paulo events. They will share their experiences with mobile aspects of WebRTC related to Android
  • Twilio – sponsoring both the San Francisco and São Paulo events. Their session in San Francisco will cover WebRTC and the Internet of Things
  • Vidyo – a new sponsor that is joining the Kranky Geek family, and probably the best one suited to talk about real time video compression technologies that make sense in mobile devices
Kranky Geek São Paulo

This will be my first time in Brazil and also the first time we run Kranky Geek in Barzil. As with San Francisco, the event is hosted at Google’s office in São Paulo.

Our focus for São Paulo will be back to the basics of WebRTC. We are trying this time to fill in the gaps – share resources and insights that developers who use WebRTC in their daily activities need. This is why we have a few sessions that are targeted at debugging and troubleshooting WebRTC in this event.

Registration for the São Paulo event is free.

For the São Paulo event, we got the help of a few sponsors as well:

  • Google
  • TokBox – at São Paulo, TokBox will share with us how to deal with device and connectivity issues when it comes to WebRTC sessions
  • Twilio – will be looking at the makeup of a WebRTC service, as the browser implementation of WebRTC is the beginning of the journey only
  • WebRTC.ventures – who are sponsoring this event for the first time, will give the overview and introduction to WebRTC
  • Callstats.io – will explain what you can find in getstats() and how to use it
See you there

I have my own session to prepare for the upcoming Kranky Geek, along with a lot of work to make these two events our best yet. There are also changes and modifications that need to make their way to the website –  but rest assured – these events have great content lined up for you.

If you happen to be in the area, my suggestion is come to the event – it is the best place to learn and interact with people who know way better than I do what WebRTC is in and out.

And if you want to meet me – just contact me. I’ll be “in town” for an extra day or so.

See you all at Kranky Geek!

The post Get Ready for Kranky Geek San Francisco AND São Paulo appeared first on BlogGeek.me.

Quiet please – people are studying

Mon, 10/24/2016 - 12:00

No article today.

My course is launching today: Advanced WebRTC Architecture Course.

I’ve got some solid attendance for it, along with a good bulk of high quality material lined up.

Hopefully, this will be a success.

If you are taking the course – then good luck and please share your thoughts with me – I’ve built this course for you and I’d like you to benefit from it as much as possible.

If you aren’t taking it but still want to attend – feel free to enroll. I’ll be closing up course signups end of this week, with no clear indication if and when I’ll be running it next.

Now quiet please – there are people studying in here. Somewhere. Hopefully.

The post Quiet please – people are studying appeared first on BlogGeek.me.

Advanced WebRTC Acrhitecture Course – Updates

Mon, 10/17/2016 - 12:00

WebRTC course starts Monday next week.

At long last, the wait will be coming to an end and my recent sleepless nights as well. I’ve been working these past months to put up the content for the course, not knowing how it will end up.

Most of the materials have been recorded, uploaded and prepared already, waiting for me to just manually add all the people who enrolled. There’s a lot of material in that course, and a lot more that I am sure is still missing in there. Trying to cover WebRTC in its entirety isn’t easy.

Through the process of putting this stuff up and out there, I’ve learned a lot myself.

 

The course is split into 7 sections:

  1. The basics of WebRTC – explanation of what WebRTC is, a review of its APIs and call flows, and general knowledge. This should get you up to speed about what it is and will probably place you among the first 10,000 people in the world who know it at this depth. It will also enable you to read the stuff that is out there about WebRTC more critically
  2. Networking basics – while we all use the Internet, many of us don’t know the distinction between TCP and UDP, or what Websockets really is. This section tries to put these things in perspective and lay the groundwork for later sections. It will be super useful for VoIP developers but also great for web developers. It also covers the NAT traversal challenge and the solutions found in WebRTC for it
  3. WebRTC signaling – signaling isn’t part of WebRTC, but is often something to contemplate. This section dives into the alternatives of signaling that are available, different types of transport protocols, as well as a lesson on SDP. It also covers the security aspects relevant to WebRTC – and it it sheds some light on FUD (fear, uncertainty and doubt) around WebRTC
  4. Codecs – I love codecs. I know little about them, but somehow, more than most. This section explains voice and video codecs, while focusing on what you need to know about them in the context of WebRTC. You won’t be able to implement a codec after this section (I never implemented a codec), but you will gain the understanding necessary for you to decide the codecs for your own scenarios
  5. Media processing – media processing is at the heart of most decisions you will take in your use case. In this section, I take the time to review how RTP and RTCP work, and then dive into different architectures and processes you might need in your back end. Things like mixing, routing and recording
  6. 3rd party frameworks and services – here we will be diverting from the beaten path of “normal course material”, and instead of talking about specifications, standards and capabilities, we will look into the various products and open source frameworks that are out there. We will review them and see which one fits what use case, and also gain an understanding of the various routes available to us, trying to match our company’s DNA and requirements to the alternatives at hand
  7. Common WebRTC design patterns – this is where we will take specific scenarios and challenges, from a list of those I see every day when people reach out to me, and analyze them. Go over the scenario, break it down to requirements and then map them into architectural alternatives. The idea here is to give you the tools to do such things on your own with your products

Most of the lessons are already ready. There are around 6 lessons that I still need to write. Hopefully, they will be available on launch day, but if not, then the following week.

 

I want to answer a few quick questions here – things I’ve been asked time and again in the past month:

Is this a one-time thing?

Yes and no.

The course takes place October 24 and lasts for 2 months. Those who enroll for office hours get an extended duration of 4 months (as well as office hours).

I don’t plan on doing this an ongoing thing where you can enroll whenever and do the course. I will be taking the time throughout these two months to listen to the students and see if there’s anything that requires updating in “real time”. I can’t do it if this is an ongoing thing.

This might change in the future, but for now, there’s this timing.

I might do that some months from now, after I rest a bit from the effort and decide if it makes financial sense to run it again.

If you have your own timing issues, then understand that the course is self-paced. You can “leave” for a week or two and come back, do it faster or slower.

Is the course for me?

I can’t really say.

Here are a few types of students that I have already enrolled for the course:

  • Developers who need to start using WebRTC, more often than not through a framework that was already selected. They know how it works, but are looking to gain deeper understanding so they can troubleshoot issues or add features to their product
  • Product managers who want to learn and understand more about WebRTC. Mostly to give them the language necessary to talk with their developers. And mainly to keep the developers honest
  • Teams who work with WebRTC, so they can get the experience together as a team and improve their proficiency
  • Testers wanting to understand the technology better and find effective ways to design their test plans

The course doesn’t include too much code. There’s the occasional piece of code shown, but the idea isn’t to explain to you how to develop with WebRTC. In truth – most of you won’t develop with WebRTC directly anyway – you’ll end up using a framework or a third party for that.

The intent is to give you the understanding of the limits and capabilities of WebRTC. To know how to yield this amazing tool and how to use it effectively in your product.

How is the course conducted?

If you enrolled, then you will be receiving an email a day or two prior to the course.

I will be registering you to the course mini-site inside the BlogGeek.me website. Once you login, you will be able to access all course sections and lessons.

Each lesson has a page of its own in the site. Most lessons have a recorded video session as the main bulk of it, along with text and additional reading material. In most cases, that additional reading material is important.

You can “tune in” to any lesson you wish and learn it at your own pace and in your free time.

There is an online forum for the course. Students will be able to raise their questions, issues and feedback there. If things require changes on my end, I’ll try making the changes to the lessons as we move along, maybe even adding course materials and lessons if the need will arise. I will also be using the forum to ask questions myself, and check out on the progress of students.

For those taking office hours, these will take place twice a week at different times to accommodate different time zones. In there, I will answer questions as they come and basically make myself available to you “in the flesh”. I haven’t decided yet which WebRTC service to use for that – suggestions are welcome.

I am still debating if I should use quizes as part of the course, placing them at the end of each section or not. If you have an opinion – please voice it (even if you’re not going to attend the course).

 

Enroll today

Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.

 

The course starts next week.

There’s a Q&A page that may answer additional questions you might have.

Official course syllabus is also available in PDF form.

I’d be happy to meet you if you decide to enroll to the course. This is a new thing for me and I an quite excited about it.

If you are not sure about the course – email me. If there’s no fit – I’ll tell you immediately. If this might help you, I’ll explain to you what you will gain from it so you can make a better decision

Until next Monday – have an awesome week.

The post Advanced WebRTC Acrhitecture Course – Updates appeared first on BlogGeek.me.

Dailymotion, Peer5 and the Future of Streaming

Mon, 10/10/2016 - 12:00

The future of streaming includes WebRTC.

Disclaimer: I am an advisor for Peer5.

If you look at reports from Ericsson or Cisco what you’ll notice is the growth of video as a large portion of what we do over the Internet. As video takes up an order of magnitude more data to pass than almost anything else we share today this is no wonder. Here are a few numbers from Cisco’s forecast from Feb 2016:

  • Mobile video traffic accounted for 55 percent of total mobile data traffic in 2015. Mobile video traffic now accounts for more than half of all mobile data traffic
  • Three-fourths of the world’s mobile data traffic will be video by 2020. Mobile video will increase 11-fold between 2015 and 2020, accounting for 75 percent of total mobile data traffic by the end of the forecast period

Source: Cisco

I think there are a few reasons for this growth:

  1. While we’re continuously moving towards HD video resolutions, 4K is already being experimented with. The increase in resolution and frame rates is inevitable. We’ve seen this growth with the displays of our devices and with the cameras we hold in our pockets. Time to see it in the videos we play back
  2. The hegemony of content creators is broken. User generated content is growing rapidly. It started with YouTube, moving to services such as Vine and now live streaming services such as Periscope, Facebook Live, YouNow and others. More creators = more video sources
  3. Viewing habits are changing. We are no longer interested in TV series broadcasted on air but rather pick and choose what we want to watch and when we want to watch, from an exponentially larger pool and variety of content

The challenge really begins when you look at the Internet technologies available to stream these massive amounts of content:

  • Flash / RTMP. This is how we streamed video over our internet for years, and that period is coming to an end. Google announced limiting its support to Flash by requiring users to opt in on sites that make use of it. This is causing large content sites to scurry towards HTML5 based streaming technologies
  • HLS. HTTP Live Streaming – Apple’s mechanism used on iOS devices. And one that is enforced if you wish to stream to iOS devices. To some extent, this makes it “necessary” to support it elsewhere – so there’s also an HLS player for browsers
  • MPEG-DASH – the standardized cousin of HLS
  • Something else, not necessarily intended for video streaming

The challenge with HLS and MPEG-DASH is latency. While this might be suitable for many use cases, there are those who require low latency live streaming:

From my course on WebRTC architecture

For those who can use HLS and MPEG-DASH, there’s this nagging issue of needing to use CDNs and pay for expensive bandwidth costs (when you stream that amount of video, everything becomes expensive).

Which brings me to the recent deal between Peer5 and Dailymotion. To bring you up to speed:

  • Dailymotion is huge
    • Similarweb ranks them #4 in their category, after YouTube, Netflix and niconico
    • Their site states they have 300 million unique monthly visitors and they stream 3.5 billion videos a month
  • Peer5 is a startup dealing with peer assisted delivery
    • They offload video traffic and reduce strain on servers and CDNs by sending video data across peers
    • They do this by using WebRTC’s data channel
  • Some of the traffic of Dailymotion now flows via Peer5’s technology, and that’s now official

There are other startups with similar technologies to Peer5, but this is the first time any of them has publicized a customer win, and with such a high profile to top it off.

In a way, this validates the technology as well as the need for new mechanisms to assist in our current state of video streaming – especially in large scales.

WebRTC seem to fit nicely in here, and in more than one way only. I am seeing more cases where companies use WebRTC either as a complementary technology or even as the main broadcast technology they use for their service.

It is also the reason I’ve added this important topic to my upcoming course – Advanced WebRTC Architecture. There is a lesson dedicated to low latency live broadcasting, where I explain the various technologies and how WebRTC can be brought into the mix in several different combinations.

If you would like to learn more about WebRTC and see how to best fit it into your scenario – this course is definitely for you. It starts October 24, so enroll now.

Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.

 

The post Dailymotion, Peer5 and the Future of Streaming appeared first on BlogGeek.me.

What’s Your Preferred Language for WebRTC Development?

Mon, 10/03/2016 - 12:00

WebRTC isn’t limited to JavaScript.

This is something I don’t get asked directly, but it does pop up from time to time. Especially when people come up with a specific language in mind and ask if it is suitable for WebRTC.

While the answer is almost always yes, I think a quick explanation of where programming languages meet WebRTC exactly is in order.

We will start with a small “diagram”, to show where we can find WebRTC related entities and move from there.

We’ve got both client and server entities with WebRTC, and I think the above depicts the main ones. There are more as your service gets more complicated, but that’s all an issue of scaling and pure development not directly related to WebRTC.

 

Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.

 

So what do we have here?

Web app

The web app is what most people think about when they think WebRTC.

This is what ends up running in the browser, loaded from an HTML and its derivatives.

What this means is that the language you end up with is Java Script.

Mobile app

When it comes to the mobile domain, there are two ways to end up with WebRTC. The first is by having the web app served inside a mobile browser, which brings you back to Java Script.

The more common approach though is to use WebRTC inside an app. You end up compiling and linking the WebRTC codebase as an SDK.

The languages here?

  • C, C++ for the low level stuff that makes up WebRTC. In all likelihood, you won’t need to handle this (either because it will just work or because you’ll be outsourcing it to someone else)
  • Java for native Android app development
  • Objective-C and/or Switft for native iOS app development

There’s also the alternative of C# via Xamarin or Java Script again if you use something like Crosswalk. With these approaches, someone should already have WebRTC wrapped for you in these platforms.

Embedded app

Embedded is where things get interesting.

There are cases where you want devices to run WebRTC for one reason or another.

Two main approaches here will dictate the languages of choice:

  1. C, C++ if you port the webrtc.org code base and use it. And then whatever else you fancy on top of it
  2. Any language you wish (Java anyone?), while implementing what you need of the WebRTC protocol (=what goes on the network) on your own

In general, here you’ll be going to lower levels of abstraction, getting as close as possible to the machine language (but stopping at C most probably).

TURN server

STUN and TURN servers are also necessary. Most likely – you won’t be needing to do a thing about them besides compiling, configuring and running them.

So no programming languages here.

I would note that the popular open source alternatives are all written in C. Again – this doesn’t matter.

Media server

Media servers come in different shapes and sizes. I’ve covered them here recently, discussing Jitsi/Kurento and later Kurento/Janus.

The programming languages here depend on the media server itself. Jitsi and Kurento are Java based. Janus is mostly C. In most cases – you wouldn’t care.

Media servers are usually entities that you communicate with via REST or Websocket, so you can just use whatever language you like on the controlling side. It is a very popular choice to juse Node.js (=Java Script) in front of a Kurento server for example. It also brings us to the last entity.

App/Signaling server

The funny thing is that this is where the question is mostly targeted at. The application and/or signaling server is what stitches everything together. It serves the web app, communicates with the mobile and embedded apps. It offers the details of the TURN server and handles any ephemeral passwords with it, it controls the media servers.

And it is also where the bulk of the development happens since it holds the business logic of the application.

And here the answer is rather simple – use whatever you want.

  • Node.js and Java Script are great and popular choice (there are good reasons for that)
  • Java seems to be a thing in enterprises though for the life of me I just can’t understand why
  • PHP works well. It is used by many WordPress plugins for WebRTC
  • Erlang seems to be something that adventurous developers like to adopt – and like
  • Ruby and Python are also good choices
  • .Net is something I’ve seen once or twice used

In general, whatever you can use to build websites can be used to build a WebRTC service.

What’s your language?

Back to you. What is the programming languages you use with WebRTC?

If you are looking for developers, then what would be the languages you’d view as mandatory and which ones as preferable with applicants?

This as well as other topics are covered in my upcoming Advanced WebRTC Architecture course. Be sure to enroll if you wish to deepen your understanding in this topic.

The post What’s Your Preferred Language for WebRTC Development? appeared first on BlogGeek.me.

Advanced WebRTC Architecture Course: Adding a Premium Package

Fri, 09/30/2016 - 12:00

So far so good, but it is time to add some more options for you.

A selection of three different course packages

I am working to complete all lessons for the course. It takes time to work things through, go over the lessons, make sure everything is in order and record the sessions.

The interesting thing to me is the variety of people that enroll to this course – they come from all over the globe, varying from small startups to large companies. I found some interesting vendors who are looking at WebRTC that I wasn’t aware of.

A few updates about the course

There are a few minor updates that are taking place in the course:

  • I will most probably add a forum to go along with the course. The forum is opened for all packages, and it will be a place where discussions and questions can take place between the students
  • The FAQ page was updated, based on questions I received in the past several weeks – check it out
  • The enrollment page now shows a pricing table, in an effort to make things clearer
  • There are now 3 packages:
    1. Basic – access to the course for 2 months + forum
    2. Plus – access to the course for 4 months + forum + office hours
    3. Premium – a new package – see below for information
  • For those who wish to enroll by wire transfer instead of PayPal – just contact me through my contact form
Course length

The course duration is 8 weeks, give or take a few days.

That said, if you want access to the recorded materials for a longer period, then you might want to consider going for the Plus or Premium packages.

The Plus package extends access to the course materials, including the forum and the office hours by an additional 2 months.

Office hours happen twice a week, at two different times to accommodate multiple time zones. During office hours I will be reviewing with the students their learning and understanding of WebRTC and assist in person in areas that will arise. I might even decide to hold a quick online lesson on relevant or timely topics during the office hours.

The Premium package extends access to the curse materials up to a full year. More about the premium package below.

Groups

If you want to enroll multiple employees or just come join as a team, they just contact me directly.

For large enough groups, I can offer discounts. For others, just the service of proforma invoice and wire transfer (which can still be better than PayPal for you).

We will be having 3-4 medium sized groups in our course this time, which will make things interesting – especially during office hours.

The Premium Package

I decided to add a premium package to the offering.

The idea behind it is to allow those who want more access to my time, and in a more private way.

The premium package offers two substantial additions on top of the Plus package:

  1. Access to course materials for a full year (instead of 2 or 4 months)
  2. Two private consultation calls with me

In the past few months I’ve noticed a lot of small companies who end up wanting an advice. A few hours of my time to explain to me what they are doing and chat about it, to see if there’s anything I can suggest. I decided to offer this service through this course as well, by bundling it as two consultation calls that go on top of the course itself.

We select together the agenda of these calls and what you want to achieve in them before we start. We then schedule the time and medium to use for the call (think something with WebRTC and a webcam, but not necessarily). And then we sit and chat.

If you already enrolled

If you already enrolled via PayPal and haven’t heard anything from me other than an order form and an invoice – don’t worry. I will be reaching out to all students a week or two before the course.

I am excited to do this, and really hope you are too.

 

See you next month!

 

Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.

 

The post Advanced WebRTC Architecture Course: Adding a Premium Package appeared first on BlogGeek.me.

Recording WebRTC Sessions: client side or server side?

Mon, 09/26/2016 - 12:00

Recording WebRTC? Definitely server side. But maybe client side.

This article is again taken partially from one of the lessons in my upcoming WebRTC Architecture Course. There, it is given in greater detail, and i recorded.

Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.

 

Recording is obviously not part of what WebRTC does. WebRTC offers the means to send media, but little more (which is just as it should be). If you want to record, you’ll need to take matters into your own hands.

Generally speaking, there are 3 different mechanisms that can be used to record:

  1. Server side recording
  2. Client side recording
  3. Media forwarding

Let’s review them all and see where that leads us.

#1 – Server side recording

This is the technique I usually suggest developers to use. Somehow, it fits best in most cases (though not always).

What we do in server-side recording is route our media via a media server instead of directly between the browsrs. This isn’t TURN relay – a TURN relay doesn’t get to “see” what’s inside the packets as they are encrypted end-to-end. What we do is terminate the WebRTC session at the server on both sides of the call – route the media via the server and at the same time send the decoded media to post processing and recording.

What do I mean by post processing?

  • We might want to mix the inputs from all participants and combine it all to a single media file
  • We might want to lower the filesize that we end up storing
  • Change format (and maybe the codecs?), to prepare it for playback in other types of devices and mediums

There are many things that factor in to a recording decision besides just saying “I want to record WebRTC”.

If I had to put pros vs cons for server side media recording in WebRTC, I’d probably get to this kind of a table:

+–No change in client-side requirementsAnother server in the infrastructureNo assumptions on client-side capabilities or behaviorLots of bandwidth (and processing)Can fit resulting recording to whatever medium and quality level necessaryNow we must route media#2- Client side recording

In many cases, developers will shy away from server-side recording, trying to solve the world’s problem on the client-side. I guess it is partially because many WebRTC developers tend to be Java Script coders and not full stack developers who know how to run complex backends. After all, putting up a media server comes with its own set of headaches and costs.

So the basics of client-side recording leans towards the following basic flow:

We first record stuff locally – WebRTC allows that.

And then we upload what we recorded to the server. Here’ we don’t really use WebRTC – just pure file upload.

Great on paper, somewhat less in reality. Why? There are a few interesting challenges when you record locally on machine you don’t know or control, via a browser:

  • Do you even know how much available storage do you have to use for the recording? Will it be enough for that full hour session you planned to do for your e-learning service?
  • And now that the session is done and you’re uploading a Gb of a file. Is the user just going to sit there and wait without closing his browser or the tab that is uploading the recording?
  • Where and what do you record? If both sides record, then how do you synchronize the recordings?

It all leads to the fact that at the end of the day, client side recording isn’t something you can use. Unless the recording is short (a few minutes) or you have complete control over the browser environment (and even then I would probably not recommend it).

There are things you can do to mitigate some of these issues too. Like upload fragments of the recording every few seconds or minutes throughout the session, or even do it in parallel to the session continuously. But somehow, they tend not to work that well and are quite sensitive.

Want the pros and cons of client side recording? Here you go:

+–No need to add a media server to the media flowClient side logic is complex and quite dependent on the use caseRequires more on the uplink of the user – or more wait time at the end of the sessionNeed to know client’s device and behavior in advance#3 – Media forwarding

This is a lesser known technique – or at least something I haven’re really seen in the wild. It is here, because the alternative is possible to use.

The idea behind this one is that you don’t get to record locally, but you don’t get to route media via a server either.

What is done here, is that media is forwarded by one or both of participants to a recording server.

The latest releases of Chrome allows to forward incoming peer connection media, making this possible.

This is what I can say further about this specific alternative:

+–No need to add a media server into the flow – just as an additional external recording serverRequires twice the uplink or moreDo you want to be the first to try this technique?Things to remember

Recording doesn’t end with how you record media.

There’s meta data to treat (record, playback, sync, etc).

And then there’s the playback part – where, how, when, etc.

There are also security issues to deal with and think about – both on the recording end and on the playback side.

These are covered in a bit more detail in the course.

What’s next?

If you are going to record, start by leaning towards server side recording.

Sit down and list all of your requirements for recording, archiving and playback – they are interconnected. Then start finding the solution that will fit your needs.

And if you feel that you still have gaps there, then why not enroll to the Advanced WebRTC Architecture course?

 

Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.

The post Recording WebRTC Sessions: client side or server side? appeared first on BlogGeek.me.

Twilio’s Voice Insights for WebRTC – a line on the sand

Fri, 09/23/2016 - 12:00

Analytics != Operation

Twilio just announced a new service to its growing cadre of services. This time – Voice Insights.

What to expect in the coming days

This week Twilio announced several interesting initiatives:

  1. Country specific guidelines on using SMS
  2. A new Voice Insights service
  3. The Kurento acquisition

Add to that their recent announcement on their new Enterprise offering and the way they seem to be adding more number choices in countries. What we get is too much work to cover a single vendor in this industry.

Twilio is enhancing its services in breadth and depth at the same time, doing so while trying to reach out to new customer types. I will be covering all of these issues soon enough. Some of it here, some on other blogs where I write. Customers with an active subscription for my WebRTC PaaS report will receive a longform written analysis separately covering all these aspects later this month.

What I want to cover in this article

I already wrote about Twilio’s Kurento acquisition. This time, I want to focus on Voice Insights.

All the media outlets I’ve checked to read about Voice Insights were regurgitating the Twilio announcement with little to add. At most, they had callstats.io to refer to. I think a lot is missing from the current conversation. So lets dig in.

What is Voice Insights?

Voice Insights is a set of tools that can be used to understand what’s going on under the rug. When you use a communications API platform – or build your own for that matter – the first thing to notice is that there’s lack of understanding of what’s really happening.

Most dashboards focus on giving you the basics – what sessions you created, how long were they, how much money you owe us. Others add some indication of quality metrics.

The tools under the Voice Insights title at Twilio include:

  1. Collection of all network stats, so you can check them out in the Twilio console
  2. Real time triggers on the client, telling you when network issues arise or the volume is too low/high
  3. Pre-call network test on the client
  4. User feedback collection (the Skype “how was your call quality” nag)

Some of them were already available in some form or another in the Twilio offering – such as user feedback collection.

The features here can be split into two types:

  1. Client side – the real time triggers, pre-call network test
  2. Server side – collection of network stats

Twilio gave a good introduction to all of thee capabilities, so I won’t be repeating them here.

What is interesting, is if and how they have decided to implement the real time triggers – do they get triggered from the backend or directly by running rules on the device. But I digress here.

How is it priced?

Interestingly, Voice Insights is priced separately from the calling service itself.

If you want insights into the voice minutes you use on Twilio, there’s an extra charge associated with it.

Prices start from $0.004 per minute, going down to ~$0.002 per minute for those who can commit to 1 million voice minutes a month. It goes down to a shy above $0.001 a minute.

For comparison, SIP-to-SIP voice calling on Twilio starts at $0.005 per minute, making Voice Insights a rather expensive service.

Comparisons with callstats.io are necessary at this point. If you take a low tier of 10,000 voice minutes a month, callstats.io is priced at 19 EUR (based on their calculator – it can get higher or lower based on “data points”) whereas Twilio Voice Insights stands at 40 USD. How do these two vendors offer lower rates at bulk is an exercise I’ll leave for others to make.

Is this high? low? market price? I have no clue.

TokBox, on the other hand, has their own tool called Inspector and another feature called Pre-Call Test. And it is given for free as part of the service.

Where is it headed?

Voice Insights can take several directions with Twilio:

  • Extend it to support video sessions as well
  • Enhance and deepen the analytics capabilities, probably once enought  feedback is received from customers on this feature
  • Switch from a paid to free offering, again, based on customer feedback
  • Unbundle it from Twilio and offer it as a stand-alone service to others – maybe to all the vendors that are using Kurento on premise?

With analytics, the sky usually isn’t the limit. It is just the beginning of the dreams and stories you can build upon a large data set. The problem is how can you take these dreams and make them come true.

Which brings us to the next issue.

The future of Analytics in Comm APIs

There’s a line drawn in the sand here. Between communications and analytics.

Analytics has a perceived value of its own – on top of enabling the interaction itself.

Will this hold water? Will other communication API vendors add such capabilities? Will they be charging extra for them?

I’ve had my share of stories around CEM (Customer Experience Management). Network equipment vendors and those handling video streaming are marketing it to their customers. Analytics on network data. This isn’t much different.

Time will tell if this is something that will become common place and desired, or just a failed attempt. I still don’t have an opinion where this will go.

Up next

Next in my quick series of articles on Twilio comes coverage of their new Enterprise plan, and how Twilio is trying to grow in breadth and depth at the same time.

 

Test and Monitor your WebRTC Service like a pro - check out how testRTC can improve your service' stability and performance.

The post Twilio’s Voice Insights for WebRTC – a line on the sand appeared first on BlogGeek.me.

Discount on the Advanced WebRTC Architecture Course ends tomorrow

Thu, 09/22/2016 - 12:00

If you haven’t yet enrolled to my Advanced WebRTC Architecture course – then why wait?

I just noticed that I haven’t written any specific post here about the upcoming course, so consider this one that announcement. To my defense – I sent it out a few days ago to the monthly newsletter I have.

Why a course on WebRTC architecture?

I’ve been working with entrepreneurs, developers, product managers and people in general about their WebRTC products for quite some time. But somehow I missed to notice that in many such discussions there were large gaps in what people thought about WebRTC and what WebRTC really is.

There’s lots of beginner’s information out there for WebRTC, but somehow it always focuses on how to use the WebRTC APIs in the browser, or what the meaning of a specific feature in the standard is. There is also a large set of walk-throughs of different frameworks that you can use, but no one seems to offer a path for a developer to decide on his architecture. To answer the question of “what should I be choosing for my service?

So I set out to put a course that answers that specific question. It gives the basics of what WebRTC is, and then dives into the part of what it means to put an architecture in place:

  • How to analyze the real requirements of your scenarios?
  • What are the various components you will need?
  • Go through common design patterns that crop up in popular service archetypes
What’s in the course?

The easiest way is to go through the course syllabus. It is available online here and also in PDF form.

When will the course take place?

The course is all conducted online, but not live.

It starts on October 24, and I am now in final preparation of recording the materials after creating them in the past two months.

The course is designed to be:

  • Built out of 7 modules
  • Have 40 lessons give or take, each on average should take you 30 minutes
  • This means if you take a lesson on every working day, you should complete this in 2 months
  • You can do it at a faster pace if you wish
  • Course materials are available online for students for a period of 2 months. This can be extended to 4 months for those who wish to add Office Hours on top of the course
Any discount for friends and family?

Enrolling to the course is $247 USD. Adding Office Hours on top of it means an additional $150 USD.

Until tomorrow, there’s a $50 USD discount – so enroll now if you’re already certain you want to.

There are discounts for those who want to enroll as a larger group – contact me for that.

Have more questions?

Check the FAQ. I’ll be updating it as more questions come it.

If you can’t find what you need there – just contact me.

The post Discount on the Advanced WebRTC Architecture Course ends tomorrow appeared first on BlogGeek.me.

Twilio Acquires Kurento. Who will Acquire Janus?

Wed, 09/21/2016 - 12:00

Open source media frameworks in WebRTC are all the rage these days.

Jitsi got acquired by Atlassian early last year and now Twilio grabs Kurento.

What to expect in the coming days

Yesterday Twilio announced several interesting initiatives:

  1. Country specific guidelines on using SMS
  2. A new Voice Insights service
  3. The Kurento acquisition

Add to that their recent announcement on their new Enterprise offering and the way they seem to be adding more number choices in countries. What we get is too much work to cover a single vendor in this industry.

Twilio is enhancing its services in breadth and depth at the same time, doing so while trying to reach out to new customer types. I will be covering all of these issues soon enough. Some of it here, some on other blogs where I write. Customers with an active subscription for my WebRTC PaaS report will receive a longform written analysis separately covering all these aspects later this month.

What I want to cover in this article

What I want to cover in this part of my analysis of the recent Twilio announcements is their acquisition of Kurento.

Things I’ll be touching is Why Kurento – how will it further Twilio’s goal – and also what will happen to the many users of Kurento.

I’ll also touch the open source media server space, and the fact that the next runner up in the acquisition roulette of our industry should be Janus.

But first things first.

What is Kurento?

Kurento is an open source WebRTC server-side media framework implemented on top of GStreamer. While it may not be limited to WebRTC, my guess is that most if not all of its users make use of WebRTC with it.

What does that mean exactly?

  • Open source – anyone can download and use Kurento. And many do
    • There’s a vibrant community around it of developers that use it independently, Outsourcing development shops that use it in their projects to customers and the Kurento team itself offering free and paid support to it
    • It is distributed under the Apache license which is quite lenient and enterprise-friendly
  • server-side media framework – when you want to process media in WebRTC for recording, multiparty or other processes, a server-side media framework is necessary
  • GStreamer – another popular open source project for media processing. Just another tidbit you may want to remember

I am seeing Kurento everywhere I go. Every couple of meetings I have with companies, they indicate that they make use of Kurento or when you look at their service it is apparent it uses Kurento. Somehow, it has become one of these universal packages that developers turn to when they need stuff done.

The Kurento team is running multiple activities/businesses (I might be doing a few mistakes here – it is always hard to follow such internal structures):

  1. Kurento, the open source project itself
    • Assisted by research done at theUniversidad Rey Juan Carlos located in Madrid, Spain
    • Funding raised through the European Commission
    • Money received by selling support and customization services
  2. NUBOMEDIA
    • A new initiative focused on scaling and an open source PaaS offering on top of Kurento
    • You can read more about it in a guest post by Luis Lopez (the face of Kurento)
  3. elasticRTC
    • Another new initiative, but a commercial one
    • Focused at getting scalable Kurento running on AWS
  4. Naevatec / Tikal Technologies SL
    • The business side of the Kurento project, where customization and support is done for a price

Kurento have a busy team…

What did Twilio acquire exactly?

This is where things get complicated. From my understanding, reading the materials online and through a briefing held with Twilio, this is what you can expect:

  • Kurento as an open source project is left open source, untouched and un-acquired. That said, the bulk of the team maintaining Kurento (the Naevatec developers) will be moving to be Twilio employees
  • Naevtec was not acquired and will live on. A new team will need to be hired and trained. During the transition period, the Twilio team will work on the Kurento project fulfilling any existing obligations. After that, Naevatec will supposedly have the internal manpower to take charge of that part of the business
  • elasticRTC was acquired. They will not be onboarding any new customers, but will continue supporting existing customers
    • This sounds like the story of AddLive and Snapchat (they waited for support contracts to expire and worked diligently but legally to get customers off the AddLive service)
    • That said, it seems like Twilio wants to leverage these early adopters of elasticRTC to design and build their own Twilio API offering around that domain (more on that later)
    • As I don’t believe there are many customers to elasticRTC, I don’t see this as a real blow to anyone
  • NUBOMEDIA was not mentioned in any of the announcements of the acquisition
    • I forgot to prod about it in my briefing…
    • Twilio are probably unhappy about this one, but had nothing to do about it
    • NUBOMEDIA is funded by multiple European projects, so was either impossible to acquire or too expensive for what Twilio had an appetite for
    • It might also had more partners to it than just the Kurento team(s)
    • How will the acquisition affect NUBOMEDIA’s project and the zeal with which Twilio’s new employees from Naevatec will have for it is an open question

To sum things up:

Twilio acqui-hired the team behind the Kurento project and took their elasticRTC offering out of the market before it became too popular.

How will Twilio use Kurento?

I’d like to split this one to short term and long term

Short term – multiparty calling

Twilio needed an SFU. Desperately.

In April 2015 the Twilio Video initiative was announced. Almost 18 months later and that service is still in beta. It is also still 1:1 calling or mesh for multiparty.

Something had to be done. While I am sure Twilio has been working for quite some time on a solid multiparty option, they probably had a few roadblocks, which got them to start using Kurento – or decide they need to buy that technology instead of build it internally.

Which got them to the point of the acquisition. Twilio will probably embed Kurento into their Twilio Video offer, adding three new capabilities to their platform with it:

  1. Multiparty calling, in an SFU model, and maybe an MCU one
  2. Video recording capability – a popular Kurento use case
  3. PSTN connectivity for video calling – Kurento has a SIP-Gateway component that can be used for that purpose
Long term – generic media server

In the long term, Twilio can employ the full power of Kurento and offer it in the cloud with a flexible API that pipelines media in real time.

This can be used in our new brave world of AI, Bots, IOT and AR – all them acronyms people love talking about.

It will be interesting to see how Twilio ends up implementing it and what kind of an API and an offering they will put in place, as there are many challenges here:

  • How do you do something so generic but still maintain low resource consumption?
  • How do you price it in an attractive way?
  • How do you decide which use cases to cover and which to ignore?
  • How do you design it for scale, especially if you are as big as Twilio?
  • How do you design simple yet flexible and powerful API for something so generic in nature?

This is one of the most interesting projects in our industry at the moment, and if Twilio is working towards that goal, then I envy their product managers and developers.

What will be left of the Kurento project?

That’s the big unknown. Luis Lopez, project lead of Kurento details the official stance of Kurento and Twilio on the Kurento blog. It is an expected positive looking write up, but it leaves the hard questions unanswered.

Maintaining the Kurento project

Twilio is known for their openness and the way they work with developers. While that is true, the Twilio github has little in the way of projects that aren’t samples written on top of the Twilio platform or open sourced projects that touch the core of Twilio. While that is understandable and expected, the question is how will Twilio treat the Kurento open source project?

Now that most of the workforce that is leading Kurento are becoming Twilio employees, will they work on the open source Kurento build or on internal needs and builds of Twilio? Here are a few hard questions that have no real answers to them:

  • What will be contributed back to the Kurento project besides stability and bug fixes?
  • If Twilio work on optimizing Kurento to higher capacities or add horizontal scalability modules to Kurento. Will that be open sourced or left inside Twilio?
  • How will Twilio prioritize bugs and requests coming from the large Kurento community versus handling their own internal roadmap?

While in many cases, with Kurento the answer would have been that Naevatec could just as well limit the access to higher level modules for paid customers – there was someone you could talk to when you wanted to purchase such modules. Now with Twilio, that route is over. Twilio are not in the business of paid support and customization of open source projects – they are in the business of cloud APIs.

There will be ongoing friction inside Twilio with the decision between investing in the open source Kurento platform versus using it internally. If you thought that was bad with Atlassian acquiring Jitsi – it is doubly so here, where Twilio may have to compete with a build vs buy decisions of companies where “build” is done on top of Kurento.

I assume Twilio doesn’t have the answers to these questions yet either.

Maintaining the business model

Kurento has customers. Not only users and developers.

These customers pay Naevatec. They pay for support hours or for customization work.

Will this be allowed moving forward?

Can the yet-to-be-hired new team at Naevatec handle the support?

What happens when someone wants to pay a large sum of money to Naevatec in order to deploy a scalable Kurento service in the cloud? Will Naevatec pick that project? If said customer also wants to build an API platform on top of it, will that be something Naeva Tec will still do?

What will others who see themselves as Twilio competitors do if they made use of Kurento up until now? Especially if they were a Naevatec paying customer…

The good thing is, that many of the Kurento users ended up getting paid support and customization by third party vendors. Now if you only could know which one of them does a decent job…

Should TokBox be worried?

Yes and no.

Yes, because it means Twilio will be getting their multiparty story, and by that competing with TokBox. Twilio has a wider set of features as well, making them more attractive in some cases.

No, because there’s room for more players, and for video calling services at the moment, TokBox is the go-to vendor. I wonder if they can maintain their lead.

What about Janus?

I recently compared Jitsi to Kurento.

Little did I know then that Twilio decided on Kurento and was in the process of acquiring it.

I also raised the question about Janus.

To some extent, Janus is next-in-line:

  • Those I know who use the project are happy with it and its architecture. A lot more than other smaller open source media framework projects
  • Slack has been using Janus for awhile now
  • Other vendors, some got acquired recently, also make use of it

Does Meetecho, the company behind Janus, willing to sell it isn’t important. It is a matter of price points.

We’ve seen the larger vendors veer towards acquiring the technology that they are using.

Will Slack go after Janus? Maybe Vonage/Nexmo? Oracle, to beef their own WebRTC offering?

Open source media frameworks have proven to be extremely effective in churning out commercial services on top of them. WebRTC made that happen by being its own open source initiative.

It is good to see Kurento finding a new home and growing up. Kudos to the Kurento team.

 

Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.

 

The post Twilio Acquires Kurento. Who will Acquire Janus? appeared first on BlogGeek.me.

How Media and Signaling flows look like in WebRTC?

Mon, 09/19/2016 - 12:00

I hope this will clear up some of the confusion around WebRTC media flows.

I guess this is one of the main reasons why I started with my new project of an Advanced WebRTC Architecture Course. In too many conversations I’ve had recently it seemed like people didn’t know exactly what happens with that WebRTC magic – what bits go where. While you can probably find that out by reading the specifications and the explanations around the WebRTC APIs or how ICE works, they all fail to consider the real use cases – the ones requiring media engines to be deployed.

So here we go.

In this article, I’ll be showing some of these flows. I made them part of the course – a whole lesson. If you are interested in learning more – then make sure to enroll to the course.

#1 – Basic P2P Call Direct WebRTC P2P call

We will start off with the basics and build on that as we move along.

Our entities will be colored in red. Signaling flows in green and media flows in blue.

What you see above is the classic explanation of WebRTC. Our entities:

  1. Two browsers, connected to an application server
  2. The application server is a simple web server that is used to “connect” both browsers. It can be something like the Facebook website, an ecommerce site, your heatlhcare provider or my own site with its monthly virtual coffee sessions
  3. Our STUN and TURN server (yes. You don’t need two separate servers. They almost always come as a single server/process). And we’re not using it in this case, but we will in the next scenarios

What we have here is the classic VoIP (or WebRTC?) triangle. Signaling flows vertically towards the server but media flows directly across the browsers.

BTW – there’s some signaling going off from the browsers towards the STUN/TURN server for practically all types of scenarios. This is used to find the public IP address of the browsers at the very least. And almost always, we don’t draw this relationship (until you really need to fix a big, STUN seems obvious and too simple to even mention).

 

Summing this one up: nothing to write home about.

Moving on…

#2 – Basic Relay Call Basic WebRTC relay call

This is probably the main drawing you’ll see when ICE and TURN get explained.

In essence, the browsers couldn’t (or weren’t allowed) to reach each other directly with their media, so a third party needs to facilitate that for them and route the media. This is exactly why we use TURN servers in WebRTC (and other VoIP protocols).

This means that WebRTC isn’t necessarily P2P and P2P can’t be enforced – it is just a best effort thing.

So far so go. But somewhat boring and expected.

Let’s start looking at more interesting scenarios. Ones where we need a media server to handle the media:

#3 – WebRTC Media Server Direct Call, Centralized Signaling WebRTC Media Server Direct Call, Centralized Signaling

Now things start to become interesting.

We’ve added a new entity into the mix – a media server. It can be used to record the calls, manage multiparty scenarios, gateway to other networks, do some other processing on the media – whatever you fancy.

To make things simple, we’ve dropped the relay via TURN. We will get to it in a moment, but for now – bear with me please.

Media

The media now needs to flow through the media server. This may look like the previous drawing, where the media was routed through the TURN server – but it isn’t.

Where the TURN server relays the media without looking at it – and without being able to look at it (it is encrypted end-to-end); the Media Server acts as a termination point for the media and the WebRTC session itself. What we really see here is two separate WebRTC sessions – one from the browser on the left to the media server, and a second one from the media server to the browser on the right. This one is important to understand – since these are two separate WebRTC sessions – you need to think and treat them separately as well.

Another important note to make about media servers is that putting them on a public IP isn’t enough – you will still need a TURN server.

Signaling

On the signaling front, most assume that signaling continues as it always have. In which case, the media server needs to be controlled in some manner, presumably using a backend-to-backend signaling with the application server.

This is a great approach that keeps things simple with a single source of truth in the system, but it doesn’t always happen.

Why? Because we have APIs everywhere. Including in media servers. And these APIs are sometimes used (and even abused) by clients running browsers.

Which leads us to our next scenario:

#4 – WebRTC Media Server Direct Call, Split Signaling WebRTC Media Server Direct Call, Split Signaling

This scenario is what we usually get to when we add a media server into the mix.

Signaling will most often than not be done between the browser and the media server while at the same time we will have signaling between the browser and the application server.

This is easier to develop and start running, but comes with a few drawbacks:

  1. Authorization now needs to take place between multiple different servers written in different technologies
  2. It is harder to get a single source of truth in the system, which means it is harder for the application server to know what is really going on
  3. Doing such work from a browser opens up vulnerabilities and attack vectors on the system – as the code itself is wide open and exposes more of the backend infrastructure

Skip it if you can.

Now lets add back that STUN/TURN server into the mix.

#5 – WebRTC Media Server Call Relay WebRTC Media Server Call Relay

This scenario is actually #3 with one minor difference – the media gets relayed via TURN.

It will happen if the browsers are behind firewalls, or in special cases when this is something that we enforce for our own reasons.

Nothing special about this scenario besides the fact that it may well happen when your intent is to run scenario #3 – hard to tell your users which network to use to access your service.

#6 – WebRTC Media Server Call Partial Relay WebRTC Media Server Call Partial Relay

Just like #5, this is also a derivative of #3 that we need to remember.

The relay may well happen only in one side of the media server – I hope you remember that each side is a WebRTC session on its own.

If you notice, I decided here to have signaling direct to the media server, but could have used the backend to backend signaling.

#7 – WebRTC Media Server and TURN Co-location WebRTC Media Server and TURN Co-location

This scenario shows a different type of a decision making point. The challenge here is to answer the question of where to deploy the STUN/TURN server.

While we can put it as an independent entity that stands on its own, we can co-locate it with the media server itself.

What do we gain by this? Less moving parts. Scales with the media server. Less routing headaches. Flexibility to get media into your infrastructure as close to the user as possible.

What do we lose? Two different functions in one box – at a time when micro services are the latest tech fad. We can’t scale them separately and at times we do want to scale them separately.

Know Your Flows

These are some of the decisions you’ll need to make if you go to deploy your own WebRTC infrastructure; and even if you don’t do that and just end up going for a communication API vendor – it is worthwhile understanding the underlying nature of the service. I’ve seen more than a single startup go work with a communication API vendor only to fail due to specific requirements and architectures that had to be put in place.

One last thing – this is 1 of 40 different lessons in my Advanced WebRTC Architecture Course. If you find this relevant to you – you should join me and enroll to the course. There’s an early bird discount valid until the end of this week.

The post How Media and Signaling flows look like in WebRTC? appeared first on BlogGeek.me.

IMTC: Supporting WebRTC Interoperability

Thu, 09/15/2016 - 12:00

Where is the IMTC focusing it efforts when it comes to WebRTC?

[Bernard Aboba, who is IMTC Director and Principal Architect for Microsoft wanted to clarify a bit what the IMTC is doing in the WebRTC Activity Group. I was happy to give him this floor, clarifying a bit the tweet I shared in an earlier post]

One of the IMTC’s core missions is to enhance interoperability in multimedia communications, with real-time video communications having been a focus of the organization since its inception. With IMTC’s membership including many companies within the video industry, IMTC has over the years dealt with a wide range of video interoperability issues, from simple 1:1 video scenarios to telepresence use cases involving multiple participants, each with multiple cameras and screens.

With WebRTC browsers now adding support for H.264/AVC as well as VP9, and support for advanced video functionality such as simulcast and scalable video coding (SVC) becoming available, the need for WebRTC video protocol and API interoperability testing has grown, particularly in scenarios implemented by video conferencing applications. As a result, the IMTC’s WebRTC Activity Group has been working to further interoperability testing between WebRTC browsers.

In the past, the IMTC has sponsored development of test suites, including a test suite for SIP over IPv6, and most recently a tool for testing interoperability of HEVC/H.265 scalable video coding. For SuperOp 2016, the WebRTC AG took on testing of WebRTC audio and video interoperability. So a logical next step was to work on development of automated WebRTC interoperability tests. Challenges include:

  1. Developing basic audio and video tests that can run on all browsers without rewriting the test code for each new browser to be supported.
  2. Developing tests covering not only basic use cases (e.g. peer-to-peer audio/video), but also advanced use cases requiring a central conferencing server (e.g. conferencing scenarios involving multiple participants, simulcast, scalable video coding, screen sharing, etc.)

For its initial work, IMTC decided to focus on the first problem. To enable interoperability testing of the VP9 and H.264/AVC implementations now available in browsers, the IMTC supported Philipp Hancke (known to the community as “fippo”) in enhancing automated WebRTC interoperability tests, now available at https://github.com/fippo/testbed. Sample code used in the automated tests is available at https://github.com/webrtc/samples.

The interoperability tests depend on adapter.js, a Javascript “shim” library originally developed by the Chrome team to enable tests to be run on Chrome and Firefox. Support for VP9 and H.264/AVC has been rolled into adapter.js 2.0, as well as support for Edge (first added by fippo in October 2015). The testbed also depends on a merged fix (not yet released) in version 2.0.2. The latest adapter.js release as well as ongoing fixes is available at https://github.com/webrtc/adapter.

With the enhancements rolled into adapter.js 2.0, the shim library enables WebRTC developers to ship audio and video applications running across browsers using a single code base. At ClueCon 2016, Anthony Minessale of Freeswitch demonstrated the Verto client written to the WebRTC 1.0 API supporting audio and video interoperability between Chrome, Firefox and Edge.

Got questions or want to learn more about the IMTC and its involvement with WebRTC? Email the IMTC directly.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post IMTC: Supporting WebRTC Interoperability appeared first on BlogGeek.me.

Do you still need TURN if your media server has a public IP address?

Mon, 09/12/2016 - 12:00

Yes you do. Sorry.

This is something I bumped into recently and was quite surprised it wasn’t obvious, which lead me to the conclusion that the WebRTC Architecture course I am launching is… mandatory. This was a company that had their media server on a public IP address, thinking that this should remove their need to run a TURN server. Apparently, the only thing it did was remove their connection rate.

It is high time I write about it here, as over the past year I actually saw 3 different ways in which vendors break their connectivity:

  1. They don’t put a TURN server at all, relying on media servers with public IP addresses
  2. They don’t put a TURN server at all, assuming STUN is enough for a peer to peer based service (!)
  3. They don’t configure the TURN server they use for TCP and TLS connectivity, assuming UDP relay is more than enough

Newsflash: THIS ISN’T ENOUGH

I digress though. I want to explain why the first alternative is broken:

Why a public IP address for your media server isn’t enough

With WebRTC, traffic goes peer to peer. Or at least it should:

But this doesn’t always work because one or both of the browsers are on private networks, so they don’t really have a public address to use – or don’t know it. If one of them has a public IP, then things should be simpler – the other end will direct traffic to that address, and from that “pinhole” that gets created, traffic can flow the other way.

The end result? If you put your media server on a public IP address – you’re set of success.

But the thing is you really aren’t.

There’s this notion of IT and security people that you should only open ports that need to be used. And since all traffic to the internet flows over HTTP(S); and HTTP(S) flows over TCP – you can just block UDP and be done with it.

Now, something that usually gets overlooked is that WebRTC uses UDP for its media traffic. Unless TURN relay over TCP/TLS is configured and necessary. Which sometimes it does. I asked a colleague of mine about the traffic they see, and got something similar to this distribution table:

With up to 20% of the sessions requiring TURN with TCP or TLS – it is no wonder a public IP configured on a media server just isn’t enough.

Oh, and while we’re talking security – I am not certain that in the long run, you really want your media server on the internet with nothing in front of it to handle nasty stuff like DDoS.

What should you do then?
  1. Make sure you have TURN configured in your service
    • But make sure you have TCP and TLS enabled in it and found in your peer connection’s configuration
    • I don’t care if you do that as part of your media server (because it is sophisticated), using a TURN server you cobbled up or through a third party service
  2. Check out my new WebRTC Architecture course
    • It covers other aspects of TURN servers, IP addresses and things imperative for a production deployment
    • The images used in this article come from the materials I’ve newly created for it
  3. Test the configuration you have in place
    • Limit UDP on your test machines, do it on live networks
    • Or just use testRTC – we have in this service simple mechanisms in place to run these specific scenarios

Whatever you do though, don’t rely on a public IP address in your media server to be enough.

The post Do you still need TURN if your media server has a public IP address? appeared first on BlogGeek.me.

Pages

Using the greatness of Parallax

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.

Get free trial

Wow, this most certainly is a great a theme.

John Smith
Company name

Startup Growth Lite is a free theme, contributed to the Drupal Community by More than Themes.