News from Industry

Different people think differently when it comes to creating WebRTC apps (obvious? maybe).

I’ve seen it all. I talk almost daily with different stakeholders in companies that end up adopting WebRTC. A developer here. An enterpreneur there. A product manager. A marketing lady. A PR agency guy who knows shit about what he is promoting. A test engineer. An architect. The sales guy. You name it.

There’s a HUGE discount on my Choosing a WebRTC API Platform report now. And it is valid only until the end of this month. Why not grab your own copy of it?

If you go and ask the average Joe who is doing something with WebRTC how exactly does creating a WebRTC app, you’ll get one of 3 different answers. You see, at the end of the day, our small market can probably be pushed into 3 neat drawers, each representing a different school of thought. 3 different set of values and world views.

These worldviews can be found within the same industry niche, serving the same customer base, using similar business processes and user experiences, and yet each vendor will explain in detail why his way of creating that WebRTC app makes the most sense. And it does. It truely does.

I mostly agree with my buddy Chris Kranky who wrote about build vs buy of WebRTC apps last week. His approach is simple – why invest in your own infrastructure to cut down ridiculously low monthly plans of a CPaaS vendor? I see it as well with those approaching us at testRTC and then running away with cold sweat because they need to pay a 3 digits figure to stress test their product. But I digress.

Back to the schools of thought.

I think it is important to understand your own behavior and that of your team before moving fotward, as this may hinder your decision – or at the very least explain it. What you want to aim at here is to find a good match between your strategy and your team but also between your team and what you are trying to achieve. In many cases, I’ve seen failed attempts and increased risk because the choices made just didn’t make sense with the market realities.

It is similar to my article recently on a development path in WebRTC just looking at it from a slightly different angle.

Let’s see what these alternatives are:

#1 – The Tinkerers

“Look what I found in the Chromium Issue Tracker”

When it comes to WebRTC bugs, Tinkerers know the current bug status in the Chrome Issue Tracker by heart.

They want to build stuff with their own bare hands, sometimes forgoing even open source frameworks and doing things from scratch. Our industry has a few of these and their names are quite known (Fippo anyone?)

If you’ve got a real Tinkerer in your team, then you’re in great luck. There are few of them out there – and even fewer who understand what they talk about and how to make real use of WebRTC.

The main challenge here is that you need to have more than a single Tinkerer. If she leaves to work someplace else – what are you to do then?

There are teams of Tinkerers out there building great products with WebRTC. What is interesting, is that these are the teams that get acquired for the technology they end up with. These are AddLive, Screenhero, BlueJimp and to some extent even Beam.

#2 – The Owners

“How can I rely on someone else with my infrastructure? I must own it to be able to resolve issues and control my own destiny”

And still you go place your service in AWS.

Owners like to own stuff. They need control over it. They are just fine paying others to build it, but they want to own and control the finished product.

While I value ownership, I think it is something that needs to be questioned each and every time. Is that piece of technology really core to the business? Is it where innovation and barriers of entry to your market is found? If not, then you should probably rent and not own.

On the other end, ownership is sometimes necessary, and the reasons vary from case to case. Here are a few good ones I’ve heard:

• No CPaaS vendor covers our geography
• Regulation in our industry mandates it. Our own customers are “Owners” themselves
• We have this critical feature no one has that forced us into building our own infrastructure
• Our industry is crowded and competitive. We need any advantage we can get

#3 – The Dreamers

“Collectors of wood art need a place to meet”

I have a dream. And in my dream, I see an untapped market. A need that isn’t answered. I am clueless about the technology that gets me there, but I am sure that will solve itself.

Many of these around. Especially now that WebRTC is with us. The reason? WebRTC lowers the barrier of entry for new players. And the best way of getting there fast is by employing CPaaS.

The Dreamers focus on their target audience. That niche market, where a problem needs to be solved. In many cases, they come from that market.

A dancer with cancer, trying to find a place for women suffering from cancer to dance from home.

Psychologists building an online group therapy service.

Teachers building education services for a very specific target audience.

You’ll find these in the verticals – places where communications is a part of the service – a feature within another service.

To You Now

Did you find yourself in that list somewhere?

Are you a Dreamer trapped inside an Owner school of thought because of the limitations of CPaaS vendors?

Are you striving to be a Tinkerer but don’t have the workforce for it?

How are your intents and company DNA match with your school of thought?

I am seriously interested in it, so leave a commend or email me about it.

 

Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

 

The post The 3 Schools of Thought for Creating a WebRTC App appeared first on BlogGeek.me.

The GIT branch 5.0 has just been created for Kamailio source tree, it will host the release series 5.0.x. To get this branch from GIT, you can use: git clone https://github.com/kamailio/kamailio.git kamailio
cd kamailio
git checkout -b 5.0 origin/5.0Hopefully before the end of the month the full release of 5.0.0 will be out.From now on, any corresponding fix has to be pushed first to master branch and then cherry-picked to branch 5.0. No new features can get in branch 5.0. Enhancements to documentation or helping tools are still allowed.Thanks for flying Kamailio!

A very descriptive article has been published by voztovoice.org showing how to build a Least Cost Routing (LCR) system for IP telephony using Kamailio on CentOS 7. The article is in Spanish, Google translate being quite helpful, but the snippets of config and screens shots make it easier to understand over all.The article is available at:

• https://www.voztovoice.org/?q=node/1491

Whenever you write an article about using Kamailio or you become aware of a similar article, do not hesitate to notify us, we gladly publish a news about it.Looking forward to meeting many of you at Kamailio World Conference, May 8-10, 2017, in Berlin, Germany!Thanks for flying Kamailio!

Microsoft getting their act with WebRTC Edge support is far from a fashionable delay, saying more about the future of Edge than the future of WebRTC.

Want to run WebRTC on anything? Check out my free WebRTC Device Cheat Sheet.

Last week, Microsoft officially announced their intent to support WebRTC 1.0 (whatever that is exactly). I skimmed over that piece of news, but direct questions from a couple of my friends about my opinion, along with short chats with them on various messaging services made up my mind to actually write something about this.

Let’s begin from the end – nothing changed under the sun. Microsoft Edge supporting WebRTC is a non-starter for most.

Now for the details.

