News from Industry

Orange Pi Zero with 512MB RAM, expansion board and black case is sold for sub-$20, including postal costs, and it is so far the cheapest Linux device you can buy.

Armbian project provides a dedicated image for this board. The nightly build is quite stable, and there’s also legacy kernel which works well.

The computer is equipped with a 100/10 Ethernet NIC, and the top throughput that I could achieve was about 90Mbps.

The on-board WiFi adapter is of very poor quality: regardless of the antenna attached, it gives about 6Mbps connection speed and excessive packet loss (up to 20% lost pings). It’s useless for any practical application, and it’s easier to disable it completely.

The two USB ports on the expansion board are not enabled by default in the legacy kernel. You need to add the following line to /boot/armbianEnv.txt file, and reboot the box:

overlays=usbhost2 usbhost3

In order to disable the onboard WiFi, comment the top line, and add another line in /etc/modprobe.d/xradio_wlan.conf:

#options xradio_wlan macaddr=DC:44:6D:1F:3C:14 blacklist xradio_wlan

Then, run the following commands to update the kernel boot parameters:

depmod -ae update-initramfs -u

The onboard USB ports are not extremely fast: with an GigE or Wifi USB adapter, the maximum speed that I could achieve was about 40Mbps. But at least you get a stable and reliable connection.

The micro-USB OTG port is used for powering the device, and the board can freeze if the power consumption on USB ports is too big. For example, an external USB drive is very likely to knock the whole thing off.

Network Manager is installed by default by Armbian, and that allows easy plug-and-play WiFi configuration, adding new SSID and passwords from “nmcli” command-line interface.

All in all, it’s still quite a pretty device in a small enclosure. It can be used as a low-cost or throw-away network agent or VPN gateway for remote access. Also it can act as a measurement agent for all kinds of network testing, especially if you need a massive deployment and price difference is important.

Filed under: Networking Tagged: arm, linux, networking, wifi

It is today one month since the release of a new major version for Kamailio SIP server, respectively v5.0.0, one with a consistent set of new features and enhancements:

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

Among its brand new features is the ability to execute JavaScript (ECMAScript) code embedded inside kamailio.cfg script — this is possible via app_jsdt module. The module relies on DukTape JavaScript engine, which is imported in the Kamailio source code, therefore it has no external library dependency.It is also possible to use JavaScript to write entirely the SIP routing blocks for kamailio.cfg via KEMI framework, offering a more extensive language to control how next hop is selected. Next are the links showing such example:

• https://github.com/kamailio/kamailio/blob/master/misc/examples/kemi/kamailio-basic-kemi-jsdt.js
• https://github.com/kamailio/kamailio/blob/master/misc/examples/kemi/kamailio-basic-kemi.cfg

Among app_jsdt module features:

• can reload the routing functions without kamailio restart via an RPC command
• execute inline JavaScript within a native kamailio.cfg or write entire SIP routing blocks in JavaScript
• no external dependencies, it compiles with same tools and libraries as Kamailio core
• access to full scripting language constructs, expressions and statements, with extensive documentation, for building SIP routing language

More about configuration file engines for Kamailio 5.0 will be presented at the next Kamailio World Conference, May 8-10, 2017, in Berlin, Germany. See you there!

So you’ve been using WebRTC for a while, or even not at all. You might have checked out AppRTC or took a piece of code from github and forked it, running your own server (yay!). But now you’re feeling stuck, unable to become a serious WebRTC developer.

WebRTC developers come in different shapes and sizes. They usually have one of two origin stories:

1. They were VoIP developers 10 years ago (that can mean anything from played with the configuration of an Asterisk installation to wrote their own RTP stack)
2. They are web developers (which can easily be implementing WordPress sites on top of premium themes, but can just as well be building backends used by the Facebooks of the world)

The challenge though is that WebRTC sits somewhere between these two very different disciplines that are VoIP and Web:

Me? I’ve got a VoIP developer origin story. I wrote my own static memory, no-recursion implementation of an ASN.1 PER encoder/decoder. Dealt with scaling linearly a UDP/TCP sockets implementation on different operating systems. Handled multi-threading in C code. Low level stuff that most developers today don’t even grok. While these are great starting points, they don’t really offer any way of making the transition to WebRTC.

This isn’t about WebRTC. It is about understanding the different mindsets and approaches of developing VoIP products and developing Internet web applications. And it requires being able to learn new techniques and new ways of thinking.

While I won’t take you through that journey here, I can help you formulate a plan. In this article, we’ll explore together three things you can start doing today to make the jump from VoIP or Web to an experienced WebRTC developer.

What Don’t You Know?

The first thing you need to get a handle on is what you need to learn. Some might think that all you need to know to be a WebRTC developer is HTML, CSS, and a bit of JavaScript. Taking a github project that makes use of WebRTC, install and run it on your own. And you’re ready!

While that is certainly a good start, developing with WebRTC isn’t as easy as just learning a bit of JavaScript. Or Node.js for that matter.

To really call yourself a WebRTC developer, you’ll need to get a handle on a wide range of topics:

