News from Industry

How many WebRTC RTCPeerConnection objects should we be aiming for?

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

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

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

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

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

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

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

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

Multiple RTCPeerConnection objects are great:

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

That said, they have their own challenges and overheads:

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

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

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

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

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

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

WebRTC RTCPeerConnection and a multiparty video service

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

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

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

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

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

Opentok: RTCPeerConnection per user

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

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

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

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

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

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

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

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

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

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

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

A few things to note about Opentok:

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

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

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

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

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

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

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

Jitsi Videobridge: Shared RTCPeerConnection

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

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

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

A single peer connection for all incoming media channels.

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

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

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

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

A few things we can see here:

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

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

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

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

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

Shared or per user RCTPeerConnection?

This is a tough question.

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

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

Here’s a quick table to summarize the differences:

What’s Next?

Here’s what we did:

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

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

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

 

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

The development (master) branch of Kamailio enters now in pre-release phase for version 5.0.0. Therefore, no new feature should be pushed to master until we create a dedicated branch for 5.0 (expected to be in about 4 weeks or so).If in doubt to push or not a commit to master branch, push it first on a personal branch (or attach to an email) and discuss it on sr-dev mailing list. The new modules can be a bit more dynamic if there is need to get them to the right shape (e.g., like decision to rename functions, parameters or adjust database structure).We hope to get many people involved in testing, to reach a stable state before releasing 5.0.0. If you want to get involved and need assistance, don’t hesitate to write to mailing lists.Besides the new features, there were two major changes for 5.0:

• source code tree restructuring – this should not affect the stability of the code, only installation scripts or packaging may still need tuning
• mi (management/control interface) code has been removed. SIP routing code should not be affected by this change that much, but testing of RPC commands needs a special care. There are few RPC commands not ported yet from the MI code, they can be done during the testing period

Moreover, help with updating the wiki page for migration from 4.4 to 5.0 as well as what is new in 5.0 is very appreciated. More updates about them very soon.Many thanks to everyone involved in development of 5.0 and the early testers that played with master branch so far.Thank you for flying Kamailio!Looking forward to meeting many of you at Kamailio World 2017!

No active MI (aka management interface) related code should be in Kamailio master branch starting with today, Jan 4, 2017. The internal library kmi, the modules mi_datagram, mi_fifo, mi_xmlrpc, mi_rpc and pua_mi were removed.The MI was a custom mechanism introduced in the early days of the project (like 2001-2002) to interact with Kamailio at runtime, using a line-based text protocol through FIFO file, with alternative transport via datagram sockets or xmlrpc. It was declared deprecated several years ago in favour of using the RPC interface. The RPC interface offers a better structured interaction protocol, with transports for XMLRPC, BINRPC and JSONRPC over HTTP(S), TCP, UDP, UNIXSOCKET or FIFO files.Couple of modules still have some mi code disabled with ifdefs, they are pending the port to RPC commands. These are: carrierroute, ims_dialog, mohqueue, p_usrloc, userblacklist, utils. They should be updated in the next few days.With MI code removed, the code base got slimmer, the future development and maintenance effort is reduced.From now on, the RPC interface has to be used for interacting with kamailio at runtime.The CLI tools were updated as well:

• kamctl – was already migrated to use RPC via jsonrpcs module.
• kamcmd – was developed to use only RPC interface via ctl module.
• kamcli – is also working with RPC via jsonrpcs module

Helping with testing the RPC commands is very appreciated — open an issue on bug tracker whenever you discover a problem.Thanks for flying Kamailio!

2016 has reached its end, a special one for Kamailio by celebrating 15 years of development! Thank you everyone for contributing to the project!We are looking forward to a great 2017, the release of v5.0.0 is around the corner! We wish a healthy and prosperous year 2017 to all Kamailio friends, hoping to meet many of you at Kamailio World Conference and other events around the globe!Thanks for flying Kamailio!Enjoy and stay safe!Happy New Year!

Passing the 15 years of development marker for Kamailio project few months ago, we are now approaching the end of 2016. A long list of people devoted a lot of time in sustaining the project with resources for development, support and advertising. So this is a good moment to thank and greet them, everyone involved in Kamailio project, old and new friends, developers, contributors, the engaged and warm community members.We are very close to the moment of freezing the version 5.0.0, a new major milestone in the project evolution, with a restructured source code tree, cleaner and slimmer code base, a new flexible configuration file framework that allows building SIP routing script in embedded languages such as Lua and Python, a.s.o. – all making a very solid foundation for developing next releases! Good premises to expect a lot of new stuff in 2017!The 5th edition of Kamailio World Conference, the project’s annual event, is scheduled for May 8-10, 2017, in Berlin, Germany. We look forward to meeting many of the community members there!Merry Christmas and Happy Winter Holidays!Santa is flying Kamailio!

There is no real peak telephony.

[Chad Hart is no stranger to my readers here. He runs webrtcHacks, part of the Kranky Geek team and works at Voxbone. This time, he takes a look at telephony and where it stands today – with and without WebRTC]

Back in April of 2015, I recall Google WebRTC Product Manager Serge LaChapell talking about the WebRTC team’s focus on mobile and how they wanted to kick “VoLTE’s butt”. To be fair he was referencing call connection times, but reading between the lines I like to believe he has had ambitions well beyond that – namely beating VoLTE and the traditional telephony network in minutes.

"We want to kick VoLTE's butt" @slac talking about #webrtc mobile improvements pic.twitter.com/f1aVnSbgMK

— Chad Hart (@chadwallacehart) April 15, 2015

For many years I have tried to keep track of how the traditional telecoms has fared against the emerging VoIP application world (what they sometimes derogatorily call “OTT”).  I have had two hypotheses for several years now:

1. Traditional telecoms over the PSTN is past “peak” and will continue to decline
2. Real time communications (RTC) in general has been on the decline but is poised to make a comeback thanks to better implementations and technologies like WebRTC

Let’s check the data to test these statements.

Peak Telephony? Maybe Not…

Digging into the statistics from various sources, I was surprised to find I was wrong about my first hypothesis on peak telephony.

The US market

Let’s start by taking a look at the situation in the US, one of the world’s largest communications markets. The Consumer Telecommunications Industry Association (CTIA) provides an annual update that sometimes includes Minutes of Use (MoU) and subscriber data. The data shows that on a subscriber-level, mobile telephony usage already peaked on a per-subscriber basis in 2007.

However, there is a growing number of data-only subscriptions for our tablets and other devices counted as subscribers. This negatively skews the numbers. Looking at “minutes” on a per capita basis is a cleaner metric, so let’s divide the minute figures by the US population. This shows a much more interesting picture where mobile phone usage for traditional calling actually went up by 16%.

Total US cellular telephony minutes appear to be rising after stalling for many years (my calculations)

Checking the data against other FCC sources, this growth may be overstated but there is no clear evidence of decline. So what’s going on? Much of cellular’s continued volumes can be attributed to fixed-mobile substitution – both in terms of people dropping their fixed lines and as the FCC reports  “A significant percentage of homes with both landline and wireless phone access received all or almost all calls on wireless telephones despite also having a landline telephone.” If we assumed total PSTN calling was flat, then according to my estimates, a 30% annual decline in fixed line minutes would be required to explain the decrease. This is possible, but way faster than past usage declines in fixed so it is more likely cellular usage did indeed have a very good year in 2015.

There is no clear evidence of peak PSTN telephony in the US, so let’s check some other sources.

The UK market

The UK’s Ofcom is generally a much better datasource than the FCC since they look at communications as a whole within the UK and compare it to other countries.

They are a lot more pessimistic when it comes to PSTN-based telephony. Their data is very definitive showing a continued, gradual decline in PSTN call volumes going back to 2010.  With a -3% 5 year CAGR, no matter how you cut it, “operator” traffic is down.

Ofcom CMR 2016 report shows declines in operator voice usage

They have not released their global figures for 2015, but their 2014 report showed similar trends with mature markets declining (US, Western Europe, Japan & Korea). However, emerging marketings like China, India, and Russia show show growth and just make up for declines in the mature markets in 2014.

Does anyone care about the PSTN anyway?

Outside of adding touch tone dialing and going cordless, the Public Switched Telephone Network (PSTN) telephony user experience hasn’t exactly changed a whole lot in a hundred years. The PSTN is only one way to make calls – now we dedicated VoIP apps,  messenger apps with voice, and a growing number of video communications options. Do these new forms for RTC give us any hope of reversing traditional telephony’s demise? The data here is more positive.

Ofcom’s data shows an increasing usage of VoIP for voice calls and a very definitive increase in video call usage. This is consistent with their international research from a year earlier:

VoIP Apps Save the Day

So where do newer RTC apps and features fit into all this? Using Ofcom’s methodology, the 18 countries they track produce somewhere around 10 Trillion minutes a year. Microsoft has previously claimed Skype does up to 3 Billion minutes a day – that’s a Trillion minutes a year if one assumes around a 3 Billion daily average. Even if the true annual value is half of that, clearly Skype alone is meaningful compared to PSTN volumes.

Apple does not release any figures for its FaceTime service introduced in 2011, but presumably its usage is substantial, although less than Skype’s based on Ofcom’s past user surveys. WeChat, Line, and Viber all have more than 200 million monthly active users with various VoIP features. WhatsApp now has more than 1 billion MAU. Its VoIP calling feature launched in April 2015 has more than 100 million voice calls a day. Taken together, these other VoIP services are easily more than a trillion minutes a year.

At 10 to 20% of the PSTN’s volume, clearly VoIP traffic has a ways to go before it dominates the PSTN, but there is no doubt its volumes are meaningful in comparison.  Furthermore, these services are still growing. Certainly some of that growth will come at the expense of the PSTN, but it appears they are also encouraging more RTC use in general.

Does WebRTC matter?

WebRTC does not factor heavily into the services cited above, but that is poised to change. At only 5 years old, WebRTC has not had that much time to widely establish itself in relation to other VoIP technologies. Still, there are a few notable standouts – particularly notably Facebook Messenger. Facebook has stated it has more than 300 million monthly active users of Messenger’s VoIP features and just this week announced it had 245 million monthly video users. Other notable users include Snapchat and of course Google’s Hangouts and Duo services.

There are a lot of other WebRTC apps showing big user gains too such as Houseparty which reported it had 20 million minutes of usage a day last month – not bad for an app that only emerged from the ruins of Meerkat a few months ago. In addition, more traditional VoIP apps like Whatsapp and Skype are starting to use WebRTC, albeit in limited circumstances today but that will certainly grow too.

In aggregate, I estimate WebRTC-based services easily have over 500 million MAU this year across 2 billion devices. Comparing this to other VoIP technologies at the 5 year mark, WebRTC is way ahead. This bodes well for WebRTC to be an incremental driver of VoIP traffic and further accelerator of RTC.

Conclusions

I have been concerned that the desire of people communicate in real time reached its pinnacle long ago. Why focus on RTC if the trend is clearly toward “messaging” and other forms of textual interaction?  Has telephony peaked? The evidence suggests that is probably the case for the PSTN in developed markets, but there are plenty of pockets of growth. Where declines exist, they are gradual. Even better, there is a large body of evidence that VoIP services are more than making up the gaps of any declines and then some. This indicates that we are actually using real time communications more than even. The recent and rapid rise of many WebRTC services is a further shows that this trend is very likely to continue, or perhaps even accelerate. That’s great news for the hundreds of WebRTC vendors out there and those that have yet to come.