The Microsoft’s WebRTC Edge announcement

The title of the announcement? Introducing WebRTC 1.0 and interoperable real-time communications in Microsoft Edge. 1.0 surpasses interoperability in the title, while interoperability (with Chrome) surpasses anything else in that announcement.

• This release is still in beta, the Windows Insider Preview, making its way to a stable release in the upcoming Windows 10 Creator Update – taking place sometime in “Spring 2017” – somewhere in Q2
• It seems that this release won’t support the WebRTC data channel, as Microsoft is more interested in getting its Skype asset to work first – making Peer Connections and ineroperability a lot more important
• On the video side, the version supports both H.264 and VP8, making the old codec wars moot (until Apple decides to join the fray)

Microsoft is doing their damnest not to mention Chrome in the announcement – and they have succeeded. Barely. The annoucement mentions “video communications are now interoperable between Microsoft Edge and other major WebRTC browsers and RTC services”. I wonder who are these major WebRTC browsers. I wonder even more what “RTC services” means here. Maybe the ability to do a Facebook Messenger video call from an Edge browser to the Facebook Messenger iOS app?

They failed in not mentioning Chrome by mentioning specific bandwith estimation algorithm that Google is using: “Support for Google Receiver Estimated Maximum Bitrate, goog-remb”. I have to wonder how much legal fought over this one getting into an official blog post on Microsoft’s website.

The end result? Edge will soon have video interoperability support with Chrome and Firefox when it comes to WebRTC.

This is great, but it changes nothing.

Edge and Market Share

Somehow, a friend of mine actually thought Edge is a real thing. Until we started searching for recent market share indication. The most recent stats I publicly found are from November 2016, and they place Microsoft Edge at 5.21% – “Trailing Microsoft Edge was only Apple’s Safari browser, with 3.61%, and Opera with 1.36%.”

NetMarketShare places Edge even lower at only 4.52%:

Great.

While Windows 10 has grown in adoption, Edge hasn’t.

Things are now getting desparate. In my own Windows 10 laptop, Microsoft is now pushing “ads” about how Edge is faster than Chrome and how great it is – enticing me (unsuccessfuly) to try it out.

This is happening to everyone NOT using Edge apparently, with some suggesting how to stop this Microsoft pushing you to the Edge.

The Enterprise Urban Legend

Microsoft reigns supreme in enterprises. There’s no doubting that. But here’s the thing – the browser of choice there is Internet Explorer. Not Edge.

Many of these enterprises use Windows 7 today – NOT Windows 10. So the IT guy in the enterprise sees the following choices in front of him when he needs to decide on a major upgrade:

1. Switch to Windows 10
   • While doing that, continue using Internet Explorer 11
   • Or go for HTML5, and standardize around Chrome, Firefox, Edge – or all of them
   • There’s a hybrid option of IE11/Edge which isn’t that fun, and as far as I am aware, isn’t popular
2. Stay with Windows 7, but shift away from Internet Explorer 11
   • Microsoft’s Edge browser isn’t available there anyway, so that option is not possible
   • So you have to go for HTML5, and standardize around Chrome and Firefox

A smart IT person, will decide on a project that makes the switch in stages. Taking him to one of these two routes:

1. Switch to Windows 10; later switching to HTML5
2. Switch to Chrome/Firefox; later switching to Windows 10

The common denominator? Use Chrome/Firefox and NOT Edge. Which is why most end up forgoing Edge. That and the notorious reputation of IE that is tarnishing Edge.

From a friend who works in front of such large enterprises, I am told that most are asking either for Chrome/Firefox support or Windows 10 with… Chrome/Firefox support. There’s no requests coming in for the Edge browser.

In the enterprise, it is either IE11 or Chrome/Firefox these days.

What the Future Holds?

From day 1 of WebRTC, it seemed obvious that out of the oligopoly of 4 web browsers, two are going to be adopting WebRTC (Chrome and Firefox) and two will need to be dragged towards adoption (IE and Safari).

Microsoft decided to kill IE and focus on Edge. It also decided to throw the towel on ORTC and adopt WebRTC. The reasons are rather obvious – when you lack market share, you need to follow the trends. It tried taking the higher ground with the better ORTC design, only to fail and get back in line and now introducing WebRTC.

Apple… who knows? They hire people. They commit stuff into WebKit. They have people in the standards bodies. Will this mature enough in 2017 for an official release? Maybe. Probably. I just don’t know.

As always, before you make the decision on what to support – do an investigation of your target users and what they are using. You might be that outlier whose users are that 5% using Edge…

If you need WebRTC to work for you, you’ll need to understand how to get it running on any device and browser. My WebRTC Device Cheat Sheet is still as relevant as ever. It’s free, so go ahead and download it.

Get the cheet sheet

The post Microsoft and the WebRTC Edge Case appeared first on BlogGeek.me.

Here’s a sequence of commands in an ssh session to an ESXi host that creates a VM backup without interrupting its work. Of course it’s only a snapshot of the disk, so there may be corrupted files as a result. vmkfstools command requires full file path for the source and destination VMDK files.

# This lists all virtual machines and their IDs. # Further in this example, our VM is number 18 vim-cmd vmsvc/getallvms cd /vmfs/volumes/datastore1/VMNAME vim-cmd vmsvc/snapshot.create 18 mybackup mkdir /vmfs/volumes/nas1/backup/VMNAME vmkfstools -i VMNAME.vmdk /vmfs/volumes/nas1/backup/VMNAME/VMNAME.vmdk cp VMNAME.vmx /vmfs/volumes/nas1/backup/VMNAME/ vim-cmd vmsvc/snapshot.removeall 18
Filed under: Networking Tagged: vmware

The Kamailio & VoIP friends dinner at Fosdem 2017 is planned to start at 20:00, on Saturday, Feb 4, 2017. The address is:Le Pickwick
Avenue Adolphe Buyl 79
1050 Ixelles, Belgium

• https://en.yelp.be/biz/le-pickwick-ixelles

If you announced the intention to participate at the dinner before Feb 1, 2017, your seat is reserved. If you did it afterwards, please contact Daniel-Constantin Mierla during RTC Devroom to confirm the availability of the seats.

There’s an underlying theme to questions from those approaching me. They most often than not consider what to pick as their WebRTC development path.

