News from Industry

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.

So far so good, but it is time to add some more options for you.

A selection of three different course packages

I am working to complete all lessons for the course. It takes time to work things through, go over the lessons, make sure everything is in order and record the sessions.

The interesting thing to me is the variety of people that enroll to this course – they come from all over the globe, varying from small startups to large companies. I found some interesting vendors who are looking at WebRTC that I wasn’t aware of.

A few updates about the course

There are a few minor updates that are taking place in the course:

• I will most probably add a forum to go along with the course. The forum is opened for all packages, and it will be a place where discussions and questions can take place between the students
• The FAQ page was updated, based on questions I received in the past several weeks – check it out
• The enrollment page now shows a pricing table, in an effort to make things clearer
• There are now 3 packages:
  1. Basic – access to the course for 2 months + forum
  2. Plus – access to the course for 4 months + forum + office hours
  3. Premium – a new package – see below for information
• For those who wish to enroll by wire transfer instead of PayPal – just contact me through my contact form

Course length

The course duration is 8 weeks, give or take a few days.

That said, if you want access to the recorded materials for a longer period, then you might want to consider going for the Plus or Premium packages.

The Plus package extends access to the course materials, including the forum and the office hours by an additional 2 months.

Office hours happen twice a week, at two different times to accommodate multiple time zones. During office hours I will be reviewing with the students their learning and understanding of WebRTC and assist in person in areas that will arise. I might even decide to hold a quick online lesson on relevant or timely topics during the office hours.

The Premium package extends access to the curse materials up to a full year. More about the premium package below.

Groups

If you want to enroll multiple employees or just come join as a team, they just contact me directly.

For large enough groups, I can offer discounts. For others, just the service of proforma invoice and wire transfer (which can still be better than PayPal for you).

We will be having 3-4 medium sized groups in our course this time, which will make things interesting – especially during office hours.

The Premium Package

I decided to add a premium package to the offering.

The idea behind it is to allow those who want more access to my time, and in a more private way.

The premium package offers two substantial additions on top of the Plus package:

1. Access to course materials for a full year (instead of 2 or 4 months)
2. Two private consultation calls with me

In the past few months I’ve noticed a lot of small companies who end up wanting an advice. A few hours of my time to explain to me what they are doing and chat about it, to see if there’s anything I can suggest. I decided to offer this service through this course as well, by bundling it as two consultation calls that go on top of the course itself.

We select together the agenda of these calls and what you want to achieve in them before we start. We then schedule the time and medium to use for the call (think something with WebRTC and a webcam, but not necessarily). And then we sit and chat.

If you already enrolled

If you already enrolled via PayPal and haven’t heard anything from me other than an order form and an invoice – don’t worry. I will be reaching out to all students a week or two before the course.

I am excited to do this, and really hope you are too.

 

See you next month!

 

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

 

The post Advanced WebRTC Architecture Course: Adding a Premium Package appeared first on BlogGeek.me.

This week mod_conference and mod_verto saw the most action with added sounds and user variables, whitelisting, and syncing outbound calls with the user directory respectively. 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-9533 [mod_conference] Add member-enter-sound
• FS-9526 [mod_conference] Add deaf sounds
• FS-9543 [core] Add pre-exec state change hooks to core
• FS-9549 [mod_verto] Add userVariables to DMTF and INFO messages
• FS-9524 [mod_verto] Enable whitelisting of Verto connections by IP using FS ACL
• FS-9550 [mod_verto] Set user on outbound verto calls to sync with user directory
• FS-9551 [switch_ivr – json cdr] Adding app-stamp to app_log

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

• FS-9527 [mod_avmd] Fix MAP_POPULATE on FreeBSD

The following bugs were squashed:

• FS-9538 [core] Fixed a segfault while reading local ringback file
• FS-9548 [core] Return with an error on wrong RTP IP given from configuration
• FS-9536 [core] Fixed the return value
• FS-9552 [mod_conference] Added ‘deaf’ to the json status per member
• FS-9435 [mod_av] Fixed an issue with receiving PLI requests once per second
• FS-9525 [mod_av] Fixed an issue with client initiated RE-INVITE with a different audio codec calling into conference causing choppy audio
• FS-9557 [rtp] Eating AV in proxy media mode causing a few seconds of black screen
• FS-9498 [mod_conference] Fixed a regression with 100% cpu

A new module has been imported recently into the Kamailio git repository, named rabbitmq — its docs are available at:

• https://www.kamailio.org/docs/modules/devel/modules/rabbitmq.html

The module is a result of a joint development between Carsten Bock and Stefan Mititelu. If offers AMQP communication from kamailio.cfg using librabbitmq, allowing to interact using a well establish message queuing mechanism with external applications.Enjoy!