The post Can WebRTC save telephony? appeared first on BlogGeek.me.

Management Interface (MI), the old line-based text protocol interface to interact with Kamailio is going to be removed in the near future. It was declared obsolete several years ago, when we introduced the RPC interface. With upcoming version 5.0 already having the code source tree restructured, this step makes a better and slimmer foundation for next generation of releases.The default configuration file is now shipping with jsonrpcs module and kamctl tool is using the RPC interface via jsonrpcs. The command line parameters for kamctl should be the same like for the past releases, but the output is now in jsonrpc format.The RPC interface is implemented by the following modules:

• ctl – binary rpc protocol – with transport layers for FIFO file, unix sockets and IP sockets (both datagram and stream). It is the module used by the kamcmd tool.
• jsonrpcs – jsonrpc protocol – with transport layers for FIFO file, unix and IP sockets (datagram) and HTTP via xhttp module. It is the module used by kamctl and kamcli tools.
• xmlrpc – xmlrpc protocol – with transport layer for HTTP

If you were using mi_fifo or mi_datagram modules, then you can switch to jsonrpcs module (it offers the transports for the two mi modules). If you were using mi_xmlrpc, then you can switch to xmlrpc module.Thanks for flying Kamailio!

WebRTC is the most secure technology for video communications. And yet – developers can screw this for you.

There is a rise in security breaches and data theft incidents in 2016. You see this from the amount of information out there. I’ve written about WebRTC and security for quite some time, but a recent post I’ve read compelled me to write about it again.

The post? Red Cross Blood Service in Australia leaks personal data.

The gist:

• Site is secure
• A contractor places database dump on the internet for backup
• And that get found

It probably happens more often than not. You build a service. You take care of its security. And then, someone down the lines screws you over with his maintenance processes. To some extent, this is just as bad as social engineering, where a hacker tries to gain access by fooling people to believe he is someone else.

Make sure to download the WebRTC Security checklist. Print it and stick it on the wall behind your monitor so you don’t forget.WebRTC Security baseline

WebRTC comes with a few security concepts that are quite new and innovative in VoIP:

1. In WebRTC, EVERYTHING is encrypted. Not only by default, but also in a way that can’t be modified – there is no way to send data over WebRTC in the clear
2. WebRTC forces you to operate over HTTPS and WSS in your web application, so signaling gets encrypted as well
3. Screensharing requires an additional layer of consent, be it whitelisting of your site or a creation of a browser extension
4. Browsers today update frequently and automatically, so any security threat found gets patched faster than most enterprise and VoIP vendors react to their security breaches

The thing people forget is that WebRTC is just a piece of technology. A building block. It is up to the developers to decide how to use it in their own product. During that integration, security breaches can be created quite easily.

In the WebRTC course I launched two months ago, I’ve added a lesson dealing with WebRTC security. It goes through the mechanisms that exist in WebRTC and the areas that need to be further secured by the application.

Two big issues left to developers today are TURN passwords and access to backend server resources.

#1 – TURN passwords

TURN servers predate WebRTC. They are used by SIP (or at least are found in the spec), and there, the notion is that the user agent (=device/endpoint) is secure and “named”. So a username and password mechanism was created to get a TURN binding. The reason you want such a mechanism in the first place is because TURN servers are bandwidth hogs – they relay media, and by doing that they cost a lot in terms of bandwidth. So if you are paying for it, you don’t want others to piggyback on it.

The problem with this approach in WebRTC is that the username and password needs to be passed from your JavaScript code inside the browser to the server. Which means that information is available in the clear for many use cases – those where you don’t need or want the user to identify with the network at all.You also don’t want someone sniffing your code in the browser and then reusing these credentials elsewhere.

The current approach out there is to use temporary passwords (I like calling them ephemeral – it makes me sound intelligent). Ones that become useless in an hour or two.

This means that someone in your backend randomly creates a password that is short-lived and shares it with both the TURN server and the client.

The above illustrates how this is done.

• The App Server, in charge of signaling in this case, creates a password. It updates the TURN server about said password and also gives that information to the User
• The User then creates a peer connection, configuring the TURN server in it with the relevant temporary password

Great.

Now lets add a media server into the mix.

Who should be generating that password and passing it around to whom? Should the Media Server now be in charge of it, or is it up to the App Server still to take care of this?

Which leads me to the second important security aspect of WebRTC when it comes to your development – backend server resources you need to protect.

#2 – Backend server resources

In many cases, I find that when the work is outsourced, the end result tends to be a jumble of an architecture if things aren’t thought out properly from the beginning.

This usually causes the wrong servers to need to connect and communicate directly with the User. While not an issue on its own, it can easily turn into a headache:

• Not having a clear picture of the state in your backend means you lose control – this can turn ugly when issues arise
• Opening up more of your backend towards the internet means more points to secure against penetration
  • And yes – I know there’s a trend to treat servers in the cloud as if they are always open to the internet
  • Which means you need to think about how best to protect them in the first place anyway, which happens to be closing them as much as possible

What I suggest in many cases is:

1. Media servers should never be controlled or accessed directly from the Internet
2. Media servers should only pass media to and from the Internet
3. Whenever they need to be controlled, you do that using backend-to-backend communication from other servers you have that are already managing the users on the Internet

What’s next?

I am not a security expert. I know a bit about it and try to stay informed, but I am by no means an expert in it.