Before we continue – there’s a huge discount on my WebRTC PaaS report this month – so make sure you don’t miss it.

–

About 10 years ago or so, a large LCD manufacturer came to the company I worked for. They wanted to build a monitor that has an embedded video conferencing endpoint in it. It was revolutionary at the time. Beautiful. Agressive. And we won the project. That was when the hard work started – we had to pick out a team to build it.

We had some of the best VoIP developers out there at the time. Our business unit licensed the technology to everyone and anyone who did anything with VoIP, so it made sense to self develop. And yet… we found ourselves hiring around 8 more developers for this project. All with skillsets different than the ones we already had. We were missing in the domain of media processing, codecs and hardware.

In almost any case, when it comes to WebRTC, the skillset you already have in place will not be exactly what is necessary to get the job done.

You will either have to hire the skillset, teach your current workforce new tricks or outright outsource the work.

Which means that when you start thinking about a product that needs real time communications, there are usually 2 routes you can pick when it comes to the WebRTC development part:

1. Use in-house developers
2. Use an outsourcing vendor

And in them, there are 2 additional aspects to decide upon:

1. Develop and maintain your own infrastructure
2. Use a 3rd party CPaaS

This all leads to the following WebRTC development matrix:

There are 4 classic development paths that I see companies take with their projects.

#1 – Hard Core

The Hard Core development model is all about control and core competencies.

At the extreme, these vendors will tend to “live off the land” and go as far as building their own SFU from scraps of code they cobble up around the web.

What they see as imperative in front of them is to be the best at communications – and to rely as little as possible on others.

For the most part, these would be companies with existing VoIP heritage who make the plunge towards a WebRTC project. At times though, they can be brand new to VoIP and for them, it starts as an adventure of sorts.

Another vendor type in this space would be the NIH type of a vendor. Where the Not Invented Here synrome is high, and trust on others to deliver what is needed is non-existent. These guys know better than everyone else how to put this type of an infrastructure in place and no explanation would deter them. Their best argument? CPaaS is too darn expensive when you start counting the minutes. And I already said – WebRTC is… free.

#2 – IT Project

The IT Project development model is about ownership.

The end game here, is to own the infrastructure and the data flow. Companies will tend to go to this approach if they have a regulatory issue they need to deal with (such as “data can’t travel out of the country”), a need to serve a specific geography (China for example) or special requirements that translates into the need of using their own infrastructure since others won’t support it (real time video analytics in the backend comes to mind).

As with the Hard Core players, they will be those who simply fancy the idea of ownership.

Why is this an IT Project then? Because an external outsourcing vendor is taken to develop it for the company. Usually because the internal workforce doesn’t have the experience, overbooked, or just more expensive.

#3 – Integrate

The Integrate develoment model is about getting things done.

You have the developers in place. They are already building your product/app/service/whatever. And you direct them to a CPaaS vendor of your choosing to work on top.

Why? Because communications isn’t your core business. Because it is cheaper. Because it gives you faster time to market. Have a pick of your reason for it – there are quite a few.

#4 – Agency

The Agency development model is about the dream.

You have a dream. You want to get it done. But you don’t really have the experience or the manpower. But you have some budget for it. What do you do?

Find and outsourcing vendor to build the product for you. Use CPaaS to work on top, so ongoing maintainance will be kept at a minimum if possible. And have that delivered to you.

Simple. If you pick the right outsourcing vendor. And the right CPaaS vendor. And the stars align just the right way to give you the luck needed in any development project.

How to choose your path?

I am in the process of updating and beefing up my WebRTC PaaS report, which is geared towards the vendor selection process of a CPaaS vendor. This time, I’ll be enhancing it to cover the IT Project, Agency and CPaaS quadrants.

Until I do, I am lowering down the price of the currently available WebRTC PaaS report from $1,950 down to $199. This should make it affordable to anyone who is planning on investing any kind of time or money in this space.

There are a few caveats:

1. This discount is available ONLY during February. The price will rise in March when the updated report is ready
2. The report will not include any of the extras – just the report itself
3. Specifically, it won’t come with any 1-year updates

Those who purchase the report now will be given a discount later on if they wish to go for the 1-year update package. Which means there’s nothing for you to lose when grabbing the report now at a huge discount.

Purchase the WebRTC PaaS report

 

The post How to Choose a WebRTC Development Path? appeared first on BlogGeek.me.

Making a CPaaS platform is not easy. Making one that is differentiated? That’s even harder.

Vidyo announced their new CPaaS called vidyo.io last week. It has been around for some time now – I covered it a couple of months ago on SearchUC – Vidyo migrating from enterprise video conferencing to video APIs. Now it is officially out, and I want to take a closer look at it.

Vidyo is/was an enterprise video conferencing company. Their focus throughout the years has been around software based solutions that make use of Scalable Video Coding – SVC. Its main competitors were probably Cisco, Polycom and Avaya – all operating in the same space.

But now, things are rather different. Vidyo has decided to go after two adjacencies at the same time – UCaaS as CPaaS:

• UCaaS – VidyoCloud offering a managed video conferencing service for the enterprise. A competitor to companies such as BlueJeans and Zoom (the latter just raised $100m at $1b valuation)
• CPaaS – vidyo.io offering an API for developers that does… video conferencing that can be embedded virtually everywhere

CPaaS isn’t something new. I have been covering the WebRTC part of it for quite some time in my own WebRTC PaaS report. And there are lots and lots of companies in that space already. So why bother with yet-another-one in 2017?

That’s a question for the vendors who join the market, but I’d say this. You can be one of two types of companies:

1. A direct competitor to Twilio, the jack of all trades when it comes to CPaaS. This means you’ll need to support anything and everything related to communications AND give developers a reason to use your platform instead of Twilio (good luck with that)
2. Become differentiated in a way that leaves developers no choice but to come to you. How do you do that? Beats me if I know. I just write here

Vidyo took the latter approach with vidyo.io, going for differentiation.

What is it that can make vidyo.io so enticing to developers and differentiate them from the crowd? Here’s what I came up with.

#1 – Razor focus on video

Vidyo does video. Not much more. There aren’t many players in this specific category besides maybe TokBox. ooVoo might be considered as another such player, at least to some extent.

