News from Industry

This demo of the Microsoft Surface Hub 2 is pretty damn cool…

I don’t run a lot of Microsoft product anymore, switched to mac when the intel chip landed + Apple moved to a unix underpinning. That said, I have seen much better quality in products coming from Microsoft in the last few years, so maybe they deserve a second look.

Surface Hub 2 sort of reminds me of a product called Perch, built a by a local Vancouver team which was meant to serve as a portal into disparate global offices. Perch was way before it’s time. WebRTC was still in its infancy and personal device video conferencing had not really crossed the chasm, which is a shame considering where we are today.

Now there are many of video conferencing companies and products, and plenty of alternatives / platforms for developers to build on. It certainly seems plausible now that we could see the Microsoft Surface Hub 2 in boardrooms across the globe. Apparently it will be interoperable with WebRTC endpoints as well, which could make this a powerful work tool indeed. That would enable collaboration with peers over IP on various endpoints including laptops, tablets and mobile, regardless of the OS. Sharing product ideas, riffing on concepts and polishing final features on a product release using the Microsoft Surface Hub 2 as a tool, could be a refreshing new way to work.

It will be interesting to see what developments come about from the Microsoft press event in NYC in April, as reported by The Verge.

 

I haven’t blogged here in some time, so I figured that since the topic is relevant this would be good a good opportunity to dust off the old blog (webrtc.is / sipthat.com) and post something we have been working on at SignalWire. I am quite passionate about WebRTC and real-time communications so it’s great to be helping bring it to life at SignalWire!

We all know and love <cough> SIP, so we decided we would enable the use of SIP over WebSockets at SignalWire. This new offer also enables functionality like WebRTC with SIP over WebSockets.

This means our customers can now use off the shelf JS libraries, like JSSIP to create basic web experiences for their users, powered by SignalWire. It used to be a bit of a PITA, to create services that provided users with seamless online communications. Now it’s a breeze, and when using SignalWire it’s also very affordable.

For now, we are enabling basic calling and video capabilities, the advanced functionality (including video conferencing) will come in conjunction with a future release of a SignalWire RELAY JS library.

Personally, I can’t wait to see what creative minds will build using this technology with SignalWire on the backend.

If you want to know more about SignalWire’s new WebRTC + SIP over WebSockets offer, you can read about it on the SignalWire product blog.

WebRTC doesn’t really connect people, but the way you think about it signaling is important to your WebRTC application.

Here’s a comment left on one of my recent articles:

WebRTC is… still just a little confusing…Tsahi, i’m reading the book recommended by Loreto & Romano but the examples are outdated. With regards to the SDP signal – if peer A is on a webRTC application, but peer B is surfing youtube – How does peer B get notified of an offer? It would have to go to peer B’s email address right? — because there is no way of knowing peer B’s IP address. Please help.

A few quick things before I dig deeper into this WebRTC connectivity thing:

• Yap. WebRTC is a little confusing. Maybe even a lot. It doesn’t behave like any other browser technology we have
• The sad thing about books about WebRTC is that they didn’t age all too well. WebRTC still changes too fast
• There’s some confusion here in wording – peers, offer, etc.

How well do you know WebRTC? Check it out in my online WebRTC quiz.

Take the WebRTC quiz

Connecting, Signaling and WebRTC

I’ll try to use a kind of a bad comparison here to try to explain this.

