News from Industry

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.

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

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

What is new in 5.1.x release series is summarized in the announcement of v5.1.0:

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

Note: the branch 5.1 is the previous stable branch. The latest stable branch is 5.2, at this time with v5.2.1 being released out of it. Be aware that you may need to change the configuration files and database structures from 5.1.x to 5.2.x. See more details about it at:

• 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. The is still a bit of time to submit a speaking proposal and the registration is already open, you can secure you seat right now!Thanks for flying Kamailio!

The year 2019 started once again at fast pace for Kamailio SIP Server project. Among the activities within the community, we have always tried to cover as much as possible the events related to open source and real time communication worlds.During the next few months, there are many occasions where you can meet with Kamailio developers and community members, among them:

• Asterisk World and ITExpo, Ft. Lauderdale, FL, USA, during January 29, 2019 – Fred Posner will give a presentation about Kamailio
• Fosdem, Brussels, Belgium, during February 2-3, 2019 – Henning Westerholt will give a presentation about Kamailio as part of RTC Devroom. Daniel-Constantin Mierla, Federico Cabiddu, Alexandr Dubovikov, Torrey Searle and couple of other developers will attend the event and participate to our traditional dinner on the evening of the 2nd of February
• Call Center World, Berlin, Germany, during February 18-21, 2019
• Mobile World Congress, Barcelona, Spain, during February 25-28, 2019
• Kamailio Advanced Training, Berlin, Germany, during March 4-6, 2019
• IETF 104, Prague, Czech Republic, during March 23-29, 2019
• Kamailio Advanced Training, Washington DC area, USA, during March 25-27, 2019
• Kamailio World Conference, Berlin, Germany, during May 6-8, 2019 – the 7th edition of the yearly event of Kamailio project

Should you participate to those events, or just happens to be in the same city during those events and want to meet, get in contact with us via sr-users mailing list. We would love to get in touch and share the latest updates about Kamailio!Thanks for flying Kamailio!

Continue reading What I learned about H.264 for WebRTC video (Tim Panton) at webrtcHacks.

Three months and a bit till the start of Kamailio World 2019, the 7th edition of the conference about Kamailio project eco-system and the open source real time communication platforms.If you want to contribute to the success of the event and benefit of a great exposure, you can join us as a sponsor. You can choose from several standard packages presented in the Sponsorship page [1] of the event website or ask for a personalized package that can be tailored to suit better your needs [2].Many of the persons with relevant contributions to the evolution of the project are invited to the event, besides that the sponsorships help to cover the costs on site for all speakers. Also, we are offering again several grants to students interested in real time communications (last edition we had four students from Spain, Germany, Poland and Czech Republic). If SER-OpenSER-Kamailio helped you along the years, your support can add on board more people that can contribute back to the project as well as having a great event with many developers and the project community at Kamailio World 2019!Do not hesitate to contact us for more details about sponsorship options.

• [1] https://www.kamailioworld.com/k07/sponsorship/
• [2] https://www.kamailioworld.com/k07/contact-us/

See you in Berlin!

This is going to be awkward. For me? WebRTC is an open source media engine with a publicly known JavaScript API that got implemented in browsers.

I’ve written a “what is WebRTC” article more than once. The most notable ones?

1. What is WebRTC? – an article from 2017
2. WebRTC FAQ: The 2018 Version
3. WebRTC for Business People – a report that got updated in 2017, with a new 2019 edition coming real soon
4. Advanced WebRTC Architecture Course – a full length paid for course that teaches WebRTC

This time, I wanted to check what Google thinks of WebRTC, so I started asking it:

Before we continue down this rabbit hole, make sure to register and join me in two weeks for a webinar covering Mesh, MCU and SFU topologies and what each one is good for in your WebRTC application.

Lets go one by one over these alternatives, trying to understand what are people looking for in their WebRTC.

WebRTC is disabled

Somehow, this got the highest ranking. VPN vendors doing their best with FUD and SEO here, in trying to get people to disable WebRTC in browsers.

Reminds me of the good old days when people disabled JavaScript in their browsers.

WebRTC does give access to the camera, microphone, screen and local IP address of a user. Most of it under the user’s own volition. You can use browser extensions to support local IP address “leaks”, while in Safari exposing local IP addresses requires user authorization of some sort as well.

Not sure how this got first place in “WebRTC is”.

WebRTC is free

Yes it is. Mostly. Somewhat. If you understand what “free” is.