• WebRTC APIs: That’s quite an understandable requirement from a WebRTC developer
• Front-end development: HTML, CSS and JavaScript
• Backend development: Node.js or some other modern asynchronous development platform
• Networking: TCP, UDP, HTTP, WebSocket and anything in-between these concepts
• Codecs and media processing: How codecs are designed and implemented, what are the algorithms and techniques used to send them over a network – using SRTP. Extra credit for understanding Simulcast and SVC
• Server side media processing: Knowing the different techniques that can be used to support group calling, live broadcasts, recording, etc.
• Troubleshooting and monitoring tools: to include, at a minimum, how to read webrtc-internals dump files and understand ICE failures
• Common frameworks: know the popular frameworks that are out there and what they are good for. It doesn’t hurt to have some understanding of Jitsi, Kurento and Janus for example

With these skills and knowledge base in hand, you’ll be able to create virtually any real time communications product. That might seem like a lot to learn, but I want to share some resources below that you can use to learn about each of these topics relatively quickly. In addition, you don’t have to be an expert in every one of these topics, but as a WebRTC developer, you do need to have some basic familiarity with each and every one of these topics. I know I am not an expert in any of these…

Now that you know what you need to know, let’s look at the top three ways you can learn what you need to learn.

#1- Learn WebRTC Development by Reading Subscribing to WebRTC related blogs is one of the ways you can keep your development skills up-to-date

One of the best things you can do to grow in your knowledge about any topic is to read and follow along with posts and tutorials written by other experts in the industry. WebRTC is no different in this regard.

There aren’t many WebRTC blogs out there, but you’ll still want to focus to get maximum value here. Pick up just a few-quality blogs to follow. I try subscribing to ALL of them, mainly because it is my job to know as much as I can about the WebRTC market AND because I need to curate the WebRTC Weekly. What I do follow closely and make sure I read and understand when it comes to hard core WebRTC development amounts to just three main blogs:

• webrtcHacks: High quality content about WebRTC for developers. That sums it up…
• Mozilla’s Advancing WebRTC: Mozilla recently started a new blog dedicated to WebRTC. Quality there is top notch and the information is really useful. It covers small issues related to WebRTC and offers code snippets that are very useful
• Philipp Hancke: If there’s anyone who knows… everything (?) about WebRTC it is Philipp. He is methodical with his approach to WebRTC and analyzing browsers behavior. Every time he writes and publishes something, I end up learning at least one new thing
• WebRTC Weekly: Yap. I curate this one with Kranky. This one gives you the pulse of what’s happening with WebRTC, so following it can get you faster to the content that others are writing – especially those who don’t publish as much as I’d like them to

Pick a few blogs that you want to follow and subscribe to them. You don’t have to read everything they publish, but make sure that on a regular basis you read technical articles that stretch and challenge your developer muscles. That’s my approach here and I don’t consider myself a developer anymore. You probably take the next step as well and open a code editor and try the code snippets that the articles you read publish.

#2 – Learn WebRTC Development by Studying The Advanced WebRTC Architecture course offers a holistic view of WebRTC development

Reading about WenRTC is ongoing maintenance that you must do to keep up-to-date – especially because WebRTC changes all the time and there’s no solid specification out there just yet. To really develop new skills quickly some formal education is in order.

There are a couple of online courses about WebRTC out there that you can find. Those that I’ve seen focus on the WebRTC APIs piece which is great to start with WebRTC. The challenge though is that WebRTC is still not standardized, so things change to quickly for such content to be kept up to date.

Out of these courses, I guess there are two places where you can learn extensively about WebRTC:

• Google’s WebRTC Codelab: This was put by Google as an introductory course on using WebRTC. It will get you through the basic concepts of WebRTC with a fast time-to-results when it comes to getting a first simple proof of concept out there
• WebRTC School: The focus of the WebRTC classes of the WebRTC school is the WebRTC API and how to use it. For those who need to develop tomorrow with WebRTC directly, this is a great resource to begin with
• Advanced WebRTC Architecture: This is the course that I offer here on this site. I decided NOT to focus on the WebRTC APIs and just skim through them. I tried covering more of the backend part in my course and just getting students to a point where they can build their own product architectures with all of its backend glory
• Kranky Geek: for the visual types, I’d sugget checking out the topics curated by Kranky Geek (I am a part of that team). You’ll get high quality content there on specific topics in WebRTC development

Other than WebRTC, make sure to look at other courses as well – things around fullstack web development or Node.js development courses at the likes of Udemy, Codecademy or Pluralsight.

How about books?

I have a nagging feeling that goes with me for a few months now.

There hasn’t been any new book published about WebRTC in over a year.

I believe June 2015 was the last time a new WebRTC book got published.

Now, if reading and learning from books is still a thing for you, then check out this roundup of WebRTC books – it is still valid today as it were then.

Oh – and make sure you read High Performance Browser Networking if you are doing anything with web browsers (and especially if you are planning on using WebRTC and cobble up your own signaling).