This resistence to fill in the legacy gaps of voice and SMS probably isn’t an easy one. There’s a need to maintain a lead in the technology and the capability of the IP based video communications and at the same time believe that that lead is warranted and perceived by customers as an advantage.

Would you source your video from a second vendor or just take what Twilio or any other CPaaS player you’ve picked up for your phone calling do the video part for you as well? Maybe. Maybe not. Depending how critical video is for you and what features are you looking for. For mission critical applications such as healthcare, financial services or even customer engagement, you might not want to take the risk when you don’t have to.

#2 – Enterprise Savviness

Everyone wants to go after the enterprise these days.

Developers are hard to work with when it comes to developer tools:

1. They aren’t the ones controlling the budget, so hard to get them to pay
2. They are usually cheap in how much they are willing to pay
3. And that’s because they think they can develop what you have on their own. How hard can it be to take a FREE WebRTC thingy and turn it into a managed service?

Mitigating that gap with the longtail world of developers is hard. So once a platform goes there, it will usually try going upmarket to get enterprise customers. This is one of the reasons that Twilio launched an enterprise plan last year.

Vidyo comes from the enterprise world, boasting as its customers government agencies, financial institutes, healthcare providers and contact centers. In all cases, big names who adopted Vidyo technology in one way or the other to add video to their business needs.

#3 – SVC, in all its glory

There’s a notion that SVC is necessary for multiparty video conferences, and while the answer is that it is, SVC done right also improves video quality in mobile devices over error prone networks.

You see, SVC enables you to create different layers:

The sender sends all layers and the server then peels the layers it thinks are the best that can fit to the device they are intended for. So if we send to multiple devices – we can just fit for each device his own view at a lower cost to our server. Which is why SVC is so good for multiparty calls.

For mobile? If I can split a stream into several layers, I can decide to “protect” the lower more important layers by increasing their probability of being received. How do I do that? I add Forward Error Correction. This means you can improve video quality in really bad networks – Vidyo has that in their platform for quite some time, making it one of the few players today with WebRTC that can do that.

There’s a lot more to it than that, as Vidyo has been making use of SVC longer than anyone else out there in the industry. Vidyo is also the only CPaaS vendor in the market who offers that as far as I know. You can read more about it in their technology overview on vidyo.io.

Which brings us to the Google angle.

#4 – The Google angle

We’re now in a world of VP8 and H.264 in WebRTC. That’s the video codecs you see deployed in the market. Will this trend continue? Unlikely. Technology waits for no one. H.264 is old. Its first version was officially released in 2003. It has improved, but it is time to start the transition as an industry to a new video codec. VP8 was meant to be on par with H.264. Its successor is VP9 or H.265).

In all browser based WebRTC implementations we either already have VP9 support or will have VP9 support. And VP9 is where scalability will happen for WebRTC. A great deal of that is taking place by a cooperation between Google and Vidyo – one that I am not privy to.

The end result? Vidyo will probably have the first SVC-enabled video routing infrastructure that works with Chrome’s VP9 implementation. And this, in turn, can give Vidyo a huge headstart over other platforms.

Can Vidyo succeed with vidyo.io?

Yes. It will be a question of execution, as the path isn’t an easy one.

There are two challenges here that Vidyo is taking upon itself:

1. Migrating to the cloud, with its own business model challenges
2. Working with developers and selling a platform and not a product, which is a different ballgame with different rules of engagement

The first point is something that Vidyo has already committed to with VidyoCloud. It is a shift that is happening – with or without the developers angle. This means that management and shareholders are already bought into the cloud strategy and will have the patience to wait until Vidyo shifts and sees enough success in this “new” market.

The second point is where the real challenges will occur. There are different things that take place when you work with developers and on a managed service. Marketing works differently. Documentation and support are also handled differently. The sales processes are different. Vidyo will need to fill in these gaps and learn fast while maintaining its position in the enterprise. Being able to do that will mean being able to win more enterprise customers with vidyo.io

CPaaS Differentiation in 2017

As we enter 2016, differentiation in the CPaaS space will be important.

The notion of “cheaper than X” will not work. It leads to a price war where nobody wins. These managed services require scale, but the market is still new and nascent, so real scale isn’t here just yet for the most part. Reducing prices and going down to AWS levels make no sense. Especially if you consider the investment in ongoing development that is required in this market.

Vendors are finding their way in this market, each trying to differentiate and carve its own niche. Vidyo may well have found its own where their strength in multiparty quality over mobile can be a differentiator. Time will tell how successful they will be.

For developers? This is definitely a big win, as there are more alternatives on the table, with Vidyo joining in and adding their enterprise video tech into the mix.

 

Join me and Vidyo for a 2017 WebRTC State of the Market webinar - registration and attendance is free.

The post Vidyo.io and Differentiating in the Brave New CPaaS World appeared first on BlogGeek.me.

The registration for the 5th edition of Kamailio World Conference & Exhibition is now open! More details and registration forms are available on the website of the event [1].Like at the previous editions, the event spans over three days, May 8-10, 2017, taking place in Berlin, Germany. The first day contains the technical tutorials, the following two days are for conference presentations and exhibition.The Call For Speakers is still in progress, but we already have a consistent group of confirmed speakers, with a very good balance of new and returning presenters, among them: Allison Smith, the famous world wide IVR and Asterisk voice; Fred Posner, Kamailio’s USA-based heavyweight; James Body with the challenging Dangerous Demos; Randy Resnick, the founder of the weekly VoIP Users Conference podcast; Sandro Gauci, the author of SIP Vicious (aka SIP Friendly Scanner).As usual, expect a big group of Kamailio developers such as Alex Balashov, Carsten Bock, Olle E. Johansson, Andreas Granig, Victor Seva, Elena-Ramona Modroiu, Dragos Vingarzan, Daniel-Constantin Mierla as well as members of Asterisk and FreeSwitch projects.Keep an eye on the website of the event, soon we will publish more details about accepted speakers and the first draft of the agenda.Looking forward to meeting many of you in Berlin at Kamailio World 2017![1] – https://www.kamailioworld.com/k05/registration/

Yap. It is that time of the year for me.

