News from Industry

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!

Kranky Geek is coming to town!

WebRTC is maturing. We’re 5 years into this roller coaster and it seems most companies have already understood that they need to use WebRTC in one way or another. To many, this is going to be an excruciatingly painful journey. They will need to change their business model, think differently about how they develop products and even rewrite their core values.

One of the reasons we decided to launch Kranky Geek over two years ago was to have a place where developers can teach developers about WebRTC. Somewhere that isn’t already “tainted” with the telecom views of the world – not because they are bad – just because WebRTC can accomplish so much more. What we are going to do next with WebRTC takes place in November and will happen in two separate locations:

Kranky Geek San Francisco

San Francisco is where Kranky Geek started and where I feel at home when it comes to this event. We will be doing our 3rd Kranky Geek event in San Francisco (and 4th in total).

It will take place on November 18, at Google’s office on Spear street.

Our focus this time around is going to be mobile. We’ve got sessions lined up that should cover most of the aspects related to WebRTC and mobile. Things like using React, cross platform development, video compression, specific aspects in iOS as well as specific aspects in Android related to WebRTC.

If you are into mobile development with real time communications – then this is an event you don’t want to pass up.

There is also a new attendance fee that was added – $10 that gets donated to Girl Develop It. You may notice we don’t have a woman speaker this time – it is hard to find women speakers in this domain, so if you are one or know one – make sure to let us know for our future events.

I’d like to thank our sponsors who made this thing possible:

• Google – who brought us WebRTC in the first place and is instrumental to the success that is Kranky Geek
• TokBox – sponsoring both the San Francisco and São Paulo events. They will share their experiences with mobile aspects of WebRTC related to Android
• Twilio – sponsoring both the San Francisco and São Paulo events. Their session in San Francisco will cover WebRTC and the Internet of Things
• Vidyo – a new sponsor that is joining the Kranky Geek family, and probably the best one suited to talk about real time video compression technologies that make sense in mobile devices

Kranky Geek São Paulo

This will be my first time in Brazil and also the first time we run Kranky Geek in Barzil. As with San Francisco, the event is hosted at Google’s office in São Paulo.

Our focus for São Paulo will be back to the basics of WebRTC. We are trying this time to fill in the gaps – share resources and insights that developers who use WebRTC in their daily activities need. This is why we have a few sessions that are targeted at debugging and troubleshooting WebRTC in this event.

Registration for the São Paulo event is free.

For the São Paulo event, we got the help of a few sponsors as well:

• Google
• TokBox – at São Paulo, TokBox will share with us how to deal with device and connectivity issues when it comes to WebRTC sessions
• Twilio – will be looking at the makeup of a WebRTC service, as the browser implementation of WebRTC is the beginning of the journey only
• WebRTC.ventures – who are sponsoring this event for the first time, will give the overview and introduction to WebRTC
• Callstats.io – will explain what you can find in getstats() and how to use it

See you there

I have my own session to prepare for the upcoming Kranky Geek, along with a lot of work to make these two events our best yet. There are also changes and modifications that need to make their way to the website –  but rest assured – these events have great content lined up for you.

If you happen to be in the area, my suggestion is come to the event – it is the best place to learn and interact with people who know way better than I do what WebRTC is in and out.

And if you want to meet me – just contact me. I’ll be “in town” for an extra day or so.

–

See you all at Kranky Geek!

The post Get Ready for Kranky Geek San Francisco AND São Paulo appeared first on BlogGeek.me.

WebRTC 1.0 uses SDP for negotiating capabilities between parties.  While there are a growing number of objects coming to WebRTC to avoid this protocol from the 90’s , the reality is SDP will be with us for some time. If you want to do things like change codecs or adjust bandwidth limits, then you’re going to need to “munge” […]

The post How to limit WebRTC bandwidth by modifying the SDP appeared first on webrtcHacks.

FOSDEM is one of the world's premier meetings of free software developers,
with over five thousand people attending each year. FOSDEM 2017
takes place 4-5 February 2017 in Brussels, Belgium. https://fosdem.org

This email contains information about:
- Real-Time communications dev-room and lounge,
- speaking opportunities,
- volunteering in the dev-room and lounge,
- related events around FOSDEM, including the XMPP summit,
- social events (the legendary FOSDEM Beer Night and Saturday night dinners
provide endless networking opportunities),
- the Planet aggregation sites for RTC blogs