You can go to webrtc.org and download it for free. You can even use it and modify it.

But then again, hosting a service isn’t free. Someone needs to pay for the network and electricity. Someone needs to do the coding.

Things brings a rather interesting mindset that I see in entrepreneurs and developers – they feel like using a third party framework or even a managed service should be free – or a lot cheaper than it is. So they go about developing it on their own, spending time and money on development (and a lot of times a lot more than it would have been just picking up a managed service instead).

That concept of free in WebRTC? It is mostly about removing barriers of entry for vendors. It isn’t about free video calling.

WebRTC is_component_build

Beats me how this got so high as a suggestion by google.

The build system in WebRTC is often challenging. That’s because Google maintains the main WebRTC open source project with the main purpose of being embedded in Chrome. Due to this, it is just part of the Chrome build process and scripts, and not a standalone product or library.

This part is probably the most painful in WebRTC for developers who need to modify or adapt it for native applications.

Still not sure why it ranks so high.

WebRTC is dead

It isn’t. Can’t even call it a grownup or a teanager.

Moving on.

WebRTC is ready

Yap. it is.

WebRTC is ready. Developers will still bitch and whine that it isn’t complete and changes all the time breaking things up, but at the end of the day – if you’re doing something with communications these days, WebRTC should be the first thing to look at before searching elsewhere.

WebRTC is udp

It is also TCP. With a dash of SCTP. With talks about making it QUIC. Go figure.

UDP is what WebRTC uses to send its media. It works well because TCP has this nasty habit of retransmitting things to make sure they get received. This retransmission thing doesn’t work well where what you’re sending is time sensitive (like media of an interactive conversation).

Not sure why this one is in the top 10 either.

WebRTC is_clang

Like is_component_build, is_clang is also a build/compiler related setting. In this case, deciding which C/C++ compiler to use with WebRTC.

And again, I am clueless as to how and why this is such a popular Google search for WebRTC is.

WebRTC is not defined

This is golden.

The search itself is most probably related to compilation and runtime errors of developers with WebRTC, where they post the error messages around the web in stack overflow, discuss-webrtc and other online forums – asking for help from fellow developers.

Yet…

WebRTC isn’t defined. Yet.

People primsed me WebRTC 1.0 since 2015. Maybe a year or two earlier. We are now in 2019, talking about things like WebAssembly in WebRTC. But we still don’t have WebRTC 1.0. We’re getting there, but it is still a draft. Will WebRTC 1.0 standardization complete in 2019? Maybe. But WebRTC is not defined. But it is ready. Go figure.

WebRTC is p2p

WebRTC is peer to peer.

You can send media directly from one browser to another (if network conditions allow). But you need to handle signaling in front of web servers, which is kinda centralized. And sometimes, sending media peer to peer won’t work media and has to be routed. And other times, you’ll want to send media towards a media server.

You can read more about it here – Get Over it: WebRTC isn’t Peer-to-Peer

WebRTC is supported

Something that is going to change meaning in 2019.

People used to ask “which browsers support WebRTC?” or “is WebRTC supported on X” where X is Internet Explorer, Edge or Safari.

Nowadays, we’re over that bit of a challenge, with the last gaps closing as well.

The shift of this one is going to be towards traditional voice and video services that are adding WebRTC support for guest access or for those who don’t want to install any apps.

In the last year or so, I’ve had to install a lot less applications for meetings I have with companies. It isn’t because we all use Google Meet – it is because almost all of the services (Zoom is the exception here) give WebRTC guest access. WebEx, GoToMeeting, Amazon Chime – all offer WebRTC support. So I can easily handle these calls without installing anything. And yes – WebRTC is supported.

What’s your WebRTC is search term?

I found this list of google search suggestions for WebRTC is quite interesting. Not exactly what I expected starting out.

For me, WebRTC is progress. It is the next step we’re taking in figuring out communications, and in that, it fills the role of one of the most basic building blocks we now have and use.

What about you? WebRTC is …

Looking to learn more about what WebRTC is? How about understanding about mesh, mixing and routing architecture? You should join me for this free webinar:

Register to Mesh, MCU or SFU webinar

The post Asking Google: WebRTC is … appeared first on BlogGeek.me.

AppRTC isn’t your friend when it comes to developing a commercial WebRTC application.