You should make sure to take security into consideration when developing your service and don’t assume WebRTC does everything for you. It doesn’t, but it is the best starting point you’ll get.

If you want to learn more about WebRTC, I will be opening the course again for another round. Probably during April.

If you are a corporate looking to have an open access to course materials throughout the year for your workforce – I am going to announce such a plan soon, but feel free to reach out to me before that happens.

Just do me a favor – don’t leave WebRTC security to chance.

Need a reminder? Download the WebRTC Security checklist. Print it and stick it on the wall behind your monitor so you don’t forget.

The post The Best WebRTC Security is Prone to the Stupidest Developer appeared first on BlogGeek.me.

Slack is an über popular and fast growing communications tool that has a ton of integrations with various WebRTC services. It also acquired a WebRTC company a year ago and launched its own audio conferencing service earlier this year which we analyzed here and here. Earlier this week they launched video. Does this work the same? Are […]

The post Slack Does WebRTC Video – Here’s How (Gustavo Garcia) appeared first on webrtcHacks.

Got a requirements document to write for WebRTC? Here’s a step by step guide to doing just that.

Here is something that I do with my customers quite often. In many cases, when I consult vendors, they are in the process of building a new product or integrating an existing product with some new communication capabilities. This involves using WebRTC and outsourcing the actual development.

More often than not, I find myself writing the baseline of the requirements document for the customer, to server as a WebRTC RFP (Request For Proposals) that get used to communicate the requirements with the potential outsourcing vendors.

I wanted to share the process that I use in writing the first draft of this document. To make this a bit more useful, let’s assume that what we want to do is build a webinars service, where a few people can join as the speakers in the webinar and people online can “listen in”.

I’ve created a WebRTC requirements template and a sample webinars requirements document that you can use when you need to write the requirements for your own product.

Get the WebRTC Requirements Template and Sample Webinars Requirements Document

Here’s step by step how I’d go about doing that.

Step #1: Structure your document

First things first. To make sure I don’t forget anything, I like to split my requirements document into 4 sections:

1. Overview
2. Architecture
3. Functional
4. Non-functional

As you can see in above, I place TBD for each section in the document. I do that for all sub sections that I add to the document as well. This way, I can easily search the areas that haven’t been filled in properly yet when I work on it. Most often than not, writing these WebRTC requirements take a couple of hours and span a few days because they are collaborative in nature.

I tend to leave out the mechanics around the project – such as the price model I am looking for, or the timeline of the project. These tend to change between companies and they often better reflected elsewhere than in the technical requirements that I try to describe here.

Step #2: Write the overview

First thing I do once I have the template ready for my needs is write the overview part.

I try to keep the overview short and sweet, with a focus on making sure people understand what it is that I am trying to achieve in the service – what my challenges are and what I consider as success.

Usually, 2-3 paragraphs should be enough.

Step #3: Describe the architecture

Now it is time to start thinking about our architecture. By that, I don’t mean the architecture of the solution, what processes, servers and switches I want – I leave that for the vendor to fill in. What I mean is the entities I have in my service, trying to focus around the session – the types of media and signaling I want running there.

I do this by going analog, and just jot it down on my whiteboard and taking a picture of the end result. I find this more natural for me than using Powerpoint or Vizio. Later on, I might redo it as a Powerpoint diagram, but more often than not, I just leave it as is.

Above is the drawing I just did to describe the BlogGeek.me Webinar I just invented.

After the visual, I explain the different entities that are in the drawing and the relations between them. This part is really important, as oftentimes, it will reveal entities or flows that I haven’t thought about earlier.

In the case of the BlogGeek.me Webinar, we’ve got multiple potential Speakers who interact using audio and video with each other in the Webinar, which then gets sent to multiple Viewers and also to an external Storage.

I try to keep things focused and to the bare minimum that is necessary for the understanding of the service.

Step #4: Fill in the features

To some extent, this step is the main chunk of what the product does. For me, this is a brain dump of the things a user should be able to do in the system.

There are different types of features you might be needing. I focus on those that relate to the communication part of the product and nothing else.

Here’s a checklist of what I usually go through when doing this:

• Is this a 1:1 service or multiparty?
• Audio? Video?
• Any screen sharing or other collaboration capabilities?
• Messaging/chat?
• How do users get authorized, authenticated and connected?
• Any in-session controls users need to have?
• Any indicators to show on their display?
• Do we need recording capabilities?
• Anything that we missed?

Make sure you answer all the questions above as requirements in the document if they make sense and add your own to the list.

Here are a few of the ones I’ve written for the webinars product:

Notice how I’ve indicated that connectivity via PSTN is optional in a future phase? This serves two purposes for me:

1. It gives the vendor a hint of what architecture to put in place to support this later on down the road
2. It also gives the vendor a feeling that this is a journey and not a one-off project. He will be more committed to its success if he knows you might call on him later on to improve and extend the service

Step #5: Handle the non-functional requirements

Now it is time to go over the non-functional requirements. These are the boring and ugly details that can make or break a service, so spend enough time on this one.

What do I mean by non-functional? These will usually be things you will take for granted, but the vendor won’t. To reduce friction and arguments in the future, I add these. In most likelihood, if you don’t write these down, a vendor will ask about a few of these things anyway – so just write them down to reduce the unnecessary round trips and to make sure you and the vendor are on the same page.

I tend to split this section to 5 subsections, each with its own focus:

1. Devices

Here I list all the devices I want to support. Browsers, operating systems, mobile devices, etc.

Each gets its own special treatment. Things I usually look at here are:

• Which browsers to support natively?
• Do I need an Electron PC app? If I do, then on which operating systems?
• What versions of iOS to support? Which earliest devices?
• What versions of Android API to support? How many specific devices do I want tested?