In the past two months there have been lots and lots of summaries, predictions and even reports thrown around about different markets. That’s what you get at the passing of a year.

I had my share of such articles written recently as well:

• WebRTC market expected to see more gradual changes
• CPaaS and API trends: Forecasting the future of embedded communications

But it is now time for something that will become a tradition here I hope, which is the yearly WebRTC Start of the Market infographic. I did one last year, so why not this time around as well?

Yes. I know. This one is almost a month into 2017, and I’ve written 2017 and not 2016 on it. In a sense, it was about practicallity – we care about what comes next more than what happened. To some of us, 2016 is almost a long forgotten memory already.

About the Infographic

What’s different this year in the infographic?

1. I decided to have a sponsor, and Vidyo were kind enough t oblige and assist. As time pass, it is becoming increasingly difficult to collect and maintain all of my WebRTC dataset fresh, so having vendors pitch in and help make it worthwhile is great. So thanks!
2. It includes a webinar
   • Last year I had a private Virtual Coffee session on this topic to my customers
   • This year I am doing a public webinar with Vidyo about this topic and the findings

The Webinar

Vidyo and BlogGeek.me will be hosting a webinar on 2017 WebRTC Market Outlook. I’ll be joining Nicholas Reid, which will make this all the more fun (doing a webinar solo is… lonely).

We will be covering the various stats in the infographic, go over trends and see how we think they will develop into 2017. We will also discuss the just announced Vidyo.io CPaaS and see how it fits into this outlook.

2017 is bound to be interesting and dynamic, so join us.

2017 WebRTC Market Outlook

When? Tuesday, February 7, 2017; 3 pm eastern / noon pacific

Where? Online

The Numbers

• Over 1,100 vendors and projects using WebRTC, and just looking at the adoption numbers of January 2017, I can say we’re in for an interesting ride this year
• Largest markets using WebRTC? Customer Management and specific verticals (Healthcare and Education lead the way)
• Outsourcing vendors are cropping like mushrooms after the rain with growth of over 100% in 2016. With the pressure and challenge of finding experienced developers for WebRTC, it is no surprise that many outsourcing vendors are either adding WebRTC to their technology warchest or going all out and focusing in WebRTC projects
• Live streaming is going strong with 70% growth in 2016. This will continue into 2017 as well, taking a lot of the attention span of enterpreneurs in the social media space
• In CPaaS there are many ways to split the market. One of them, is by horizontal and vertical players. The dynamics here are truly fascinating, along with the acquisitions in this specific domain (Xura, Twilio and Sinch)

The Infographic

PDF | PNG

What’s next?

That’s the big question, and one I’ll be focusing on a lot this year.

Here’s what you can do next:

1. Register to the webinar and meet Nicholas and myself there
2. Subscribe to my newsletter, so you don’t miss out. Lots of interesting announcements coming soon

 

Thanks again for Vidyo for sponsoring this infographic.

The post WebRTC State of the Market 2017 appeared first on BlogGeek.me.

Ansible is a system for rapid deployment of services. Alberto Llamas has shared a link to his Ansible Kamailio Role that could be used as starting point for many people when deploying their Kamailio:

• https://galaxy.ansible.com/albertollamaso/Ansible-kamailio-role/

Over the time there were other people sharing similar resources, such as the one in the article:

• Kamailio HA with Ansible, Corosync and Pacemaker

We welcome any resource, blog post or tools that make it easier to deploy and work with Kamailio and gladly publish news about them. Should you have or know such resource, do not hesitate to contact Kamailio project!Thanks for flying Kamailio!

Kamailio SIP Server v4.4.5 stable is out – a minor release including fixes in code and documentation since v4.4.4. The configuration file and database schema compatibility is preserved, which means you don’t have to change anything to update.Kamailio v4.4.5 is based on the latest version of GIT branch 4.4. We recommend those running previous 4.4.x 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 v4.4 branch.Resources for Kamailio version 4.4.5Source tarballs are available at:

• http://www.kamailio.org/pub/kamailio/4.4.5/src/

Detailed changelog:

• http://www.kamailio.org/pub/kamailio/4.4.5/ChangeLog

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

• http://www.kamailio.org/pub/kamailio/4.4.5/

Modules’ documentation:

• http://www.kamailio.org/docs/modules/4.4.x/

What is new in 4.4.x release series is summarized in the announcement of v4.4.0:

• http://www.kamailio.org/w/kamailio-v4-4-0-release-notes/

We hope to meet many of you at the 5th edition of Kamailio World Conference, the project’s annual event, scheduled for May 8-10, 2017, in Berlin, Germany!Thanks for flying Kamailio!

If you think WebRTC is free, then think again.

WebRTC is free

I see it everyday and it is glaringly obvious. I probably haven’t made things any better myself with this slide of mine:

WebRTC is free. But lets consider what exactly is free with this technology:

1. The code. You can go download it from webrtc.org. And then… do with it whatever. It is licensed under BSD
2. The codecs used – and yes – I know – there are people who feel entitled to them through some patents – but no one yet cares about it – almost everyone assumes it is free and uses it – for now
3. It is readily available inside browsers. Well… at least some of them (Chrome, Firefox & Edge. Coming to Safari sometime)
4. And that’s a wrap

It is a hell of a lot to give for free. Especially if you went to sleep ten years ago and just woke up.

What’s missing in WebRTC?

But that’s only a small piece of the puzzle. Or as another slide in my deck usually states:

There are loads of things in WebRTC that you need to do in order to get a service to production. Here’s a shortlist of things that just came to mind:

1. Selecting and implementing singaling
2. Writing the application
3. Installing and deploying TURN servers (preferably at scale)
4. Adding media servers if needed – and making them work for your scenario
5. Testing it all
6. Monitoring it in production
7. Tweaking and upgrading as you go along

How do you fill in these gaps in WebRTC?

All these complementary solutions come in different shapes and sizes:

• Open source frameworks of various kinds you can use. Most will be half baked (=require more work to get them to production), or not exactly fit your needs
• Vendors offering consulting and outsourcing (check out a few of them in the WebRTC Index)
• Different vendors offering hosted and managed services. From signaling, to NAT traversal, testing & monitoring and complete CPaaS

The funny thing is, that whenever you talk to one of the companies developing with WebRTC, they believe everything in WebRTC should be free.