I already wrote about the fact that there’s no free TURN server from Google. It seems that I failed to mention the fact that you shouldn’t use Google’s “free” STUN server in production either. Which leads us to this great question on github on AppRTC:

apprtc websocket server down?

The interesting part about this one is that no one from Google commented on it at any point in time.

You see, AppRTC wasn’t meant as a full fledged application, and to some extent, not even as a reference application for other developers. It is mostly meant to be a hello world type of an example.

With a glaring lack of good, simple, popular open source signaling frameworks for WebRTC,
developers sometimes use AppRTC for that purpose.

Signaling is important, and so is media. If you want to learn more about mesh, mixing and routing architecture, you should join me for this free webinar:

Register to Mesh, MCU or SFU webinar

While I use AppRTC for baselining, I don’t think it is a good starting place for actual development of a real service.

Here are 4 reasons why:

#1 – AppRTC doesn’t get much love and attention

Look at github insights for AppRTC:

See the number of additions and deletions taking place in 2018?

Latest commit? March 2018.

One could argue that this is because the “Hello World” example for WebRTC is already quite polished and working well, so there’s no need to change anything. Or that WebRTC is now stable enough.

#2 – This is just a “Hello World”

Here’s an example of a Hello World js function:

function hello(name){ console.log("Hello " + name); } hello('node.js');

This isn’t a starting point I’d use for writing an application.

The AppRTC application is admittedly larger. Here’s the lines of code count for its github project at the time of writing (not that I’d expect much change to it in 2019):

The problem is in what AppRTC doesn’t include, which many developers want/try to add:

• Android and/or iOS AppRTC apps – these aren’t available from Google. There are 3rd party projects for it you can find on github, but they are even less maintained than the Google AppRTC one
• Screen sharing – it isn’t there. Need it? Add it on your own
• Multiparty – not there either. And if you’d try using AppRTC for it, my guess is you’d end up with a mesh architecture (which for 99.9% of the use cases and most definitely for your use case – is destructive)

#3 – Not built to scale

AppRTC uses a python based signaling server, which is great. The actual signaling protocol selected and used isn’t really documented anywhere, so you’ll need to dive into the code to figure it out if you’ll want to add or modify anything. And you will, simply because a lot of functionality you might want is missing.

The thing is, if you plan on scaling up your service to large number of users, you’ll need this to work across machines – and that’s not easy – or at least not trivial.

At Kranky Geek 2016, Google explained what they did to scale and improve signaling for their own production services. Check out what that means:

Not everyone needs to do things at scale, but many do. Starting for AppRTC places you at the wrong place for growth.

And when it comes to edge cases, it doesn’t cover them all – if ICE negotiation fails, you won’t know about it on the UI, just have it as an ICE failure message in the console log. That’s the example I’ve bumped into when using testRTC with it and closing all ports but 443.

#4 – Don’t iframe or URL to it

Running a service and just need basic meeting capabilities?

Don’t place AppRTC in an iframe of your app or have a URL to it open in another window.

You don’t get an SLA from Google when using AppRTC, and they won’t treat it like a critical service when it fails to run. Throughout the years there have been times when AppRTC was down for one reason or another.

Upwork, for example, used to use a third party free/sample/demo service similar to AppRTC or Jitsi Meet. You had to schedule a meeting with people you work with on Upwork? Click a button, it created a kind of an ad-hoc, random URL for that meeting and opened it on a new browser tab. They were smart enough to replace it with their own branded meetings feature later down the road.

That service that Upwork used? No longer exists. Want to get a signed guarantee from Google that AppRTC will stay up and running and work the same way it does today 2 years from now?

If you plan on running a serious business, host your own communications infrastructure or pay for it.

Do you have any other alternative?

Not really. Not an immediate one at least.

People are still falling to the trap of using peerjs (see here why NOT to use peer.js).

We used to have EasyRTC and SimpleWebRTC in the past. EasyRTC still gets some love and attention, so you can try it out. SimpleWebRTC is now deprecated – &yet have decided to offer it “as a service” instead.

There are many other github projects offering webrtc signaling. Most of them seem to be projects people built for themselves but never really matured to a robust framework that others have adopted.

I started suggesting matrix, but many don’t really manage getting WebRTC to work well with out.

Then there’s the cloud based services – PubNub, Pusher, Scaledrone, Ably and even Google’s Firebase. These give you robust transport where you can pour your signaling protocol into.

Or a commercial software you can install anywhere such as Frozen Mountain’s WebSync.