The FreeSWITCH 1.6.11 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.11.tar.gz
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation

New features that were added:

• FS-9138 [mod_avmd] Add config to vanilla folder
• FS-9480 [mod_kazoo] Add api enhancements
• FS-9457 [mod_http_cache] Allow GET and PUT from Azure Blob Service
• FS-9551 [switch_ivr – json cdr] Adding app-stamp to app_log
• FS-9487 [core] Add CBR param to video file recording params
• FS-9543 [core] Add pre-exec state change hooks to core
• FS-9472 [core] Add originate_retry_timeout, a maximum duration in seconds to allow retry
  attempts to occur, and originate_retry_min_period_ms, a minimum spacing between retry attempts
• FS-9495 [mod_conference] Add conference_join_energy_level variable
• FS-9533 [mod_conference] Add member-enter-sound
• FS-9526 [mod_conference] Add deaf sounds
• FS-9474 [mod_conference] Add variables to set initial volume on mod_conference
• FS-9498 [mod_conference] Fixed a regression with 100% cpu
• FS-9549 [mod_verto] Add userVariables to DMTF and INFO messages
• FS-9524 [mod_verto] Enable whitelisting of Verto connections by IP using FS ACL
• FS-9550 [mod_verto] Set user on outbound verto calls to sync with user directory
• FS-9242 [mod_verto] Convert to adapter.js
• FS-8955 [verto_communicator] Adding DTMF shortcuts and handling DTMF history on DTMF widget
• FS-9469 [verto.js] Added onGrant/onDenied callbacks in onStream/onError of RTCCallbacks so that the client code gets notified of a webrtc permission change immediately
• 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-9466 [build] Use system MD5 if available
• FS-8623 [build] Fixed sun studio build errors building libvpx
• FS-9553 [core] Refactor video-on-hold
• FS-9465 [ubuntu packages] Add xenial instrumentation to Debian/utils.sh script
• FS-9471 [verto_communicator] Updating In Call display after receiving display update mes\
  sage from mod_verto.
• FS-9475 [mod_verto] Video bandwidth not conveyed in SDP for verto
• FS-9551 [mod_sofia] Compare session before setting TFLAG_SKIP_EARLY
• FS-9488 [mod_http_cache] Fixed a compile error
• FS-9498 [mod_conference] Try to make video writing thread more efficient
• FS-9527 [mod_avmd] Fix MAP_POPULATE on FreeBSD

The following bugs were squashed:

• FS-9538 [core] Fixed a segfault while reading local ringback file
• FS-9548 [core] Return with an error on wrong RTP IP given from configuration and fixed a crash on Invite due to bad configuration for sip profile
• FS-9536 [core] Fixed an issue with the return value
• FS-9580 [core] Add auto adjust for RTCP separate from RTP for sync NAT
• FS-9482 [core] Fixed a segfault on the second attempt to use uuid_media_3p
• FS-9484 [core] Fixed a variable type format spec
• FS-6954 [core] Use channel flags to check for proxy media or bypass media
• FS-9483 [mod_conference] Fixed a missing keyframe after re-invite
• FS-9493 [mod_conference] Fixed a possible crash when changing from normal to personal canvas on the fly
• FS-9494 [mod_conference] Fixed issues with video avatar switching when video starts/stops
• FS-9552 [mod_conference] Added ‘deaf’ to the json status per member
• FS-9435 [mod_av] Fixed an issue with receiving PLI requests once per second
• FS-9525 [mod_av] Fixed an issue with client initiated RE-INVITE with a different audio codec calling into conference causing choppy audio
• FS-9497 [mod_av] Fixed an AV sync record issue
• FS-9557 [rtp] Eating AV in proxy media mode causing a few seconds of black screen
• FS-9574 [mod_verto] We shouldn’t print data sent on the buffer because of the potential security issues
• FS-9475 [mod_verto] Video bandwidth not conveyed in SDP for verto
• FS-9471 [verto_communicator] Updating In Call display after receiving display update message from mod_verto.
• FS-9346 [verto_communicator] Add DTMF icon while on a video call, fixing conferences with pin number
• 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-9486 [mod_sofia] Fixed an issue with uuid_drop_dtmf switching between tone replace and digit
• FS-9458 [mod_avmd] Set channel variable before BEEP event is fired

Recording WebRTC? Definitely server side. But maybe client side.

This article is again taken partially from one of the lessons in my upcoming WebRTC Architecture Course. There, it is given in greater detail, and i recorded.

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

 

Recording is obviously not part of what WebRTC does. WebRTC offers the means to send media, but little more (which is just as it should be). If you want to record, you’ll need to take matters into your own hands.

