News from Industry

Water and oil?

Let’s start by saying this for starters:

WebRTC is VoIP

That said, it is different than VoIP in the most important of ways:

1. In the ways entrepreneurs make use of it to bring their ideas to life
2. In the ways developers yield it to build applications

Why is that?

Because WebRTC lends itself to two very different worlds, all running over the Internet: The World Wide Web. And VoIP.

And these two worlds? They don’t mix much. Beside the fact that they both run over IP, there’s not a lot of resemblance between them. Well, that and the fact that both SIP and HTTP has a 200 OK message.

Everyone is focused on the browser implementation of WebRTC. But what of the needed backend? Join my free mini video WebRTC course that explains the server story of WebRTC.

Join the free server side WebRTC course

If you ever developed anything in the world of VoIP, then you know how calls get connected. You’re all about ring tones and the many features that comprise a Class 5 softswitch. The turth of the matter is, that this kind of knowledge can often be your undoing when it comes to WebRTC.

Here are 10 major differences between developing with WebRTC and developing with VoIP:

#1 – You are No Longer in Control

With VoIP, life was simple. All pieces of the solution was yours.

The server, the clients, whatever.

When something didn’t work, you’d go in, analyze it, fix the relevant piece of software, and be done with it.

WebRTC is different.

You’ve got this nagging thing known as the “browser”.

4 of them.

And they change. And update. A lot.

Here’s what happened in the past year with Chrome and Firefox:

A version every 6-8 weeks. For each of them.

And these versions? They tend to change things in how the browsers change their behavior when it comes to WebRTC. These changes may cause services to falter.

These changes means that:

1. You are not in control over the whole software running your service
2. You are not in control of when pieces of your deployment get upgraded (browsers will upgrade without you having a say in it)

VoIP doesn’t work this way.

You develop, integrate, deploy and then you decide when to upgrade or modify things. With WebRTC that isn’t the case any longer.

You must continuously test against future browser versions (beta, unstable, Canary and nightly should become part of your vocabulary). You need to have the means to easily and quickly upgrade a production service – at runtime. And be prepared to do it rather frequently.

#2 – Javascript is King

My pedigree comes from VoIP.

I am a VoIP developer.

I did development, project management, product management and then been a CTO of a business unit where what we did was develop VoIP software SDKs that were used (and are still used) in many communication products.

I am a great developer. Really. One of the best I know. At least when it comes to coding in C.

VoIP was traditionally developed in C/C++ and Java.

With Javascript I know my way but by no means am I even an average developer. My guess is that a lot of VoIP engineers have a similar background to me.

WebRTC is all about Javascript.

In WebRTC, JavaScript is King
Click To Tweet

Yes. WebRTC has a Javascript API. But that’s half the story. Many of the backend systems written for use with WebRTC ends up using Node.js. Which uses Javascript.

WebRTC isn’t limited to Javascript. There are systems written in C, Java, Python, C#, Erlang, Dart and even PHP that are used. There are .Net systems. On mobile, native apps use Objective C, Swift or Java in their implementations of client-side WebRTC SDKs.

But the majority? That’s Javascript.

Three main reasons I can see for it:

1. Fashion. Node.js is fashionable and new. WebRTC is also new, so there’s a fit
2. Asynchronous. The signaling in WebRTC needs to be snappy and interactive. It needs to have a backend that can fit nicely with its model of asynchronous interactions and interfaces. Node.js offers just that and makes it easier to think of signaling on the frontend and backend at the same time. Which leads us to the third and probably most important reason –
3. Javascript. You use it in the frontend and backend. Easier for developers to use a single language for both. Easier to shift bits and pieces of code from one side to the other if and when needed

#3 – A Big Island

VoIP is all about interoperability. A big happy family of vendors. All collaborating and cooperating. The idea is that if you purchase a phone from one vendor, you *should* be able to dial another vendor’s phone with it via a third vendor’s PBX. It works. Sometimes. And it requires a lot of effort in interoperability testing and tweaking. An ongoing arduous task. The end result though is a system where you end up testing a small set of vendors that are approved to work within a certain deployment.

VoIP and interoperability abhors the idea of islands. Different communication services that can’t connect to each other.

WebRTC is rather different. You no longer build one VoIP product or device that is designed to communicate with VoIP devices of other vendors. You build the whole shebang.

An island of sorts, but a rather big one. One where you can offer access through all browsers, operating systems and mobile devices.