In many cases, this will be an each to his own situation, where you’ll just need to develop it yourself or start somewhere and make it your own quite fast.

Signaling is important, and so is media. If you want to learn more about mesh, mixing and routing architecture, you should join me for this free webinar:

Register to Mesh, MCU or SFU webinar

The post What is a WebRTC Signaling Server and Why You Should NOT Use AppRTC? appeared first on BlogGeek.me.

Kamailio SIP Server v5.2.1 stable is out – a minor release including fixes in code and documentation since v5.2.0. The configuration file and database schema compatibility is preserved, which means you don’t have to change anything to update.Kamailio® v5.2.1 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.1Source tarballs are available at:

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

Detailed changelog:

• https://www.kamailio.org/pub/kamailio/5.2.1/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.1/

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. The registration is open!Thanks for flying Kamailio!

The registration for the 7th edition of Kamailio World Conference is now open! More details and registration forms are available on the website:

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

Like at the previous editions, the event spans over three days, May 6-8, 2019, taking place at our usual venue, in the hearth of Berlin city, Germany. The first day contains the technical tutorials, the following two days are for conference presentations and exhibition.With this edition, we are introducing a new social networking event during the evening of the first day, the 6th of May. The goal is to allow more time for interaction and networking between participants, as well as get a taste of Berlin. Therefore, this event is organized outside of the conference venue, couple of options being considered at this time, like city tour by boat or double deck bus, pub or pizza party. The cocktail party will take place as usual, during the evening of the 2nd day, the 7th of May. More updates about this new social networking event in the near future!Note also that the Call For Speakers is still in progress and we already have a consistent group of submissions, if you plan to present at Kamailio World 2019, hurry up with the proposal! Scalability and security, WebRTC, IMS and VoLTE or IoT with Kamailio as well as related projects such as Asterisk or FreeSwitch are among the topics to be covered this year.Keep an eye on the website of the event, soon we will publish more details about accepted speakers and the first draft of the agenda.Looking forward to meeting many of you in Berlin at Kamailio World 2019!

WebAssembly in WebRTC will enable vendors to create differentiation in their products, probably favoring the more established, larger players.

In Kranky Geek two months ago, Google gave a presentation covering the overhaul of audio in Chrome as well as there is WebRTC headed next. That what’s next part was presented by Justin Uberti, creator and lead engineer for Google Duo and WebRTC.

The main theme Uberti used was the role of WebAssembly, and how deeper customizations of WebRTC are currently being thought of/planned for the next version of WebRTC (also known as WebRTC NV).

Before we dive into this and where my own opinions lie, let’s take a look at what WebAssembly is and what makes it important.

Looking to learn more about WebRTC? Start from understanding the server side aspects of it using my free mini video course.

Enroll to the free course

What is WebAssembly?

Here’s what webassembly.org has to say about WebAssembly:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

To me, WebAssembly is a JVM for your browser. The same as Java is a language that gets compiled into a binary code that then gets interpreted and executed on a virtual machine, WebAssembly, or Wasm, allows developers to take the hard core languages (which means virtually any language), “compile” it to a binary representation that a Wasm virtual machine can execute efficiently. And this Wasm virtual machine just happen to be available on all web browsers.

WebAssembly allows vendors to do some really cool things – things that just weren’t possible to do with JavaScript. JavaScript is kinda slow compared to using C/C++ and a lot of hard core stuff that’s already written in C/C++ can now be ported/migrated/compiled using WebAssembly and used inside a browser.

Here are a few interesting examples:

• Construct 3 decided to use Opus in browsers. Even when it isn’t available – by implementing Opus with Wasm
• Zoom uses WebAssembly in order NOT to use WebRTC (probably because it doesn’t want to transcode at the edge of its network)
• Unity, the popular gaming engine has adopted Wasm for its Unity WebGL target

What’s in WebRTC NV?

While the ink hasn’t dried yet on WebRTC 1.0 (I haven’t seen a press release announcing its final publication), discussions are taking place around what comes next. This is being captured in a W3C document called WebRTC Next Version Use Cases – WebRTC NV in short.

The current list of use cases includes:

• Multiparty voice and video communications for online gaming – mainly more control on how streams are created, consumed and controlled
• Improved support in mobile networks – the ability to manage and switch across network connections
• Better support for media servers
• New file sharing capabilities
• Internet of Things – giving some love, care and attention to the data channel
• Funny hats – enabling AI (computer vision) on video streams
• Machine learning – like funny hats, but a bit more generic in its nature and requirements
• Virtual reality – ability to synchronize audio/video with the data channel