Generally speaking, there are 3 different mechanisms that can be used to record:

1. Server side recording
2. Client side recording
3. Media forwarding

Let’s review them all and see where that leads us.

#1 – Server side recording

This is the technique I usually suggest developers to use. Somehow, it fits best in most cases (though not always).

What we do in server-side recording is route our media via a media server instead of directly between the browsrs. This isn’t TURN relay – a TURN relay doesn’t get to “see” what’s inside the packets as they are encrypted end-to-end. What we do is terminate the WebRTC session at the server on both sides of the call – route the media via the server and at the same time send the decoded media to post processing and recording.

What do I mean by post processing?

• We might want to mix the inputs from all participants and combine it all to a single media file
• We might want to lower the filesize that we end up storing
• Change format (and maybe the codecs?), to prepare it for playback in other types of devices and mediums

There are many things that factor in to a recording decision besides just saying “I want to record WebRTC”.

If I had to put pros vs cons for server side media recording in WebRTC, I’d probably get to this kind of a table:

+–No change in client-side requirementsAnother server in the infrastructureNo assumptions on client-side capabilities or behaviorLots of bandwidth (and processing)Can fit resulting recording to whatever medium and quality level necessaryNow we must route media#2- Client side recording

In many cases, developers will shy away from server-side recording, trying to solve the world’s problem on the client-side. I guess it is partially because many WebRTC developers tend to be Java Script coders and not full stack developers who know how to run complex backends. After all, putting up a media server comes with its own set of headaches and costs.

So the basics of client-side recording leans towards the following basic flow:

We first record stuff locally – WebRTC allows that.

And then we upload what we recorded to the server. Here’ we don’t really use WebRTC – just pure file upload.

Great on paper, somewhat less in reality. Why? There are a few interesting challenges when you record locally on machine you don’t know or control, via a browser:

• Do you even know how much available storage do you have to use for the recording? Will it be enough for that full hour session you planned to do for your e-learning service?
• And now that the session is done and you’re uploading a Gb of a file. Is the user just going to sit there and wait without closing his browser or the tab that is uploading the recording?
• Where and what do you record? If both sides record, then how do you synchronize the recordings?

It all leads to the fact that at the end of the day, client side recording isn’t something you can use. Unless the recording is short (a few minutes) or you have complete control over the browser environment (and even then I would probably not recommend it).

There are things you can do to mitigate some of these issues too. Like upload fragments of the recording every few seconds or minutes throughout the session, or even do it in parallel to the session continuously. But somehow, they tend not to work that well and are quite sensitive.

Want the pros and cons of client side recording? Here you go:

+–No need to add a media server to the media flowClient side logic is complex and quite dependent on the use caseRequires more on the uplink of the user – or more wait time at the end of the sessionNeed to know client’s device and behavior in advance#3 – Media forwarding

This is a lesser known technique – or at least something I haven’re really seen in the wild. It is here, because the alternative is possible to use.

The idea behind this one is that you don’t get to record locally, but you don’t get to route media via a server either.

What is done here, is that media is forwarded by one or both of participants to a recording server.

The latest releases of Chrome allows to forward incoming peer connection media, making this possible.

This is what I can say further about this specific alternative:

+–No need to add a media server into the flow – just as an additional external recording serverRequires twice the uplink or moreDo you want to be the first to try this technique?Things to remember

Recording doesn’t end with how you record media.

There’s meta data to treat (record, playback, sync, etc).

And then there’s the playback part – where, how, when, etc.

There are also security issues to deal with and think about – both on the recording end and on the playback side.

These are covered in a bit more detail in the course.

What’s next?

If you are going to record, start by leaning towards server side recording.

Sit down and list all of your requirements for recording, archiving and playback – they are interconnected. Then start finding the solution that will fit your needs.

And if you feel that you still have gaps there, then why not enroll to the Advanced WebRTC Architecture course?

 

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

The post Recording WebRTC Sessions: client side or server side? appeared first on BlogGeek.me.

Analytics != Operation

Twilio just announced a new service to its growing cadre of services. This time – Voice Insights.

What to expect in the coming days

This week Twilio announced several interesting initiatives:

1. Country specific guidelines on using SMS
2. A new Voice Insights service
3. The Kurento acquisition

Add to that their recent announcement on their new Enterprise offering and the way they seem to be adding more number choices in countries. What we get is too much work to cover a single vendor in this industry.

Twilio is enhancing its services in breadth and depth at the same time, doing so while trying to reach out to new customer types. I will be covering all of these issues soon enough. Some of it here, some on other blogs where I write. Customers with an active subscription for my WebRTC PaaS report will receive a longform written analysis separately covering all these aspects later this month.