In many ways, I derive the requirements here based on the WebRTC Device Cheat Sheet that I published.

2. NAT traversal

NAT traversal is often overlooked. There are two areas where I cover NAT traversal – here and in the Security subsection below.

Here, I define who takes care of it – do I expect the vendor to bring a NAT traversal solution, will I be doing it, or should they use a third party hosted service (there are a few out there offering it).

The second part that I sometimes decide here, but not always, is where I want it deployed – along with the media servers or closer to the connecting user. It is a matter of architecture needs that I prefer leaving to the vendor to fill in but not always (can’t really say when in a definitive way).

In my webinar example, I decided to make things easy and just use a third-party hosting service:

3. Scalability

For scalability I make sure I cover a few areas:

1. What’s the scale of a single session? Just make sure that if there are different types of users, you indicate how each can scale
2. What’s the scale of the service as a whole? How many sessions can exist concurrently?
3. Do I need to address any geographical locations when it comes to scaling?
4. How are the different parts of the systems scale? Independently of each other?

Here’s how I fit it into our webinar example:

4. Security

The security part is slightly tricky. First, because I am not an expert. But also because almost nobody is.

What I usually place here is the basics of how I’d like to see the backend (encryption between the servers), but I do cover two important areas:

1. Media servers. I prefer access to them to be limited to the application server only when it comes to control and have all signaling be routed through the application server or a signaling server. I don’t like giving access to my resource hog openly over the internet. Call me old fashioned
2. TURN servers. Here I always state that I want ephemeral passwords. Otherwise, vendors usually do the short route of using a static username and password, which in WebRTC is like no password at all on the TURN server

5. DevOps

The DevOps section deals with things required to run this product on a daily basis. I tend to fill in three main things here:

1. Hosting – is this planned to be deployed on premise? In a specific cloud provider? Using Docker or some other container technology?
2. Reporting – what type of information do you want to collect to generate reports on the use of the system? These should be for offline use – think a daily email or something similar
3. Events and statistics collection – this is what you want to be able to collect to monitor the health of the service in realtime

Step #6: Do a one-over and share

Now that we’ve written t all, time to go over the whole document to make sure things aren’t missing:

1. Clean up any leftover TBDs
2. Add clarifications where necessary
3. Add things not in the template

Here’s what I decided to add to the webinar example:

As you can see, for me, open source was really important.

Now that you are done – go share the document with your colleagues, and once approved internally, it is time to share with potential outsourcing vendors.

Why so short?

To some, this approach may seem a bit shallow. It doesn’t include all corner cases or describe in a lot of detail what goes on. The thing is, that there is a balance between what you can effectively do and achieve as a small startup or even a big company with a new project than what you’d do on a long running multi-year millions of dollars project.

For me, this proves itself as a good way to capture the essence of what it is that needs to be developed and getting replies from potential vendors to building the product. Once I get the replies, it is time to go over them and see who makes the most sense – a lot based on how they replied to the RFP in the first place.

What’s next?

So here’s how you should write your next WebRTC requirements document:

Step #1: Structure the document to make sure all bases are covered

Step #2: Focus on the overview – explain what your product needs to achieve

Step #3: Draw the architecture and explain it

Step #4: Write down your functional requirements

Step #5: Write down all non-functional requirements

Step #6: Do a one-over to make sure you didn’t miss anything

I’ve built a WebRTC Requirements Template document for you. You can copy it and fill it in with the requirements of your own product. It already holds many of the questions you’ll need to answer, so it can serve as a guide for you.

Now, to write this article, I also had to create a real-world example (remember our webinar service?). This example is also shared so you can see how I write things down.

Get the WebRTC Requirements Template and Sample Webinars Requirements Document

Oh, and if you still need help – I do offer a consulting service, where a lot of the time invested is placed into writing these requirements documents, finding suitable potential vendors and going over their responses.

The post How to Write the WebRTC Requirements for Your New Product? appeared first on BlogGeek.me.

Today – Dec 7, 2016 – the source code tree of Kamailio project was restructured into a slim and clean root folder. This was done in order to better handle various components and make it easier to get into the source. You can browse it online at:

• https://github.com/kamailio/kamailio

Here is a summary with the new locations:

• src/main.c – the main c file of kamailio application
• src/core/ – contains the source code for the core, including the subfolders for sip parser, memory manager and other core components
• src/lib/ – contains the internal libraries
• src/modules/ – contains the modules
• utils/ – contains the tools used to operate kamailio such as kamctl and kamcmd
• etc/ – configuration files
• doc/ – resources for building documentations and core tutorials
• pkg/ – packaging specs
• misc/ – contains related resources, such as config examples, additional tools and scripts, vim syntax highlighting files, …
• test/ – components related to testing

The Makefiles for building the application are in src/, with a new root folder Makefile that does target forwarding to src/. You should be able to use the same make commands inside root folder as well as inside src/.The kamailio binary is built in src/ directory.For example, next are the commands to build and run kamailio from source code tree, with debug mode logging to terminal:git clone https://github.com/kamailio/kamailio
cd kamailio
make all
./src/kamailio -f etc/kamailio.cfg -L src/modules/ -E -e -dddWhile some small adjustments may still be done, we hope that the new structure is going to make the long term management and development of the project smoother.Thank you for flying Kamailio!

Want to learn more about WebRTC in education?

Next week, testRTC will be hosting a webinar titled How WebRTC ushers the next wave of e-Learning innovation. As a co-founder of testRTC, I am tasked with the actual creation and hosting of the webinar, which means I will be speaking about what vendors are doing WebRTC when it comes to education and where I see their challenges.

I haven’t done a webinar in quite some time, so this is going to be fun for me.