#3 – Learn WebRTC Development by Doing Working and writing about your projects can further help cement what you read and learn about

Reading about WebRTC development will keep you sharp. Studying WebRTC development will help you develop new skills and give you solid understanding of the technology. But to really grow as a developer you’ve got to find opportunities to put all of that education to good use.

I can think of four different ways you can put your education to good use:

1. Build out personal projects – a blog, a personal portfolio, a hobby site. Create personal projects that really stretch you and that you’ll have to figure out as you go. I guess Muaz Khan does this best. I really liked how Brian Ho shared his experience recently on using WebRTC in a client-server web game
2. Build products for paying clients – You wouldn’t believe how many vendors are out there looking for capable hands when it comes to WebRTC development
3. Write about the new skills you’re learning and publish them on your own blog or better yet – submit it to webrtcHacks. There’s nothing that will ensure you really understand a topic like writing a tutorial about it
4. Become a WebRTC professional –  Once you have the requisite knowledge and a bit of experience, you might want to join a WebRTC outsourcing company that is actively building products with WebRTC. Here’s how Germán Goldenstein puts it – you really can’t ask for more than this as a developer. It reminded my what I love so much about developing and working with developers

What will you do tomorrow?

There’s a paradox in our industry.

For one, WebRTC is stupidly simple (if you compare it to doing the same things before WebRTC). But at the same time, there aren’t a lot of experienced developers out there that know how to use it. Talk to employers who are looking for WebRTC skills and you’ll see how hard it is to come by – most end up with using internal resources they grow into WebRTC developers – sometimes after a really bad experience with an external outsourcing vendor that knows how to build websites or mobile apps, but know nothing about WebRTC.

If you’re ready to move past copy+paste implementations from github of Hello World WebRTC concepts and become a real WebRTC developer. However, if you’re ready to mobe past implementation or hobby and become a real WebRTC developer all you need is a plan and the self-discipline to stick to it.

Your plan should include three core learning activities: reading, studying, and doing. Work on those three activities on a consistent basis and it won’t be long before you’ve left the hobby behind and grown into a WebRTC professional developer.

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

The post How to Get Started Learning WebRTC Development appeared first on BlogGeek.me.

A customer has its own PI range of public IP addresses, and they way to use part of this range in a remote office and place some servers there. The remote office is connected via some third-party ISP. So, the VPN tunnel should route the customer’s addresses and provide full Internet access to the remote office. Both sides should use Fortinet’s FortiGate firewalls.

It is quite natural to use a policy-based VPN for the remote side: the policy would match “all” destination addresses, and send all Internet traffic to the IPSec tunnel. But the central site is a firewall on a stick, so both Internet and IPSec traffic are going through the same wan1 interface.

Professional support at a local Fortinet partner gave an idea that I could not derive from any documentation: policy-based VPN and interface-based VPN can work together within the same IPSec tunnel.

So, the remote site is configured with policy-based VPN. The tunnel’s Phase 2 selector is 0.0.0.0/0.0.0.0 for both source and destination. The VPN policy matches all traffic from the local LAN addresses to “all”.

The central site is configured as interface-based VPN. The tunnel is pointing to a dynamic DNS endpoint, and the Phase 2 selector is also 0.0.0.0/0.0.0.0 (as it must match the selector on the other side of the tunnel). Then, it’s accomplished with in- and outbound policies that “ACCEPT” all traffic from and to the remote LAN, and a static route that sends all traffic toward remote LAN through the tunnel.

Filed under: Networking Tagged: ipsec

WebRTC, Chrome, Market share. These are all intertwined, but WebRTC isn’t the only reason Chrome is dominant today.

The nagging question about support of WebRTC in Internet Explorer and Safari refuse to go away. I hear them almost on a daily basis in meetings I have, emails I receive and posts I read. In recent months. Things being what they are for the past 5 years or so, I have decided to ask a slightly different question –

If a browser doesn’t support WebRTC – will it hurt the browser’s adoption?

My inclination until recently was that WebRTC doesn’t matter that much. It is a great technology, but it won’t really hurt the market share of browser vendors that decide not to adopt it wholeheartedly.

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

And then I read this story: Safari browser sheds users, mimicking IE

According to California-based analytics vendor Net Applications, in March 2015, an estimated 69% of all Mac owners used Safari to go online. But by last month, that number had dropped to 56%, a drop of 13 percentage points — representing a decline of nearly a fifth of the share of two years prior.

I took the liberty of using StatCounter for my own check, focusing on the desktop browser and operating system (mobile is different opera).

Here’s what you’ll find when you look from the beginning of 2012 and up until today – roughly the time frame of WebRTC’s existence:

What can we see here?

1. Edge starting to see “some” traction, but a lot less than what you’d expect. I’ve covered that one before
2. Internet Explorer is on the decline, with the bitter end already known
3. Firefox shedding users
4. Safari keeping in the 5% market share – we will get back to this one in a second
5. Chrome is the only browser that is increasing its market share, apparently grabbing it from all other browsers
6. If you think at WebRTC Chrome market share, I am sure numbers will look a lot more in favor of Chrome – and not only because Safari and IE don’t support WebRTC