What I want to cover in this article

I already wrote about Twilio’s Kurento acquisition. This time, I want to focus on Voice Insights.

All the media outlets I’ve checked to read about Voice Insights were regurgitating the Twilio announcement with little to add. At most, they had callstats.io to refer to. I think a lot is missing from the current conversation. So lets dig in.

What is Voice Insights?

Voice Insights is a set of tools that can be used to understand what’s going on under the rug. When you use a communications API platform – or build your own for that matter – the first thing to notice is that there’s lack of understanding of what’s really happening.

Most dashboards focus on giving you the basics – what sessions you created, how long were they, how much money you owe us. Others add some indication of quality metrics.

The tools under the Voice Insights title at Twilio include:

1. Collection of all network stats, so you can check them out in the Twilio console
2. Real time triggers on the client, telling you when network issues arise or the volume is too low/high
3. Pre-call network test on the client
4. User feedback collection (the Skype “how was your call quality” nag)

Some of them were already available in some form or another in the Twilio offering – such as user feedback collection.

The features here can be split into two types:

1. Client side – the real time triggers, pre-call network test
2. Server side – collection of network stats

Twilio gave a good introduction to all of thee capabilities, so I won’t be repeating them here.

What is interesting, is if and how they have decided to implement the real time triggers – do they get triggered from the backend or directly by running rules on the device. But I digress here.

How is it priced?

Interestingly, Voice Insights is priced separately from the calling service itself.

If you want insights into the voice minutes you use on Twilio, there’s an extra charge associated with it.

Prices start from $0.004 per minute, going down to ~$0.002 per minute for those who can commit to 1 million voice minutes a month. It goes down to a shy above $0.001 a minute.

For comparison, SIP-to-SIP voice calling on Twilio starts at $0.005 per minute, making Voice Insights a rather expensive service.

Comparisons with callstats.io are necessary at this point. If you take a low tier of 10,000 voice minutes a month, callstats.io is priced at 19 EUR (based on their calculator – it can get higher or lower based on “data points”) whereas Twilio Voice Insights stands at 40 USD. How do these two vendors offer lower rates at bulk is an exercise I’ll leave for others to make.

Is this high? low? market price? I have no clue.

TokBox, on the other hand, has their own tool called Inspector and another feature called Pre-Call Test. And it is given for free as part of the service.

Where is it headed?

Voice Insights can take several directions with Twilio:

• Extend it to support video sessions as well
• Enhance and deepen the analytics capabilities, probably once enought  feedback is received from customers on this feature
• Switch from a paid to free offering, again, based on customer feedback
• Unbundle it from Twilio and offer it as a stand-alone service to others – maybe to all the vendors that are using Kurento on premise?

With analytics, the sky usually isn’t the limit. It is just the beginning of the dreams and stories you can build upon a large data set. The problem is how can you take these dreams and make them come true.

Which brings us to the next issue.

The future of Analytics in Comm APIs

There’s a line drawn in the sand here. Between communications and analytics.

Analytics has a perceived value of its own – on top of enabling the interaction itself.

Will this hold water? Will other communication API vendors add such capabilities? Will they be charging extra for them?

I’ve had my share of stories around CEM (Customer Experience Management). Network equipment vendors and those handling video streaming are marketing it to their customers. Analytics on network data. This isn’t much different.

Time will tell if this is something that will become common place and desired, or just a failed attempt. I still don’t have an opinion where this will go.

Up next

Next in my quick series of articles on Twilio comes coverage of their new Enterprise plan, and how Twilio is trying to grow in breadth and depth at the same time.

 

Test and Monitor your WebRTC Service like a pro - check out how testRTC can improve your service' stability and performance.

The post Twilio’s Voice Insights for WebRTC – a line on the sand appeared first on BlogGeek.me.

If you haven’t yet enrolled to my Advanced WebRTC Architecture course – then why wait?

I just noticed that I haven’t written any specific post here about the upcoming course, so consider this one that announcement. To my defense – I sent it out a few days ago to the monthly newsletter I have.

Why a course on WebRTC architecture?

I’ve been working with entrepreneurs, developers, product managers and people in general about their WebRTC products for quite some time. But somehow I missed to notice that in many such discussions there were large gaps in what people thought about WebRTC and what WebRTC really is.

There’s lots of beginner’s information out there for WebRTC, but somehow it always focuses on how to use the WebRTC APIs in the browser, or what the meaning of a specific feature in the standard is. There is also a large set of walk-throughs of different frameworks that you can use, but no one seems to offer a path for a developer to decide on his architecture. To answer the question of “what should I be choosing for my service?”