You no longer care about interoperability with other vendors – just with interoperability of your service with the browsers you are relying on. It simplifies things some while complicating the whole issue of being in control (see #1 above).

#4 – It is Cloudy

It seems like VoIP was always mean to run in local deployments. There are a few cases where you see it deployed globally, but they aren’t many. Usually, there’s a geography that goes into the process.

This is probably rooted with the origins of VoIP – as a replacement / digital copy of what you did in telecom before. It also relates to the fact that the world was bigger in the past – the cloud as we know it today (AWS and the many other cloud providers that followed) didn’t really exist.

Skype is said to have succeeded so much as it did due to the fact that it had a great speech codec at the time that was error resilient (it had FEC built-in at a time companies conceptualized about bickering in the IETF and the ITU standard bodies about adding FEC in the RTP layer). It also had NAT traversal that just worked (again, when STUN and TURN were just ideas). The rest of the world? We were all happy enough to instruct customers to install their gatekeepers and B2BUAs in the DMZ.

Since then VoIP has evolved a lot. It turned towards the SBC (more on this in #10).

WebRTC has bigger challenges and requirements ahead of it.

For the most part, and with most deployments of WebRTC, there are three things that almost always are apparent:

1. Deployments are global. You never know from where the users will be joining. Not globally and not their type of network
2. Networks are unmanaged. This is similar to the above. You have zero control over the networks, but your users will still complain about the quality (just check out any of Fippo’s analysis posts)
3. We deploy them on AWS. All the time. On virtual machines. Inside Docker containers. Layers and layers of abstraction. For a real time service. It it seems to work

#5 – Bring Your Own Signaling

VoIP is easy. It is standardized. Be it SIP, H.323, XMPP or whatever you bring to the table. You are meant to use a signaling protocol. Something someone else has thought of in the far dark rooms in some standards organization. It is meant to keep you safe. To support the notion and model of interoperability. To allow for vendor agnostic deployments.

WebRTC did away with all this, opting to not have a signaling protocol at all out of the box.

Some complain about it (mostly VoIP people). I’ve written about it some 4 years ago – about the death of signaling.

With WebRTC you make the decision on what signaling protocol you will be using. You can decide to go for a standards based solution such as SIP over WebSocket, XMPP over BOSH or WebSocket – or you can use a newly created signaling protocol invented only for your specific scenario – or use whatever you already have in your app to signal people.

As with anything in WebRTC, it opens up a few immediate questions:

1. Should you use a standards based signaling protocol or a proprietary one?
2. Should you built it on your own from scratch or use a third party framework for it?
3. Should you host and manage it on your own or use it as a service instead?

All answers are now valid.

#6 – Encryption and Privacy are MANDATORY

With VoIP, encryption was always optional. Seldom used.

I remember going to these interoperability events as a developer. The tests that almost never really succeeded were the ones that used security. Why? You got to them last during the week long event, and nobody got that part quite the same as others.

That has definitely changed over the years, but the notion of using encryption hasn’t. VoIP products are shipped to customers and deployed without encryption. The encryption piece is an optional configuration that many skip. Encryption makes it hard to use wireshark to understand what goes in the network, it takes up CPU (not much anymore, but still conceptually it is), it complicates things.

WebRTC on the other hand, has only encryption configured into it. No way to use it with clear RTP. even if you really really want to. Even if you swear all browsers and their communications run inside a secure network. Nope. can’t take security out of WebRTC.

#7 – If it is New, WebRTC Will be Using it

When WebRTC came out, it made use of the latest most recent RFCs that were VoIP related in the media domain.

Ability to bundle RTP and RTCP on the same stream? Check.

Ability to multiplex audio and video on the same stream? Check.

Ability to send FIR commands over RTCP and not signaling? Check.

Ability to negotiate keys over DTLS-SRTP instead of SDES? Check.

There are many other examples for it.

And in many cases, WebRTC went to the extreme of banning the other, more common, older mechanisms of doing things.

VoIP was always made with options in mind. You have at least 10 different ways in the standard to do something. And all are acceptable.

WebRTC takes what makes sense to it, throwing the rest out the window, leaving the standard slightly cleaner in the end of it.

Just recently, a decision was made about supporting non-multiplexed streams. This forced Asterisk and all of its users to upgrade.

VoIP and SIP were never really that important to WebRTC. Live with it.

#8 – Identity Management and Authorization are Tricky

There’s no identity management in WebRTC.

There’s also no clear authorization model to be heard of.

Here’s a simple one:

With SIP, the way you handle users is giving them usernames and passwords.

The user clicks that into the client and this gets used to sign up to the service.

With regular apps, it is easy to set that username/password as your TURN credentials as well. But doing it with WebRTC inside a browser opens up a world of pain with the potential of harvesting that information to piggyback on your TURN servers, costing you money.

So instead you end up using ephemeral passwords in TURN with WebRTC. Here’s an explanation how to do just that.

In many other cases, you simply don’t care. If the user already logged into the page, and identified and authenticated himself in front of your service, then why have an additional set of credentials for him? You can just as easily piggyback a mechanism such as Facebook connect, Twitter, LinkedIn or Google accounts to get the authentication part going for you.

#9 – Route. Don’t Mix

If you come from VoIP, then you know that for more than two participants in a call you mix the media. You do it usually for audio, but also for the video. That’s just how things are (were) done.

But for WebRTC, routing media through an SFU is how you do things.

It makes the most sense because of a multitude of reasons:

1. For many use cases, this is the only thing that can work when it comes to meeting your business model. It strikes that balance between usability and costs
2. This in turn, brings a lot of developers and researchers to this domain, improving media routing and SFU related technologies, making it even better as time goes by
3. In WebRTC, the client belongs to the server – the server sends the client as HTML/JS code. With the added flexibility of getting multiple media streams, comes an added flexibility to the UI’s look and feel as well as behavior

There are those who are still resistant to the routing model. When these people have a VoIP pedigree, they’ll lean towards the mixing model of an MCU, calling it superior. It will usually cost 10 times or more to deploy an MCU instead of an SFU.

Be sure to know and understand SFUs if you plan on using WebRTC.

#10 – SBCs are Useless

Or at least not mandatory anymore.

Every. SBC. vendor. out. there. is. adding. WebRTC.

And I get it. If you’re building an SBC – a Session Border Controller – then you should also make sure it supports WebRTC so all these pesky people looking to get access through the browser can actually get it.

An SBC was an abomination added to VoIP. It was a necessary evil.

It served the purpose of sitting in the DMZ, making sure your internal network is protected against malicious VoIP access. A firewall for VoIP traffic.

Later people bolted on that SBC the ability to handle interoperability, because different vendor products never really worked well with one another (we’ve already seen that in #3). Then transcoding was added, because we could. And then other functions.

And at some point, it was just obvious to place SBCs in VoIP infrastructure. Well… WebRTC doesn’t need an SBC.

VoIP needs an SBC that handles WebRTC. But if you’re planning on doing a WebRTC based application that doesn’t have much of VoIP in it, you can skip the SBC.

#11 – Ecosystem Created by the API and Not the Specification

Did I say 10 differences? So here’s a bonus difference.

Ecosystems in VoIP are created around the network protocol.

You get people to understand the standard specification of the network protocol, and from there you build products.

In WebRTC, the center is not the network protocol (yes, it is important and everything) – it is the WebRTC APIs. The ones implemented in the browsers that enable you to build a client on top. One that theoretically should run across all browsers.

That’s a huge distinction.

Many of the developers in WebRTC are clueless about the network, which is a shame.  On the other hand, many VoIP developers think they understand the network but fail to understand the nuanced differences between how the network works in VoIP and in WebRTC.

What’s Next?

If you have VoIP background, then there are things for you to learn when shifting your focus towards WebRTC. And you need to come at it with an open mind.

WebRTC seems very similar to VoIP – and it is – because it is VoIP. But it is also very different. In the ways it is designed, thought of and used.

Knowing VoIP, you should have a head start on others. But only if you grok the differences.

Need to warm up to WebRTC? Try my free WebRTC server side mini course.

And if you’re really serious, enroll to my Advanced WebRTC Architecture Course.

 

The post Why Developing With WebRTC is Different than VoIP Development? appeared first on BlogGeek.me.

Kamailio SIP Server v5.0.3 stable is out – a minor release including fixes in code and documentation since v5.0.2. The configuration file and database schema compatibility is preserved, which means you don’t have to change anything to update.Kamailio v5.0.3 is based on the latest version of GIT branch 5.0. We recommend those running previous 5.0.x or older versions to upgrade. There is no change that has to be done to configuration file or database structure comparing with the previous release of the v5.0 branch.Resources for Kamailio version 5.0.3Source tarballs are available at:

• https://www.kamailio.org/pub/kamailio/5.0.3/src/

Detailed changelog:

• https://www.kamailio.org/pub/kamailio/5.0.3/ChangeLog

Download via GIT: # git clone https://github.com/kamailio/kamailio kamailio
# cd kamailio
# git checkout -b 5.0 origin/5.0Relevant notes, binaries and packages will be uploaded at:

• https://www.kamailio.org/pub/kamailio/5.0.3/

Modules’ documentation:

• https://www.kamailio.org/docs/modules/5.0.x/

What is new in 5.0.x release series is summarized in the announcement of v5.0.0:

• https://www.kamailio.org/w/kamailio-v5-0-0-release-notes/

Thanks for flying Kamailio!

Decoding video when there is packet loss is not an easy task.  Recent Chrome versions have been plagued by video corruption issues related to a new video jitter buffer introduced in Chrome 58. These issues are hard to debug since they occur only when certain packets are lost. To combat these issues, webrtc.org has a […]

The post How to capture & replay WebRTC video streams with video_replay (Stian Selnes) appeared first on webrtcHacks.

Fred Posner, our big friend (and baker from Florida), participated to ClueCon Conference 2017 and gave a presentation about Kamailio SIP Server. The slides deck is available at:

• https://kamailio.org/events/2017-ClueCon/Fred.Posner-Kamailio.pdf

You can find some good hints and tips about using Kamailio for building intelligent SIP routing.As usual, we would like to thank for spending time and financial resources for promoting Kamailio. Should you present at a large world wide event or small meetup in your area and have some notes about Kamailio, we definitely appreciate it a lot and we are more than happy to host a copy of the slides on our events directory:

• https://kamailio.org/events/

Just get in touch with us!Thank you for flying Kamailio!

See you in September.

Time for some downtime for me.

Not from work – got too many projects going on at the moment – updating my course, testRTC and some interesting customer projects I am involved with. I am also working on an offering around APIs. More on that later.

This means – no new writing here for the next couple of weeks.

See you all once I am back.

In the meantime, if you have any questions or needs around the things I write about, feel free to contact me. I’ll gladly help you find your way around this tech (and even focus my writing in the areas you are interested in).

Until September

The post Taking a Breather. Be Back in September appeared first on BlogGeek.me.

I say it doesn’t matter what the technique is as long as you go through the motion of upgrading your WebRTC Media Servers…

Here’s the thing. In many cases, you end up with a WebRTC deployment built for you. Or you invest in a project until its launch.

And that’s it.

Why Upgrade WebRTC Media Servers?

With WebRTC, things become interesting. WebRTC is still a moving target. Yes. I am promised that WebRTC 1.0 will be complete and published by the end of the year. I hear that promise since 2015. It might actually happen in 2017, but it seems browser vendors are still moving fast with WebRTC, improving and optimizing their implementations. And breaking stuff at times as they move along.

Add to that the fact that media servers are complex, and they have their own fixes, patches, security updates, optimizations and features – and you find yourself with the need to upgrade them from time to time.

Upgrade as a non-functional feature is important for your WebRTC requirements. I just updated my template, so you don’t forget it:

Download the WebRTC Requirements How To

I’ll take it a bit further still:

1. With WebRTC, the browser (your client) will get upgraded automatically. It is for your own safety This in turn, may force you to upgrade the rest of your infrastructure; and the one prone the most?
2. Your WebRTC media server needs to be upgraded. First to keep pace with the browsers, but also and not less important, to improve; but also
3. The signaling server you use for WebRTC. That one may need some polish and fine tuning because of the browser. It may also need to get some care and attention – especially if and when you start expanding your service and need to scale out – locally or geographically
4. Your TURN/STUN servers. These tend to go through the least amount of updates (and they are also relatively easy to upgrade in production)

Great. So we need to upgrade our backend servers. And we must do it if we want our service to be operational next year.

Talking Production

But what about production system? One that is running and have active users on it.

How do you upgrade it exactly?

Gustavo García‏ in a recent tweet gave the techniques available and asked to see them by popularity:

Just curious about how do you upgrade your #WebRTC mediaservers?

— Gustavo García (@anarchyco) August 4, 2017

I’d like to review these alternatives and see why developers opt for “Draining first”. I’ll be using Gustavo’s naming convention here as well. I will introduce them in a different order though.

#1 – Immediate Kill+Reconnect

This one is the easiest and most straightforward alternative.

If you want to upgrade WebRTC media servers, you take the following steps:

1. Kill the existing server(s)
2. Upgrade their software (or outright replace their machines – virtual or bare metal)
3. Reconnect the sessions that got interrupted – or don’t…

This is by far the simplest solution for developers and DevOps. But it is the most disruptive for the users.

That third step is also something of a choice – you can decide to not reconnect existing sessions, which means users will now have to reconnect on their own (refresh that web page or whatever), or you might have them reconnected, either by invoking it from the server somehow or having the clients implement some persistency in them to make them automatically retry on service interruption.

This is also the easiest way to maintain a single version of your backend running at all times (more on that later).

#2 – Active/Passive Setup

In an active/passive setup you’ll have idle machines sitting and waiting to pick up traffic when the active WebRTC media servers are down (usually for whatever reasons and not only on upgrades).

This alternative is great for high availability – offering uptime when machines or whole data centers break, as the time to migrate or maintain service continuity will be close to instantaneous.

The downside here is cost. You pay for these idle machines that do nothing but sit and wait.

There are variations of this approach, such as active-active and clustering of machines. Not going to go in the details here.

In general, there are two ways to handle this approach:

1. Upgrade the passive machines (maybe even just create them just before the upgrade). Once all are upgraded, divert new traffic to them. Kill the old machines one by one as the traffic on them whanes
2. Employ rolling upgrade, where you upgrade one (or more) machines each time and continue to “roll” the upgrade across your infrastructure. This will reduce your costs somewhat if you don’t plan on keeping 1:1 active/passive setup at all times

(1) above is the classic active/passive setup. (2) is somewhat of an optimization that gets more relevant as your backend increases in its size – it is damn hard to replace everything at the same time, so you do it in stages instead.

Note that in all cases from here on you are going to have at least two versions of your WebRTC media servers running in your infrastructure during the upgrade. You also don’t really know when the upgrade is going to complete – it depends on when people will close their ongoing sessions.

In some ways, the next two cases are actually just answering the question – “but what do we do with the open sessions once we upgrade?”

#3 – Sessions Migration First

Sessions migration first means that we aren’t going to wait for the current sessions to end before we kill the WebRTC media server they are on. But we aren’t going to just immediately kill the session either (as we did in option #1).

What we are going to do, is have some means of persistency for the sessions. Once a new upgraded WebRTC media server machine is up and running, we are going to instruct the sessions on the old machine to migrate to the new one.

How?

Good question…

• We can add some control message and send it via our signaling channel to the clients in that session so they’ll know that they need to “silently” reconnect
• We can have the client persistently try to reconnect the moment the session is severed with no explanation
• We can try and replicate the machine in full and have the load balancer do the switchover from old to new (don’t try this at home, and probably don’t waste your time on it – too much of a headache and effort to deal with anyways)

Whatever the technique, the result is that you are going to be able to migrate rather quickly from one version to the next – simply because once the upgrade is done, there won’t be any sessions left in the old machine and you’ll be able to decommission it – or upgrade it as well as part of a rolling upgrade mechanism.

#4 – Draining First

Draining first is actually draining last… let’s see why.

What we are going to do here is bring up our new upgraded WebRTC media servers, route all new traffic to them and… that’s about it.

We will keep the old machines up and running until they drain out of the sessions that they are handling. This can take a couple of minutes. An hour. A couple of hours. A day. Indefinitely. Depending on the type of service you have and how users interact with it will determine how long on average it will take for a WebRTC media server to drain its sessions with no service interruption.

A few things to ponder about here (some came from the replies to that original tweet):

• WebRTC media servers can’t hold too much traffic (they don’t scale to millions of sessions in parallel)
  • With a large service, you can easily get to hundreds of these machines
  • Having two installations running in parallel, one with the new version and one with the old will be very expensive to operate
  • The more servers you’ll have, the more you’ll want to practice a rolling upgrade, where not all servers are upgraded at the same time
• You can have more than two versions of the WebRTC media server running in parallel in your deployment. Especially if you have some really long lived sessions
• You can be impatient if you like. Let session drain for an hour. Or two. Or more. And then kill what’s left on the old WebRTC media server
• Media servers might be connected to other types of services – not only WebRTC clients. In such a case, you’ll need to figure out what it means to kill long lived sessions – and maybe decouple your WebRTC media server to further smaller servers

Why Most Developers Lean Towards Draining First?

Gustavo’s poll garnered only 6 answers, but they somehow feel right. They make sense from what I’ve seen and heard from the discussions I’ve had with many vendors out there.

And the reasons for this are simple:

1. There’s no additional development on the client or WebRTC media servers. It is mostly DevOps scripts that need to reroute new incoming traffic and some monitoring logic to decide when to kill an empty old WebRTC media server
2. There’s no service disruption. Old sessions keep running until they naturally die. New sessions get the upgraded WebRTC media servers to work on

What’s next?

If you are planning on deploying your own infrastructure for WebRTC (or have it outsourced), you should definitely add into the mix the upgrade strategy for that infrastructure.

This is something I overlooked in my WebRTC Requirements How To – so I just added it into that template.

Need to write requirements for your WebRTC project? Make sure you don’t miss out on the upgrading strategy in your requirements:

Get my WebRTC Requirements How To

The post How do you Upgrade Your WebRTC Media Servers? appeared first on BlogGeek.me.

The ACC module (accounting) in Kamailio got a bit of clean up, therefore be aware of following changes:

• (1) the define conditions on SQL_ACC were removed — this was enabled for more than 10 years and only made the code look complex and hard to follow up its logic.
• (2) the code related to DIAMETER accounting was relocated to acc_diameter (new) module. It was a consistent size of code that was not enabled for sooo… long. It is now a dedicated module, similar to acc_radius. The diameter accounting code, even a new module now, is in the same stage, compiling but not tested, in pair with auth_diameter module, it may work, but very likely not.

In summary, what’s important for those using the acc module — it offers the same functionality as it was enabled by default in the past 10 years or more: writing accounting records to syslog and sql databases — only the unused code was relocated.The acc module is now slimmer, only with the code that it needs, therefore easier to maintain and enhance for the future. For any issue, as usual open a report on Github project portal.Thanks for flying Kamailio!

Yes.

In recent years, we’ve seen a lot of hysteria going on around WebRTC. Mainly it being unsafe to use. So much so, that there are tutorials out there explaining how to disable it in every conceivable browser out there.

This reminds me all of the past (and present?) hysteria around running JavaScript code inside the browser – and again – how to disable it.

If you are developing a WebRTC application AND you care about the security of your service and the privacy of your users, make sure to review my WebRTC Security Checklist.

Get the WebRTC Security Checklist

Why is WebRTC Perceived as Dangerous?

WebRTC is a real time communication technology that is embedded in the browser. It can access your camera and your microphone as well as share the contents of your screen. As such, it enables a browser (and web developers) access to a lot more resources on the device of an end user.

This boils down to two main risks:

1. Your data can be stolen by nefarious people
2. Your privacy can be breached by knowing more about your device

1. Your data can be stolen by nefarious people

Here are a few scary ideas:

• If I can access your microphone, I’ll be able to record all of your conversations
• If I can access your camera, I’ll be able to snoop on you. Maybe take a nice recording of your intimate moments
• If I can access your screen remotely, I’ll be able to record what you’re doing. Maybe even control your mouse and keyboard remotely while at it?

With all the goodness WebRTC brings, who wants to be spied on by his own device?

Now, that said, we also need to understand two things here:

1. The browser isn’t the only game in town to gaining this access to your data and actions
2. There are measures put in place to limit the ability to conduct in such activities

2. Your privacy can be breached by knowing more about your device

This one I guess is mostly about tracking you over the internet. Which is what ad networks are doing most of the time.

WebRTC gives access to more elements that are unique, which makes fingerprinting of the device (and you) a lot more accurate. Or so they say.

The main concern here are around the exposure of private IP addresses to web servers. There are many out there who see these “IP leaks” as a serious threat. for most of humanity, I believe it isn’t, which is why I’ll gladly publish my private IP address here: 10.0.0.9.

There are other, more nuanced ways in which WebRTC can be used for fingerprinting, such enumerating the device list as part of your device’s unique identity. Which is a concern, until you review the  accuracy of fingerprinting without even using WebRTC. Here are two resources for you to enjoy:

1. Panopticlick – EFF’s fingerprinting check up ad research. If you are not unique – comment below – I have a feeling your browser is as unique as mine. Their TL;DR? Disable JavaScript (which will be too much work) or use a more “common” browser. I am NOT making this up:
   
2. Fingerprintjs2 – one of the many libraries available to fingerprint your browser. It doesn’t use WebRTC, although there’s an “intent” in there to add support to it

In this area, Apple with their new WebRTC support in Safari is leading the way in maintaining privacy. You can read about it in a recent article in the WebKit blog. Look specifically on the sections titled “ICE Candidate Restrictions” and “Fingerprinting”.

Why is WebRTC the Safest Alternative?

If you are a developer looking for a real time communications technology to use in your application, or you are an IT person trying to decide what to deploy in your company, then WebRTC should be your first alternative. Always.

Here’s why.

1. Browser vendors take care security seriously

There are 4 major browser vendors: Apple, Google, Microsoft and Mozilla

All of these vendors are taking care of security and patching their browsers continuously. In some cases, they even roll out new versions at breakneck speeds of 6-8 weeks, with security patches in-between.

If a security threat is found, it gets fixed fast.

While many other vendors can say that they are fixing and patching security threats fast – do they deploy them fast? Do they have the means to do so?

Since browsers get updated and upgraded so frequently, and to hundreds of millions of users, getting a security patch to the field happens rather fast. Philipp Hancke showed and explained some Here are some browser upgrade stats last year. This is from real users conducting appear.in sessions. I asked him to share a more recent graph, and here’s what they’ve had in the last two large browser version cycles for Chrome:

Look at the point in time when each Chrome version got ramped up from less than 30% to over 80% in a span of a couple of days. Chrome 59 is especially interesting. Also note that there are at most 2 versions of Chrome out there with over 95%+ of use. Since they routinely do it, patching and deploying security issues is “easy”.

The only other vendors who can roll out and deploy patches so fast? Operating system vendors (again we end up with Apple, Google and Microsoft), and application developers, through mobile app stores (which sums up to Apple and Google).

Nothing comes close to it.

Takeaway: Assume there will be security breaches or at the very least the need to patch security issues. Which means you should also plan for upgrade policies. Browsers are the best at upgrading these days.

2. You don’t need to redeploy the client software

Lets face it – most users don’t disable the automatic update policy of their browsers. If you’re even remotely interested in security, you shouldn’t disable automatic update policies of ANYTHING.

Manual updates bring with them a world of pain:

(a) When do you upgrade?

Here’s the thing.

How do you know an upgrade is in order? Are you on the list of threat alerts of all the software and middleware you are using in your company? Once a threat is announced and a patch is available – do you immediately upgrade?

When we leave this decision to a human, then he might just miss the alert. Or fail to upgrade. Or decide to delay. Just because… he’s human.

Most software can get updated, but usually won’t do it automatically or won’t do it silently. And automation in this area that is done externally, such as the Kaspersky Software Updater. It works, but up to a point and it also adds another headache to contend with and manage.

If a browser does that for you freely, why not use it?

(b) What if this fails?

Did you ever get a software update to fail?

What about doing that in a company with 100+ employees?

If software fails to update 1% of the time, it means that every time you update something – someone will complain or just fail to update, making you revert back to a manual process.

There are tons of reasons why these processes fail, and most are due to the fact that we all have different firmware, software and device drivers on our machines (see fingerprinting above). This fact alone means that if a software isn’t running on millions of devices already, it will fail for some. I’ve seen this too many times when the company I worked for developed a plugin for browsers.

Anyone not using WebRTC and deploying via software installation will cause you grief here. If this is only in front of employees, then maybe that’s fine. But often times this is also with end user devices – and you don’t want to mess there.

Browser upgrades will fail a lot less often, so better use that and just make use of WebRTC instead of rolling your own proprietary solution.

(c) What about edge cases?

You can’t control your employees and their whereabouts for your upgrades.

People working from home.

People traveling abroad.

People using BYOD and… not having tight enterprise policies on their own home laptop.

If you want less headache in this department, then again – using WebRTC will give you peace of mind that security patches get updated.

Why?

Look at it this way, the engine of WebRTC will always stay secure when you rely on browser and browser updates.

You have control over the backend (or rely on a cloud service provider with an SLA you are paying for exactly for this reason). The backend gets updated for security patches all the time (or as much as you care). The browsers get updated automatically so you can think less about it.

Using proprietary software or legacy VoIP vendor software means you’ll need to patch both backend and client software. This is harder to do and maintain – and easier to miss.

3. WebRTC has inherent security measures in place

This should probably be the first reason…

One thing you hear many complain about is questioning why WebRTC is always encrypted. Somehow, developers decided that sending media in the clear is a good thing. While there might be some reasons to do that, most of them are rather irrelevant for something like WebRTC, meant to be used on unmanaged networks.

WebRTC took the approach of placing its security measures first. This means:

1. There’s no way send media in the clear. Everything is always encrypted. In other VoIP solutions, you can configure encryption on and off (if encryption is even there)
2. There’s no way to use WebRTC in websites that aren’t served over HTTPS. This means WebRTC forces developers to use secure connections for signaling – and for the whole site. And no. Using iframes won’t work either
3. Users are asked to allow access to the their media inputs. Each browser handles this one slightly differently, and these models also changes over time, but suffice to say that the idea here is again – to balance privacy of the users and the usability of the service

Me? I’d rather rely on the security measures placed in browsers. These go through the scrutiny of lots of people who are all too happy to announce these security flaws. Software from vendors that is specific to communications? A lot less so.

And yes. This isn’t enough. WebRTC is the building block used to build an application. A lot of what goes to the security of the finished service will rely on the developers who developed the application – but at least they got a head start by using WebRTC.

Ads and WebRTC

There’s an angle that isn’t much discussed about WebRTC. And that’s the uses it finds in the ad business.

The Bad

Two main scenarios that I’ve seen here:

1. Fingerprinting. You get better means to know more about who the user behind the browser is
2. Serving ads themselves. Theoretically, you might be able to serve ads via WebRTC, and that at the moment has the potential to circumvent ad blockers

The Good

There’s the second part of it. When ads are served today, the companies paying for these ads being served like to get their ROI. On the other hand, there are those who would like the money spent on ads to be wasted. So they use bots to click ads. Probably by automating selenium processes.

This is similar in concept to the “I am not a robot” type of entry measures and captchas out there. WebRTC gives another layer of understanding about the user and its behavior – and enables us to know if he is a human or a bot inside that browser. And yes. We can use it for things other than ad serving.

Where do we go from here?

There are two main approaches to security:

1. Security by obscurity – relying on people not knowing the protocol in place. It works great when you’re small and insignificant, so no one is going to care about you anyway. It falls apart when you become popular
2. Kerckhoffs’ principle – a system needs to be secure even when we know everything about the system. It works best when many people scrutinize, analyze and try to hack such systems, making it better and more robust through time

WebRTC is in the second category (the first one – security by obscurity – is often criticized for being unsecure by nature).

With all the resources put into WebRTC from all angles, security is also being taken care of and not left behind.

WebRTC is safe to adopt as developers. IT and security people in the enterprise shouldn’t shy away from it either – just make sure the vendor you pick did a decent job with his implementation.

Are you doing what it takes to improve the security of your WebRTC application?

Get the WebRTC Security Checklist

The post Is WebRTC Safe? appeared first on BlogGeek.me.

Konstantin Tumalevich has posted an article via GitHub about his research done on VoIP fraud using Kamailio as a sensor, along with other VoIP applications such as Asterisk.Some interesting facts extracted from the article:For research, I created honeypot what mimics vulnerable PBX.For emulation, I used Kamailio nodes that send any calls to termination node and answers to OPTIONS and REGISTER.For every INVITE I recorded From, To, UA, Call-ID, IP and call time.Termination node has Kamailio with Flask app for preprocessing calls and Asterisk for topology hiding when calls sent to PSTN.All calls with a cost of more than 2 cents per minute were rejected with code 486.I used 4 sensor nodes located in NL, DE, SG and NYC.For 18 days, 254805 INVITE were collected from 296 different IP’s. On average, 860 INVITEs were received from an IP.Reports about top source IPs, countries of origin and the operator as well as related graphs can be found in the conclusions of the research. Few hints are also provided about how to protect better.You can read the entire article at:

• https://github.com/UserAd/data_science/blob/master/VoIPfraud/en.md

Enjoy!Thanks for flying Kamailio!

When it comes to different verticals and market niches, it seems like WebRTC can fit anywhere.

6 years in, and there are many who still question if WebRTC is the way to go with their use case. This is one of the reasons why I started the WebRTC Dataset. The idea behind it all was to showcase all the variations and services where WebRTC is being used.

Here’s an example for you.

Musicians of all kinds make use of WebRTC. They have services today that are geared towards their specific needs. And I am not talking only about replacing Skype with a marketplace or a searchable directory of experts that can help you take private guitar lessons online.

When I bumped into Profound Studio, I knew this is an area I’d like to write a bit more about, so here it goes.

What I will be doing in this article, is go over some of the vendors found in the WebRTC Dataset, collected over the years, who are playing a role in the sound/music industry in one way or another.

I won’t be picking favorites here – my own experience with music is rather dull – I like to hear music just like anyone else, but I don’t consider myself an expert or a fan of anything really. This means that we’ll be going in alphabetic order of the vendors.

Care 2 Rock

Care 2 Rock is that we-teach-guitar-lessons use case with a twist.

The basic premise is having teaching music lessons of any kind online, through a video call. The twist is that this is a paid/voluntary act on the side of the teacher, who ends up teaching and mentoring a foster care kid in his community.

Profound Studio

Profound Studio connects musicians with recording experts.

This is a marketplace for professionals – not for hobbyists. You can run live classes there or do consultation calls.

sofasession

sofasession is all about musicians making music together online. The majority of it is done asynchronously, where each musician contributes and edits tracks of the final masterpiece, but they don’t need to be live together at the same time. And still, this kind of a use case can use WebRTC.

Here’s a job posting they had from two years ago:

We will use Kurento as media server and extending the service for multitrack mixing and reducing latency by developing latency reducing algorithms for serving content to clients connected via the webRTC protocol.

For the layman, handling audio in realtime in the browser to handle that mixing module that’s inside sofasession requires low latency. The best way to get there is to have something like WebRTC manage it – we are talking about real time here.

I am not sure if and how far they went with their WebRTC support. They do support live jam sessions, but there’s a need to download dedicated software for that. It does use UDP to work, so there still might be some WebRTC in there.

Soundtrap

Soundtrap is similar to sofasessions. It too focuses on musicians collaborating online.

Based in Stockholm, where some of the Google WebRTC team are located, even got it to appear at Google I/O in 2014:

StreetJelly

StreetJelly is about live performances. It allows artists to stream their music live to a global audience.

At the moment, performing and viewing is free. Viewers can tip performers if they want.

On the technical side, StreetJelly uses HTML5 video playback for the viewers and either Flash (now dead) or WebRTC (the new method for StreetJelly) to be able to broadcast the performances. They explain this further here.

Shots in the dark

Other vendors such as Rapt.fm and unltd.fm came and went.

As with any set of startups, the vendors in this space don’t always succeed.

How will others fair? Time will tell.

The Appeal

Music and WebRTC. There’s an appeal there.

VoIP was crap most of the time up until recently. There were two main reasons for it:

1. The selection of voice codecs, with the dominant ones being narrowband codecs like G.711 or the G.729. When you did get a better sounding codec, it was either protected by patents, not suitable for real time or just stuck in wideband but still focusing on speech and not music
2. These codecs aren’t usually error resilient. The moment you introduce packet loss (and these happen regularly), the audio quality suffers. So something had to be done in that front

WebRTC comes with Opus “out of the box”. A wideband codec suitable for music – not only speech, which is royalty free, low latency and error resilient. To top it all – it is mandatory in WebRTC and one of only two such codecs (the other one being the ridiculously crappy G.711). What’s not to like as a musician?

Why is this important?

Well… here’s the kicker.

None of it is new.

VoIP and video calling could have done this all before WebRTC.

But it didn’t.

Why?

Costs. Barriers of entry. Finding talent.

WebRTC solves all that, which is why I categorize all of these vendors and many others as WebRTC vendors.

They don’t care about WebRTC as a technology – for them it is just means to an end, which is just fine.

But what about you?

Want to learn more about a specific market niche where real time communications be of use? Want to instantly find who’s there already and what they are doing?

You’d better take a look at the WebRTC Dataset. Especially today, before the earlybird discount ends.

Get access to the WebRTC Dataset

The post Sound Gurus Finding a Home in WebRTC appeared first on BlogGeek.me.

I am a big fan of Chrome’s webrtc-internals tool. It is one of the most useful debugging tools for WebRTC and when it was added to Chrome back in 2012 it made my life a lot easier. I even wrote a lengthy series of blog post together with Tsahi Levent-Levi describing how to use it […]

The post WebRTC Externals – the cross-browser WebRTC debug extension appeared first on webrtcHacks.

As every August for more than a decade, the ClueCon conference takes place again in Chicago, USA, during August 7-10, 2017. Mainly organised by the people behind FreeSwitch project, ClueCon is among those events where you can meet a large group of experienced people with open source realtime communication technologies.Kamailio will be present with a talk by Fred Posner, one of our very active advocates of the project in North America and not only. His presentation is scheduled for Wednesday, August 9, at 10:45am:

• https://www.cluecon.com/schedule.html

Besides Fred, you will be able to meet other relevant members of Kamailio project or friends from the VoIP world! If you haven’t checked the event so far, do it very soon and consider to register, no much time left and ClueCon is always worth attending! Read moreabout the event at:

• https://www.cluecon.com

Enjoy!Thank you for flying Kamailio!

Knowledge=Power. Which is why the WebRTC Dataset might be just what you need.

A Quick History Lesson

You see numbers flying around about WebRTC all the time. One of them is the number of vendors using WebRTC. 1,200 might sound familiar in that context. Well… it comes from the WebRTC Dataset that I am maintaining.

It all started ages ago. I think it was Alan Quayle who made a shortlist of the companies that were using WebRTC that he knew about. That was somewhere in 2012. Which made me start my own Excel sheet. Which was then converted into a Google sheet. Which was then converted into a whole operation of how to find, catalog and update a dataset.

The reason? One of the main companies who are influencers in WebRTC wanted access to it and were willing to pay, so I made it into a product. Since then it had a few more customers who got exclusive ongoing access to this dataset, and now, I decided to repackage it in a different fashion, making it more accessible to more companies.

What’s in the WebRTC Dataset?

The WebRTC Dataset itself is a collection of vendors and projects who are making use of WebRTC in one way or another. It can be anything from a healthcare service to an outsourcing vendor to a live streaming service or a contact center.

The list includes today around 1,200 vendors and counting – it grows and gets updated on a monthly basis.

You’ll find in the dataset vendors large and small. Anything from Google, Cisco and Facebook to small startups and even individual projects that are popular or interesting enough.

You’ll find there acquisitions made in the industry, with reasons behind them and my own indication of how related they are to WebRTC.

You’ll find there vendors who have shut down. Those who have pivoted and changed their focus.

When the information is publicly known, available or can be found online – the suppliers that are used by a vendor are also indicated.

Here’s an example vendor’s information from the WebRTC Dataset:

The page is split into several parts:

1. The top part, where general information about the company/project can be found. Including things like size, ranking, status and external sources such as Crunchbase
2. Then there’s the verbal description and notes, which gets updated through time as the offering evolves
3. After that, different classifications. These are parameters that you can easily use to filter out or find similarly typed vendors in the dataset
4. Then come links from other sources as well as my own blog and the latest tweets from that vendor
5. Last but not least, a quick form in the end allows you to ask anything you have about this vendor and get direct answers from me

Where does this data come from?

All over the web.

Since I am actively working on projects like WebRTC Index and WebRTC Weekly, I got to keep tabs with anything related to WebRTC. I go over the blogs of all the vendors using WebRTC and investigate anything that looks like RTC that I bump into in whatever it is that I am reading. On top of that, I use additional sources like Google Alerts and a few other trade secrets

And I’ve been doing this since 2013.

The data in the WebRTC Dataset got created along the way. First as a resource for me to use whenever I need research information on certain domains. And then because it made sense to package it as a distinct product of its own.

Whatever is on the WebRTC Dataset it is something you can go and find out on your own. But it will take you time. Lots and lots of time.

What can you DO With the WebRTC Dataset?

Lots of things actually. It all depends on what it is you’re trying to gain.

Here are a few ideas and uses that people have been using it for already:

1. Mark potential companies as leads for your salespeople – if you have a cool solution or service that can fit a certain segment, then you can find some interesting companies who might be interested in what you have to offer in this dataset
2. Check out your competitors – find who they are. See who their known customers are. Compare them to your own company
3. Find target markets and their size – need to decide where to put your focus? Should it be Healthcare or should it be Education? Should you offer a click to dial button as a service or go for a video chat widget instead? Who are the competitors in the niche you’re trying to carve for yourself? What are they doing?
4. Understand market trends – here’s what Serge Lachapelle, who was Group Product Manager at Google heading their WebRTC efforts, had to say of the time he used the WebRTC Dataset:

The dataset enables me to understand where the WebRTC platform is going and make strategic roadmap decisions based on where the innovation and heavy usage lies. Being able to get an updated complete view of the market at any given point in time over a large set of criteria makes it easy to see trends in different industries and verticals that make use of WebRTC.

I am sure you’ll be able to find other ways to use it if you only think about it.

And me?

I use this WebRTC Dataset all the time. One of the things I use it for is my annual “WebRTC State of the Market” infographic.

Here’s the one for 2016 and the one for 2017 that I created.

How about a sneak peak?

If you want to see how the WebRTC Dataset feels like to use, then here’s a short video:

I’m interested. Now what?

Access to the WebRTC Dataset comes at $2,400.

The WebRTC Dataset access gives you 1 month of access to all the vendors there. You’ll be able to download the main worksheet and use it after that month is up.

You can decide to purchase it at any point in time, just head to the WebRTC Dataset page.

While we’re at it – if you decide to purchase before the end of July (even if you plan on using it later on), there’s an early bird discount of $400. Just use coupon code DATASET-EARLYBIRD.

Get the dataset

The post Drilling into the WebRTC Dataset appeared first on BlogGeek.me.

SIMCom SIM7100E is a recent LTE modem released by Simcom. It’s approximately $20 cheaper than Huawei LTE modem, and also it provides USB voice function, so it could be integrated with FreeSWITCH mod_gsmopen module (this needs development).

My set of udev rules and chat scripts is updated with SIM7100E information, and here’s a copy:

cat >/etc/udev/rules.d/99-wwan.rules <<'EOT' # SIMCom SIM7100 SUBSYSTEM=="tty", ATTRS{idVendor}=="1e0e", ATTRS{idProduct}=="9001", SYMLINK+="ttyWWAN%E{ID_USB_INTERFACE_NUM}" SUBSYSTEM=="net", ATTRS{idVendor}=="1e0e", ATTRS{idProduct}=="9001", NAME="lte0" EOT cat >/etc/chatscripts/sunrise.SIM7100 <<'EOT' ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR TIMEOUT 10 '' 'AT+CFUN=1' OK 'AT+CMEE=0' OK 'AT+CGDCONT=1,"IP","internet"' OK '\dAT\$QCRMCALL=1,1' OK EOT cat >/etc/chatscripts/gsm_off.SIM7100 <<'EOT' ABORT ERROR TIMEOUT 5 '' 'AT\$QCRMCALL=0,1' OK AT+CFUN=0 OK EOT cat >/etc/network/interfaces.d/lte0 <<'EOT' allow-hotplug lte0 iface lte0 inet dhcp pre-up /usr/sbin/chat -v -f /etc/chatscripts/sunrise.SIM7100 >/dev/ttyWWAN02 </dev/ttyWWAN02 post-down /usr/sbin/chat -v -f /etc/chatscripts/gsm_off.SIM7100 >/dev/ttyWWAN02 </dev/ttyWWAN02 EOT

 

Filed under: Networking Tagged: 3G, GSM, linux, lte, pcengines

Where are we headed with WebRTC?

Google made an interesting announcement recently. It was about WebRTC 1.0 and Google’s own commitment to it. It seems we’ve come to a point in time when WebRTC is considered a done deal and the rest are just details – getting bugs fixed and polishing its performance.

I wanted to understand a bit more where we are headed, from the point of view of the company who lead the effort up until now. So I reached out to Niklas Blum, who is leading product management for WebRTC at Google, to answer a few of my questions.

 

How is it like to manage something like WebRTC at Google?

WebRTC is an exciting project. It is one of these kind of projects that are only possible at companies like Google and a few other places when you think of scale and impact of the technology. We started about 6 years ago as an open source project in Chrome and now WebRTC is providing the stack for an ecosystem for real-time communication services on Web. From a product management perspective there are tons of requirements impacting the platform – ranging from enterprise multi-party communications to p2p video calling on bad networks and even streaming services. It’s a very challenging and exciting time, with so many opportunities to further evolve the product.

 

What metrics do you use to gauge WebRTC’s success?

We have very practical metrics like number of API requests and amount of media/data being consumed in Chrome from users that opt-in to share this data with us. From a product perspective, I like to measure the impact of the technology on the Internet. You are tracking for example the number of projects and services that build with WebRTC. The latest update I got from you was around 1200 projects and companies. I think this is a great metric reflecting the success of WebRTC and the impact we achieved by open sourcing it.

 

You recently made an announcement in discuss-webrtc around WebRTC 1.0. Why now?

We have reaching our goal of having all the standards defined, and the technology is now stable enough for everyone to use. The web-based RTC ecosystem is becoming mature as more and more services that build on top of WebRTC are getting massive reach.

With Chrome, Edge, Firefox and Safari supporting WebRTC, about 80% of all installed browsers globally have now WebRTC build in. This is a big milestone for us as we are achieving our initial goal of making audio and video available in all browsers, through a uniform standardized set of APIs. Additionally, formerly application-focused communication services are transitioning towards the Web platform and adopting WebRTC.

About 80% of all installed browsers globally have now WebRTC build in
Click To Tweet

We believe that interoperability between different WebRTC browsers is now of key importance to continue growing the adoption of WebRTC. It’s also of key importance to provide stability and a common ground to services and companies for continue growing a user base and eventually a flourishing business.

 

6 years in. What would you say worked great with WebRTC and what needs some improvement?

Our original mission to bring secure p2p real-time communication to the web has become real. This by itself is major contribution to the Web platform and the team is incredibly proud of this achievement. Our current efforts can be split into two main categories:

1. Finalize the specs in Chrome
2. Provide enterprise-grade reliability

We are working very hard on performance and to iron out remaining reliability issues in Chrome to make WebRTC the solution of choice for enterprise-grade communication services. These efforts address bugs like missing audio-input from the microphone or when the the camera is not detected. We are also getting close to launching a completely new echo canceller in Chrome for desktop. This should significantly improve the call quality when no headset is used on various devices. Additionally, we have major projects aiming at removing glitches in the audio and video capture and rendering processes. We are porting these time and resource critical processes to Mojo, a new process framework in Chrome. This will allow us to have a much better real-time performance in Chrome.

 

Looking 2 years ahead. What should we expect to see coming to WebRTC? AV1? Support for AR? …

Google is a founding member AOMedia and very active in defining the AV1 bitstream. Once AV1 is finalized we will start work on adding it to WebRTC. AR/VR/Mixed Reality is a completely new technology space with the potential to change how we consume services and media fundamentally. But the platform and overall product/market-fit is still unclear. But adding AR/VR functionality to WebRTC is definitely an interesting idea.

An interesting opportunity for evolving WebRTC is to replace RTP with QUIC. Experimenting with QUIC as media transport protocol could reduce the transport-layer protocol overhead and provide integrated congestion control. We also consider using QUIC for the DataChannel that is being used a lot by p2p CDNs for content distribution. Generally, we believe that there are still quite a few opportunities for reinventing real-time communications.

Looking a bit further ahead, a new mobile network generation (5G) is emerging. Which role WebRTC will play here still needs to be identified. But generally, having more bandwidth and lower latency available will open the door to explore video resolutions >4K and massive parallel connections. Additionally, having new software-defined networking functionality exposed to the application-layer seems to be an interesting option to improve real-time communication services. It will be very interesting to see the opportunities for WebRTC here.

 

During your time as the product manager of WebRTC at Google. What was the thing that surprised you the most?

I am still surprised every day by the creativity of developers building great services on top of WebRTC and the value those provide to users. A company called Qbtech, for example, uses WebRTC in a product that assess symptoms of ADHD. While traditional methods for assessing ADHD typically use subjective rating scales from physicians, Qbtech provides objective measurements by analyzing motion tracking over video. After implementing WebRTC, they went from specialized hardware to a web application that could run on a normal computer — opening up access to this technology to smaller clinics, schools, and even rural providers that might not have the resources for more specialized solutions.

Of course, there are many other great services that use WebRTC, but it’s this kind of out of the box thinking to apply WebRTC beyond its original audio/video calling use case and the value that is created by it that always surprises me.

How can developers contribute to WebRTC?

We have received thousands of user feedback reports and feature requests in the WebRTC and Chromium trackers from the growing WebRTC developer community. This feedback has been extremely valuable to improve WebRTC overall and especially to make it more stable for production usage. Generally, developers can provide feedback at bugs.webrtc.org by filing bugs or feature requests. And if you want to do more – you can become contributors and help us polishing the codebase – either as an individual or a company.

 

The post Google and WebRTC. An Interview with Niklas Blum appeared first on BlogGeek.me.

NanoPi NEO Plus2 is a brand new board released by FriendlyELEC. It’s slightly bigger than the NEO2 board, and packed with much more cool stuff: 1GB RAM, Wifi+Bluetooth module, and 8GB eMMC chip. It has also two USB2.0 port connected to independent USB controllers.

The NanoPi NEO Plus2 Basic Kit accompanies the board with an acrylic enclosure, and the first orders are delivered with an UART USB adapter. They also listed an antenna, but I did not receive it in my kit. Anyway I have a better option, a flat self-adhesive antenna like this one.

The acrylic enclosure is about two times thicker than that for NEO boards, and it also has a hole for antenna mount. I added 8 pieces of M2.5 washers and 4 M3 pillars to the original design, to make it more long-lasting. The photo below has the UART adapter plugged in.

Armbian still needs some work to be done to support this new board. But the Ubuntu image that is available from FriendlyELEC is quite enough to demonstrate all the hardware capabilities. Unlike Armbian, it does not mount /tmp and /var/log as tmpfs, so the SD card may experience a faster wearing.

Filed under: Hardware Tagged: arm, friendlyelec, linux

dSIPRouter is a web GUI that facilitates deploying Kamailio for SIP trunking services, developed by dOpensource.com and offered as open source on Github under Apache 2.0 license.It allows to manage the carriers and PBXes from a modern front end web GUI, built in Python. The application was developed for Kamailio 4.4.x series and tested mainly on CentOS.Several screen shots are presented in its documentation.Enjoy!Note: should you develop or are aware of any application that is related to Kamailio, do not hesitate to contact us, we will happily publish a news about it on kamailio.org.Thanks for flying Kamailio!

Are you sure you’re ready with your WebRTC product launch?

Here’s the thing. If you want to have a successful launch at the end of the project, you should focus on the planning phase in the beginning. Oh – and your plan should be different if you are going to self develop it all in-house or have the communication parts of it outsourced to external vendors.

Too often people contact me when they have already budgeted the project, spent the money, have a “product” in hand but it is lacking.

Two extreme cases recently:

1. A startup hired a development company who said they know WebRTC. They were so good that they said there is no need to use a media server for 8 participants in a session unless the session is being recorded (if you think that way too, then you are more than welcome to take my WebRTC course)
2. Another startup got delivered a finished product. Just to find out it didn’t even come with a TURN server

We see this even more at testRTC, where I am a co-founder. Companies come to us because they think the product a third party developed for them doesn’t work as expected, and too often it breaks in ways that are unacceptable (like stressing the service with 20 browsers).

The problem is finding these issues too late in the game, and paying dearly for them.

There are lots and lots of images out there that illustrate the issue. I’ll use the one from Raygun:

We can dispute the multipliers. They don’t really matter. But here’s how a typical WebRTC product with outsourced development takes place:

1. Someone writes down the requirements (amount of detail varies wildly here, and of course, you can use my requirements template)
2. He sends a few development companies the RFP. Mostly, these will be sent to local developers, but sometimes to other vendors as well
3. Once responses are back, he will pick one. Almost at random… (I know it isn’t random, but it will mostly lean towards cost, as the one in charge knows little in this domain anyway)
4. Now we wait. Just like placing a cake in the oven and waiting for it to cook. Once the big day arrives, the customer plays with what he gets back and finds out there are some holes in it. Areas left uncovered, or just an impression of poor media quality

Here’s the problem. Steps (1), (2) and (3) are the Design phase. And no one took any real ownership of it in this scenario.

Step (4) is probably Development,Testing and Staging. And they were all left to an outsourcing vendor. Who is most likely looking at this project from a cost perspective as well – but he doesn’t really care if this gets launched or not. Not really.

The customer got to step (5) immediately. With no milestones along the way. No checkpoints to see if everything is done correctly.

And please don’t sell me the story of agile development and how that will save the day for this customer. With agile he sees the “results” every week or two. In every sprint. But does he really know if that first Design phase was done properly?

Do you think you are getting a stable product that can scale to the millions (or even thousands) of users you plan on having? Are you sure your contractor feels the same way and didn’t build you a proof of concept instead?

Two things to do NOW about your WebRTC project:

#1 – Make sure you have a solid WebRTC architecture

Do you trust your vendor to build you the architecture you need?

Don’t.

You should do your homework or bring someone on “your side” that knows what he is doing.

Go now and look at the architecture you’ve been promised.

Take that architecture you’ve been given by the vendor and get a second opinion. It will be worth the time and effort.

#2 – Register to this free webinar

At testRTC we’ve decided to host a free webinar that deals with these issues exactly. And me? I decided to announce it here as well because I think it fits my readers AND it gets more people to know about testRTC, which is another thing I am a part of.

WebRTC: How NOT to Fail in Your BIG Launch

The webinar will take place on July 25 at 14:30 EDT.

It will be recorded and available for playback, so register now.

See you then!

 

The post Prepping for that Big WebRTC Product Launch appeared first on BlogGeek.me.

IvozProvider is a provider oriented multilevel IP telephony solution for use on public internet or private networks. It allows multiple access levels within the same infrastructure, from operator administrator to granular brand and company administrators as well as end user.Here is an excerpt from its presentation:“IvozProvider was designed always keeping in mind the horizontal scaling of each of its elements, so it can handle hundred of thousands concurrent calls and what is more important, adapt the platform resources to the expected service quality.”It relies on an handful of open source applications, including Kamailio, RTPEngine, Asterisk, MySQL or JsSIP.The project is available on Github at:

• https://github.com/irontec/ivozprovider

It has quite an extensive documentation online, offering several options for an easy install:

• https://irontec.github.io/ivozprovider/en/index.html

It is developed by Irontec, the company being another popular SIP-related project, respectively sngrep.

Time for someone to offer an updated view of the WebRTC Developer Tools Landscape.

Want to learn more about the WebRTC Developer Tools Landscape?

Register to my free Virtual Coffee session

As I am on vacation this week with my family (in Barcelona – ping me if you’re there this week and want to meet and say hi), I will keep this one short.

A few years back, Brad Bush of Genband released a WebRTC Landscape infographic. While he has updated it a couple of times, he since then stopped, leaving the WebRTC space altogether. His site was also lost in the abyss that is the Internet of un-renewed domain names, now hosting a Japanese website promising “services by married women” (Google’s translation).

I figured it was time to create another WebRTC Landscape infographic, but decided to be a bit more focused. Covering the whole WebRTC scene is rather hard, especially trying to do it on the first attempt. Which is why I decided to cover only the WebRTC Developer Tools Landscape in my infographic.

So without further ado, here it is:

I had to modify and update this twice already in the past few weeks – just to keep up with the changes in the industry (adding Safari and removing Tropo).

A few quick notes:

• Permanent, high resolution, updated version can be found here
• Need it as a PDF? Get it here
• Feel free to share this and use it where needed
• Did I miss you? Ping me and we’ll remedy that – I plan on updating this infographic every couple of months
• Want to learn more? There’s a free Virtual Coffee session next week that will be focused on this Infographic. Register now

See you next week in my Virtual Coffee

The post Introducing the WebRTC Developer Tools Landscape appeared first on BlogGeek.me.