Call for participation - Real Time Communications (RTC)
=======================================================

The Real-Time dev-room and Real-Time lounge is about all things involving
real-time communication, including: XMPP, SIP, WebRTC, telephony,
mobile VoIP, codecs, peer-to-peer, privacy and encryption. The dev-room
is a successor to the previous XMPP and telephony dev-rooms.
We are looking for speakers for the dev-room and volunteers and
participants for the tables in the Real-Time lounge.

The dev-room is only on Saturday, 4 February 2017. The lounge will
be present for both days.

To discuss the dev-room and lounge, please join the FSFE-sponsored
Free RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc

To be kept aware of major developments in Free RTC, without being on the
discussion list, please join the Free-RTC Announce list:
http://lists.freertc.org/mailman/listinfo/announce

Speaking opportunities
----------------------

Note: if you used FOSDEM Pentabarf before, please use the same account/username

Real-Time Communications dev-room: deadline 23:59 UTC on 17 November.
Please use the Pentabarf system to submit a talk proposal for the
dev-room. On the "General" tab, please look for the "Track" option and
choose "Real-Time devroom". https://penta.fosdem.org/submission/FOSDEM17/

Other dev-rooms and lightning talks: some speakers may find their topic is
in the scope of more than one dev-room. It is encouraged to apply to more
than one dev-room and also consider proposing a lightning talk, but please
be kind enough to tell us if you do this by filling out the notes in the form.
You can find the full list of dev-rooms at
https://www.fosdem.org/2017/schedule/tracks/
and apply for a lightning talk at https://fosdem.org/submit

Main track: the deadline for main track presentations is 23:59 UTC
31 October. Leading developers in the Real-Time Communications
field are encouraged to consider submitting a presentation to
the main track at https://fosdem.org/submit

First-time speaking?
--------------------

FOSDEM dev-rooms are a welcoming environment for people who have never
given a talk before. Please feel free to contact the dev-room administrators
personally if you would like to ask any questions about it.

Submission guidelines
---------------------

The Pentabarf system will ask for many of the essential details. Please
remember to re-use your account from previous years if you have one.

In the "Submission notes", please tell us about:
- the purpose of your talk
- any other talk applications (dev-rooms, lightning talks, main track)
- availability constraints and special needs

You can use HTML and links in your bio, abstract and description.

If you maintain a blog, please consider providing us with the
URL of a feed with posts tagged for your RTC-related work.

We will be looking for relevance to the conference and dev-room themes,
presentations aimed at developers of free and open source software about
RTC-related topics.

Please feel free to suggest a duration between 20 minutes and 55 minutes
but note that the final decision on talk durations will be made by the
dev-room administrators. As the two previous dev-rooms have been
combined into one, we may decide to give shorter slots than in previous
years so that more speakers can participate.

Please note FOSDEM aims to record and live-stream all talks.
The CC-BY license is used.

Volunteers needed
=================

To make the dev-room and lounge run successfully, we are looking for
volunteers:

- FOSDEM provides video recording equipment and live streaming,
volunteers are needed to assist in this
- organizing one or more restaurant bookings (dependending upon number of
participants) for the evening of Saturday, 4 February
- participation in the Real-Time lounge
- helping attract sponsorship funds for the dev-room to pay for the
Saturday night dinner and any other expenses
- circulating this Call for Participation to other mailing lists

See the mailing list discussion for more details about volunteering:
https://lists.fsfe.org/pipermail/free-rtc/2016-October/000285.html

Related events - XMPP and RTC summits
=====================================

The XMPP Standards Foundation (XSF) has traditionally held a summit
in the days before FOSDEM. There is discussion about a similar
summit taking place on 2 and 3 February 2017
http://wiki.xmpp.org/web/Summit_21 - please join the mailing
list for details: http://mail.jabber.org/mailman/listinfo/summit

We are also considering a more general RTC or telephony summit,
potentially in collaboration with the XMPP summit.
Please join the Free-RTC mailing list and send an email if you would
be interested in participating, sponsoring or hosting such an event.

Social events and dinners
=========================