So I set out to put a course that answers that specific question. It gives the basics of what WebRTC is, and then dives into the part of what it means to put an architecture in place:

• How to analyze the real requirements of your scenarios?
• What are the various components you will need?
• Go through common design patterns that crop up in popular service archetypes

What’s in the course?

The easiest way is to go through the course syllabus. It is available online here and also in PDF form.

When will the course take place?

The course is all conducted online, but not live.

It starts on October 24, and I am now in final preparation of recording the materials after creating them in the past two months.

The course is designed to be:

• Built out of 7 modules
• Have 40 lessons give or take, each on average should take you 30 minutes
• This means if you take a lesson on every working day, you should complete this in 2 months
• You can do it at a faster pace if you wish
• Course materials are available online for students for a period of 2 months. This can be extended to 4 months for those who wish to add Office Hours on top of the course

Any discount for friends and family?

Enrolling to the course is $247 USD. Adding Office Hours on top of it means an additional $150 USD.

Until tomorrow, there’s a $50 USD discount – so enroll now if you’re already certain you want to.

There are discounts for those who want to enroll as a larger group – contact me for that.

Have more questions?

Check the FAQ. I’ll be updating it as more questions come it.

If you can’t find what you need there – just contact me.

The post Discount on the Advanced WebRTC Architecture Course ends tomorrow appeared first on BlogGeek.me.

Open source media frameworks in WebRTC are all the rage these days.

Jitsi got acquired by Atlassian early last year and now Twilio grabs Kurento.

What to expect in the coming days

Yesterday Twilio announced several interesting initiatives:

1. Country specific guidelines on using SMS
2. A new Voice Insights service
3. The Kurento acquisition

Add to that their recent announcement on their new Enterprise offering and the way they seem to be adding more number choices in countries. What we get is too much work to cover a single vendor in this industry.

Twilio is enhancing its services in breadth and depth at the same time, doing so while trying to reach out to new customer types. I will be covering all of these issues soon enough. Some of it here, some on other blogs where I write. Customers with an active subscription for my WebRTC PaaS report will receive a longform written analysis separately covering all these aspects later this month.

What I want to cover in this article

What I want to cover in this part of my analysis of the recent Twilio announcements is their acquisition of Kurento.

Things I’ll be touching is Why Kurento – how will it further Twilio’s goal – and also what will happen to the many users of Kurento.

I’ll also touch the open source media server space, and the fact that the next runner up in the acquisition roulette of our industry should be Janus.

But first things first.

What is Kurento?

Kurento is an open source WebRTC server-side media framework implemented on top of GStreamer. While it may not be limited to WebRTC, my guess is that most if not all of its users make use of WebRTC with it.

What does that mean exactly?

• Open source – anyone can download and use Kurento. And many do
  • There’s a vibrant community around it of developers that use it independently, Outsourcing development shops that use it in their projects to customers and the Kurento team itself offering free and paid support to it
  • It is distributed under the Apache license which is quite lenient and enterprise-friendly
• server-side media framework – when you want to process media in WebRTC for recording, multiparty or other processes, a server-side media framework is necessary
• GStreamer – another popular open source project for media processing. Just another tidbit you may want to remember

I am seeing Kurento everywhere I go. Every couple of meetings I have with companies, they indicate that they make use of Kurento or when you look at their service it is apparent it uses Kurento. Somehow, it has become one of these universal packages that developers turn to when they need stuff done.

The Kurento team is running multiple activities/businesses (I might be doing a few mistakes here – it is always hard to follow such internal structures):

1. Kurento, the open source project itself
   • Assisted by research done at theUniversidad Rey Juan Carlos located in Madrid, Spain
   • Funding raised through the European Commission
   • Money received by selling support and customization services
2. NUBOMEDIA
   • A new initiative focused on scaling and an open source PaaS offering on top of Kurento
   • You can read more about it in a guest post by Luis Lopez (the face of Kurento)
3. elasticRTC
   • Another new initiative, but a commercial one
   • Focused at getting scalable Kurento running on AWS
4. Naevatec / Tikal Technologies SL
   • The business side of the Kurento project, where customization and support is done for a price

Kurento have a busy team…

What did Twilio acquire exactly?

This is where things get complicated. From my understanding, reading the materials online and through a briefing held with Twilio, this is what you can expect:

• Kurento as an open source project is left open source, untouched and un-acquired. That said, the bulk of the team maintaining Kurento (the Naevatec developers) will be moving to be Twilio employees
• Naevtec was not acquired and will live on. A new team will need to be hired and trained. During the transition period, the Twilio team will work on the Kurento project fulfilling any existing obligations. After that, Naevatec will supposedly have the internal manpower to take charge of that part of the business
• elasticRTC was acquired. They will not be onboarding any new customers, but will continue supporting existing customers
  • This sounds like the story of AddLive and Snapchat (they waited for support contracts to expire and worked diligently but legally to get customers off the AddLive service)
  • That said, it seems like Twilio wants to leverage these early adopters of elasticRTC to design and build their own Twilio API offering around that domain (more on that later)
  • As I don’t believe there are many customers to elasticRTC, I don’t see this as a real blow to anyone