Is Safari really keeping its market share or losing market share? To answer that question, we need to look at the desktop operating systems market share for that same period:

I’ll make it simple for you. In the past 5 years, OS X grew from around 7% to over 11%. That’s a growth of over 50% in its market share.

While at the same time, Safari, available only on OS X AND the default browser on OS X – didn’t grew in its market share.

Which means that people using Mac OS X are now more inclined towards using Chrome than they were 5 years ago.

Today, people CHOOSE their browser on the desktop and don’t use the default one provided to them by the operating system.

And when they choose, they more often than not pick Chrome.

I know:

• Statistics are just that, and it all depends on what you count – but there’s a trend here that is being counted through a long period of time that is hard to ignore
• It depends on regions, as there are areas who are still predominantly IE and countries with people who love Firefox

Why is Chrome our default browser these days?

This is a tough question to answer. For me, it is the one I am most comfortable with. Since I switched to it from Firefox years ago, I never looked back – and when I do – I just return back to Chrome.

If I had to estimate, it has to do with developers. It isn’t quite related to APIs, apps or the creation of developer ecosystems where innovation and value creation happens.

No. It is about developers as early adopters.

The people who spread the word and get their friends and family to switch browsers when things don’t work for them.

The people who end up building websites and working on them daily on… Chrome… which brings it all into a virtuous cycle, as now sites work better on Chrome, so you end up having more users use it, which means developers will target it first, increasing its popularity.

Google has done a lot to get it there. It started by making a lean and mean browser that had tabs crash independently of each other, and from there it grew with the set of rich developer tools it has and the technologies packed into it.

Other browsers have been trying recently to innovate as well, but it seems this haven’t caught on with the mainstream crowds just yet.

Is this a good thing?

Today, Chrome is the de facto standard for browser behavior.

There are other browsers as well, but their market share is declining – not growing or even stagnating. If this continues, Chrome will become the only play in town on the desktop.

This isn’t a good thing. It gives too much power in the hands of Google.

That said, Chrome is mostly open source (Chromium), it adheres to standards as much as can be expected from a product used by so many people daily.

But  they can change their minds at some point in the future.

On the other hand, we’re now all mobile, and there, the browser is a lot less important.

What does that mean for WebRTC?

as stated, Chrome is the de facto standard for browser behavior.

So much so that Edge is doing its best to look like a Chrome browser to developers, making it easier to interoperate with.

Should you develop based on the WebRTC specification? No.

You should develop based on what’s available in Chrome and what is planned for it in the mid term, as well as make use of adapter.js.

There’s the W3C flavor of WebRTC and then there’s the Chrome implementation of WebRTC.

Developers should stick to the Chrome implementation of WebRTC.

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 Does WebRTC has a Role in Chrome’s Market Dominance? appeared first on BlogGeek.me.

Is it finally the year of video? Who knows.

Up until recently, there wasn’t much out there for anyone who wanted to really use video in his use case. In the past few months we’ve seen so many announcements and moves that makes video as a service seem almost commonplace.

Who are these new and old players and what is it that they are doing in 2017?

TokBox

TokBox has been the main player when it comes to multiparty video with WebRTC. In 2012, they got acquired by Telefonica, but left as an independent entity. This gives them stability of sorts.

Their main competitor – AddLive – got acquired in 2014 and taken off market. Other vendors tried to enter that same niche, but no one caught on in the same way.

What’s interesting is the path that TokBox selected for itself. It is resisting the path of connecting to legacy directly. Their offering doesn’t include PSTN or phone numbers. On the other hand, they have been progressing and expanding their video support into broadcast.

Their recent announcement tells a story of large scale live broadcast:

1. 3,000 real-time interactive users. TokBox is probably achieving that by cascading their SFU infrastructure – not an easy feat by all means – especially if you consider the large variety of customers and the dynamics of sessions that they need to endure
2. Adding RTMP support. TokBox had HLS support already. HLS makes it easy to stream video, but doesn’t work well for live broadcasts. RTMP does a better job at that – and enables connecting to YouTube Live, Facebook Live and others

It seems that any type of workload that relates to real time and video is where TokBox is.

Twilio

Twilio is getting ready to become a serious video player.

In 2015, almost two years ago, Twilio came out with video chat capabilities. Since then, it stayed mostly in beta, with 1:1 video chat support only.

Last year, Twilio acquired Kurento (or at least some important parts of it along with the its developers). This acquisition of Kurento was about “programmable video” – the ability to do multiparty, but also much more. Last month? Twilio introduced a new Rooms API – a first step in offering multiparty video.

For Twilio, this is a catch-up game, trying to fit the many requirements of video. It starts with multiparty video, moves on to recording, then hybrid support of video/voice/telephony and from there to live broadcast and whoever knows what comes next.

In 2017, Twilio probably won’t be the best of breed solution for video, buy hey – if you’re already using them for voice and/or messaging – it makes sense to source video from the same vendor.

Vidyo.io

Vidyo.io is new to CPaaS but they are not new to video.