Let’s say you are the proud owners of a Pilates studio. You’re the instructor there (#truestory – at least for my wife).

My wife gives Pilates lessons at different hours of the day. These are private lessons so it is rather flexible on both sides. But let me ask you this – how do people know when to come for a lesson?

This being Israel, they usually communicate with my wife via Whatsapp to decide together on the date and time. Usually, people stick to the day of week and time and start communicating only if they can’t make it, want to reschedule or just make sure the lesson is still taking place.

Back to WebRTC.

WebRTC is that Pilates studio. It does one thing – enables live media to flow from one browser to another. Sometimes also non-browsers, but let’s stick to the basics here.

How do the people who need to share or receive that live media connect to each other? That’s not what WebRTC does – it happens somewhere else. And that somewhere is the signaling mechanism that you pick for your own application. I am calling it a mechanism and not a protocol, since it is going to be a tad more confusing in a second.

Or not.

Now let’s go back to WebRTC, signaling and connecting people and look at it from a point of view of different scenarios.

Scheduled Meeting

We’ll start with a scheduled meeting. At any given point in time, I have a few of those coming up. Meetings with clients, partners and potential clients. Here’s one such calendar invitation:

This one happens to take place using Google Meet. Who’s calling who? No one really. I’ll just click that link in the invite when the time comes and magically find myself in the same conference with the other participants.

In most scheduled conferences, you just join a WebRTC link

Where do you get that link to use?

• Inside the calendar invite
• In an email that was sent
• Through an SMS reminder

Some of these services allow inviting people from inside the meeting. That ends up being sent to them via email or an SMS as a link or just dialing their phone (without WebRTC).

Ad-hoc “upgrade” of text chat to video conference

There are ad-hoc calls. These usually start from a chat message.

Often times, I’d rather text chat than do a voice or a video call. It has to do with the speed and asynchronous nature of text. Which means that I’ll be chatting with someone over whatever instant messaging service we select, and at some point, I might want to switch medium – move from text to something a bit more synchronous like video:

Like this example with Philipp – most of our conversations start in Hangouts (that’s where he is most reachable to me) and when needed, we’ll just jump on a call, without planning it first.

Who is calling whom here? Does it matter?

What happens here is that both of us are already “inside” the communications app, so we both have a direct link to the service. Passing that information from one side to the other is a no brainer at this point.

So how will that get signaled? However you see fit. Probably on top of a Websocket or over HTTPS.

I am calling you on the “phone”

What if there’s nothing pre-planned, so it isn’t a scheduled meeting. And we haven’t really been on a text chat to warm things up towards a call. How do you reach me now?

How do you “dial”?

Puneet is one of our support/testing engineers at testRTC. While he will usually text me over slack to start a call, he might just try calling directly from time to time.

What happens then?

I am not in front of my laptop with the Slack app opened. My phone is on standby mode. How does it start ringing on me? What does WebRTC do to get my attention?

Nothing.

The phone starts dialing because it received a mobile push notification. I’ve got the Slack app installed, so it can receive push notifications. Slack invoked a push notification to wake up the app and make it “ring” for me.

The same can be done with web notifications. And there are probably other means to do similar things in IOT devices. The thing is – this is out of scope for WebRTC, but something that is doable with the signaling technologies available to you.

Contact center agent answering calls

When a contact center adopts WebRTC to be able to migrate its agents from using desktop phones or installed softphone towards WebRTC, calls will end up being received in the browser.

This happens by integrating callbars inside CRMs or just by having the CRM implement the contact center part of the equation as well.

What happens then? How do calls get dialed? (the above is a screenshot taken from Talkdesk’s support site)

They go through PSTN towards a PBX. More often than not, that PBX will be based on Asterisk or FreeSWITCH, though other alternatives exist. PBXs usually base themselves around the SIP protocol, which will lead to two alternatives on the signaling protocol that will be used by WebRTC in the browser:

1. SIP over Websocket. Practically the same thing happening in SIP will happen on the browser
2. Some proprietary protocol will be used, translated from SIP

In both cases, the contact center agent is registered in advance. It is also marked as “available” in most contact center software logic – this means that incoming calls waiting in the call center queue can be routed to that agent. So it is sitting and waiting for incoming calls. In some ways, this is similar to the upgrade from text chat scenario.

Connecting? WebRTC?

When it comes to actual users, WebRTC doesn’t get them “connected”. At least not from a signaling point of view.

What WebRTC does is negotiate the paths that the media will use throughout the session. That’s the “offer-answer” (or JSEP) messages that pass between one WebRTC entity to another. And even that isn’t sent by WebRTC itself – WebRTC creates the blob of data it wants to send and lets your application send it in any way you see fit.

Still confused? There’s a course for that – my online WebRTC training. The first module (out of eight modules) is free, so go learn about WebRTC.

Get a WebRTC training

The post How does WebRTC connect people? appeared first on BlogGeek.me.

WebRTC wins over competition because there is no competition – browsers offer only WebRTC as a technology for web developers.

It was raining and miserable this last Saturday. I had lost of ideas for articles to write for BlogGeek.me in my backlog, but none of them really inspired me to action. The 8yo went to his cousin. The wife had her own things to do. My 11yo daughter was bored to death. She comes to me and says: “Can we do a trip outside to the park? I need some fresh air.” How could I answer besides saying yes?

The rain stopped a bit, so we went outside. What she really wanted wasn’t fresh air, but a chaperone to the closest candy vending machine. They are having a game at school for Purim, where she needs to bring small presents and candies to another kid in her class without her knowing who is pampering her. She needed an extra candy.

How is this related to WebRTC? It isn’t.

When I asked her about her plans for this game, she mentioned the trinket she planned on giving today –

2 mechanical pencils.

And that’s definitely WebRTC related.

A quick conversation ensued between me and my daughter – are these 0.5 mm or 0.7 mm point type? My daughter went to explain that it might even be 0.9 mm.

So many alternatives.

Competing standards

It got me thinking:

With analog video recording we had VHS and Betamax.

Paper size? A4 and Letter.

Power frequency? 50 Hz and 60 Hz.

With VoIP signaling we had H.323 and SIP. And also XMPP.

Audio and video codecs? A shopping mall of alternatives.

Web browser streaming? HLS and MPEG-DASH.

Inches and Meters. Left side vs right side driver in cars.

The list is endless.

WebRTC standard

But browser based real time media communications?

WebRTC.

There. Is. No. Other. Alternative.

We had that short romance around ORTC, which ended with ORTC dead and its main concepts just wrapped back into WebRTC.

What other technology would you use or could you use inside a browser to do a video call?

Nothing.

Just WebRTC.

The other alternatives just don’t cure it (including what Zoom is presumably doing).

• You want to build a real time service
• It needs to run in the browser
• You use WebRTC

What does that mean exactly? It gives us a kind of a virtuous circle.

• You want to build a real time service
• Looking at alternatives, you find WebRTC
• There’s a vibrant community around it (because of web browsers)
• Alternatives are limited proprietary solutions or old open source
• You pick WebRTC
• Adding to its popularity, adoption and ecosystem

For the most part, there’s no question if you should select WebRTC these days. There’s also no question what are the alternatives (there usually are none). It isn’t a question if WebRTC is getting adopted, used, growing or popular.

When our window to the world is the browser, then WebRTC is what you use.

For mobile apps or other devices, the need for browsers or just having an ecosystem around the technology picked translates again to WebRTC.

Thinking of using real time media technology? That’s synonymous to WebRTC.

Want to learn more about WebRTC? Check out the first module of my online course – it is free.

Start learning WebRTC

The post Why is WebRTC winning over its (non)competition? appeared first on BlogGeek.me.

Time is flying fast, only about 8 weeks till the start of the 7th edition of Kamailio World Conference, happening again in Berlin, Germany, during May 6-8, 2019! The details for the most of accepted presentations are published, the full schedule to be made available in the near future.Besides bringing a consistent group for distinguished speakers, with every edition we aim to improve the interaction between all the participants. From the first edition of the event we had the VUC Visions panel and Dangerous Demos, along with the cocktail party for social networking. At the previous edition we introduced the Ask Me Anything session with Kamailio core developers.In 2019, we are adding two new sessions to offer even more chances that the participants know each other and network between them, opening the doors for partnerships and collaboration. These are:

• Your Deployment On Stage – 5 Minutes 5 Slides – the session is coordinated by Markus Monka, head of IT infrastructure at sipgate.de. In this session any participant can come in the front of the others and speak about how they use Kamailio or what they are offering in the VoIP/RTC space. Think of it as a quick exposure, letting the others notice your presence so they can approach during the breaks or social networking event for further discussions. Time is limited, the proposals will be accepted in the order they are received. You can contact us starting now and get your 5min — use the web form for it. Important note: this session is not for accepted speakers, but for the registered attendees.
• Berlin City Tour By Boat – with special credits to sipgate.de for sponsoring it, this new social networking event during the evening of May 6, 2019, aims to offer a relaxing time combine sightseeing in the beautiful city center of Berlin with enjoying a few drinks, overall enabling more chances to chat between us.

Looking forward to meeting many of you in Berlin at Kamailio World Conference 2019! You still have the chance to secure your seat now at the early registration fee:

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

Ending the post with a big shut out to sipgate.de, a company that supported all our editions and even more events related to Kamailio project! They are also hiring VoIP engineers, and not only — you have the opportunity to join an amazing team in Dusseldorf, Germany.

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

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

What is new in 5.2.x release series is summarized in the announcement of v5.2.0:

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

Do not forget about the next Kamailio World Conference, taking place in Berlin, Germany, during May 6-8, 2019. A selection of sessions has been published! The registration is open, secure your seat now!Thanks for flying Kamailio!

I know I am. I am constantly surprised what people are doing with WebRTC.

Here’s something I hear a lot:

How do you make a call with WebRTC?

Well… you don’t. Not really. And in many scenarios – that term call, or dialing, or answering – has no real meaning.

Here’s a funny opposite for you:

Kids in front of old phones don’t know what to do. It isn’t “natural”. Guess what? Nothing is. The things that are natural to you are things you’ve learned, and are now used to. They are a set of rules in your upbringing.

If you come from a VoIP background, then WebRTC brings with it quite a challenge to your world. I know – I had 13 years of VoIP background before WebRTC was announced. Since that announcement, I’ve been surprised time and again by what people are doing with WebRTC. Especially people who shouldn’t be able to even use it because they don’t know VoIP enough.

Coming from VoIP? Interested in streaming? Broadcasting? Some other communication use cases? Tomorrow I am hosting a free webinar – Google Does Gaming: WebRTC Man-to-Machine Use Cases

Register to the webinar

When we all first started out in this adventure called WebRTC, what we’ve seen was video calling. It was all about face to face meetings. It took time to think about WebRTC in other settings and for other use cases.

And here we are. Years later, dealing with WebRTC in the aid of cloud gaming. Google used WebRTC in Project Stream, where they showcased playing the game Spartan through a web browser – the game itself was rendered in Google’s cloud.

(that’s a screenshot of one of my slides for tomorrow’s webinar)

Who would have thought WebRTC would be used for that?

Anyways, if you come from a VoIP background, here are some aspects of WebRTC you’ll need to unlearn and relearn – I am still grappling with them myself every once in awhile:

Signaling? What’s “Signaling”?

With any other VoIP protocol out there, it seems like we’re starting off with signaling.

H.323? Signaling.

SIP? That’s signaling.

XMPP? Ditto.

WebRTC? Nope. No signaling. Sorry.

What does that mean exactly? That you can use whatever signaling mechanism/protocol you see fit. That’s assuming you can get it to run inside a web browser or wherever it is your application needs to operate.

SIP, which is the most popular VoIP signaling protocol out there, is probably an overkill for a lot of WebRTC services. I tend to look at it as a hindrance when I see it in architectures – I often ask time and again why is it there to make sure there’s a real need other than saying someone needed signaling for his WebRTC application.

You. Don’t. Answer. Calls.

There’s no such thing as a call while we’re at it.

I remember doing a live WebRTC training a couple of years back. I had to hammer out of the people the need to ask incessant questions about dial, answer, mute, hold and a bunch of other paradigms they thought are golden rules in communications.

If you feel that way too, then look at that video at the top of this article again. What made sense 20 years ago doesn’t hold water today.

WebRTC isn’t fixed in any specific concept of how “calls” are made. I prefer using the term session and deal with the initiation part of it on a case by case basis.

If there’s no need for dialing or answering – just don’t force it on your WebRTC solution.

It isn’t only Google

Most days of the week, I like thinking of WebRTC as the source code that resides on webrtc.org. That’s the codebase Google is maintaining and putting inside its Chrome browser.

The thing is, many end up modifying it for their own needs. They:

• Port it over to mobile
• Fix private bugs in it
• Add their own minor modifications to it where needed
• Seriously change it (check out what Discord did)
• Modify the Chromium version, replace it inside Electron and release their own stuff

There are some really interesting “mods” to the vinyl WebRTC implementations out there, usually held privately for internal use of companies. In many ways, this is a shortcut to building your own media engine from scratch.

There’s more than one way

What I like about WebRTC is that usually, there’s a single way of doing things with it: everything is encrypted – you can’t override that; it defaults to multiplex and bundle its media connections; the list goes on.

How you use it is a totally different story.

Each SFU implementation is different than the other. There are different ways to record a session. Different ideas and approaches to broadcasting at low latency.

The “right” answer differs a lot not only based on the use case, but also on the business model, the developers available, the DNA of the company, etc.

Wasteful can be just fine

There’s also a school of thought that never really existed with VoIP: the “good enough” approach – one where we’re just fine with not optimizing everything and leaving things it a kind of a mediocre stage that is good enough for what we’re trying to do. It may eat up to much bandwidth or tax on the CPU. Or just not be how things are done around here. But it works. Good enough.

Heck – the default WebRTC implementation does it on its own, deciding to waste 1.7Mbps for a VGA resolution encoding instead of limiting it to 800kbps or less. Such a waste of good resources.

I learned to love this approach (and then try to optimize it with my clients).

How do you think about WebRTC?

What about you?

What mistakes you see people make when thinking about WebRTC that fits the web or VoIP better?

What things do you need to unlearn about WebRTC?

Coming from VoIP? Interested in streaming? Broadcasting? Some other communication use cases? Tomorrow I am hosting a free webinar – Google Does Gaming: WebRTC Man-to-Machine Use Cases

Register to the webinar

The post Are you blocked by the rules of your upbringing in your WebRTC application? appeared first on BlogGeek.me.

Thanks to work initiated by Google Project Zero, fuzzing has become a popular topic within WebRTC since late last year.  It was clear WebRTC was lacking in this area. However, the community has shown its strength by giving this topic an immense amount of focus and resolving many issues.  In a previous post, we showed how to break the Janus Server RTCP parser. The Meetecho team behind Janus did not take that lightly. They got to the bottom of what turned out to be quite a big project.

Continue reading How Janus Battled libFuzzer and Won (Alessandro Toppi) at webrtcHacks.

To discuss about the next major release of Kamailio (v5.3.0) and ongoing development, we propose an IRC devel meeting for next week, on Monday, March 11, 2019.The meeting is going to be held as usual in the #kamailio channel on freenode.net IRC network.A wiki page was created to collect the topics that are wanted to be discussed:

• https://www.kamailio.org/wiki/devel/irc-meetings/2019a

Fell free to add there or reply to the mailing list with what you think it is relevant to discuss.Thanks for flying Kamailio!

Slightly more than 2  months till the start of the 7th edition of Kamailio World Conference, the event is approaching at a fast pace!Recently we published the details for a group of accepted speakers, today we made a selection of sessions at the Kamailio World 2019. You can head to the Schedule page and see the details for about 20 sessions, from both workshops and conference days:

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

A very diverse range of topics, from using Kamailio to secure your VoIP services, deploying in a containerized environment with Docker and Kubernetes, using RTPEngine or the new addition RTP Media Server module, optimizations for KEMI language scripting such as Lua, Python or Javascript, to blockchains in telephony, building high throughput SBC systems with topos, using Kamailio and FreeSwitch together, or latest updates from Asterisk PBX.There will be sessions covering IMS/VoLTE and IoT, and, of course, we have the very popular two sessions that never missed a Kamailio World edition: Dangerous Demos with James Body and VUC Visions with Randy Resnick.The open discussions session Kamailio – Ask Me Anything with the main developers or the project is again present and allows the attendees to address questions about their needs of using Kamailio and the development of the project.A new kind of session is introduced at this edition Your Deployment On Stage – 5 Minutes 5 Slides enabling attendees to show what their are doing in the RTC space, what are their services and products, where and how Kamailio is used.The details for other speakers and sessions will be published in the near future, stay tuned!Do not miss Kamailio World Conference 2019, it is going to be another great edition! You can register now!

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

Looking forward to meeting many of you at the next Kamailio World Conference, during May 6-8, 2019, in Berlin, Germany!

Some believe WebRTC isn’t ready. I think it is ready. But when will WebRTC 1.0 be available?

Ready or not, WebRTC is here. The thing is, we still don’t have a closed standard specification we can all print and take on a plane to read for our enjoyment. There are drafts – but nothing that is final.

And once final, does it mean that it is available?

There are 3 parts that needs to be addressed to answer this question. I’ll deal with only two of them (skipping the IETF one):

1. When will the relevant WebRTC draft become IETF RFC
2. When will the relevant WebRTC draft become W3C recommendation
3. When will browsers implement the new specification

Want to learn more about WebRTC, the various components in its specification and what compute power you need for each WebRTC server? Try out my free video course:

Learn about WebRTC servers

Want to learn more about WebRTC, the various components in its specification and what compute power you need for each WebRTC server? Try out my free video course:

WebRTC standardization

WebRTC as a standard is built out of two components:

1. What goes on over the network – that’s what the IETF is working on
2. What APIs can developers use on top of a web browser – that’s what the W3C is working on

Most of the industry is already viewing WebRTC as a done deal – so much so that the IETF already has an RFC for SIP over WebSocket. The only reason to have such an RFC is to be able to use SIP inside a browser, and the only way to use SIP inside a browser with media being sent or received would be by way of WebRTC. The people working at the IETF were so certain WebRTC will get an RFC of its own in 2014 already (5 years ago!).

Each of these organizations has its own set of rules, policies, governance and flow.

I’ve tried to keep the standardization of WebRTC at arm’s length. In the past I’ve been part of standardization processes related to H.323 and 3G-324M, going to ITU-T and 3GPP standardization meetings as well as acting as a co-chair of the 3G-324M activity group at the IMTC (dealing with interoperability). It is a tedious work that combines technology with politics. As fun as it is (at times at least), dealing with it as an employee of a company is different than doing it as a consultant. The value for me just wasn’t there.

For vendors? If you want to take a driver’s seat at this, and decide what gets more attention, then you should invest time in it.

But where are we with WebRTC then?

W3C WebRTC status

I’ve asked Dominique Hazael-Massieux about WebRTC’s status. He works as a W3C Staff dealing with WebRTC. Here’s what I got –

When it comes to W3C, where the browser WebRTC APIs are being defined, WebRTC is considered to be at the CR stage.

CR means a Candidate Recommendation. We’ve moved from a Working Draft (WD) towards a Candidate Recommendation.

Next up would be PR – Proposed Recommendation, and from there, a Recommendation.

How do we move to the next step?

1. First the draft needs to be finalized. There are some open issues that needs to be closed for that to happen (at the time of writing this, there were 53 open issues)
2. All the features written in the draft need to be implemented in two independent browsers (this is kinda tricky now that Chrome is gobbling up the market). More on browser implementations later
3. It needs to be tested for interoperability across browsers. So tests needs to be written to validate that

That first one is “easy”. Get the people writing the spec into a room. Have them agree. Then have someone write down the agreement on “paper”. Get everyone to read it. And agree again. Rinse and repeat. It’s never easy.

That second one of implementing in browsers? That’s also not easy. They have other things on their minds as well. And WebRTC is pretty darn complex to implement. But we’re getting there.

That third one of interoperability testing? With a test suite. That tests for the various features? This is downright suicidal. And daunting.

All that work needs to be done for “free”. There’s no direct money to be made out of it. But lost of hours needs to be spent by many people to get it done. We’re getting there, but we’re not there yet.

WebRTC 1.0 browser implementation

And then there are the browser implementations.

The specification is as good as its implementations. People always complain when I suggest following the Chrome behavior in WebRTC as opposed to implementing against the specification. That’s where theory and expectations meets reality.

At the end of the day, your service will need to:

1. Run inside web browsers; and/or
2. Integrate/port/embed a WebRTC SDK in your app

In the first case, Chrome wins on market share; Microsoft Edge will be migrating to Chromium. And for most use cases, Chrome is the first browser to target anyway.

In the second case, if you are using the code in webrtc.org for your app, then you are effectively basing your app on Chrome’s WebRTC implementation.

Better go with what’s available now than what will be ready some time in the future.

In the past, the changes we’ve seen in browser implementations of WebRTC revolved a lot around media optimizations and interoperability across browsers. What we are seeing now a lot more is changes in the API layer, where browsers are shifting towards the WebRTC 1.0 specification. This is necessary because:

• Without spec compliant implementations we can’t move WebRTC from CR to PR
• People still (rightfully) expect to have the specification implemented by browser vendors
• It is about time…

These changes mean one sad thing though. You can be certain in one thing – during 2019, WebRTC implementations in browsers is going to break existing apps multiple times. This is due to the changes taking place. We are seeing migration from Plan B towards Unified Plan, modifications to the connection state machine, and an experimental implementation of mDNS. There’s more that I probably forgot and more ahead of us still.

The only certainty is that nothing is certain. You’ll need to continue investing in aligning with the browser implementations with each and every browser version release.

When then?

The current intent is to be able to get to the PR stage for WebRTC somewhere in Q3 2019. Will it be postponed further? I don’t really know.

Interestingly, work has started in parallel about WebRTC NV – what comes next. I’ve covered the WebAssembly in WebRTC part of it in the past.

Want to learn more about WebRTC, the various components in its specification and what compute power you need for each WebRTC server? Try out my free video course:

Learn about WebRTC servers

The post When will WebRTC 1.0 be available? appeared first on BlogGeek.me.

Via social media media, I noticed a nice article about a Kamailio exporter for Prometheus written in Golang:

• https://blog.callr.tech/kamailio-exporter-for-prometheus/

So I thought sharing it further via Kamailio’s website. Lately I noticed an increase of interest on using Prometheus, hopefully this exporter tool will help others inside our community.As a matter of fact, one of the submissions for the next Kamailio World Conference (May 608, 2019, in Berlin) is about using Prometheus with Kamailio for visualising statistics and other metrics via Grafana dashboards (to avoid any confusions, it is not from the author of the linked article in this text). The schedule of the event is expected to be published in the near future, meanwhile you can view a selection of accepted speakers. Early bird registration is still open, if you want to benefit of the discounted access, hurry up to register!Thanks for flying Kamailio!

WebRTC is a great piece of technology, assuming you can develop a coherent strategy on how you plan on using it.

There are two extremes happening in the enterprise communication space, and they are quite opposite in nature. On one hand, companies are striving towards more automation and this is coming to their contact centers by way of machine learning and bots “replacing” humans. On the other hand, many of us are striving for better and more meaningful communications. Be it for long distance relationships (personal as well as business ones) or by the use of machine learning (again) and context, to guide us through an interaction – being able to know beforehand the intents of people for example.

Enter WebRTC, which enables communications to take place anywhere – be it a mobile application, a physical device or a modern web browser. What WebRTC brings with it is better context of sessions and lower barrier of entry for enterprises to make use if this technology. Some enterprises use it to improve business agility or lower their operating costs. Others use it to create new businesses never before seen or to improve the communications with their customers or peers in the industry.

We are now 7-8 years since the announcement of WebRTC (depends on who’s doing the counting and from which date), but in many ways, a lot of enterprises (I don’t want to say most) have failed in to capture the value they initially envisioned from using WebRTC. In many cases, the lack of any thoughtful strategy created a rush towards initiatives that never really matured.

Through my work with many clients on their WebRTC initiatives along with discussions with many others on their projects and services – failed as well as successful ones, I’ve seen a few challenges that crop up consistently across such initiatives.

#1 – Where to begin?

WebRTC is a versatile and powerful building block in your arsenal. This means that you can do a lot with it. That range of utility can be overwhelming, oftentimes leading to wasted resources. The other problem is that WebRTC can’t do everything, while the expectations of it are rather high. This leads to requirements and plans that are often not grounded in what can be done in reality or within the allocated budget and resources.

Deciding what to build using WebRTC requires an understanding of the capabilities and limitations of WebRTC coupled with a clear view of the communication problems you are trying to solve for your customers. There’s a lot of feature creep happening when it comes to WebRTC. I find myself asked about a simple video chat service for 2 people, but once you dig a layer deeper, you see requirements for group video calls, recording and even broadcasts as part of the project. Being able to see the full picture, and map it back into requirements and a roadmap comprised out of multiple phases is an important first step in any WebRTC initiative.

There are a few other things to keep in mind –

Integration with existing infrastructure

Oftentimes, you’d be planning on adding WebRTC to an existing service. This can happen in many ways:

• A chat application that gets voice/video interactions as an additional feature
• An existing telephony/communication service that needs to get guest access via the web browser
• Just a regular self service application with a new option to connect to the contact center via the application itself (instead of using expensive 1-800 numbers)

This requires extra care in how WebRTC gets introduced as it isn’t going into a green field where anything you pick immediately fits your needs.

Cloud migration and transformation

WebRTC was born in the cloud era. Many of its deployments are cloud based.

Most of its uses in non-cloud environments are actually enabling guest access from the public cloud towards the internal communications infrastructure. In other cases, it just needs to integrate with on premise data centers for things like users database and policies.

This places an additional strain on enterprises who are just starting out their migration towards the cloud.

Not your regular web application

WebRTC is different than other web technologies. It has a lot more moving parts to get to a minimal viable product, and then there’s that media quality issue to contend with. Its deployment needs to start as a global one for many of the use cases.

What are the server side components needed for WebRTC? Learn that in my free online mini video course.

Register now

#2 – Who should I have on my team?

Putting a team of developers on a WebRTC initiative is a daunting task. There are multiple disciplines they need to come from and the myth of a full stack developer that can do it all gets stretched even further here, as that superhero needs to also know about media processing, WebRTC APIs, browser changes and standardization processes.

Here’s what i wrote a while back about WebRTC developers after discussing the topic with a few people who manage/hire them.

Some other aspects you’ll need to decide on:

Internal vs External

Will you be relying on your existing engineering team or will you be outsourcing some/most of the project to an external vendor? Assuming you decide to go for an external vendor, who will maintain the service on an ongoing basis?

Multidisciplinary

The team in question needs to be multidisciplinary, capable of handling anything from media processing, to mobile app development, to backend integration work and ongoing DevOps and maintenance.

There needs to be a skilled product manager and a system architect who understand WebRTC enough to know what is possible and what’s… less possible. What incurs risk and where quick wins can be found.

Which new skills are needed?

Your teams. Do they have the necessary skills?

Here it goes to a lot more than just developers. There are product managers, testers, DevOps people, support staff.

Do I need to enhance some in-house capabilities?

What skills are you missing? If you operate everything on premise and WebRTC is forcing you to start using cloud services, then this is an in-house capability you will need to start contending with.

The same goes for mobile application development, going global in how you deploy servers, etc.

Looking to beef up the WebRTC experience and skills of your team? Check out my WebRTC training (the first module is free).

Enroll to my course

#3 – What technology stack do I use?

Different companies have different DNA to them. That often dictates what their technology stack will look like and how they’d prefer to partner/hire.

There are three main aspects that need to be taken into account when picking a WebRTC technology stack:

Open source / commercial

You might favor open source components and frameworks for your WebRTC service or you might be someone who prefers a commercial offering with a company focused on that product development.

Both alternatives can come with support contracts but companies seem to prefer one or the other.

Which alternative will it be for you?

Hosted or on prem?

These two approaches means different technology stacks, levels of expertise and staffing on your end.

Are you planning on hosting this on your own, in your data centers, on bare metal or in the cloud? Or are you going to have someone else host the service for you? Which parts of it will be managed and which will be self managed?

Acquisitions

WebRTC is still relatively new, with the vendors ecosystem dynamically shifting. There have been quite a few acquisitions in this space. These acquisitions sometimes removed solutions from the market, made them weaker or made them stronger.

When selecting a technology stack, the potential acquisition scenario of the vendors in question needs to be taken into consideration as well.

Fit for the requirements

This one seems silly but it is highly relevant and important.

Are you sure the technology stack you’ve selected can do the things you want it to do?

I’ve seen too many cases where the framework used wasn’t up for the task. Things like taking signaling when media servers needs to be used, picking a CPaaS vendor when the scenario requires too much control of media processing, etc.

Just look at what WebRTC signaling alternatives people have these days.

#4 – How do I know it is working?

You built it. Tested it in the lab. Did a call or two with your colleagues. Went home and showed it to a friend.

Does it scale? Will it work properly?

I had a customer recently who is developing a group video calling feature. He wanted to test the service with around 20 people in a single room. It wasn’t easy to find 20 people to run that one scenario. And when he did – things broke and needed fixing. So he had to find 20 people to run it again once a fix was put in place.

Testing is often neglected when it comes to WebRTC applications and it shouldn’t be. Take this one seriously. You can cobble up a testing environment on your own (there are even a few open source projects that can help you out here) or you can just use testRTC (I am a co-founder there) and start running tests within a couple of hours.

#5 – What do I track?

Tracking websites is rather “easy” these days. Use Nagios, Cacti, Zabbix or any other open source tool that sounds like a disease. Or use something like New Relic or DataDog to do it managed in the cloud.

Problem is, these tools only cover the machines metrics and performance and they don’t really watch for the media and its quality (or even if a session got connected for that matter). There’s no end to end monitoring/tracking.

You will need to collect WebRTC related metrics from either the backend or the devices (or both). You’ll need to track it for quality.

You’ll need to monitor your service (we’re doing a webinar on WebRTC monitoring next more @ testRTC – register to join).

How can I get help?

There are various ways in which you can get some help for what you are doing.

The best approach is probably to get some external assistance in what you are doing as part of your research and planning – even before you go outsourcing the whole project (if that’s the path you are going to take).

You can contact me for that, or go to other consultants. Some of the outsourcing vendors offer such consultancy service as well. Whatever you do – don’t go it alone. At least not in the planning stages.

The post The five make-or-break WebRTC challenges you need to address appeared first on BlogGeek.me.

With slightly more than two months and a half before the start of Kamailio World 2019, we are glad to announce the first group of speakers. Their details are available at:

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

The selection procedure is ongoing, therefore expect the details for other speakers to be published in the near future.The two interactive sessions present at all the past editions return in 2019, respectively VUC Visions and Dangerous Demos. In addition, we will have at least two other similar sessions to allow better interaction between Kamailio developers and the participants. As usual, expect presentations that go beyond Kamailio, covering Asterisk, FreeSwitch, VoLTE/IMS, WebRTC or IoT and technologies such as blockchain, containerisation and artificial intelligence.To facilitate more networking between attendees, the 2019 edition is adding a new social event in the evening of the 6th of May, a boat trip on the channels of the city center.The registration is open, you can do it now to benefit of the early registration price:

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

Looking forward to meeting many of you at Kamailio World Conference, May 6-8, 2019, in Berlin, Germany!Thanks for flying Kamailio!

Is QUIC in WebRTC a solution looking for a problem or a real requirement?

QUIC is the next evolution of browser transport protocols. I’ve written about it in 2015, when Google started experimenting with the idea of replacing SCTP with QUIC for data channels. Three and a half years later, and we still don’t really have QUIC in WebRTC – at least not until last month. Google decided to come out with a new RTCQUICTransport for WebRTC in Chrome and written a post about it on their Chrome Developers site.

UDP, TCP, SCTP & QUIC. How do these transport protocols compare?

Download my free Transport Comparison Table

What is QUIC again?

I am not going to go into the technical details – I’ve done that in the past already, and there are other places for that. I want to focus here on the bigger picture.

If you look at the timeline of web transport protocols, it looks something like this:

We had TCP and UDP for some 40 years now. HTTP 1.1 is defunct, but runs most of the internet at the moment. HTTP/2 is growing nicely in adoption. According to W3Techs, we’re standing on ~33% adoption for HTTP/2 (Feb 2019):

HTTP/2 came to be after Google came out with SPDY, a “fix” for HTTP and got parts (most?) of it wrapped into HTTP/2 to get it standardized.

HTTP 1.0, 1.1 and HTTP/2 are all built on top of TCP. Signaling, which requires reliability and causality won’t work on top of UDP without adding these characteristics. After around 40 years, it is time for a refresh. Enter QUIC. It uses UDP and works in ways that are better than TCP for signaling purposes.

QUIC follows a similar path – Google created it to “fix” the ailments of HTTP over TCP. the end goal here is to turn it into HTTP/3.

Since QUIC is built on top of UDP, it can handle a lot more than just HTTP signaling. Which is why it is becoming an interesting topic for WebRTC –

Where QUIC in WebRTC fits exactly?

This is the real question. My answer to it in 2015 was this:

There are two places where QUIC fits in WebRTC:

1. In the signaling, which is out of scope of WebRTC, but interesting, as it enables faster connection of the initial call (theoretically at least)

2. In the data channel, by replacing SCTP with QUIC wholesale

Google’s answer in their post on Chrome Developers blog?

Why?

A powerful low level data transport API can enable applications (like real time communications) to do new things on the web. You can build on top of the API, creating your own solutions, pushing the limits of what can be done with peer to peer connections, […] WebRTC’s NV effort is to move towards lower level APIs, and experimenting early with this is valuable.

Why QUIC?

The QUIC protocol is desirable for real time communications. It is built on top of UDP, has built in encryption, congestion control and is multiplexed without head of line blocking.

Hmm… somehow they lost me in that explanation somewhere. This is about real time communications. It is about doing stuff on top of UDP. And it is about low level APIs. Great. Why do I need it again? For voice and video I already have SRTP in WebRTC. The SCTP data channel works quite well. So where exactly do I need this great thing called QUIC in WebRTC?

I think there’s merit, but it is in totally different places.

QUIC is about having a single, modern, common transport protocol for the web.

Here’s what we do today with WebRTC in terms of transport protocols:

• HTTPS, HTTP/2 or WebSocket for our signaling, which runs over TCP/TLS
• SRTP for media, which runs over UDP
• SCTP for data channels

There’s this popular drawing from the High Performance Browser Networking book that shows this amalgamation of protocols:

So many transport protocols in a single standard. This makes implementations of the backend more complex, as they need to be able to understand all these transport protocols as well. One can say that this is already common enough and widely used already that it is a solution looking for a problem, but the developer in me can appreciate unifying all these functionality over a single transport protocol.

Here’s how life will look like with QUIC in WebRTC:

• QUIC is being planned for HTTP/3, so it can be used for WebRTC signaling moving forward (replacing both WebSocket and HTTP/2)
• QUIC is looked as an SRTP replacement, which means sending real time audio and video can take place on top of it
• QUIC can replace SCTP for the data channels (that was the obvious use of QUIC in WebRTC to begin with)

Putting it into an architecture diagram of my own, we get this:

Much simpler.

What do we gain?

Theoretically, we can multiplex signaling, voice, video and low latency data in a single QUIC connection. That’s powerful:

• We can now tunnel or proxy all that WebRTC traffic with a lot less logic, boxes and code in our servers
• For smaller deployments, we might not even need multiple servers – just the one that handles it all
• It makes developing web servers that handle media and data channels simpler, as they need to support only one transport – QUIC, instead of having to implement multiple transports

What do we lose?

This isn’t going to happen in a day. Getting there is going to be a journey of multiple years and people will complain and whine about it along the way. Similar to what is happening today with WebRTC – whenever something is modified or something new is added – things tend to break (either because APIs get deprecated, behavior changes or just pure bugs).

Moving to a QUIC based stack is a huge undertaking – for the WebRTC stack, browser vendors and all the related internet infrastructure vendors.

Connecting to other realms such as SIP? That’s going to get even harder, as we move away from the domain of SRTP towards QUIC, more translations and protocol interworking will be required.

The question then becomes – is it worth all the fuss? Are we gaining enough to make this effort worthwhile?

Can you use QUIC in WebRTC now?

To some extent you can. Check out the recent post on QUIC @ webrtcHacks for that.

I will be adding a new dedicated lesson to my online WebRTC course about QUIC – my goal is to have the most up to date and relevant WebRTC training curriculum in the market, so keeping up with these changes comes with the territory.

Interested in WebRTC? Check out my WebRTC course.

The post Who needs QUIC in WebRTC anyway? appeared first on BlogGeek.me.

Continue reading First steps with QUIC DataChannels at webrtcHacks.

I don’t really know, but there’s a lot in this innocent “WebRTC JS library” question that isn’t clear without digging a lot further.

Every now and again (= a week or two) I get a question asking me to help with the selection of this or that open source component, pick a CPaaS vendor for a project, find someone to outsource WebRTC work to or hire a stellar WebRTC developer.

Many of these emails are about shortcuts. Give us that silver bullet. Shortcuts seldomly work with WebRTC.

Last week, I had a question come in. A startup is looking for a “WebRTC JS library” to use. Something that does 1:1 voice chat rooms, stores user profiles, etc. It also needed to be inexpensive – Twilio is too expensive for them. And a free alternative was their main preference.

The problem I had with it, is that this simple question of which WebRTC JS library should I use didn’t align that well with the set of questions asked.

This article is about what components are needed for WebRTC deployments. If you’re looking to dig deeper into the media paths in WebRTC, then join my free webinar: Mesh, MCU or SFU

Register to the webinar

Let’s break down WebRTC to its main components as seen from a network architecture perspective:

1. Signaling
2. NAT traversal
3. Media
4. Other

Here’s a slide I’ve been using to explain where a device gets connected to in a typical WebRTC session –

Signaling

Signaling is how the devices reach out to one another. They can’t do it directly, since they don’t have each other’s IP address, and even if they could, we need some kind of a “protocol” for them to do that.

Signaling in WebRTC is… non-existent. You need to bring your own signaling. This approach confuses some developers, and probably causes this lack of a good solution that fits no-one and everyone at the same time.

Today, you can use SIP, XMPP, MQTT or just proprietary protocols as your signaling for WebRTC traffic. Each such protocol will have its own set of frameworks, services and SDKs that you can use. Some will be free (open source) while others will be licensable software or SaaS based.

NAT traversal

NAT traversal is about being able to actually get media flowing.

WebRTC is P2P (peer to peer), meaning you can, in some cases, send media directly across devices. This is something that is impossible otherwise with web browsers. WebRTC also have a preference on using UDP, since it offers better real time low latency characteristics. It is also the only web browser traffic that makes use of UDP, which means it is sometimes blocked as well.

NAT traversal is how WebRTC get past these pesky issues, and it requires additional servers to help it out to do so. Some of these servers (TURN) may end up relaying all traffic through it…

At the end of the day, you will need to deploy these servers or pay for someone to do it for you (no free meals here).

Media

Recording. Group calling. The need to control media paths. Broadcasting. All these end up requiring media servers in the backend. Ones that can process media in one way or another.

The most common approaches today is to use SFUs and solve most of the world/media problems with them. These also offer some signaling protocol of their own – my preference is usually to short circuit these and redirect all this traffic through a different signaling/messaging path – especially for the more complex applications.

Again, they come in different shapes, sizes and types – open source ones and commercial ones. You usually won’t be able to pay for them separately as a hosted service and will need to go to a CPaaS vendor to get the whole set of solutions – if you’re looking for the hosted/managed path.

Other

Payments, user authentication and identity, the website itself and a large number of other things you might be needing.

These are really out of scope of WebRTC, but sometimes are provided by the various vendors and frameworks out there.

Back to that question

What were we dealing with to begin with here?

looking for a “WebRTC JS library” to use. Something that does 1:1 voice chat rooms, stores user profiles, etc. It also needed to be inexpensive – Twilio is too expensive for them. And a free alternative was their main preference.

Here’s how I’d break this one down to try and understand what was asked:

• That “WebRTC JS library” gives a hint of someone searching for a signaling framework. Which is great
• 1:1 voice chats strengthens that feeling we’re dealing with signaling only
• The word rooms… that feels more like an SFU media server. In this case, I’ll assume there’s no need for a media server though – due to the price points asked (free), the fact that there’s no ask on recording and that this is a 1:1 scenario
• Stores user profiles. Hmm. this usually has nothing to do with WebRTC. So much so that most CPaaS vendors don’t offer such a capability either
• Twilio is about the full shebang – getting a hosted, SaaS, CPaaS, managed (pick the term you like best) solution that gives you signaling, NAT traversal, media and some other knick knacks. Doesn’t quite fit in with the rest of the ask here

When I get such jumbled questions, it feels like there’s a bit of a misunderstanding of what WebRTC is and about how the ecosystem of vendors and services has evolved around it.

Want to learn more about WebRTC?

There are several things to do at this point if you need to grok WebRTC:

1. Read this article on learning WebRTC for more suggestions
2. Read my WebRTC for Business People report (it is free)
3. Learn how I think about WebRTC requirements
4. Take the first module of my WebRTC training (it’s free)
5. Join me for the webinar tomorrow – I’ll talk about Mesh, MCU and SFU media architectures

The post Which WebRTC JS library should I use? appeared first on BlogGeek.me.

We are delighted to announce that Kamailio project was awarded the “Open Source Excellence” prize at SimCon 2019, ceremony hosted by Rachel Riley (twitter – wikipedia) and Simon Woodhead (twitter).From their announcement:Kamailio were awarded ‘Open Source Excellence’, a key reason being the superb management of the project. Kamailio is used within huge networks and really is the secret weapon of many modern telcos. It is open source and, in the judges’ opinion, one of the best run projects around.This recognizes the enormous effort made over more than 15 years by the development team and the community to keep Kamailio at the top of open source SIP/VoIP server applications, with a well defined development process and project organizing procedures.With key targets such as flexibility, robustness, security and scalability, Kamailio continued to bring constantly a consistent set of new features with each major release (19 of them, from SER 0.8.x to Kamailio 5.2.x) and consolidated the trust in being a reliable application that can be used from start-ups to large established telcos and mobile operators.It is actually a double celebration, because Fred Posner (twitter), one of our most prominent community members and advocate, was also awarded — citing: a genuine ‘Pre-Posthumous Legend’, a selfless, long standing contributor and supporter of the open-source community who has never sought the limelight.Thank you SimCon for the award and Simwood for supporting the project for so many years!We look forward to Kamailio World Conference 2019 and hoping to meet many of you there!Thanks for flying Kamailio!

Fact that open source development is huge nowadays couldn’t be felt better than at Fosdem 2019, practically during the first day was almost impossible to move around even on the corridors. It is irrelevant to say that I gave up quickly in the morning trying to attend any session, after failing to find seats in two of the rooms I wanted to get in.Therefore the first day resumed to hallways, expo areas and cafeterias, meeting and chatting mainly with fellow Kamailians and VoIP/RTC folks. I got also the chance to see again and catch up with couple of other projects and organizations, among them: FSFE, OSI, SFC, the main Linux distros, Fossasia or GSoC.Back to real time communications, being again being again part of organizing team for the DevRoom and the lounge…The lounge was available during the both days, as usual filled with many XMPP projects and devs, joined by the Matrix.org team. The SIP/VoIP folks were never attracted by the lounge during all these years, but we always had a stronger presence in the DevRoom.The RTC DevRoom took place in building H, with a fair large space accommodating about 150 seats, allowing us to run smooth during the day. I haven’t done much on Sunday apart of helping around and chatting with folks just outside.Henning gave a presentation on what’s new lately on Kamailio project. Asterisk, Matrix, Homer SIP Capture, reSIProcate and CGRateS had their usual presentations as well and WebRTC was also a relevant stake of the day. A new comer this year was the sip3.io project, another SIP capture and troubleshooting tool. Of course, some presentations were about XMPP, open source devs doing a lot of cool stuff with that protocol as well.On Saturday, we had our informal developers meeting about Kamailio, among participants, besides myself (Daniel-Constantin Mierla), there were Henning Westerholt, Federico Cabiddu, Alexandr Dubovikov and Dragos Oancea. Four were also at the developers meetup in Dusseldorf and we agreed that was something very productive and we should do it again. Couple of ideas were discussed about short term development, more to be announced via mailing lists.The top of the event was as usual the dinner, done by Kamailio project every Fosdem edition since 2009 (see who was there 10 years ago). Like in the past few years, we were joined by other VoIP devs participating in the DevRoom, being nearly 40 participants (to give few more names: James Body, Tim Panton, Dan Jenkins, Daniel Pocock, Joachim Vanheuverzwijn). Lot of fun and interesting discussions!Big thanks to Voxbone.com for sponsoring it and to Torrey Searle for helping to organize the dinner!And to attract more of you to contribute to open source (and Kamailio), I have to mention that I got one of the most amazing gifts in more than 17 years of OSS development: home made Belgian chocolate truffles, amazing taste (thanks Joachim/Zoiper)!Till the next Fosdem, I am looking forward to meeting many of you at the next Kamailio World Conference, May 6-8, 2019, in Berlin, Germany! Registration is open!Thanks for flying Kamailio!

Fresh from the oven – an update to my first ever report – WebRTC for Business People. Download it for free.

It was time. Two years have passed since my last update to this report. In WebRTC-land, things deteriorate and become unusable quite fast. We now have WebRTC in all modern browsers (at least theoretically and to some scenarios) and Microsoft decided to place Edge on top of Chromium. On the vendor stories things have changed and shifted as well.

This, and the need to do something to start off 2019, I decided to write an update to the report. This time, with the assistance of Frozen Mountain who sponsored this update.

Besides the usual updates of reading the report and making sure it is as close to where we are with WebRTC today as possible (and adding more references and links while at it), I’ve also updated the use cases section. I consider this part the most important one in the report.

I removed a few of the stories and added others, ending up with a total of 28 vendor stories. While the groups of these vendor stories haven’t changed, the direction I’ve taken in some of them did.

Here’s what you’ll find in there:

Tooling

The tooling section is usually the hardest one. With over 100 vendors in this space, I wanted to make a few distinct picks, each from a different angle of tooling. I decided this time around to also feature testRTC, a company where I am a co-founder (I am biased on this one, so sorry).

Customer Services and Support

In the customer services space I wanted to make a change to reflect the growing adoption of “see what I see” type of contact center services, also known as “remote assistance” or similar names. To that end, I’ve featured Indeca4D who are making use of mixed reality in their solution.

Enterprise Communications

In the enterprise communications space, it was time to put a UCaaS vendor – something overdue from the last round I guess. I picked Vonage for this one. They are unique also because they offer CPaaS (=Tooling) and contact center services.

Webinars

For the webinars section, I decided to add AnyMeeting. I’ve used other platforms in the past, and after getting to know their platform somewhat more, I decided to start using it for my webinars in 2019. The first webinar will take place next week (feel free to register here).

Healthcare

In Healthcare I’ve replaced one of the stories there for the story of GuruMD. One of the trends in this space is the creation of marketplaces and tools that independent doctors and clinics can start using with their patients or for attracting new clients.

Education

For Education, I’ve added Soliya. I wanted to somehow emphasize that education is probably one of the most varied domains where you see WebRTC. Almost every vendor there is looking at education from a different angle, leading to different requirements and final product offerings.

Social

Social… remained the same. The stories got a bit of a refresh where needed, but stayed mostly the same. I felt that Facebook, Houseparty, Snap and YouNow are relevant today as they were two years ago.

Streaming and Content Delivery

In streaming and content delivery, I’ve replaced two vendors, deciding to showcase Google Project Stream and Limelight. Both bringing some strong validation to where WebRTC is headed and how it fits into these non-video calling domains.

Download the report

If WebRTC interests you, then you should definitely read this report –

Tell me what you think about it.

The post WebRTC for Business People: 2019 Edition appeared first on BlogGeek.me.