We’ve decided to use Crowdcast as our webinars platform for it. Partially because it is a WebRTC based service, and I do love dog fooding. But also because I received some good reviews about it.

If I had to pick two very active verticals in the domain of WebRTC, these would be healthcare and education. We see this also at testRTC, where we help these vendors in testing and deploying their services to production.

Next Wednesday

So here’s what we’re doing next Wednesday – me and you:

• On December 14 at 14:30 EDT, we’re going to meet online
• I am going to give a few interesting examples of how education looks like when it meets WebRTC
• Then talk about some of the challenges involved
• You will have time to ask questions. I’ll answer them to the best of my ability
• And then I am going to give you a bonus

The examples

The examples part of the webinar is probably going to be the most interesting one.

I remember talking almost 3 years ago with a startup in India about their use case. It was related to education and it blew my mind. It was so starkly different than what I assumed a startup in India would do within their local market for education that I saw it as my own private lesson. Since then, I talked with tens of vendors in this space. Each doing his own thing. Each focusing on solving a problem in tutoring. They are so wide in variety that you can’t even look at them as a single market.

But this is exactly what we will try to do here. I am going to categorize them a bit – I wonder where you will find yourself in that categorization.

The challenges

Learning has its challenges for the student, the teacher and now also for the platform.

My intent is to look at the challenges of the platform – what are the things necessary to put these different education systems in production and how to make sure they work properly.

For the various types of education platforms, I’ll give you tips for where you should focus with your testing – what are the weak spots to look for – so you can find and deal with them before your customers do.

The bonus

I am not going to say what the bonus is now – it will ruin the surprise. I will say though, that this is something you’ll find immediately useful.

The bonus will be available only to those who will be with me during the webinar itself, so register now and save your place.

What’s next?Register of course!

And feel free to write down your questions in advance – Crowdcast allows for that.

The post WebRTC and Education – the Webinar Edition (and a Bonus) appeared first on BlogGeek.me.

Different ways to do the same thing.

One of the biggest problems is choice. We don’t like having choice. Really. The less options you have in front of you the easier it is to choose. The more options we have – the less inclined we are to make a decision. It might be this thing called FOMO – Fear Of Missing Out, or the fact that we don’t want to make a decision without having the whole information – something that is impossible to achieve anyway, or it might be just the fear of committing to something – commitment means owning the decision and its ramifications.

WebRTC comes with a huge set of options to select from if you are a developer. Heck – even as a user of this technology I can no longer say what service I am using:

• I use Drum for my Virtual Coffee sessions (haven’t done one in some time. Should do one next month)
• I now use Jitsi meet for my Office Hours
• Google Hangouts for testRTC meetings with customers
• Whatever a customer wants for my own consultation meetings, which varies between Hangouts, Skype, appear.in, talky, GoToMeeting, WebEx, … or the customer’s own service

In my online course, there’s a lesson discussing NAT traversal. One of the things I share there is the need to place the TURN server as close as possible to the edge – to the user with his WebRTC client. Last week, in one of my Office Hour sessions, a question was raised – how do you make that decision. And the answer isn’t clear cut. There are… a few options.

My guess is that in most cases, the idea or thought of taking a problem and scaling it out seems daunting. Taking that same scale out problem and spreading it across the globe to offer lower latency and geolocation support might seem paralyzing. At the end of the day, though it isn’t that complex to get a decent solution going.

The idea is you’ve got a user that runs on a browser or a mobile device. He is trying to reach out to your infrastructure (to another person probably, but still – through your infrastructure). And since your infrastructure is spread all over the globe, you want him to get the closest box to him.

How do we know what’s closest? Here are two ways I’ve seen this go down with WebRTC based services:

Via DNS

When your browser tries to reach out the server – be it the STUN or TURN server, the signaling server, or whatever – he ends up using DNS in most cases (you better use DNS than an IP address for these things in production – you are aware of it – right?).

Since the DNS knows where the request originated, it can make an informed decision as to which IP address to give back to the browser. That informed decision is done in the infrastructure side but by the DNS itself.

One of the popular services for it is AWS Route 53. From their website:

Amazon Route 53 Traffic Flow makes it easy for you to manage traffic globally through a variety of routing types, including Latency Based Routing, Geo DNS, and Weighted Round Robin.

This means you can put a policy in place so that the Route 53 DNS will simply route the incoming request to a server based on its location (Latency Based Routing, Geo DNS) or based on load balancing (Weighted Round Robin).

appear.in, for example, is making use of route53.

Amazon Route 53 isn’t the only such service – there are others out there, and depending on the cloud provider you use and your needs, you may end up using something else.

Via Geo IP

Another option is to use a Geo IP type of a service. You give your public IP address – and get your location in return.

You can use this link for exampleto check out where you are. Here’s what I get:

A few things that immediately show up here:

• Yes. I live in Israel
• Yes. My ISP is Bezeq
• Not really… Tel-Aviv isn’t a state. It is just a city
• And I don’t live in Bat Yam. I live in Kiryat Ono – a 20km drive

That said, this is pretty close!

Now, this is a link, but you can also get this kind of a thing programmatically and there are vendors who offer just that. I’ve head the pleasure to use MaxMind’s GeoIP. It comes in two flavors:

1. As a service – you shoot them an API and get geo IP related information, priced per query
2. As a database – you download their database and query it locally

There’s a kind of a confidence level to such a service, as the reply you get might not be accurate at all. We had a customer complaining at testRTC servers which jinxed his geolocation feature and added latency. His geo IP service thought the machine was in Europe while in truth it was located in the US.

The interesting thing is, that different such services will give you different responses. Here’s where I am located base (see here):