The traditional FOSDEM beer night occurs on Friday, 3 February.

On Saturday night, there are usually dinners associated with
each of the dev-rooms. Most restaurants in Brussels are not so
large so these dinners have space constraints and reservations are
essential. Please subscribe to the Free-RTC mailing list for
further details about the Saturday night dinner options and how
you can register for a seat: https://lists.fsfe.org/mailman/listinfo/free-rtc

Spread the word and discuss
===========================

If you know of any mailing lists where this CfP would be relevant, please
forward this email. If this dev-room excites you, please blog or microblog
about it, especially if you are submitting a talk.

If you regularly blog about RTC topics, please send details about your
blog to the planet site administrators:

All projects http://planet.freertc.org planet@freertc.org

XMPP http://planet.jabber.org ralphm@ik.nu

SIP http://planet.sip5060.net planet@sip5060.net
(Español) http://planet.sip5060.net/es/ planet@sip5060.net

Please also link to the Planet sites from your own blog or web site as
this helps everybody in the free real-time communications community.

Contact
=======

For any private queries, contact us directly using the address
fosdem-rtc-admin@freertc.org and for any other queries please ask on
the Free-RTC mailing list:
https://lists.fsfe.org/mailman/listinfo/free-rtc

The 7th edition of FUSECO Forum, organized by Fraunhofer Fokus Institute, takes place between November 3-4, 2017, in Berlin, Germany:

• https://www.fokus.fraunhofer.de/fuseco-forum-2016

This year, the focus is on understanding application drivers and technology evolution towards softwarized 5G networks and the industrial internet revolution.This year the FUSECO Forum will be accompanied by 2 additional international events on 5G, all of them held during the same week in Berlin. Don´t miss any of them and get ready for 5G and the Industrial Internet of Things!

No article today.

My course is launching today: Advanced WebRTC Architecture Course.

I’ve got some solid attendance for it, along with a good bulk of high quality material lined up.

Hopefully, this will be a success.

If you are taking the course – then good luck and please share your thoughts with me – I’ve built this course for you and I’d like you to benefit from it as much as possible.

If you aren’t taking it but still want to attend – feel free to enroll. I’ll be closing up course signups end of this week, with no clear indication if and when I’ll be running it next.

Now quiet please – there are people studying in here. Somewhere. Hopefully.

The post Quiet please – people are studying appeared first on BlogGeek.me.

WebRTC course starts Monday next week.

At long last, the wait will be coming to an end and my recent sleepless nights as well. I’ve been working these past months to put up the content for the course, not knowing how it will end up.

Most of the materials have been recorded, uploaded and prepared already, waiting for me to just manually add all the people who enrolled. There’s a lot of material in that course, and a lot more that I am sure is still missing in there. Trying to cover WebRTC in its entirety isn’t easy.

Through the process of putting this stuff up and out there, I’ve learned a lot myself.

 

The course is split into 7 sections:

1. The basics of WebRTC – explanation of what WebRTC is, a review of its APIs and call flows, and general knowledge. This should get you up to speed about what it is and will probably place you among the first 10,000 people in the world who know it at this depth. It will also enable you to read the stuff that is out there about WebRTC more critically
2. Networking basics – while we all use the Internet, many of us don’t know the distinction between TCP and UDP, or what Websockets really is. This section tries to put these things in perspective and lay the groundwork for later sections. It will be super useful for VoIP developers but also great for web developers. It also covers the NAT traversal challenge and the solutions found in WebRTC for it
3. WebRTC signaling – signaling isn’t part of WebRTC, but is often something to contemplate. This section dives into the alternatives of signaling that are available, different types of transport protocols, as well as a lesson on SDP. It also covers the security aspects relevant to WebRTC – and it it sheds some light on FUD (fear, uncertainty and doubt) around WebRTC
4. Codecs – I love codecs. I know little about them, but somehow, more than most. This section explains voice and video codecs, while focusing on what you need to know about them in the context of WebRTC. You won’t be able to implement a codec after this section (I never implemented a codec), but you will gain the understanding necessary for you to decide the codecs for your own scenarios
5. Media processing – media processing is at the heart of most decisions you will take in your use case. In this section, I take the time to review how RTP and RTCP work, and then dive into different architectures and processes you might need in your back end. Things like mixing, routing and recording
6. 3rd party frameworks and services – here we will be diverting from the beaten path of “normal course material”, and instead of talking about specifications, standards and capabilities, we will look into the various products and open source frameworks that are out there. We will review them and see which one fits what use case, and also gain an understanding of the various routes available to us, trying to match our company’s DNA and requirements to the alternatives at hand
7. Common WebRTC design patterns – this is where we will take specific scenarios and challenges, from a list of those I see every day when people reach out to me, and analyze them. Go over the scenario, break it down to requirements and then map them into architectural alternatives. The idea here is to give you the tools to do such things on your own with your products