Vidyo have been working over a decade on video conferencing. Longer than other CPaaS vendors. They did that in the enterprise, offering multiparty video using SVC technology. This gave them an edge in media quality competing with enterprise video conferencing giants Cisco and Polycom at the time.

Now they are bringing this technology and their know how to the cloud and developers via Vidyo.io. And it doesn’t hurt that they are collaborating with Google on getting SVC into VP9…

They are also an enterprise player, which is where the action seems to be today for CPaaS.

One has to wonder how this is going to affect the other players in this space.

Others?

There are other players out there in CPaaS. Some offering video from the start while others adding it onto their voice offering. Notable names include Agora, TrueVoice and VoxImplant. Each with his own flavor. Each with his own story.

How big is this pond and is there room for so many players?

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.

Is this only about CPaaS?

While we’re on this topic, what about enablers? Vendors or frameworks who offer the ability to use WebRTC video in your own installation – cloud or on prem? There we had only Jitsi in the past, but now?

• We have Jitsi and Kurento as the leading open source frameworks
• There’s mediasoup and medooze, building SFUs
• There’s the Intel platform
• There’s SwitchRTC
• And FrozenMountain, who is working on their own multiparty offering

More choice than ever before?

Here’s the thing though… There is still no one-size-fits-all.

The post What’s up with WebRTC Video as a Service in 2017 appeared first on BlogGeek.me.

Chuwi Hi10 Protablet is sold for about $200 with an attachable keyboard, which makes it a potential candidate to replace my old Acer Aspire One and run Linux on it. It’s also equipped with a high-quality 10″, 1920×1200 IPS screen.

The tablet is based on Intel Atom x5-Z8350 CPU, which requires a fresh Linux kernel. So I started with pre-release of Lubuntu 17.04 (Zesty Zapus).

So far, out of the box:

• screen is oriented vertically, which makes it difficult to operate with the keyboard.
• Touchscreen, sound, Bluetooth, and Wifi are not visible to the kernel.

Solving the screen orientation:

In /etc/default/grub, edit the following setting:

GRUB_CMDLINE_LINUX="fbcon=rotate:1"

Then, add the following to make lightdm rotate the screen automatically:

cat >/etc/lightdm/chuwi_hi10_screen_orientation.sh <<'EOT' #!/bin/sh xrandr --orientation right EOT cat >/etc/lightdm/lightdm.conf.d/50_chuwi_hi10.conf <<'EOT' [SeatDefaults] display-setup-script=/etc/lightdm/chuwi_hi10_screen_orientation.sh EOT # this will apply the setting immediately: systemctl restart lightd

There is one bug though: for some reason, the display manager still thinks it’s the old resolution, e.g. 1920 on vertical resolution,  so all fonts look much smaller than they are, and window closing buttons are hardly visible. If I start lightdm without my customization and login, and then run “xrandr –orientation right”, all fonts and window controls are of normal size.