As you can see, there’s a real debate as to my exact whereabouts. They all feel I live in Israel, but the city thing is rather spread – and none of them is exact in my case.

So.

There are many Geo IP services. They will differ in the results they give. And they are best used if you need an application level geolocation solution and a DNS one can’t be used directly.

Telemetry

When inside an app, or even from a browser when you ask permission, you can get better location information.

A mobile device has a GPS, so it will know the position of the device better than anything else most of the time. The browser can do something similar.

The problem with this type of location is that you need permission to use it, and asking for more permissions from the user means adding friction – decide if this is what you want to do or not.

What’s next?

I am sure the DNS option is similar in its accuracy level to the geo IP ones, though it might be a bit more up to date, or have some learning algorithm to handle latency based routing. At the end of the day, you should use one of these options and it doesn’t really matters which.

Assume that the solution you end up with isn’t bulletproof – it will work most of the times, but sometimes it may fail – in which case, latency will suffer a bit.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

 

The post WebRTC, TURN and Geolocation. How to Pick the Best Server to Work With? appeared first on BlogGeek.me.

A new version of Siremis, the web management interface for Kamailio, has been released recently, respectively v4.3.0. The main work was towards making it compatible with PHP 7 and the new constraints from MySQL 5.7+. The announcement is available at:

• http://siremis.asipto.com/2016/11/26/siremis-v4-3-0-released/

As a side note, the organizing of the 5th edition of Kamailio World Conference has started, being planned for May 8-10, 2017, in Berlin, Germany. More details will be available in the near future!Thanks for flying Kamailio!

Kranky Geek last week was quite a rush.

Wow.

What can I say. Last week, our Kranky Geek event was so much fun.

I won’t bore you with the details. We’ve focused this time on WebRTC in mobile. Got the best speakers possible – really. And had a blast of an event. I received so much positive feedback that it warms my heart.

I’d like to thank our sponsors for this event: Google, Vidyo, Twilio and TokBox. Without them, this event wouldn’t have been possible.

The videos are available online, and below you’ll find the playlist of the event:

Tomorrow we’re doing another Kranky Geek event. This time in Sao Paulo, Brazil. Different theme. Different sessions. I am dead tired, but working hard with Chad and Chris to make that a huge success as well. See you soon!

 

The post Kranky Geek 2016 SF: Mobile WebRTC appeared first on BlogGeek.me.

All you wanted to know but didn’t know how to ask.

2 billion Chrome browsers? 7 billion WebRTC enabled devices by 2017? 50 billion IoT devices?

At the end of the day, who cares? What you are really interested in is to make sure that the WebRTC product you develop will end up working for YOUR target customers. If these customers end up running Windows XP with Internet Explorer 6 then you couldn’t care less about Apple, Safari and iOS support. But if what you are targeting is a mobile app, then which browser supports webRTC is less of an issue for you.

To make things a bit simpler for you, I decided to create a quick Cheat Sheet. A one pager to focus you better on where you need to invest with your WebRTC efforts.

This cheat sheet includes all the various devices and browsers, and more importantly, how to get WebRTC to work on them.

So why wait? Grab your copy of the cheat sheet by filling out this form:

• Name* First Last
• Company*
• Email*
• CommentsThis field is for validation purposes and should be left unchanged.

jQuery(document).bind('gform_post_render', function(event, formId, currentPage){if(formId == 9) {} } );jQuery(document).bind('gform_post_conditional_logic', function(event, formId, fields, isInit){} );jQuery(document).ready(function(){jQuery(document).trigger('gform_post_render', [9, 1]) } );

 

 

The post My WebRTC Device Cheat Sheet appeared first on BlogGeek.me.

Kamailio SIP Server v4.4.4 stable is out – a minor release including fixes in code and documentation since v4.4.3. The configuration file and database schema compatibility is preserved.Kamailio v4.4.4 is based on the latest version of GIT branch 4.4, therefore those running previous 4.4.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.4.x.Resources for Kamailio version 4.4.4Source tarballs are available at:

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

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

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

Thanks for flying Kamailio!

Time for a quick reality check when it comes to browsers and WebRTC.

I know you’ve been dying for Apple to support WebRTC in Safari. I am also aware that without WebRTC in your Microsft Internet Explorer 6 that you have deployed in your contact center there is no way for WebRTC to become ubiquitous or widely adopted. But hear me out please.

Browsers market share

The recent update by NetMarketShare on the desktop browsers market share is rather interesting:

It shows the trend between the various desktop browsers for the last year or so.

Here are some things that comes to mind immediately:

• Google Chrome now has 55% market share. Its rise has stalled somewhat in the last couple of months
• Microsoft Internet Explorer is still free falling. It will probably stop somewhere at 10% or so if you ask me
• While Chrome gained the most users from Internet Explorer, it seems that Firefox has picked up users from Internet Explorer in the past two months
• Microsoft Edge gained very little from the demise of Microsoft Internet Explorer. People who have adopted Windows 10 aren’t adopting Edge and are most probably opting to install and use Chrome or Firefox instead. I’ve mentioned it here in the past

What happens between Microsoft Edge and Apple Safari is even more interesting. Apple Safari is falling behind Microsoft Edge:

Something doesn’t add up here.

The Edge numbers should rise a lot higher, due to the successful upgrades we’ve seen for Windows 10 in the market. And it doesn’t. We already noticed how Chrome and to some extent Firefox enjoyed that switch to Windows 10.

I am not sure how the slip of Apple Safari market share from almost 5% in the beginning of this year to below 4% can be explained. Is it due to the slip in Mac sales in recent months or is it people who prefer using Chrome or Firefox on their Macs?

–