While some of these requirements will end up being added as APIs and capabilities to WebRTC, a lot of them will end up enabling someone to control and interfere with how WebRTC works and behaves, which is where WebAssembly will find (and is already finding) a home in WebRTC.

Google’s example use case for WebAssembly in WebRTC

At the recent Kranky Geek event, Google shared with the audience their recent work in the audio pipeline for WebRTC in Chrome and the work ahead around WebRTC NV.

For Google, WebRTC NV means these areas:

The Low Level APIs is about places where WebAssembly can be used.

You should see the whole session, but here it is from where Justin Uberti starts talking about WebRTC NV – and mainly about WebAssembly in WebRTC:

WebAssembly is a really powerful tool. To give a taste of it with WebRTC, Justin Uberti resorted to the domain of noise separation – distinguishing between speech and noise. To do that, he put up an online demo that takes RNNoise, a noise suppression algorithm based on machine learning, ported it to WebAssembly, and built a small demo around it. The idea is that in a multiparty conference, the system won’t switch to a camera of a person unless he is really speaking – ignoring all other interfering noises (key strokes, falling pen, eating, moving furniture, etc).

Interestingly enough, the webpage hosting this demo is internal to Google and has a URL called hangouts_echo_detector/hackathon_2018/doritos – more on that later.

To explain the intent, Justin Uberti showed this slide:

As he said, the “stuff in green” (that’s Session Management, Media Processing, Codecs and Packetizer/FEC/RTX) can now be handled by the application instead of by WebRTC’s PeerConnection and enable higher differentiation and innovation.

I am not sure if this should make us happier or more worried.

In favor of differentiation and innovation through WebAssembly in WebRTC

Savvy developers will LOVE WebAssembly in WebRTC. It allows them to:

• have way more control over the browser behavior with WebRTC
• add their own shtick
• do stuff they can’t do today – without waiting on Google and the other browser vendors

In 2018, I’ve seen a lot of companies using customized WebRTC implementations to solve problems that are very close to what WebRTC does, but with a difference. These mainly revolved around streaming and internet of things type of use cases, where people aren’t communicating with each other in the classic sense. If they’d have low level API access, they could use WebAssembly and run these same use cases in the browser instead of having to port, compile and run their own stand-alone applications.

This theoretically allows Zoom to use WebRTC and by using WebAssembly get it to play nice with its current Zoom infrastructure without the need to modify it. The result would give better user experience than the current Zoom implementation in the browser.

Enabling WebAssembly in WebRTC can increase the speed of innovation and spread it across a larger talent pool and vendors pool.

In favor of a level playing field for WebRTC

The best part about WebRTC? Practically any developer can get a sample application up and running in no time compared to the alternatives. It reduced the barrier of entry for companies who wanted to use real time communications, democratizing the technology and making it accessible to all.

Since I am on a roll here – WebRTC did one more thing. It leveled the playing field for the players in this space.

Enabling something like WebAssembly in WebRTC goes in the exact opposite direction. It favors the bigger players who can invest in media optimizations. It enables them to place patents on media processing and use it not only to differentiate but to create a legal mote around their applications and services.

The simplest example to this can be seen in how Google itself decided to share the concept by taking RNNoise and porting it to WebAssembly. The demo itself isn’t publicly available. It was shown at Kranky Geek, but that’s about it. Was it because it isn’t ready? Because Google prefers having such innovations to itself (which it is certainly allowed to do)? I don’t know.

There’s a dark side to enabling WebAssembly in WebRTC – and we will most definitely be seeing it soon enough.

Where do we go from here?

WebRTC is maturing, and with it, the way vendors are trying to adopt it and use it.

Enabling WebAssembly in WebRTC is going to take it to the next level, allowing developers more control of media processing. This is going to be great for those looking to differentiate and innovate or those that want to take WebRTC towards new markets and new use cases, where the current implementation isn’t suitable.

It is also going to require developers to have better understanding of WebRTC if they want to unlock such capabilities.

Looking to learn more about WebRTC? Start from understanding the server side aspects of it using my free mini video course.

Enroll to the free course

The post What’s the Role of WebAssembly in WebRTC? appeared first on BlogGeek.me.