Windows recognizes the WiFi hardware as “Realtek RTL8723BS Wireless LAN 802.11n SDIO Network Adapter”, so I need to figure out how to make it work in Linux. This fix does not work with kernel 4.10.0-11 (bug is already filed: https://github.com/hadess/rtl8723bs/issues/119)

Filed under: Networking

Time for another refresh of my WebRTC CpaaS report.

Call it what you want – WebRTC PaaS, CPaaS, API Platform, Communication API – they all end up doing a couple of things for the industry:

1. Simplify and streamline the use of programmable communications that can be embedded virtually anywhere
2. Make use of WebRTC as one of their building blocks. Usually a significant one
3. Run in the cloud. Though not necessarily and not always

Today, I am launching the update of my Choosing a WebRTC API Platform report. It is now in its 6th edition with almost 4 years behind it already.

Before I begin – a thanks to my sponsor on this one

This time, I have a launch sponsor for the report – one of the new vendors that are profiled in it – Vidyo.

Vidyo launched recently CPaaS that enables you to embed real time video experiences into applications (here’s my recent analysis). While they are not the first in the market to do so, they bring with them some interesting SVC capabilities.

You can read more about SVC in this guest post by Alex Eleftheriadis – Chief Scientist & Co-founder of Vidyo.

SVC is a mechanism by which you can layer a video you are encoding in a way that allows peeling off the layers along the path the video takes – without needing to decode the video. This seemingly innocuous capability brings with it two very powerful capabilities:

1. Better multiparty conferencing routing and control – because we can now easily decide in our SFU/router which layers to send based on the dynamic conditions of the call (network, CPU, screen size, etc)
2. Better resiliency to bad network conditions – because we can take the lower layer(s) and add things like forward error correction to them to make them more resilient to packet losses (we can’t do it to all layers because that will just eat too much bandwidth)

That second capability is often forgotten – it is what can make or break great video experiences over things like WiFi or 4G networks.

SVC is starting to make its way into WebRTC, and you see developers tinkering with it. Vidyo has been at it longer than most, and have it boiled into their product. Vidyo already has SVC as an integrated part of their backend as well as their mobile and PC SDKs. When will that get enabled in their WebRTC part of the offering is a question to them, but you can assume it will have all the bells and whistles required.

Anyway, you can learn more about Vidyo.io in this report sample.

Why should you purchase this report?

This report will guide you through the process of deciding how to tackle the task of developing your product:

1. It explains what WebRTC is briefly, and reviews the WebRTC ecosystem actors
2. It lists the challenges you will face when developing products that make use of WebRTC
3. It explores the various approaches to develping WebRTC – anything from self-development up to full CPaaS
4. It shows you the key performance indicators that can guide you through your selection decision
5. It profiles all relevant WebRTC PaaS vendors to make the selection process simpler for you

Having this kind of information can reduce the risks of your project by enabling you to make a more informed decision.

What’s new in this report?

You still won’t find marketing BS in this one such as weird market sizing numbers going to billions of dollars or devices with estimates of 2030.

That said, there are 4 important changes I made to the report:

#1 – New Vendors

The main driver for these report updates are two: major changes in existing vendors (multiparty video support in Twilio for example) and new entrants to the market.

In this update, we have 3 new entrants to the market, and they are all interesting:

1. Agora.io, who are now adding WebRTC support to their platform
2. TrueVoice, started with 3D voice and are now introducing video capabilities
3. Vidyo.io, who are also sponsoring this report launch – check out there free profile (have I already mention that?)

I will be writing some more about the new video players in CPaaS next week.

#2 – Outlier Vendors

As time goes by, vendors and their products change and shift focus. Since my first release of the report this was bound to happen. Which is why I “migrated” some vendor profiles to a new section about outliers.

In some cases, you can use an outlier vendor instead of a CPaaS one, assuming your use cases fits what they have on sale. These vendors essentially cover a specific type of behavior (such as contact centers who offer visual assistance, or a click to dial consultation service for independent professionals). They might also target a very niche set of customers that just not fit what I am looking for in this report.

While they are SaaS companies in nature, they do have APIs and do offer some deep integration capabilities – and they are viable approaches to research for your product.

Two vendors who were profiled in this report in the past now find their home in this section:

1. Respoke by Digium, who now focus on Digium’s Asterisk customers and cater to their needs only
2. SightCall, who now focus on Visual Assist and no longer catre the more general purpose CPaaS market

#3 – Closed Platforms

And then there are platform vendors that got acquired, shut down or stopped catering for developers altogether. They were once profiled in the report, and are no longer with us.

They now have a whole section for themselves.

The reason I am not removing it? It isn’t due to sentiment. It is because this stuff is important. I believe that understanding the past and how these dynamics work will help make a better decision. It will give some more insights into the stability and trajectory of the “living” vendors in the report.

Whose gone to my deadpool section?

1. AddLive – they were acquired in 2014 by Snapchat (yes, that company with the successful IPO). They immediately closed their doors to new customers and are shuttering their whole API service this year
2. AT&T WebRTC Enhanced APIs – AT&T is still alive and kicking obviously. Their API developer platform is also active. But the WebRTC parts of it were shutdown. While no reason was given, it is probably due to low traction
3. ooVoo – they tried appealing for developers by opening up their existing platform. Just to shut this initiative down recently. I am assuming similar reasons to AT&T’s decision
4. OpenClove – I am not really sure what happened to them. The site is live, though copyright is from 2014. Up until last year, I got replies from my contacts there, but no more. There’s no indication if this is alive or dead, which is dead enough for me
5. Requestec – who got acquired by Blackboard and taken off the API market

Each vendor section here is frozen in time, at the last point of its update. Reasons for its death have been added.

Hopefully, future updates of this report won’t make this section grow any bigger.

#4 – Multiparty Explainer

It is 2017, and it seems that many of the WebRTC API Platform vendors are now offering multiparty support of one kind of another.

When it comes to video, there’s a variety of alternative technologies of getting there. These affect pricing, quality and flexibility of the solution. It was appropriate to add that as an additional factor in the report, which means that now, there’s a new appendix in the report giving an explanation of the differences between mesh, mixing, routing, simulcast and scalability.

The Timespan Aspect of the report

This is something I added in the previous update and just… updated again in this round.

When I got to updating the vendor profiles this time around, I found this addition really useful for myself – and I try to follow the industary and gauge its heartbeat on a daily basis.

This is a small section added at the end of each vendor’s profile, where I added an “investment” section – an indication of what did the vendor introduced to the market since the pervious report. This can really show what these vendors are focusing on for growth and are they in the process of pivoting out.

Take for example the investment section I have for SightCall:

Green indicates investment into the API platform. Yellow indicates some investment. White with no text means nothing to write home about. And red means defocus in investment – putting money in non-API activities.

In this case, it is understandable that after SightCall’s investment in its Visual Assist service (May 2016), which was probably successful for them, they pivoted out of the general API market. Which is also the reason there is no update for it in March 2017.

This this is now part of each vendor’s profile in the report, so you can now factor it in with your vendor selection process (I know I would).

How about the price of this report?

The report’s price is $1950 USD. That includes:

1. The written report (all 200+ pages of it)
2. Online vendor selection matrix to use for comparison purposes
3. Yearly updates – you’ll be elidgable to receive the next update of the report when it comes out

If you make your buy decision today, you’ll get a 35% discount by using the FASTMOVER coupon.

How do you do that?

Click to purchase the Premium package of the report.

Then on the shopping cart, make sure to indicate the coupon.

 

Prices go back up tomorrow at midnight, so better purchse this report now.

The post Check the Pulse of WebRTC and CPaaS in my Updated Report appeared first on BlogGeek.me.

The event structure of the Kamailio World 2017 (May 8-10, in Berlin) has been published along with a selection of the conference workshops and presentations. It is going to be agin a balanced content, combining sessions on how to use Kamailio, sharing knowledge on security and scalability as well as presentations about related tools and applications from the Real Time Communications area.You can see more details at:

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

Soon the first version of the schedule should become available, keep an eye on the event website!Thanks for flying Kamailio!

February 27, 2017: Kamailio v5.0.0 is out –  a new major release, bringing new features and improvements added during about seven months of development and one and a half month of testing.In short, this major release brings 6 new modules and enhancements to more than 50 existing modules, plus components of the core and internal libraries. Detailed release notes are available at:

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

This release brings an increase to major number, 5.0.0 to be the first in a series of 5.x.y versions. Among the relevant updates being the source code tree restructuring, the KEMI framework which allows writing the routing blocks in other embedded languages such as Lua, JavaScript or Python, and the removal of MI control framework (replaced by RPC).Enjoy SIP routing in a secure, flexible and easier way with Kamailio v5.0.0!Thank you for flying Kamailio and looking forward to meeting you at Kamailio World Conference 2017!

Who really knows?

Local or global for CPaaS?

In the past two months I’ve been conducting briefings with a lot of the CPaaS vendors out there. Some of them are now being added to my Choosing a WebRTC API Platform report that is getting a refresh next month.

During these chats, I came to realize a relatively lesser known type of CPaaS – the localized one.

To me, it was almost always about two types of players: you were either a “telco” or a global players. Telcos were based in their geography of operation, both limited and protected in their environment due to rules and regulations. Global players were the pure XaaS cloud vendors. I even created a nice graphic for that in 2013, comparing telcos to OTTs:

What we see now are mainly UCaaS vendors who are trying to join the CPaaS world. Put simply – vendors offering phone systems as a service to enterprises adding APIs for developers.

There are two reasons why these vendors are local in nature:

1. Their offering is still tethered to a phone number for the most part, making them a kin to the telco
2. They prefer it that way, probably because of where most/all of their business is taking place

For UCaaS, this localization might not a real issue. Corporations are still thinking locally, even the global ones. You work with people. And use phone numbers, so you tend to use the “law of the land” in every country. From how you allocate phone numbers to what exactly BYOD means at that country.

The problem starts when you want to serve one of two markets as your customers:

1. Large multinational coroporates, whose footprint is global
2. Small enterpreneurial teams who are spread out globally

That first one always existed. But I believe there are more of them today – smaller sized companies are reaching out globally, making them “multinatoinal corporations”.

The second? More of them as well, but probably focused on specific industries – high-tech comes to mind immediately.

What changes when moving to CPaaS while staying local?

First thing you’ll notice with these vendors, is that while they may be using AWS for their data centers and are offering WebRTC connectivity and VoIP, their distribution across AWS data centers ends up looking something like this:

This means that WebRTC calling is going to be affected – and not for the better. If I need to get a call going in France (2 people in Paris for example), then they get connected via US East – maybe even rounting their media through US East. Which lends itself to a bad user experience.

For UCaaS we might not care, as this would be an outlier – but for CPaaS?

The difference now is that we are API driven in what we do. We build processes around our company to offer programmatic communications. And these tend to be wider spread than the local mindset of corporate communications.

Are we using CPaaS to enable our customers to interact directly with each other? Are our customers as local as our own company is?

The end result

In most cases, the end result is simple. CPaaS is there as an API initiative for the UCaaS vendor.

As companies learn the importance and strength of integrations (see Slack and many of the new startups who offer B2B services and capabilities), they tend to offer APIs on top of their own infrastructure. One that their customers can use to integrate better. This makes CPaaS just that API layer.

In the same way that a movie rating company would offer an API that exposes its ratings, a UCaaS vendor exposes an API that enables communications – and then coins it CPaaS.

Only it may not really be CPaaS – just an API layer on top of his UCaaS offering.

The business models here are also different – they tend to be per seat and not per transaction. They tend to rely on the notion that the customer already paid for UCaaS, so no need to double dip when he uses CPaaS as long as he does that reasonably.

Does this make it any worse?

No.

It just makes it different, but still something you’d like to try out and see if it fits your needs.

–

Is this confusing? The whole UCaaS/CPaaS area is murky and mired with doubletalk and marketing speak. It is really hard to dig deeper and understand what you’re getting before trying it out.

 

Tomorrow I’ll be starting out a short series of emails about the decision making process of build vs buy – building a comms infrastructure versus adopting a CPaaS offering. If you aren’t subscribed to my newsletter, then you should subscribe now, as these emails will not be available here on the blog.

 

The post How Can Localized CPaaS Players Thrive? appeared first on BlogGeek.me.

While Windows may no longer be the default platform it was a decade ago it still has a huge and active community. More than 400 million devices support Windows 10 and there are many millions of .NET and Visual Studio users out there. In fact, I made my first WebRTC application in .NET using XSockets years ago. In […]

The post New Windows into WebRTC with UWP: Q&A with Microsoft’s James Cadd appeared first on webrtcHacks.

All paths lead to the enterprise.

My report was titled Choosing a WebRTC API Platform vendor. Later, I leaned towards calling it WebRTC PaaS. Last year, a new industry term starting to get used a lot – CPaaS – Communication Platform as a Service. These in many cases will include WebRTC, which leads me to call the vendors in my report CPaaS from time to time.

I am currently working on the 6th edition of my report. It has come a long way since it was first introduced. A theme that has grown over the years and especially in the past several months is the way vendors are vying towards the enterprise. It makes sense in a way.

Here are 3 different approaches CPaaS vendors are taking when they are targeting the enterprise.

#1 – Special Pricing

The current notion that WebRTC is free. This in turn leads vendors in this space towards a race to the bottom when it comes to pricing. This leads vendors to look at other alternatives, bringing them towards the enterprise.

Why?

Because enterprises are willing to pay. Maybe.

This special pricing for enterprise means they pay more for a package that may accomodate them a bit better.

Check out for example Twilio’s Enterprise Plan. It starts at $15,000/month, offering more control over the account – user roles, single sign on, events auditing, etc.

It is a great way to grow from the penny pinching game of all the platform users to some serious numbers. Only question is – would enterprises be willing to see the extra value and pay premium for it? I sure hope they do, otherwise, we may have a big problem.

#2 – Extending UCaaS to CPaaS

The second set of players viying for a place in the enterprise CPaaS game? The UCaaS players.

If you do UCaaS, Unified Communication as a Service, then you have an infrastructure already that can be leveraged for the use of CPaaS. Or at least the story says.

Who do we have here?

1. ooVoo, went from running a communication service towards a developer play (not an enterprise one mind you), only to shut it down later
2. Cisco Spark, coming up with its own API
3. Skype, looking at developers from time to time, trying to get their attention and then failing to give them the tools they need
4. Vonage, with its acquisition of Nexmo
5. RingCentral, adding a developer platform
6. Vidyo, to some extent, with VidyoCloud and Vidyo.io

The challenge here is the change in the nature of the business and the expectations of the customers. Developers aren’t IT. They have different decition processes, different values they live by. Selling to them is different.

#3 – Simplifying and Customizing

There are those who try to simplify things. They build widgets, modules and reference applications on top of their CPaaS. They customize it for the customer. They try to target customers who aren’t developers – assuming that enterprises lack the capacity and willingness to develop.

They augment that with system integrators they work with. Ones who speak and talk the language of the enterprise. Ones who can fill in all the integration gaps.

This is a slow process though. It is elephant hunting at its best – a slow process compared to the CPaaS game.

Where does this all lead us?

There is no one-size-fits-all.

No silver bullet for winning the enterprise.

But there are a few approaches out there that are worth looking at.

For me? I am just looking at it from the sideline and documenting this process. It is part of what gets captured in my upcoming WebRTC PaaS report – these changing dynamics. The new entrants, those who exist and the progress and change that others are experiencing.

 

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 When CPaaS Target Enterprises. 3 Different Approaches appeared first on BlogGeek.me.

Multi-party calling architectures are a common topic here at webrtcHacks, largely because group calling is widely needed but difficult to implement and understand. Most would agree Scalable Video Coding (SVC) is the most advanced, but the most complex multi-party calling architecture. To help explain how it works we have brought in not one, but two WebRTC video architecture experts. […]

The post Chrome’s WebRTC VP9 SVC Layer Cake: Sergio Garcia Murillo & Gustavo Garcia appeared first on webrtcHacks.

The first group of speakers at Kamailio World 2017 has been announced, you can see their details at:

• https://www.kamailioworld.com/k05/speakers/

The event takes place in Berlin, Germany, during May 8-10, 2017. There is still a large set of proposal under revision, more details about accepted one being scheduled to be published in the near future.This is the 5th edition of an event focused on realtime communications, besides the Kamailio project, you can meet there the people behind other popular open source projects such as Asterisk, FreeSwitch, Jitsi or SEMS, as well as other well known players from the industry.The event starts on Monday, May 8, around noon with technical tutorials, and continues for the next two days with conference sessions. The topics span from experiences on building and deploying typical VoIP services, to WebRTC, IoT and 4/5G technologies.Registration is open, don’t delay too long if you want to participate, the number of seats is limited:

• https://www.kamailioworld.com/k05/registration/

Looking forward to meeting many of you in Berlin!

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