• NUBOMEDIA was not mentioned in any of the announcements of the acquisition
  • I forgot to prod about it in my briefing…
  • Twilio are probably unhappy about this one, but had nothing to do about it
  • NUBOMEDIA is funded by multiple European projects, so was either impossible to acquire or too expensive for what Twilio had an appetite for
  • It might also had more partners to it than just the Kurento team(s)
  • How will the acquisition affect NUBOMEDIA’s project and the zeal with which Twilio’s new employees from Naevatec will have for it is an open question

To sum things up:

Twilio acqui-hired the team behind the Kurento project and took their elasticRTC offering out of the market before it became too popular.

How will Twilio use Kurento?

I’d like to split this one to short term and long term

Short term – multiparty calling

Twilio needed an SFU. Desperately.

In April 2015 the Twilio Video initiative was announced. Almost 18 months later and that service is still in beta. It is also still 1:1 calling or mesh for multiparty.

Something had to be done. While I am sure Twilio has been working for quite some time on a solid multiparty option, they probably had a few roadblocks, which got them to start using Kurento – or decide they need to buy that technology instead of build it internally.

Which got them to the point of the acquisition. Twilio will probably embed Kurento into their Twilio Video offer, adding three new capabilities to their platform with it:

1. Multiparty calling, in an SFU model, and maybe an MCU one
2. Video recording capability – a popular Kurento use case
3. PSTN connectivity for video calling – Kurento has a SIP-Gateway component that can be used for that purpose

Long term – generic media server

In the long term, Twilio can employ the full power of Kurento and offer it in the cloud with a flexible API that pipelines media in real time.

This can be used in our new brave world of AI, Bots, IOT and AR – all them acronyms people love talking about.

It will be interesting to see how Twilio ends up implementing it and what kind of an API and an offering they will put in place, as there are many challenges here:

• How do you do something so generic but still maintain low resource consumption?
• How do you price it in an attractive way?
• How do you decide which use cases to cover and which to ignore?
• How do you design it for scale, especially if you are as big as Twilio?
• How do you design simple yet flexible and powerful API for something so generic in nature?

This is one of the most interesting projects in our industry at the moment, and if Twilio is working towards that goal, then I envy their product managers and developers.

What will be left of the Kurento project?

That’s the big unknown. Luis Lopez, project lead of Kurento details the official stance of Kurento and Twilio on the Kurento blog. It is an expected positive looking write up, but it leaves the hard questions unanswered.

Maintaining the Kurento project

Twilio is known for their openness and the way they work with developers. While that is true, the Twilio github has little in the way of projects that aren’t samples written on top of the Twilio platform or open sourced projects that touch the core of Twilio. While that is understandable and expected, the question is how will Twilio treat the Kurento open source project?

Now that most of the workforce that is leading Kurento are becoming Twilio employees, will they work on the open source Kurento build or on internal needs and builds of Twilio? Here are a few hard questions that have no real answers to them:

• What will be contributed back to the Kurento project besides stability and bug fixes?
• If Twilio work on optimizing Kurento to higher capacities or add horizontal scalability modules to Kurento. Will that be open sourced or left inside Twilio?
• How will Twilio prioritize bugs and requests coming from the large Kurento community versus handling their own internal roadmap?

While in many cases, with Kurento the answer would have been that Naevatec could just as well limit the access to higher level modules for paid customers – there was someone you could talk to when you wanted to purchase such modules. Now with Twilio, that route is over. Twilio are not in the business of paid support and customization of open source projects – they are in the business of cloud APIs.

There will be ongoing friction inside Twilio with the decision between investing in the open source Kurento platform versus using it internally. If you thought that was bad with Atlassian acquiring Jitsi – it is doubly so here, where Twilio may have to compete with a build vs buy decisions of companies where “build” is done on top of Kurento.

I assume Twilio doesn’t have the answers to these questions yet either.

Maintaining the business model

Kurento has customers. Not only users and developers.

These customers pay Naevatec. They pay for support hours or for customization work.

Will this be allowed moving forward?

Can the yet-to-be-hired new team at Naevatec handle the support?

What happens when someone wants to pay a large sum of money to Naevatec in order to deploy a scalable Kurento service in the cloud? Will Naevatec pick that project? If said customer also wants to build an API platform on top of it, will that be something Naeva Tec will still do?