Fosdem 2019 is approaching, so we surveying to see who from the community plans to go to the event. We also plan to organize again a dinner on Saturday evening, a tradition for our project at the past 10 editions or even more.Henning Westerholt will give a presentation about Kamailio in the RTC Devroom.Several other developers plan to go to the conference as well, among them Daniel-Constantin Mierla, Federico Cabiddu and Alexandr Dubovikov, therefore we open here the invitation to join for everyone in our community. Of course, at Fosdem will be developers from other VoIP projects, like Asterisk, Janus, CGRates, Homer, Jitsi, …At the past editions we typically had two “kamailio” events:

• (1) an “ad-hoc” developers meeting in the cantina (or other available
  room around) to discuss about short term plans for Kamailio — time and
  place being decided as we meet there between us (expected in the
  afternoon of Saturday or during Sunday).
• (2) a dinner at a place nearby, with other VoIP folks joining us

If you plan to go to Fosdem and want to join the dinner, announce yourself on sr-users@lists.kamailio.org mailing list. Just be aware that you have to pay for your food and drinks at the dinner, unless we are going to be surprised again by a generous sponsor that covers partially or completely to dinner.If you need more details about Fosdem, the website is:

• https://fosdem.org

Thanks for flying Kamailio!

Small, Medium, Big or Extra Large? How do you like your WebRC SFU Media Server?

I just checked AWS. If I had to build the most bad-ass, biggest, meanest, scalest, siziest server for WebRTC. One that can handle gazillions of sessions, I’d go for this one:

A machine to drool over… Should buy such a toy to write my articles on.

Or should I go for the biggest machine out there?

I did a round-up of some of the people who develop these SFUs. And guess what? None of them is ordering the XL machine.

They go for a Medium or Medium Well. Or should I say Medium Large?

Media servers, Signaling, NAT traversal – do you know what it takes to install and manage your own WebRTC infrastructure? Check out this free video course on the untold story of the WebRTC servers backend.

Start your free course

Anyways – here are a few things to think about when picking a machine for your SFU:

Going BIG on your SFU

As big as they come that’s how big you wanna take them.

We called it scale up in the past. Taking the same monolith application and put it on a bigger machine to get more juice out of it.

It’s not all bad, and there are good reasons to go that route with a media server:

Managing less machines

If one big machine does the work of 10 smaller machines, then all in all, you’ll need 1/10 the number of machines to handle the same workload.

In many ways, scaling is non-linear. To get to linear scaling, you’ll need to put a lot of effort. Different bits and pieces of your architecture will start breaking once you scale too much. In this sense, having less machines to manage means less scaling headaches as well.

Having bigger rooms

Group calling is what we’re after with media servers. Not always, but mostly.

Getting 4 people in a room is easy. 20? Harder. 500? Doable.

The bigger the rooms, the more you’ll need to start addressing it with your architecture and scale out strategies.

If you take smaller machines, say ones that can handle up to 100 concurrent users, then getting any group meeting to 100 participants or more is going to be quite a headache – especially if the alternative is just to use a bigger machine spec.

The bigger the rooms you want, the bigger the machines you’ll aim for (up to a point – if you want to cater for 100+ users in a room, I’d aim for other scaling metrics and factors than just enlarging the machines).

Less fragmentation

Similar to how you fit chunks of memory allocations into physical memory, fitting group sessions into media servers, and maybe even cascading them across machines will end up with fragmentation headaches for you.

Let’s say some of your meetings are really large and most are pretty smallish. But you don’t really know in advance which is which. What would be the best approach of starting to fit new rooms into existing media servers? This isn’t a simple question to answer, and it gets harder the smaller the machines are.

Simpler architecture (=no cascading)

If you are setting up the media server for a specific need, say catering for the needs of a hospital, then the size is known in advance – there’s a given number of hospital beds and they aren’t going to expand exponentially over night. The size of the workforce (doctors and nurses) is also known. And these numbers aren’t too big. In such a case, aiming for a large machine, with an additional one acting as active/passive server for high availability will be rather easy.

Aiming for smaller machines might get you faster to the need to scale out in your architecture. And scaling out has its own headaches and management costs.

Simpler

Bigger machines are going to be simpler in many ways.

Going small on your SFU

This is something I haven’t thought about as an alternative – at least not until a few years ago when I was helping a client in picking a media server for his cloud based service. One of the parameters that interested him was how small was considered too small by each media server vendor – trying to understand the overhead of a single media server process/machine/application.