There’s one caveat here of course – these numbers are all statistics, and statistics do tend to lie. When going to specific countries, there will be a different spread across browsers, and to a similar extent, your service sees a different type of browser spread because your users are different. Here’s the stats from Google Analytics for this blog:

For me, it is titled towards browsers supporting WebRTC, and Safari is way higher than Edge and Internet Explorer put together.

Back to WebRTC

Every once in a while, someone would stand up and ask: “But what about Internet Explorer?” when I talk about WebRTC. It is becoming one of these questions I now expect.

Here’s what you need to think about and address:

• Chrome is probably your go-to browser and the first one to support with your WebRTC product
• Firefox comes next, and growing. So keep your tabs on it to see how it “performs” with your product
• Edge. Useless for most. Add support to it if:
  • You do voice only (should work nicely), and you want that extra market share
  • You know for sure your users are on Edge
• Internet Explorer. Ignore
  • Microsoft probably won’t invest in having WebRTC support in it, so don’t wait for them
  • Use a plugin or whatever if you must
• Safari. Ignore for now. Nothing to do about it anyway

What’s next?

I am working on a quick cheat sheet for you. One which will enable you to make fast decisions for browser support. It will extend also into apps and mobile. Probably by next week.

Until then, if you plan on picking up browsers to support, think of your target audience first. Don’t come up with statements like “IE must be supported” or “Without Safari I can’t use this technology”. You are just hurting yourself this way.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

 

The post Desktop browsers support in WebRTC – a reality check appeared first on BlogGeek.me.

A new Kamailio IRC devel meeting to has beep proposed to discuss the current major issues and the plans for next Kamailio releaseThe target time frame is Nov 08-10, 2016 (Tuesday, Wednesday or Thursday).If many developers are not available, it can postponed it to another date in the near future (make proposals if that is the case for you).A wiki page has been created for it:

• https://www.kamailio.org/wiki/devel/irc-meetings/2016b

Add there the topics that you want to be discussed and your availability.Thanks for flying Kamailio!

Coordinated by its founder Alan Quayle, with the help of many local teams across the world, TADHack Global 2016 edition was organized during October 14-16 in over 30 cities, counting over 2600 registrations that resulted in over 170 hacks. It is probably one of the largest hackathons recorded so far, maybe even the largest, anyhow, for sure in the telecom world.One of the cities involved in the hackfest was Berlin, the local event was hosted by VoIP Labs, being managed by Dennis P. Kersten. On a rainy weekend, a bunch of VoIP enthusiasts met, paired and started hacking with various telecom APIs offered by the event sponsors. The results were amazing, 4 completed hacks, all of them winning at least one prize, 3 of them being awarded TADHack global prizes — the details about all winners can be found at:

• http://blog.tadhack.com/2016/10/16/tadhack-2016-winners/

One of the global winning hacks, awarded by Canonical/Ubuntu, was named “Snappy Kamailio” done by Daniel-Constantin Mierla, the co-founder of Kamailio project. The title of the hack is not related to the behaviour of the application, as one could imagine, but to the rather new packaging system known as ‘snap’. Here is the definition of a snap taken from the snapcraft.io:A snap is a fancy zip file containing an application together with its dependencies, and a description of how it should safely be run on your system, especially the different ways it should talk to other software.Most importantly snaps are designed to be secure, sandboxed, containerised applications isolated from the underlying system and from other applications. Snaps allow the safe installation of apps from any vendor on mission critical devices and desktops.Aiming to ease the deployment of applications across different Linux-based systems, wrapped with proper layers of security, the snaps concept look very promising.Daniel’s remarks on the TADHAck event and its outcome:“”I am glad that I could participate to the TADHack Global 2016, the local event in Berlin made it easier in a rather busy period of traveling, huge credits to Alan and Dennis for making it possible.As for the hack, what Canonical/Ubuntu was offering during the hackfest was a perfect fit for me – a Linux/Ubuntu cloud infrastructure to meet the needs of scaling deployments and RTC platforms. As one of core developers of Kamailio SIP server project, I wanted to do something using it, that, after all, can also be useful for our community.Cloud, virtualization, containers — all very hot concepts these days. But snaps target to be even slimmer, still avoiding annoying issues such as broken dependencies and different versions of libraries on different distributions. I heard about them, but never got the time to play with. TADHack global offered the chance that I didn’t want to miss. The hack-intense environment and discussions with other people around helped to clarify some doubts (hey Torsten, Dominik, Dennis).Once I started to build snaps and test them running, I realized that the sandboxed snap restricts some privileges that Kamailio uses when running on Linux, such as creating raw UDP sockets. With a bunch of patches after many try-and-errors, I was able to get the stock Kamailio from our github.com repositorybuilt and run as a snap.It felt that the participation to the TADHack was fruitful already. The prize announced few days later came as a very pleasant complement awarded by Canonical/Ubuntu.Now I am looking forward to get new versions of Kamailio snaps with a more specific target functionality, such as a load balancer, SIP registrar, a.s.o. Let’s see how far I can go till the TAD Summit, Nov 15-16, 2016, in Lisbon, Portugal, where I will participate and show the Snappy Kamailio and the evolution after the hackfest. If you are in telecom or real time communications looking for future transformations of the market, it’s an event you should definitely attend!””Next are the relevant resources for Snappy Kamailio.The spec files to build the Kamailio snap and some instructions are available at:

• https://github.com/miconda/kamailio-snapcraft

The slides of the TADHack Global pitch for Snappy Kamailio:

• http://www.slideshare.net/miconda/snappy-kamailio

The video recording of the pitch:

• https://www.youtube.com/watch?v=-eX0cqXVVA8

If you are interested in Kamailio snaps, join our development community on sr-dev mailing list.Thank you for flying Kamailio!