What will others who see themselves as Twilio competitors do if they made use of Kurento up until now? Especially if they were a Naevatec paying customer…

The good thing is, that many of the Kurento users ended up getting paid support and customization by third party vendors. Now if you only could know which one of them does a decent job…

Should TokBox be worried?

Yes and no.

Yes, because it means Twilio will be getting their multiparty story, and by that competing with TokBox. Twilio has a wider set of features as well, making them more attractive in some cases.

No, because there’s room for more players, and for video calling services at the moment, TokBox is the go-to vendor. I wonder if they can maintain their lead.

What about Janus?

I recently compared Jitsi to Kurento.

Little did I know then that Twilio decided on Kurento and was in the process of acquiring it.

I also raised the question about Janus.

To some extent, Janus is next-in-line:

• Those I know who use the project are happy with it and its architecture. A lot more than other smaller open source media framework projects
• Slack has been using Janus for awhile now
• Other vendors, some got acquired recently, also make use of it

Does Meetecho, the company behind Janus, willing to sell it isn’t important. It is a matter of price points.

We’ve seen the larger vendors veer towards acquiring the technology that they are using.

Will Slack go after Janus? Maybe Vonage/Nexmo? Oracle, to beef their own WebRTC offering?

–

Open source media frameworks have proven to be extremely effective in churning out commercial services on top of them. WebRTC made that happen by being its own open source initiative.

It is good to see Kurento finding a new home and growing up. Kudos to the Kurento team.

 

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

 

The post Twilio Acquires Kurento. Who will Acquire Janus? appeared first on BlogGeek.me.

I hope this will clear up some of the confusion around WebRTC media flows.

I guess this is one of the main reasons why I started with my new project of an Advanced WebRTC Architecture Course. In too many conversations I’ve had recently it seemed like people didn’t know exactly what happens with that WebRTC magic – what bits go where. While you can probably find that out by reading the specifications and the explanations around the WebRTC APIs or how ICE works, they all fail to consider the real use cases – the ones requiring media engines to be deployed.

So here we go.

In this article, I’ll be showing some of these flows. I made them part of the course – a whole lesson. If you are interested in learning more – then make sure to enroll to the course.

#1 – Basic P2P Call Direct WebRTC P2P call

We will start off with the basics and build on that as we move along.

Our entities will be colored in red. Signaling flows in green and media flows in blue.

What you see above is the classic explanation of WebRTC. Our entities:

1. Two browsers, connected to an application server
2. The application server is a simple web server that is used to “connect” both browsers. It can be something like the Facebook website, an ecommerce site, your heatlhcare provider or my own site with its monthly virtual coffee sessions
3. Our STUN and TURN server (yes. You don’t need two separate servers. They almost always come as a single server/process). And we’re not using it in this case, but we will in the next scenarios

What we have here is the classic VoIP (or WebRTC?) triangle. Signaling flows vertically towards the server but media flows directly across the browsers.

BTW – there’s some signaling going off from the browsers towards the STUN/TURN server for practically all types of scenarios. This is used to find the public IP address of the browsers at the very least. And almost always, we don’t draw this relationship (until you really need to fix a big, STUN seems obvious and too simple to even mention).

 

Summing this one up: nothing to write home about.

Moving on…

#2 – Basic Relay Call Basic WebRTC relay call

This is probably the main drawing you’ll see when ICE and TURN get explained.

In essence, the browsers couldn’t (or weren’t allowed) to reach each other directly with their media, so a third party needs to facilitate that for them and route the media. This is exactly why we use TURN servers in WebRTC (and other VoIP protocols).

This means that WebRTC isn’t necessarily P2P and P2P can’t be enforced – it is just a best effort thing.

So far so go. But somewhat boring and expected.

Let’s start looking at more interesting scenarios. Ones where we need a media server to handle the media:

#3 – WebRTC Media Server Direct Call, Centralized Signaling WebRTC Media Server Direct Call, Centralized Signaling

Now things start to become interesting.

We’ve added a new entity into the mix – a media server. It can be used to record the calls, manage multiparty scenarios, gateway to other networks, do some other processing on the media – whatever you fancy.

To make things simple, we’ve dropped the relay via TURN. We will get to it in a moment, but for now – bear with me please.

Media

The media now needs to flow through the media server. This may look like the previous drawing, where the media was routed through the TURN server – but it isn’t.

Where the TURN server relays the media without looking at it – and without being able to look at it (it is encrypted end-to-end); the Media Server acts as a termination point for the media and the WebRTC session itself. What we really see here is two separate WebRTC sessions – one from the browser on the left to the media server, and a second one from the media server to the browser on the right. This one is important to understand – since these are two separate WebRTC sessions – you need to think and treat them separately as well.