I asked, and got good answers. I since decided to always look at this angle as well with the projects I handle. Here’s where smaller is better for WebRTC media servers:

Easier to upgrade

I dealt with upgrading WebRTC media servers in the past.

There are two things you need to remember and understand:

1. WebRTC moves fast (and breaks things while doing so)
2. You’ll need to update your backend rather frequently, including your media servers

The most common approach to upgrades these days is to drain media servers – when wanting to upgrade, block new sessions from going into some of the media servers, and once the sessions the are already handling are closed, kill and upgrade that media server. If it takes too long – just kill the sessions.

Smaller machines make it easier to drain them as they hold less sessions in them to begin with.

Having more machines also means you can mark more on them in parallel for draining without breaking the bank.

Blast radius of crashes

This is what started me on this article to begin with.

I took the time to watch Werner Vogels’s keynote from AWS re:Invent which took place November 2018. In it, he explains what got AWS on the route to build their own databases instead of using Oracle, and why cloud has different requirements and characteristics.

Here’s what Werner Vogels said:

With blast radius we mean that if a failure happens, and remember: everything fails all the time. Whether this is hardware or networking or transformers or your code. Things fail. And what you want to achieve is that you minimize the impact of such a failure on your customers.

Basically, if something fails, the minimum set of customers should be affected, if that’s the case.

Everything fails all the time.

And we do want to minimize who’s affected by such failures.

The more media servers we have (because they are smaller), the less customers will be affected if one of these servers fail. Why? Because our blast radius will be smaller.

CPU utilization

Here’s something about most modern media servers you might not have known – they don’t eat up CPU. Well… they do, but less than they used to a decade ago.

In the past, media servers were focused on mixing media – the industry was rallied around the MCU concept. This means that all video and audio content had to be decoded and re-encoded at least once. These days, it is a lot more common for vendors to be using a routing model for media – in the form of SFUs. With it, media gets routed around but never decoded or encoded.

Media servers, Signaling, NAT traversal – do you know what it takes to install and manage your own WebRTC infrastructure? Check out this free video course on the untold story of the WebRTC servers backend.

Start your free course

In an SFU, network I/O and even memory gets far more utilized than the CPU itself. When vendors go for bigger machines, they end up using less of the CPU of the machines, which translates into wasted resources (and you are paying for that waste).

At times, cloud vendors throttle network traffic, putting a limit at the number of packets you can send or receive from your cloud servers, which again ends up as putting a limit to how much you can push through your servers. Again, causing you to go for bigger machines but finding it hard to get them fully utilized.

Smaller machines translates into better CPU utilization for your SFU in most cases.

Number of Cores/CPUs and Your SFU’s Architecture

Big or small, there’s another thing you’ll need to give your thought to – and that’s the architecture of the media server itself.

Media servers contain two main components (at least for an SFU):

1. Control/signaling
2. Media routing

Sometimes, they are coupled together, other times, they are split between threads or even processes.

In general, there are 3 types of architectures that SFUs take:

1. Have a single process handle both control and media; doing it in a multithreaded mode
2. Have separate processes that can scale out, running each on its own machine or thread
3. Decoupling control and media and having both of them scale out independently of each other

Me? I like the third alternative for large scale deployments. Especially when each process there is also running a single thread (I don’t really like multithreaded architectures and prefer shying away from them if possible).

That said, that third option isn’t always the solution I suggest to clients. It all depends on the use case and requirements.

In any case, you do need to give some thought to this as well when you pick a machine size – in almost all cases, you’ll be used a multi-core multi-threaded machine anyway, so better make the most of it.

How Do You Like Your SFU?

Back to you.

Media servers, Signaling, NAT traversal – do you know what it takes to install and manage your own WebRTC infrastructure? Check out this free video course on the untold story of the WebRTC servers backend.

Start your free course

The post What’s the Best Size for a WebRTC SFU Media Server? appeared first on BlogGeek.me.

Fast, so fast, the 2018 is gone, one of those years of consolidation in terms of development and community activity for the Kamailio project, with another major release and an amazing edition of Kamailio World Conference! Thank you everyone for contributing to the project!We are now looking forward to a healthy and fruitful year 2019 to all Kamailio friends and the project itself, once again hoping to meet many of you at the 7th edition of Kamailio World Conference and other events around this magnificent world!Thanks for flying Kamailio!Enjoy 2019 and stay safe!Happy New Year!