1. STUN servers? Free. There are lists of free STUN servers you can use
2. TURN servers? Free. Or more like “why can’t I find free TURN srevers?” (mind you – you should NEVER use free TURN servers)
3. Using a WebRTC PaaS vendor? That’s waaaay to expensive. We want to build it on our own to keep costs down

The thing is that building these things on your own will take time and money. Lots of both to be exact.

Same thing about how you end up testing it all or monitoring it. I’d say this is how the market looks like when it comes to testing WebRTC:

So what?

If you are planning a product that needs communications, you should definitely consider WebRTC first. Before anything else. It is probably going to be the cheapest technology for your needs but also the best one.

That said, you shouldn’t consider it all free. Plan it. Budget it. Write down your requirements. Decide on your architecture. Figure out who your partners should be in this road.

This is why I decided to start off the year with a giveaway. $1,000 worth of credits on VoxImplant. And all you have to do is signup for it. It just might get you started on your road with WebRTC. And who knows what will happen later on?

 

The post WebRTC is FREE. But Developers Aren’t appeared first on BlogGeek.me.

There are many situations within a day when the CPU fans are going crazy, being it some heavy loaded JavaScript site, compiling Kamailio or other applications. I was looking for tools, either open source or from "trusted?" sources that I can use to check the CPU temperature on my MacOS Sierra, but should work also on older MacOSX versions.

I ended up installing two applications, one command line tool and the other with GUI, both are free to use:

• iStats - open source cli - https://github.com/Chris911/iStats
• Intel (r) Power Gadget - GUI app - https://software.intel.com/en-us/articles/intel-power-gadget-20

iStats is open source, Ruby is already installed on Mac OS, so installing it is as simple as running in a terminal:
sudo gem install iStatsThen execute istats and you should see something like:


Besides the CPU temperature, it shows fan and battery stats.
Intel Power Gadget - not open source (or I missed the link to the repo), but it is free to use and made by the guys that manufacture the CPU, so I expect to get more accurate values. After installation, once you start it and let you run for a while, you should see something like:


It shows the usage of power by CPUs, along with frequency and temperature, tracking the history of the values and displaying the charts for them.
Hopefully this post will save some time for people looking for similar tools!

We are less than two weeks into 2017 and there are plenty of options in the short term to meet with Kamailio around the world:

• Kazoo (Cloud PBX incorporating Kamailio and Freeswitch) Training, Feb 1-3, San Francisco, CA, USA
• FOSDEM 2017, Feb 3-4, Brussels, Belgium – Olle E. Johansson (in RTC devroom) and Daniel-Constantin Mierla (in Lua devroom) will have presentations. Expect a large group of Kamailio friends around (more details soon)
• Asterisk World, Feb 8-10, Fort Lauderdale, FL, USA, with Fred Posner presenting about Kamailio and Asterisk
• SIP Masterclass by Edvina and Avanzada7 with Olle E. Johansson, Feb 20-23, Madrid, Spain
• Call Center World, Feb 21-23, Berlin, Germany
• Mobile World Congress, Feb 27-Mar 2, Barcelona, Spain – Quobis and other Kamailio folks will be there
• RTC Meetup Barcelona, Feb 28, Spain – coordinated by Victor Pascual Avila, usually packed with a consistent group of Kamailio friends
• Kamailio Advanced Training by Asipto with Daniel-Constantin Mierla, Mar 6-8, Berlin, Germany

An of course, don’t forget the Kamailio World Conference 2017, May 8-10, Berlin, Germany.If you are in the area of an event, but you don’t participate directly to it, just ask around in our forums, there might be group gatherings outside of them, such as dinners, meetups, … where anyone can join or simply people being there want to meet you. For discussions about these events, you can use our public mailing lists.If you organize or you are aware of events involving Kamailio, do not hesitate to contact us, we will gladly publish news about them.Looking forward to meeting many of you around the globe during 2017!Thanks for flying Kamailio!

If you got until here and haven’t entered your email yet, then you should definitely go back up.

I decided to kick off 2017 with a few interesting initiatives. And the first one is this giveaway – a first that I am doing on my website.

I’ve been following the CPaaS space for quite some time now, and have focused on WebRTC PaaS. CPaaS, PaaS and other XaaS acronyms are confusing. For the laymen, if you want to develop something that needs communication capabilities but don’t want to host the communication service itself – that’s what you end up using. And if this is your case, then why not try out one of the interesting vendors out there?

VoxImplant was kind enough to offer $1,000 in credits for one person.

To enter, all you need to do is place your email in the large giveaway box at the top – and that’s about it.

Be sure to share this giveaway with others using that URL you’ll be getting, as that will increase your chances of winning – and if enough people join the giveaway – will get you a nice bonus as well (even if you don’t win in this giveaway).

What do you have to lose?

Join now, and maybe it will get you a bit faster to your application goal with the help of VoxImplant.

The post Jumpstart Your WebRTC Development with $1000 on VoxImplant appeared first on BlogGeek.me.

With a rather busy end of 2016, several additions to Kamailio missed the chance to get into the news as they were imported in the repository. Now it’s time to catch up with some of them, given that development is frozen and the focus is on testing master branch in order to prepare the v5.0.0 release.One of the new modules that will make it into v5.0.0 is named ims_ocs. As the prefix suggests is related to Internet Multimedia Subsystem (aka IMS), the core platform for 4G/VoLTE mobile networks. More specifically, it is an implementation of a simple Online Charging Server, communicating with ims_charging module via Diameter-Ro interface.The module was developed by the folks at NG Voice, led by Carsten Bock. More details about the module can be found in its readme docs:

• http://kamailio.org/docs/modules/devel/modules/ims_ocs.html

Stay tuned for more news about what’s new in upcoming Kamailio v5.0.0!Thanks for flying Kamailio!

On Wednesday, January 11, 2017, at 18:00UTC (12:00CT, 18:00 London, 19:00 Berlin), the Cluecon weekly conference call will focus again on Kamailio and FreeSwitch. Daniel-Constantin Mierla will be joining the call, presenting what is new in latest Kamailio, what to expect at Kamailio World Conference 2017, answering the questions about Kamailio and its options to integrate with FreeSwitch. Expect the FreeSwitch core developers to be around to handle the questions about their project.Participation is open for anyone, you can dial in for audio or video sessions using a SIP phone or webrtc capable browser:

• sip:888@conference.freeswitch.org
• https://conference.freeswitch.org/vc (WebRTC Enabled voice and video, call 888 once you are logged in)

More dial in options (PSTN) are presented at:

• https://freeswitch.org/confluence/display/FREESWITCH/ClueCon+Weekly+Conference+call

Thanks for flying Kamailio!

Submission of presentation proposals for Kamailio World 2017 is open. Deadline for submission is February 10, 2017, notification of accepted proposals will be done latest on March 01, 2017.Be aware that interesting proposals can be accepted before the deadline, we plan to have two intermediate review sessions before February 10, 2017, announcing any accepted presentations immediately. Note also that at the previous edition there were more proposals than available slots and we expect to happen again this time. Therefore it is recommended to send your proposal as soon as possible, do not wait till deadline.To submit the proposal, fill in the web form at:

• https://www.kamailioworld.com/k05/call-for-speakers/

The main topic of the conference is Real Time Communications, with the majority of the content being about Kamailio and other open source projects in the area. However, like for the past editions, we welcome very interesting presentations beyond those subjects.If you are interested to look at the agenda from previous edition, visit:

• https://www.kamailioworld.com/k04/schedule/

Have a great 2017! Looking forward to meeting many of you at the next Kamailio World!

How many WebRTC RTCPeerConnection objects should we be aiming for?

This is something that bothered me in recent weeks during some analysis we’ve done for a specific customer at testRTC.

It all started when a customer using Tokbox came to us. He was complaining he couldn’t get the product he built stabilized enough and due to that, couldn’t really get it launched. The reason behind it was partially his inability to decide how many users in parallel can fit into a single session.

So we took that as a side project at testRTC. It is rather easy for us to get 50, 100, 200 or more browsers to direct towards a single service and session and get the analysis we need. So it was easy to use once we’ve written the script necessary. While we have Tokbox customers using our platform, I never did try to go deeper into the analysis until now for such customers. This time, it was part of what the customer expected of us, so it got me looking closer at Tokbox and how they implement multiparty sessions.

In the past couple of weeks we’ve done our digging and got to conclusions of our own. I haven’t meant to write about them here, but a recent question on Stack Overflow compelled me to do so – Maximum number of RTCPeerConnection:

I know web browsers have a limit on the amount of simultaneous http requests etc. But is there also a limit on the amount of open RTCPeerConnection’s a web page can have?

And somewhat related: RTCPeerConnection allows to send multiple streams over 1 connection. What would be the trade-offs between combining multiple streams in 1 connection or setting up multiple connections (e.g. 1 for each stream)?

The answer I wrote there, slightly modified is this one:

Not sure about the limit. It was around 256, though I heard it was increased. If you try to open up such peer connections in a tight loop – Chrome will crash. You should also not assume the same limit on all browsers anyway.

Multiple RTCPeerConnection objects are great:

• They are easy to add and remove, so offer a higher degree of flexibility when joining or leaving a group call
  They can be connected to different destinations

That said, they have their own challenges and overheads:

• Each RTCPeerConnection carries its own NAT configuration – so STUN and TURN bindings and traffic takes place in parallel across RTCPeerConnection objects even if they get connected to the same entity (an SFU for example). This overhead is one of local resources like memory and CPU as well as network traffic (not huge overhead, but it is there to deal with)
• They clutter your webrtc-internals view on Chrome with multiple tabs (a matter of taste), and SSRC might have the same values between them, making them a bit harder to trace and debug (again, a matter of taste)

A single RTCPeerConnection object suffers from having to renegotiate it all whenever someone needs to be added to the list (or removed).

I’d like to take a step further here in the explanation and show a bit of the analysis. To that end, I am going to use the following:

1. testRTC – the service I’ll use to collect the information, visualize and analyze it
2. Tokbox’ Opentok demo – Tokbox demo, running a multiparty video call, and using a single RTCPeerConnection per user
3. Jitsi meet demo/service – Jitsi Videobridge service, running a multiparty video, and using a shared RTCPeerConnection for all users

If you rather consume your data from a slidedeck, then I’ve made a short one for you – explaining the RTCPeerConnection count issue. You can download the deck here.

But first things first. What’s the relationship between these multiparty video services and RTCPeerConnection count?

WebRTC RTCPeerConnection and a multiparty video service

While the question on Stack Overflow can relate to many issues (such as P2P CDN technology), the context I want to look at it here is video conferencing that uses the SFU model.

The illustration above shows a video conferencing between 5 participants. I’ve “taken the liberty” of picking it up from my Advanced WebRTC Architecture Course.

What happens here is that each participant in the session is sending a single media stream and receiving 4 media streams for the other participants. These media streams all get routed through the SFU – the box in the middle.

So. Should the SFU box create 4 RTCPeerConnection objects in front of each participant, each such object holding the media of one of the other participants, or should it just cram all media streams into a single RTCPeerConnection in front of each participant?

Let’s start from the end: both options will work just fine. But each has its advantages and shortcomings.

Opentok: RTCPeerConnection per user

If you are following the series of articles Fippo wrote with me on testRTC about how to read webrtc-internals, then you should know a thing or two about its analysis.

Here’s how that session looks like when I join on my own and get testRTC to add the 4 additional participants into the room:

Here’s a quick screenshot of the webrtc-internals tab when used in a 5-way video call on the Opentok demo:

One thing that should pop up by now (especially with them green squares I’ve added) – TokBox’ Opentok uses a strategy of one RTCPeerConnection per user.

One of these tabs in the green squares is the outgoing media streams from my own browser while the other four are incoming media streams from the testRTC browser probes that are aggregated and routed through the TokBox SFU.

To understand the effect of having open RTCPeerConnections that aren’t used, I’ve ran the same test scenario again, but this time, I had all participants mute their outgoing media streams. This is how the session looked like:

To achieve that with the Opentok demo, I had to use a combination of the onscreen mute audio button and having all participants mute their video when they join. So I added the following lines to the testRTC script – practically clicking on the relevant video mute button on the UI:

After this most engaging session, I looked at the webrtc-internals dump that testRTC collected for one of the participants.

Let’s start with what testRTC has to offer immediately by looking at the high level graphs of one of the probes that participated in this session:

1. There is no incoming data on the channels
2. There is some out going media, though quite low when it comes to bitrate

What we will be doing, is ignore the outgoing media and focus on the incoming one only. Remember – this is Opentok, so we have 5 peer connections here: 1 outgoing, 4 incoming.

A few things to note about Opentok:

1. Opentok uses BUNDLE and rtcp-mux, so the audio and video share the same connection. This is rather typical of WebRTC services
2. Opentok “randomly” picks SSRC values to be numbered 1, 2, … – probably to make it easy to debug
3. Since each stream goes on a different peer connection, there will be one Conn-audio-1-0 in each session – the differences between them will be the indexed SSRC values.

For this test run that I did, I had “Conn-audio-1-0 (connection 363-1)” up to “Conn-audio-1-0 (connection 363-5)”. The first one is the sender and the rest are our 4 receivers. Since we are interested here in what happens in a muted peer connection, we will look into “Conn-audio-1-0 (connection 363-2)”. You can assume the rest are practically the same.

Here’s what the testRTC advanced graphs had to show for it:

I removed some of the information to show these two lines – the yellow one showing responsesReceived and the orange one showing requestsReceived. These are STUN related messages. On a peer connection where there’s no real incoming media of any type. That’s almost 120 incoming STUN related messages in total for a span of 3 minutes. As we have 4 such peer connections that are receive only and silent – we get to roughly 480 incoming STUN related messages for the 3 minutes of this session – 160 incoming messages a minute – 2-3 incoming messages a second. Multiply the number by 2 so we include also the outgoing STUN messages and you get this nice picture.

There’s an overhead for a peer connection. It comes in the form of keeping that peer connection open and running for a rainy day. And that is costing us:

• Network
  • Some small amount of bitrate for STUN messages
  • Maybe some RTCP messages going back and forth for reporting purposes – I wasn’t able to see them in this streams, but I bet you’d find them with Wireshark (I just personally hate using that tool. Never liked it)
  • This means we pay extra on the network for maintenance instead of using it for our media
• Processing
  • That’s CPU and memory
  • We need to somewhere maintain that information in memory and then work with it at all times
  • Not much, but it adds up the larger the session is going to be

Now, this overhead is low. 2-3 incoming messages a second is something we shouldn’t fret about when we get around 50 incoming audio packets a second. But it can add up. I got to notice this when a customer at testRTC wanted to have 50 or more peer connections with only a few of them active (the rest muted). It got kinda crowded. Oh – and it crashed Chrome quite a lot.

Jitsi Videobridge: Shared RTCPeerConnection

Now that we know how a 5-way video call looks like on Opentok, let’s see how it looks like with the Jitsi Videobridge.

For this, I again “hired” the help of testRTC and got a simple test script to bring 4 additional browsers into a Jitsi meeting room that I joined with my own laptop. The layout is somewhat different and resembles the Google Hangouts layout more:

What we are interested here is actually the peer connections. Here’s what we get in webrtc-internals:

A single peer connection for all incoming media channels.

And again, as with the TokBox option – I’ll mute the video. For that purpose, I’ll need to get the participants to mute their media “voluntarily”, which is easy to achieve by a change in the testRTC script:

What I did was just was instruct each of my automated testRTC friends that are joining Jitsi to immediately mute their camera and microphone by clicking the relevant on-screen buttons based on their HTML id tags (#toolbar_button_mute and #toolbar_button_camera), causing them to send no media over the network towards the Jitsi Videobridge.

To some extent, we ended up with the same boring user experience as we did with the Opentok demo: a 5-way video call with everyone muted and no one sending any media on the network.

Let’s see if we can notice some differences by diving into the webrtc-internals data.

A few things we can see here:

• Jitsi Videobridge has 5 incoming video and audio channels instead of 4. Jitsi reserves and pre-opens an extra channel for future use of screen sharing
• Bitrates are 0, so all is quiet and muted
• Remeber that all channels here share a single peer connection

To make sure we’ve handled this properly, here’s a view of the video channels’ bitrate values:

There’s the obvious initial spike – that’s the time it took us to mute the channels at the beginning of the session. Other than that, it is all quiet.

Now here’s the thing – when we look at the active connection, it doesn’t look much different than the ones we’ve seen in Opentok:

We end up with 140 incoming messages for the span of 3 minutes – but we don’t multiply it by 4 or 5. This happens once for ALL media channels.

Shared or per user RCTPeerConnection?

This is a tough question.

A single RTCPeerConnection means less overhead on the network and the browser resources. But it has its drawbacks. When someone needs to join or leave, there’s a need to somehow renegotiate the session – for everyone. And there’s also the extra complexity of writing the code itself and debugging it.

With multiple RTCPeerConnection we’ve got a lot more flexibility, since the sessions are now independent – each encapsulated in its own RTCPeerConnection. On the other hand, there’s this overhead we’re incurring.

Here’s a quick table to summarize the differences:

What’s Next?

Here’s what we did:

1. We selected two seemingly “identical” services
   • The free Jitsi Videobridge service and the Opektok demo
   • We focused on doing a 5-way video session – the same one in both
   • We searched for differences: Opentok had 5 RTCPeerConnections whereas Jitsi had 1 RTCPeerConnection
2. We then used testRTC to define the test scripts and run our scenario
   • Have 4 testRTC browser probes join the session
   • Have them mute themselves
   • Have me join as another participant from my own laptop into the session
   • Run the scenario and collect the data
3. Looked into the statistics to see what happens
   • Saw the overhead of the peer connection

I have only scratched the surface here: There are other issues at play – creating a RTCPeerConnection is a traumatic event. When I grew up, I was told connecting TCP is hellish due to its 3-way handshake. RTCPeerConnection is a lot more time consuming and energy consuming than a TCP 3-way handshake and it involves additional players (STUN and TURN servers).

Rather consume your information from a slidedeck? Or have it shared/printed with others in your office? You can download the RTCPeerConnection count deck here.

 

The post WebRTC RTCPeerConnection. One to rule them all, or one per stream? appeared first on BlogGeek.me.