Another important note to make about media servers is that putting them on a public IP isn’t enough – you will still need a TURN server.

Signaling

On the signaling front, most assume that signaling continues as it always have. In which case, the media server needs to be controlled in some manner, presumably using a backend-to-backend signaling with the application server.

This is a great approach that keeps things simple with a single source of truth in the system, but it doesn’t always happen.

Why? Because we have APIs everywhere. Including in media servers. And these APIs are sometimes used (and even abused) by clients running browsers.

Which leads us to our next scenario:

#4 – WebRTC Media Server Direct Call, Split Signaling WebRTC Media Server Direct Call, Split Signaling

This scenario is what we usually get to when we add a media server into the mix.

Signaling will most often than not be done between the browser and the media server while at the same time we will have signaling between the browser and the application server.

This is easier to develop and start running, but comes with a few drawbacks:

1. Authorization now needs to take place between multiple different servers written in different technologies
2. It is harder to get a single source of truth in the system, which means it is harder for the application server to know what is really going on
3. Doing such work from a browser opens up vulnerabilities and attack vectors on the system – as the code itself is wide open and exposes more of the backend infrastructure

Skip it if you can.

Now lets add back that STUN/TURN server into the mix.

#5 – WebRTC Media Server Call Relay WebRTC Media Server Call Relay

This scenario is actually #3 with one minor difference – the media gets relayed via TURN.

It will happen if the browsers are behind firewalls, or in special cases when this is something that we enforce for our own reasons.

Nothing special about this scenario besides the fact that it may well happen when your intent is to run scenario #3 – hard to tell your users which network to use to access your service.

#6 – WebRTC Media Server Call Partial Relay WebRTC Media Server Call Partial Relay

Just like #5, this is also a derivative of #3 that we need to remember.

The relay may well happen only in one side of the media server – I hope you remember that each side is a WebRTC session on its own.

If you notice, I decided here to have signaling direct to the media server, but could have used the backend to backend signaling.

#7 – WebRTC Media Server and TURN Co-location WebRTC Media Server and TURN Co-location

This scenario shows a different type of a decision making point. The challenge here is to answer the question of where to deploy the STUN/TURN server.

While we can put it as an independent entity that stands on its own, we can co-locate it with the media server itself.

What do we gain by this? Less moving parts. Scales with the media server. Less routing headaches. Flexibility to get media into your infrastructure as close to the user as possible.

What do we lose? Two different functions in one box – at a time when micro services are the latest tech fad. We can’t scale them separately and at times we do want to scale them separately.

Know Your Flows

These are some of the decisions you’ll need to make if you go to deploy your own WebRTC infrastructure; and even if you don’t do that and just end up going for a communication API vendor – it is worthwhile understanding the underlying nature of the service. I’ve seen more than a single startup go work with a communication API vendor only to fail due to specific requirements and architectures that had to be put in place.

One last thing – this is 1 of 40 different lessons in my Advanced WebRTC Architecture Course. If you find this relevant to you – you should join me and enroll to the course. There’s an early bird discount valid until the end of this week.

The post How Media and Signaling flows look like in WebRTC? appeared first on BlogGeek.me.

The Asterisk Users Conference – AstriCon – is taking place in Glendale, Arizona, during September 27-29, 2016.With a consistent group of VoIP community using both Kamailio and Asterisk projects, Kamailio will have again a strong presence on site this year, including the participation in the expo floor, coordinated this edition by Fred Posner.Along with him, you may meet around Torrey Searle, Nir Simionovich, Joran Vinzens and others that can answer your questions about Kamailio and Asterisk. Like in the past editions, several presentations will touch the use of Kamailio and integration with Asterisk — see agenda.It is definitely a must-attend event if you are looking to build flexible real time communications using Kamailio and Asterisk, or even beyond that, there are not many places around the world where you can find so much VoIP knowledge at the same time along the year!

Chad Hart joins the ClueCon Weekly Team to talk WebRTC

*It should be noted that the lip sync on this video is off due to bandwidth issues on our presenters side.

Next European edition of Kamailio Advanced Training will take place in Berlin, Germany, during October 24-26, 2016.The content will be based on latest stable series of Kamailio 4.4.x, released in March 2016, the major version that brought a large set of new features, currently having the minor release number v4.4.2.The class in Berlin is organized by Asipto  and will be taught by Daniel-Constantin Mierla, co-founder and core developer of Kamailio SIP Server project.Read more details about the class and registration process at:

• http://www.asipto.com/sw/kamailio-advanced-training/

Looking forward to meeting some of you in Berlin!