Most of the lessons are already ready. There are around 6 lessons that I still need to write. Hopefully, they will be available on launch day, but if not, then the following week.

 

I want to answer a few quick questions here – things I’ve been asked time and again in the past month:

Is this a one-time thing?

Yes and no.

The course takes place October 24 and lasts for 2 months. Those who enroll for office hours get an extended duration of 4 months (as well as office hours).

I don’t plan on doing this an ongoing thing where you can enroll whenever and do the course. I will be taking the time throughout these two months to listen to the students and see if there’s anything that requires updating in “real time”. I can’t do it if this is an ongoing thing.

This might change in the future, but for now, there’s this timing.

I might do that some months from now, after I rest a bit from the effort and decide if it makes financial sense to run it again.

If you have your own timing issues, then understand that the course is self-paced. You can “leave” for a week or two and come back, do it faster or slower.

Is the course for me?

I can’t really say.

Here are a few types of students that I have already enrolled for the course:

• Developers who need to start using WebRTC, more often than not through a framework that was already selected. They know how it works, but are looking to gain deeper understanding so they can troubleshoot issues or add features to their product
• Product managers who want to learn and understand more about WebRTC. Mostly to give them the language necessary to talk with their developers. And mainly to keep the developers honest
• Teams who work with WebRTC, so they can get the experience together as a team and improve their proficiency
• Testers wanting to understand the technology better and find effective ways to design their test plans

The course doesn’t include too much code. There’s the occasional piece of code shown, but the idea isn’t to explain to you how to develop with WebRTC. In truth – most of you won’t develop with WebRTC directly anyway – you’ll end up using a framework or a third party for that.

The intent is to give you the understanding of the limits and capabilities of WebRTC. To know how to yield this amazing tool and how to use it effectively in your product.

How is the course conducted?

If you enrolled, then you will be receiving an email a day or two prior to the course.

I will be registering you to the course mini-site inside the BlogGeek.me website. Once you login, you will be able to access all course sections and lessons.

Each lesson has a page of its own in the site. Most lessons have a recorded video session as the main bulk of it, along with text and additional reading material. In most cases, that additional reading material is important.

You can “tune in” to any lesson you wish and learn it at your own pace and in your free time.

There is an online forum for the course. Students will be able to raise their questions, issues and feedback there. If things require changes on my end, I’ll try making the changes to the lessons as we move along, maybe even adding course materials and lessons if the need will arise. I will also be using the forum to ask questions myself, and check out on the progress of students.

For those taking office hours, these will take place twice a week at different times to accommodate different time zones. In there, I will answer questions as they come and basically make myself available to you “in the flesh”. I haven’t decided yet which WebRTC service to use for that – suggestions are welcome.

I am still debating if I should use quizes as part of the course, placing them at the end of each section or not. If you have an opinion – please voice it (even if you’re not going to attend the course).

 

Enroll today

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

 

The course starts next week.

There’s a Q&A page that may answer additional questions you might have.

Official course syllabus is also available in PDF form.

I’d be happy to meet you if you decide to enroll to the course. This is a new thing for me and I an quite excited about it.

If you are not sure about the course – email me. If there’s no fit – I’ll tell you immediately. If this might help you, I’ll explain to you what you will gain from it so you can make a better decision

Until next Monday – have an awesome week.

The post Advanced WebRTC Acrhitecture Course – Updates appeared first on BlogGeek.me.

The FreeSWITCH 1.6.12 release is here!

This is also a routine maintenance release. Change Log and source tarball information below.

Release files are located here:

• Tarball: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.6.12.tar.gz
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation

New features that were added:

• FS-9242 [mod_verto] Convert to adapter.js
• FS-8955 [verto_communicator] Adding DTMF shortcuts and handling DTMF history on DTMF widget
• FS-9601 [mod_opus] Make adjustable bitrate mutually exclusive with FEC enforcing on the decreasing trend, add step calculation for bitrate adjustment, fix bug on context settings
• FS-8644 [mod_opus] OPUS_SET_BITRATE(), codec control and estimators for packet loss and RTT (with Kalman filters) to detect a slow or congested link. Feature enabled with “adjust-bitrate” in opus.conf.xml – it’s a feedback loop with incoming RTCP.

Improvements in build system, cross-platform support, and packaging:

• FS-8623 [build] Fixed sun studio build errors building libvpx
• FS-9553 [core] Refactor video-on-hold
• FS-9616 [libvpx] Update libvpx to latest upstream
• FS-9618 [libyuv] Update libyuv to latest upstream

The following bugs were squashed:

• FS-9574 [mod_verto] We shouldn’t print data set on the buffer because of the potential security issues
• FS-9508 [verto_communicator] Adding AGC option on settings, enabled by default
• FS-7876 [verto_communicator] Adding hold button for video calls
• FS-9242 [verto.js] Fixed screen share for chrome to work in VC with additional camera
• FS-9586 [mod_local_stream] Fixed the local_stream video queue sticking when not being read from
• FS-9610 [core] Video keyframe requests not being propagated properly
• FS-9612 [core] RTCP-MUX wrongly enabled in cases where answer contains RTCP but offer didn’t / remote
  address not obtained in UDPTL mode
• FS-9580 [core] Add auto adjust for RTCP separate from RTP for sync NAT
• FS-9548 [core] Crash on Invite due to bad config for sip profile
• FS-9498 [mod_conference] Fixed a regression with 100% cpu

The future of streaming includes WebRTC.

Disclaimer: I am an advisor for Peer5.

If you look at reports from Ericsson or Cisco what you’ll notice is the growth of video as a large portion of what we do over the Internet. As video takes up an order of magnitude more data to pass than almost anything else we share today this is no wonder. Here are a few numbers from Cisco’s forecast from Feb 2016:

• Mobile video traffic accounted for 55 percent of total mobile data traffic in 2015. Mobile video traffic now accounts for more than half of all mobile data traffic
• Three-fourths of the world’s mobile data traffic will be video by 2020. Mobile video will increase 11-fold between 2015 and 2020, accounting for 75 percent of total mobile data traffic by the end of the forecast period

Source: Cisco

I think there are a few reasons for this growth:

1. While we’re continuously moving towards HD video resolutions, 4K is already being experimented with. The increase in resolution and frame rates is inevitable. We’ve seen this growth with the displays of our devices and with the cameras we hold in our pockets. Time to see it in the videos we play back
2. The hegemony of content creators is broken. User generated content is growing rapidly. It started with YouTube, moving to services such as Vine and now live streaming services such as Periscope, Facebook Live, YouNow and others. More creators = more video sources
3. Viewing habits are changing. We are no longer interested in TV series broadcasted on air but rather pick and choose what we want to watch and when we want to watch, from an exponentially larger pool and variety of content

The challenge really begins when you look at the Internet technologies available to stream these massive amounts of content:

• Flash / RTMP. This is how we streamed video over our internet for years, and that period is coming to an end. Google announced limiting its support to Flash by requiring users to opt in on sites that make use of it. This is causing large content sites to scurry towards HTML5 based streaming technologies
• HLS. HTTP Live Streaming – Apple’s mechanism used on iOS devices. And one that is enforced if you wish to stream to iOS devices. To some extent, this makes it “necessary” to support it elsewhere – so there’s also an HLS player for browsers
• MPEG-DASH – the standardized cousin of HLS
• Something else, not necessarily intended for video streaming

The challenge with HLS and MPEG-DASH is latency. While this might be suitable for many use cases, there are those who require low latency live streaming:

From my course on WebRTC architecture

For those who can use HLS and MPEG-DASH, there’s this nagging issue of needing to use CDNs and pay for expensive bandwidth costs (when you stream that amount of video, everything becomes expensive).

Which brings me to the recent deal between Peer5 and Dailymotion. To bring you up to speed:

• Dailymotion is huge
  • Similarweb ranks them #4 in their category, after YouTube, Netflix and niconico
  • Their site states they have 300 million unique monthly visitors and they stream 3.5 billion videos a month
• Peer5 is a startup dealing with peer assisted delivery
  • They offload video traffic and reduce strain on servers and CDNs by sending video data across peers
  • They do this by using WebRTC’s data channel
• Some of the traffic of Dailymotion now flows via Peer5’s technology, and that’s now official

There are other startups with similar technologies to Peer5, but this is the first time any of them has publicized a customer win, and with such a high profile to top it off.

In a way, this validates the technology as well as the need for new mechanisms to assist in our current state of video streaming – especially in large scales.

WebRTC seem to fit nicely in here, and in more than one way only. I am seeing more cases where companies use WebRTC either as a complementary technology or even as the main broadcast technology they use for their service.

It is also the reason I’ve added this important topic to my upcoming course – Advanced WebRTC Architecture. There is a lesson dedicated to low latency live broadcasting, where I explain the various technologies and how WebRTC can be brought into the mix in several different combinations.

If you would like to learn more about WebRTC and see how to best fit it into your scenario – this course is definitely for you. It starts October 24, so enroll now.

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

 

The post Dailymotion, Peer5 and the Future of Streaming appeared first on BlogGeek.me.

This year the global edition of Telecom Application Developer Hackathon is organized during October 14 -16, 2016, with many locations world wide, among them being also Berlin. For more details, see:

• http://tadhack.com/2016/global/

TADHack is the global meeting place for developers who want to learn, share, code and create using the tools and technologies available in telecommunications.The Berlin event is hosted by VoIP Lab, part of Buro 2.0 co-working space, being coordinated by Dennis P. Kersten during October 15-16, 2016.Several Kamailio developers from Berlin area are participating to the event. Any developer can participate for free, you are welcome to join us in Berlin or anywhere around the world — you can do it also remotely, from your living room or your preferred working space. Think about an idea to code, hack and demo it for wining some nice goodies from sponsors!Happy telecom hacking!

The next edition of Kazoo Project Conference takes place in San Francisco, CA, USA, during October 17-18, 2016.Kazoo is a flexible cloud PBX platform, released under open source, developed by 2600hz.com, with the telephony engine built using Kamailio, FreeSwitch and an Erlang controller, all wrapped nicely with a web management interface, doing all sorts of things from account management to billing and monitoring.If you want to start a cloud telephony business or get into this market as a reseller, KazooCon is an event that you should definitely attend. More details about the conference are available at:

• http://kazoocon.com

Kamailio incorporates a module with the same name, kazoo, but besides it, the developers from Kazoo project contributed a consistent effort in advancing the presence and database modules. Therefore expect to meet a lot of Kamailio friends around at KazooCon and participate in many interesting discussions.Thanks for flying Kamailio!

This week mod_opus got a cool new feature that allows the detection of a slow or contaminated link. And verto is converting to adapter.js as well as getting DTMF shortcuts. The FreeSWITCH configuration audit is ongoing with initial minor commits and will continue throughout the year. If you are looking to volunteer to help with that or would like more information email brian@freeswitch.org or join the Bug Hunt on Tuesdays at 12:00pm Central Time.

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8644 [mod_opus] OPUS_SET_BITRATE(), codec control and estimators for packet loss and RTT (with Kalman filters) to detect a slow or congested link. Feature enabled with “adjust-bitrate” in opus.conf.xml – it’s a feedback loop with incoming RTCP.
• FS-9242  [mod_verto] Convert to adapter.js
• FS-8955  [verto_communicator] Adding DTMF shortcuts and handling DTMF history on DTMF widget

Improvements in build system, cross-platform support, and packaging:

• FS-8623  [build] Fixed sun studio build errors building libvpx
• FS-9553  [core] Refactor video-on-hold

The following bugs were squashed:

• FS-9548  [core] Crash on Invite due to bad config for sip profile
• FS-9580  [core] Add auto adjust for RTCP separate from RTP for sync NAT
• FS-9574  [mod_verto] We shouldn’t print data sent on the buffer because of the potential security issues
• FS-9508  [verto_communicator] Adding AGC option on settings, enabled by default
• FS-7876  [verto_communicator] Adding hold button for video calls
• FS-9242  [verto.js] Fixed screen share for chrome to work in VC with additional camera
• FS-9586  [mod_local_stream] Fixed the local_stream video queue sticking when not being read from

WebRTC isn’t limited to JavaScript.

This is something I don’t get asked directly, but it does pop up from time to time. Especially when people come up with a specific language in mind and ask if it is suitable for WebRTC.

While the answer is almost always yes, I think a quick explanation of where programming languages meet WebRTC exactly is in order.

We will start with a small “diagram”, to show where we can find WebRTC related entities and move from there.

We’ve got both client and server entities with WebRTC, and I think the above depicts the main ones. There are more as your service gets more complicated, but that’s all an issue of scaling and pure development not directly related to WebRTC.

 

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

 

So what do we have here?

Web app

The web app is what most people think about when they think WebRTC.

This is what ends up running in the browser, loaded from an HTML and its derivatives.

What this means is that the language you end up with is Java Script.

Mobile app

When it comes to the mobile domain, there are two ways to end up with WebRTC. The first is by having the web app served inside a mobile browser, which brings you back to Java Script.

The more common approach though is to use WebRTC inside an app. You end up compiling and linking the WebRTC codebase as an SDK.

The languages here?

• C, C++ for the low level stuff that makes up WebRTC. In all likelihood, you won’t need to handle this (either because it will just work or because you’ll be outsourcing it to someone else)
• Java for native Android app development
• Objective-C and/or Switft for native iOS app development

There’s also the alternative of C# via Xamarin or Java Script again if you use something like Crosswalk. With these approaches, someone should already have WebRTC wrapped for you in these platforms.

Embedded app

Embedded is where things get interesting.

There are cases where you want devices to run WebRTC for one reason or another.

Two main approaches here will dictate the languages of choice:

1. C, C++ if you port the webrtc.org code base and use it. And then whatever else you fancy on top of it
2. Any language you wish (Java anyone?), while implementing what you need of the WebRTC protocol (=what goes on the network) on your own

In general, here you’ll be going to lower levels of abstraction, getting as close as possible to the machine language (but stopping at C most probably).

TURN server

STUN and TURN servers are also necessary. Most likely – you won’t be needing to do a thing about them besides compiling, configuring and running them.

So no programming languages here.

I would note that the popular open source alternatives are all written in C. Again – this doesn’t matter.

Media server

Media servers come in different shapes and sizes. I’ve covered them here recently, discussing Jitsi/Kurento and later Kurento/Janus.

The programming languages here depend on the media server itself. Jitsi and Kurento are Java based. Janus is mostly C. In most cases – you wouldn’t care.

Media servers are usually entities that you communicate with via REST or Websocket, so you can just use whatever language you like on the controlling side. It is a very popular choice to juse Node.js (=Java Script) in front of a Kurento server for example. It also brings us to the last entity.

App/Signaling server

The funny thing is that this is where the question is mostly targeted at. The application and/or signaling server is what stitches everything together. It serves the web app, communicates with the mobile and embedded apps. It offers the details of the TURN server and handles any ephemeral passwords with it, it controls the media servers.

And it is also where the bulk of the development happens since it holds the business logic of the application.

And here the answer is rather simple – use whatever you want.

• Node.js and Java Script are great and popular choice (there are good reasons for that)
• Java seems to be a thing in enterprises though for the life of me I just can’t understand why
• PHP works well. It is used by many WordPress plugins for WebRTC
• Erlang seems to be something that adventurous developers like to adopt – and like
• Ruby and Python are also good choices
• .Net is something I’ve seen once or twice used

In general, whatever you can use to build websites can be used to build a WebRTC service.

What’s your language?

Back to you. What is the programming languages you use with WebRTC?

If you are looking for developers, then what would be the languages you’d view as mandatory and which ones as preferable with applicants?

–

This as well as other topics are covered in my upcoming Advanced WebRTC Architecture course. Be sure to enroll if you wish to deepen your understanding in this topic.

The post What’s Your Preferred Language for WebRTC Development? appeared first on BlogGeek.me.