News from Industry

FreeSWITCH Week in Review (Master Branch) June 13th-19th

FreeSWITCH - Tue, 06/23/2015 - 19:28

Hello, again. This passed week in the FreeSWITCH master branch we had 94 commits! We had a large amount of work done this week and a few of the highlights are: added mod_local_stream video support, added member status in json format to the conference live array, added function to enable debug information about Opus payload, and a security issue concerning enabling cert CN/SAN validation.

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

Security issues:
FS-7708 Fixed docs on enabling cert CN/SAN validation

New features that were added:
FS-7656 [mod_localstream] Added mod_local_stream video support, and make mod_conference move the video in and out of a layer when the stream has video or not, scan for relative file in art/eg.wav.png and display it as video when playing audio files, put video banner up if artist or title is set, and fixed a/v sync on first connection
FS-7629 [mod_conference] Added member status in json format to the conference live array, add livearray-json-status to conference-flags to enable
FS-7517 FS-7519 [mod_av] [mod_openh264] Added H264 STAP-A packeting support so it would work with FireFox
FS-7664 [mod_verto] Set ICE candidate timeout to wait for only 1 second to fix media delays
FS-7660 [mod_opus] Enabled with new API command “opus_debug” to show information about Opus payload for debugging.
FS-7519 [mod_av] Fixed bitrate and added some presets
FS-7693 [mod_conference] Lower the default energy level in sample configs to improve voice quality

Improvements in build system, cross platform support, and packaging:
FS-7648 More work toward setting up a QA testing configuration, add condition testing for regex all and xor cases, adding profile-variable for testing cases , add lipsync tests for playback and local stream, add stereo, and configuration for mcu test
FS-7338 Fixed bug in Debian packaging when trying to build against custom repo
FS-7609 Enable building of mod_sangoma_codec for Debian Wheezy/Jessie
FS-7667 [mod_java] Fixed include directory detection when using Debian java packages and use detected directory
FS-7655 Make libvpx and libyuv optional (none of the video features will work without them) The following modules require these libraries to be installed still: mod_av mod_cv mod_fsv mod_mp4v2 mod_openh264 mod_vpx mod_imagick mod_vpx mod_yuv mod_png mod_vlc, fix build issue w/ strict prototypes, and fix a few functions that need to be disabled without YUV
FS-7605 Fixed default configuration directory in Debian packages and fixed Debian packaging dependencies on libyuv and libvpx
FS-7669 When installing from Debian packaging if you don’t have the /etc/freeswitch directory, we will install the default packages for you. If you already have this directory, we’ll let you deal with your own configs.
FS-7297 [mod_com_g729] Updated the make target installer
FS-7644 Added a working windows build without video support for msvc 2013
FS-7666 [mod_managed] Fixed error building mod_managed on non windows platforms

The following bugs were squashed:
FS-7641 Fixed a segfault in eavesdrop video support
FS-7649 [mod_verto] Fixed issue with h264 codec not being configured in verto.conf.xml
FS-7657 [mod_verto] Fixed a bug with TURN not being used. Note, you can pass an array of stun servers, including TURN, to the verto when you start it up. (see verto.js where iceServers is passed)
FS-7665 [mod_conference] Fixed a bug with the video floor settings not giving the video floor to the speaker
FS-7650 [mod_verto] Fixed crash when making a call from a verto user with profile-variables in their user profile
FS-7710 [mod_conference] Added the ability to set bandwidth to “auto” for conference config
FS-7432 Fixed dtls/srtp, use correct a=setup parameter on recovering channels
FS-7678 Fixed for fail_on_single_reject not working with | bridge
FS-7709 [mod_verto] Verto compatibility fixes for Firefox
FS-7689 [mod_lua] Fixed a bug with lua not loading directory configurations
FS-7694 [mod_av] Fixed for leaking file handles when the file is closed.

Why Did Atlassian Switch Jitsi’s Open Source License from LGPL to Apache?

bloggeek - Tue, 06/23/2015 - 12:00

Jitsi switching to the Apache open source license is what the doctor ordered.

Blue Jimp, and with it Jitsi, was acquired by Atlassian in April this year. I wrote at the time about Jitsi’s open source license:

The problem with getting the Jitsi Videobridge to larger corporations was its open source license

  • Jitsi uses LGPL. A non-permissive license that is somewhat challenging for commercial use. While it is suitable for SaaS, many lawyers prefer not to deal with it
  • This reduces the Jitsi Videobridge’s chance to get adopted by enterprise developers who can pour more resources into it
  • This may limit Jitsi from building the ecosystem Atlassian wants (i.e – outsourcing some of the development effort to an external developers community)
  • Using BSD, MIT or Apache licenses would have been a better alternative. Will Atlassian choose that route? I am not sure
  • Did Atlassian leave the open source offering due to legal issues or real intent in becoming an open source powerhouse?

You can read my explanation on open source licenses. If you read the comments as well, you’ll see how complex and mired with landmines this domain is.

Last week, an announcement was made in the jitsi-dev mailing list: Jitsi is switching from LGPL to Apache license:

LGPL, our current license allows everyone to integrate and ship our various jars. Once you start making changes and distributing them however, then you you need to make sure these changes are also available under LGPL, AKA the LGPL reciprocity clause.

What I found interesting weer the next two paragraphs:

As the copyright holder, in BlueJimp we have been been exempt from this reciprocity clause. Even though we rarely use it, we had the liberty to modify our code without making our changes public. No one else had this option.

Switching to Apache ends our advantage in this regard, and allows everyone to use, integrate and distribute Jitsi with a lot less limitations.

Some things to notice here:

  • People who made changes to the Jitsi code base had to contribute back the code to Blue Jimp, along with the ability for Jitsi not to act the same – Jitsi maintained a different “license” for itself – this works well when your business model is consulting and customization of the open source project you maintain – not so good for a large enterprise
  • Atlassian took a different approach here by switching to Apache:
    • Atlassian internally has the same decision making processes as other large enterprises. LGPL is harder to adopt than Apache, making a switch to the Apache license for Jitsi a reasonable step to take – preferential treatment for Apache license in Atlassian and elsewhere played a key role here
    • It removed the possible nightmare of maintaining all of the existing CLAs (contributor license agreements) – they might have found them inaccurate, requiring a modification in their terms, needing a reassignment to Atlassian, etc – it was a good time to make the switch to Apache anyway
    • It gives a strong signal to the market, and especially to large enterprises that Jitsi is something they can use – if this turns out well, there will be additional contributors to this software package, as it is a popular one in the WebRTC industry
  • This switch from LGPL to APL (Apache) changes nothing in the ability of Blue Jimp and Atlassian to modify the base code and not contribute it back to the open source package
    • This kind of a thing has happened before during acquisitions of open source project teams
    • It also happens when competition starts using your own open source against you (think Google’s Android)
    • It is unlikely to happen in the short or medium term, based on the signals coming from Atlassian and their current focus
  • This opens up a powerful WebRTC media server (an SFU actually) to a larger number of vendors

All in all, this is a great move to our WebRTC ecosystem. Atlassian is doing the right moves in maintaining the Jitsi community happy and engaged while attracting the larger players in the market. I wouldn’t have done it any other way if I were in their shoes.


Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.


The post Why Did Atlassian Switch Jitsi’s Open Source License from LGPL to Apache? appeared first on

Kamailio Server Maintenance – Wed-Thu Night

miconda - Tue, 06/23/2015 - 10:16
During the night between Wed (June 24, 2015) and Thu (June 25, 2015), planned to start not early than 00:00 GMT+1, there will be some schedule maintenance work to the infrastructure that is hosting some of the servers.The main affected services will be:
  • main website (
  • wiki portals
  • mailing lists (
  • git mirror (
It is expected to have short downtimes of few minutes.

W3C ORTC CG – Editors Draft Update - Mon, 06/22/2015 - 21:37

Big thanks to everyone (especially Bernard) for putting in the extra work required here for our next CG meeting:

Draft Community Group Report 22 June 2015


B.1 Changes since 7 May 2015
  1. Addressed Philipp Hancke’s review comments, as noted in: Issue 198
  2. Added the “failed” state to RTCIceTransportState, as noted in: Issue 199
  3. Added text relating to handling of incoming media packets prior to remote fingerprint verification, as noted in: Issue 200
  4. Added a complete attribute to the RTCIceCandidateComplete dictionary, as noted in:Issue 207
  5. Updated the description of RTCIceGatherer.close() and the “closed” state, as noted in: Issue 208
  6. Updated Statistics API error handling to reflect proposed changes to the WebRTC 1.0 API, as noted in: Issue 214
  7. Updated Section 10 (RTCDtmfSender) to reflect changes in the WebRTC 1.0 API, as noted in: Issue 215
  8. Clarified state transitions due to consent failure, as noted in: Issue 216
  9. Added a reference to [FEC], as noted in: Issue 217

How OTTs are Challenging VoLTE’s Prime Asset on Smartphones

bloggeek - Mon, 06/22/2015 - 12:00

While our smartphones aren’t phone anymore, their phone-calling real estate is still a prime asset.

VoLTE stands for Voice over LTE. It has been in the making for quite some time, but haven’t made its grand public appearance yet. While carriers around the globe boast LTE adoption stats, this says NOTHING about the lag of the carrier’s once main service – the humble voice call.

Today, in almost all cases where you open your smartphone greeted with an LTE network, if you make a phone call, it will go over 3G or GSM. Why? Because for voice to traverse LTE it requires VoLTE – or some other workaround means. Once VoLTE makes it into the scene, it will need to replace the voice calls today – and be a part of the smartphone’s dialer.

But there are other means of making calls these days, and I am not talking about Skype buddy lists.

Here is how the different players on the market redefining how we make calls, and trying to win the real-estate of the phone’s dialer by… replacing it.


In some ways, Apple is dependent on carriers selling its smartphones through contract agreements. So it can’t piss off their channel to market too much. But they can are treading on a very fine line here.

It started with FaceTime. Apple’s video chat service. Which then grew to iMessage, and later an introduction of FaceTime Audio.

Apple controls the iPhone’s UI, which means it decides how the dialer looks like and what functions it exposes to the user.

The end result?

  • When you want to send an SMS to someone, Apple will automatically “convert” it to an iMessage if possible
  • When you want to make a call to someone, if he uses an Apple device, you have the option to call him – voice or video – using FaceTime

Google has Hangouts. You get it pre-installed in Android devices. Many never use it, but it is there.

Google tried making Hangouts sticky in the past, so they allowed it to receive and send SMS – similar in some ways to how Apple does iMessage, but different as the experience isn’t as seamless.

On a mobile phone, think of Hangouts as a step in the way. Google’s Project Fi, their new MVNO initiative, probably uses Hangouts internally – it does connect with Hangouts as their website explains:

Connect any device that supports Google Hangouts (Android, iOS, Windows, Mac, or Chromebook) to your number. Then, talk and text with anyone—it doesn’t matter what device they’re using.

Google is bulking up its communication chops nicely these past few years, and Fi is the next step. I am certain that part of the tech and learnings that Google gains from Fi will find its way back to their general Hangouts service.


Facebook had its share of romance with mobile. From rumors of Facebook smartphones, to a failed Facebook Home app.

For Facebook mobile is critical. Many of its customers use it exclusively on mobile. How do you increase your share in a digital life pie if you are Facebook? You try to control the smartphone experience.

Building a smartphone is hard (ask Amazon), so Facebook tried controlling the home screen by developing a Facebook centric Android launcher. This didn’t work, but wasn’t a failure at the scale of a smartphone launch.

Next up, is their relatively new Hello app. It looks rather innocuous – you receive calls through their Hello app to get a “social ID” – Facebook will match the phone number to a person’s Facebook account to show to you on incoming calls.

The end result?

  • Facebook Hello is used as your smartphone’s calling app
  • They didn’t miss the opportunity of adding their own dialer in – which enables you to call via Messenger
Whatsapp (still Facebook)

Whatsapp is a part of Facebook, but it took a very different approach. It simply added voice calling to its app.

If you are interested in understanding the size of Whatsapp, then there’s a good bulleted list on Mobile Industry Review.

Think of this move in the following context:

  • As of April 2015, WhatsApp has more than 800 million active users
  • Average amount of time spent by users on WhatsApp is 195 minutes a week
  • Teenagers use Whatsapp all the time. At least here in Israel. They don’t talk – they text. Faced with the need to escalate a text chat to a voice call – will they switch app and context or just press the phone icon on the Whatsapp page?

What is your dialer now? The traditional phone dialer with its contacts app or Whatsapp?

Why is it important?

Communication is being redefined. Switching from voice and video towards data access and messaging.

This brings with it a bigger change of what is considered prime real estate on one smartphone’s display, and there are non-telco vendors who are positioned nicely to displace the carriers from the dialer as well. Where would that leave the carrier’s efforts with VoLTE?


Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post How OTTs are Challenging VoLTE’s Prime Asset on Smartphones appeared first on

Changes in the W3C WebRTC Working Group - Fri, 06/19/2015 - 20:40

With the forthcoming re-charter @W3C WebRTC Working Group, there were also a few managerial changes:

  • Peter Saint Andre (@andyet fame), will be joining as co-editor
  • Erik Lagerway, yours truly (co-founder @hookflash), will be joining as co-chair
  • Vivien Lacourba, W3C staff, will be helping out Dominique Hazael-Massieux with increased W3C staff time in the WebRTC Working Group

I am personally flattered and over the moon excited to have been asked to co-chair the WebRTC Working Group and look forward to working with Harald and Stefan to help usher in the next era of WebRTC standards work.


Why You Should Start Using WebRTC TODAY and Abandon Perfection?

bloggeek - Thu, 06/18/2015 - 12:00

To paraphrase Seth Godin, WebRTC is about breaking things.

Seth Godin (who you should definitely read) had an interesting post this week, titled Abandoning perfection. It is short so go over and read it. I’ll just put one of the paragraphs of this post here, to serve as my context:

Perfect is the ideal defense mechanism, the work of Pressfield’s Resistance, the lizard brain giving you an out. Perfect lets you stall, ask more questions, do more reviews, dumb it down, safe it up and generally avoid doing anything that might fail (or anything important).

Now that we have it here, why don’t we check on the excuses people (and companies) give for not using WebRTC?

  • “Microsoft and Apple don’t support it”
    • Do you have any better idea on how to do video calling in browsers? Because I don’t
    • And there are WebRTC plugins for those who want them in Safari and IE
    • There are also those who can live with Chrome and Firefox use cases only
  • “You can’t do multiparty calls with it”
    • This is true for any client side VoIP solution. They require a server
    • And since WebRTC is a technology, it is up to you to come up with the solution and implement server side multiparty
    • Join my webinar next week with TokBox on this subject while you’re at it…
  • “There’s no quality of service”
    • No VoIP service has quality of service
    • WebRTC changes nothing in this regard
    • And people are still happy to use Skype (!) for their business meetings
  • “Without signaling, it can’t interoperate with anything else”
    • True. WebRTC comes without signaling
    • Which means you can add your own – SIP, XMPP or anything you fancy. To fit your exact need and use case
    • In many cases, interoperability is overrated anyway, and building your own service silo is good enough
  • “Mobile First, iOS First. Apple not there, so no way I can use WebRTC”
    • You’ll be surprised how many commercial iOS production apps there are that use WebRTC
    • That’s why I even published a report on WebRTC adoption in mobile apps

Got a lizard brain? Make sure you use the excuses above in the next weekly meeting with your boss. Want to break things and be useful? Check out what WebRTC can do for you.

Oh, and when someone tells you that WebRTC isn’t ready for prime time yet, but will be in 2-3 years – and a lot sooner than you expect – tell him it is ready. Today.

I’ve seen companies using WebRTC daily – in ways that advances their business – adding more flexibility – enabling them to make better decisions – lowers their costs – or allow them to exist in the first place.

Got a good use case that requires real time communications? First check if WebRTC fits your needs – REALLY check. 80% or more of the time – it will.


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

Trying to understand how to get your service to mobile with WebRTC? Read my WebRTC Mobile Adoption report, written specifically to assist you with this task.

Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

Looking for a WebRTC related job? Need the best WebRTC developer out there? You should definitely try out the WebRTC Job Board - satisfaction guaranteed!

The post Why You Should Start Using WebRTC TODAY and Abandon Perfection? appeared first on

The new Android M App Permissions – Dag-Inge Aas

webrtchacks - Wed, 06/17/2015 - 15:30

Android got a lot of WebRTC’s mobile development attention in the early days.  As a result a lot of the blogosphere’s attention has turned to the harder iOS problem and Android is often overlooked for those that want to get started with WebRTC. Dag-Inge Aas of has not forgotten about the Android WebRTC developer. He recently published an awesome walkthrough post explaining how to get started with WebRTC on Android. (Dag’s colleague Thomas Bruun also put out an equally awesome getting started walkthrough for iOS.) Earlier this month Google also announced some updates on how WebRTC permissions interaction will work on the new Android.  Dag-Inge provides another great walkthrough below, this time covering the new permission model.

{“editor”: “chad“}


At this year’s Google I/O, Google released the Android M Developer Preview with lots of new features. One of them is called App Permissions, and will have an impact on how you design your WebRTC powered applications. In this article, we will go through how you can design your applications to work with this new permissions model.

To give you the gist of App Permissions, they allow the user to explicitly grant access to certain high-profile permissions. These include permissions such as Calendar, Sensors, SMS, Camera and Microphone. The permissions are granted at runtime, for example, when the user has pressed the video call-button in your application. A user can also at any time, without the app being notified, revoke permissions through the app settings, as seen on the right. If the app requests access to the camera again after being revoked, the user is prompted to once again grant permission.

This model is very similar to how iOS has worked their permission model for years. User’s can feel safe that their camera and microphone are only used if they have given explicit consent at a time that is relevant for them and the action they are trying to perform.

However, this does mean that WebRTC apps built for Android now have to face the same challenges that developers on iOS have to face. What if the user does not grant access?

To get started, let’s make sure our application is built for the new Android M release. To do this, you have to edit your application’s build.gradle file with the following values:

targetSdkVersion "MNC" compileSdkVersion "android-MNC" minSdkVersion "MNC" // For testing on Android M Preview only.

Note that these values are prone to change once the finalized version of Android M is out.

In addition, I had to update my Android Studio to the Canary version (1.3 Preview 2) and add the following properties to my build.gradle to get my sources to compile successfully:

compileOptions { sourceCompatibility JavaVersion.VERSION_1_7 targetCompatibility JavaVersion.VERSION_1_7 }

However, your mileage may vary. With all that said and done, and the M version SDK installed, you can compile your app to your Android device running Android M.

Checking and asking for permissions

If you start your application and enable its audio and video capabilities, you will notice that the camera stream is black, and that no audio is being recorded. This is because you haven’t asked for permission to use those APIs from your user yet. To do this, you have to call requestPermissions(permissions, yourRequestCode)  in your activity, where permissions is a String[] of android permission identifiers, and yourRequestCode is a unique integer to identify this specific request for permissions.

String[] permissions = {   "android.permission.CAMERA",   "android.permission.RECORD_AUDIO" }; int yourRequestId = 1; requestPermissions(permissions, yourRequestCode);

Calling requestPermissions will spawn two dialogs to the user, as shown below.

When the user has denied or allowed access to the APIs you request, the Activity’s onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) method is called. Here we can recognize the requestCode we sent when asking for permissions, the String[] of permissions we asked for access to, and an int[]  of results from the grant permission dialog. We now need to inspect what permissions the user granted us, and act accordingly. To act on this data, your Activity needs to override this method.

@Override public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) { switch (requestCode) { case YOUR_REQUEST_CODE: { if (grantResults[0] == PackageManager.PERMISSION_GRANTED){ // permission was granted, woho! } else { // permission denied, boo! Disable the // functionality that depends on this permission. } return; } } }

Handling denied permissions will be up to your app how you want to handle, but best practices dictate that you should disable any functions that rely on these permissions being granted. For example, if the user denies access to the camera, but enables the microphone, the toggle video button should be disabled, or alternatively trigger the request again, should the user wish to add their camera stream at a later point in the conversation. Disabling access to video also means that you can avoid doing the VideoCapturer  dance to get the camera stream, it will be black anyway.

One thing to note is that you don’t always need to ask for permission. If the user has already granted access to the camera and microphone previously, you can skip this step entirely. To determine if you need to ask for permission, you can use checkSelfPermission(PERMISSION_STRING)  in your Activity. This will return PackageManager.PERMISSION_GRANTED  if the permission has been granted, and PackageManager.PERMISSION_DENIED  if the request was denied. If the request was denied, you may ask for permission using requestPermissions.

if (checkSelfPermission(Manifest.permission.CAMERA) == PackageManager.PERMISSION_DENIED) { requestPermissions(new String[]{Manifest.permission.CAMERA}, YOUR_REQUEST_CODE); }

When to ask for permission

The biggest question with this approach is when to ask for permission. When are the user’s more likely to understand what they are agreeing to, and therefore more likely to accept your request for permissions?

To me, best practices really depend on what your application does. If your applications primary purpose is to enable video communication, for example a video chat application, then you should at initial app startup prime the user for setting up their permissions. However, you must at the same time make sure that permissions are still valid, and if necessary, reprompt the user in whatever context is natural for permissions should you need it. For example, a video chat application based on rooms may prompt the user to enable video and audio before entering a video room. If the user has already granted access, the application should proceed to the next step. If not, the application should explain in clear terms why it needs audio and video access, and ask the user to press a button to get prompted. This makes the user much more likely to trust the application, and grant access.

If your application’s secondary purpose is video communication, for example in a text messaging app with video capabilities, best practices dictate that the user should get prompted when clicking the video icon for starting a video conversation. This has a clear benefit, as the user knows their original intention, and will therefore be likely to grant access to their camera and microphone.

And remember, camera and microphone access can be revoked at any time without the app’s knowledge, so you have to run the permission check every time.

The new Android M permissions UI

But do I have to do it all now?

Yes and no. Android M is still a ways off, so there is no immediate rush. In addition, the new permission style only affects applications built for, or targeting, Android M or greater API levels. This means that your application with the old permission model will still work and be available to devices running Android M. The user will instead be asked to grant access at install time. Note that the user may still explicitly disable access through the app settings, at which point your application will show black video or no sound. So unless you wish to use any of the new features made available in Android M, you can safely hold off for a little while longer.

{“author”: “Dag-Inge Aas“}

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart@reidstidolph, @victorpascual and @tsahil.

The post The new Android M App Permissions – Dag-Inge Aas appeared first on webrtcHacks.

Comverse Acquires Acision, Framing Digital an APIs Around WebRTC

bloggeek - Tue, 06/16/2015 - 12:00

Is Comverse becoming a serious WebRTC player?

Comverse is a company in transition. It has been catering the world’s telcos for many years. In recent years, it had its share of issues. Why are they important in the context of this blog?

  1. They acquired Solaiemes. But that was in August 2014. Almost a year ago
  2. Less than 2 months ago, Comverse sold its BSS business to Amdocs
  3. Yesterday, it acquired Acision, for around $210M
What does this say about Comverse?

Comverse is a company searching for their way. Their current focus is digital services with the set of customers being Telcos.

Digital focus means APIs and platforms that enable rapid creation of services.

The interesting part here is that Comverse is getting a sales team and an operation that knows how to sell to enterprises and not only to Telcos. I do hope they will be smart enough to keep that part of the business alive and leverage it.

Open questions include: Will Comverse merge Acision assets with Solaiemes? Try to build one on top of the other?

What does this say about Acision?

Acision got acquired for their SMS and voice business more than for their WebRTC or API platform components. No one gets acquired for that much money for WebRTC. Yet.

It is funny to note that Acision Forge platform, which runs their WebRTC PaaS part, was an acquisition of Crocodile RCS.

Comverse being focused on Telcos, how will they view the Forge platform?

  • As something to be sold to carriers or through carriers? This means taking the route that Tropo took in recent years
  • Would they try to leverage it and expand their offering to enterprises in other areas?
  • Will Comverse management understand the enterprise business enough to try and let it grow unhindered?
Why is this important?

This isn’t the first or last WebRTC related acquisition of the year. We had a few already.

If you are looking to use any vendor for your WebRTC technology, you need to consider the possibility of acquisition seriously.

It also led me to updating my WebRTC dataset subscription service: as of today, its subscribers also receive an updated acquisitions table, detailing all acquisitions related to WebRTC since 2012.


Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

The post Comverse Acquires Acision, Framing Digital an APIs Around WebRTC appeared first on

3CX Phone System v14: Preview tecnica

Libera il VoIP - Tue, 06/16/2015 - 09:08

La nuova major release di 3CX Phone System è pronta! Il nostro team Ricerca&Sviluppo c’è riuscito un’altra volta e ci ha fornito una versione straordinaria: pronta per il Cloud e corredata di una serie di miglioramenti e funzionalità innovative.

Di particolare interesse per i partners e i Service Providers sono le nuove funzionalità di centralino virtuale contenute in 3CX Phone System v14. Il vecchio 3CX Cloud Server fa ormai parte del passato e questa funzionalità è ora integrata nel setup principale, consentedovi di scegliere se installare una v14 come sistema on-premise o come centralino virtuale in grado di gestire fino a 25 istanze per ogni macchina. L’installazione e la gestione delle istanze virtuali possono da ora essere effettuate attraverso il nostro sistema ERP o via API. Entra in competizione con altri fornitori di centralini virtuali con una piattaforma migliore e più ricca di funzioni, pur mantenendo il controllo dei dati del cliente e potendo scegliere il VoIP Provider più adatto!

Breve elenco delle nuove funzionalità:

  • Opzione di virtualizzazione centralino integrata nel setup
  • Client Android completamente ridisegnato
  • Nuovo client iPhone con tunnel integrato (in attesa di rilascio sull’appstore)
  • Tutti i client: risposta più rapida a seguito di miglioramenti nell’architettura del push
  • Tutti i client: consumo ridotto della batteria
  • Funzionalità di failover integrata
  • Backup & Restore programmabili
  • Nuovi criteri di gestione delle Voice mail
  • Voice mail e registrazioni in formato compresso
  • Nuovo sistema di reportistica con rapporti inviati via email
  • Supporto per contatti Office 365
  • Aggiunta di numerosi nuovi SIP Trunk providers

Download Links e Documentazione
Scarica la 3CX Phone System v14 Technical Preview:
Scarica 3CXPhone per Android
Scarica 3CXPhone per Windows
Scarica 3CXPhone per Mac – Si prega di notare che il nuovo client per Mac sarà rilasciato nella prossima build
Scarica 3CXPhone per iOS
Scarica 3CX Session Border Controller per Windows
Manuale Amministratore:  Capitolo 8 : ‘Deploying 3CX Phone System as a Virtual PBX Server’


FreeSWITCH Week in Review (Master Branch) June 6th-12th

FreeSWITCH - Tue, 06/16/2015 - 03:39

Hello, again. This passed week in the FreeSWITCH master branch we had 51 commits! Some of the new commits this week include: the addition of a new reserve-agents param to mod_callcenter, allowing for custom exchange name and type for mod_amqp producers, a sample build system for a stand alone(out of tree) FreeSWITCH module, and added video support to eavesdrop.

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

New features that were added:

  • FS-7620 [ftmod_libpri] Correctly set calling number presentation and screening fields
  • FS-7138 [mod_callcenter] Added a new reserve-agents param
  • FS-7436  FS-7601 [mod_opus] FEC support
  • FS-7623 [mod_amqp] Allow for custom exchange name and type for producers and fixed param name ordering bug caused by exposing these params
  • FS-7638 Allow ipv4 mapped ipv6 address to pass ipv4 ACLs properly
  • FS-7643 [mod_opus] Added interpretation of maxplaybackrate and sprop-maxcapturerate
  • FS-7641 Added video support to eavesdrop

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

  • FS-7635 Removed msvc 2005, 2008, and 2010 non working build systems
  • FS-7373 Expose the custom repo and key path to the build-all command too
  • FS-7648 Foundation for QA testing config , adding leave/check videomail test cases, adding videomail voicemail profile, adding video record/ playback test cases, adding set video on hold, force pre-answer prefix, and adding an eavesdrop test case.
  • FS-7338 Removed mod_shout dep libs to system libs to continue cleaning up the libs for the 1.6 build process and added Debian packaging for several new modules, as well as handle system lib change for a handful of modules
  • FS-7653 Sample build system for a stand alone(out of tree) FreeSWITCH module
  • FS-7601 [mod_opus] [mod_silk]  Removed a bounds check that can never be true in opus fec code and modify jitterbuffer usage to match the api change

The following bugs were squashed:

  • FS-7612 Fixed invalid json format for callflow key
  • FS-7609 [mod_sangoma_codec] Now that libsngtc-dev and libsngtc are in the FS debian repo, enable mod_sangoma_codec
  • FS-7621 [mod_shout] Fixed a slow interrupt
  • FS-7432 Fixed missing a=setup parameter from answering SDP
  • FS-7622 [mod_amqp] Make sure to close the connections on destroy. Currently the connection is malloc’d from the module pool, so there is nothing to destroy.
  • FS-7586 [mod_vlc] A fix for failing to encode audio during the recording of video calls
  • FS-7573 Fixed 80bit tag support for zrtp
  • FS-7636 Fixed an issue with transfer_after_bridge and park_after_bridge pre-empting transfers
  • FS-7654 Fixed an issue with eavesdrop audio not working correctly with a mixture of mono and stereo

ORTC Lib – mini update #webrtc - Mon, 06/15/2015 - 23:48

It’s been about a year since we uploaded the ORTC Lib presentation on slideshare …

We have been rather busy since then…

Good things are coming! :)

Join Us For Our Next Kazoo Training - July 20-22

2600hz - Mon, 06/15/2015 - 23:05

Join us for three days of Kazoo training – July 20-22. We will deep dive into Kazoo APIs and learn how to set up a cluster, GUI, WhApps, FreeSWITCH, BigCouch and more. Learn how to install, configure, maintain and program Kazoo so that you can build your business. Go in to the bootcamp as a novice – and come out as a Kazoo ninja. Register Now! 

LinkedIn – Where are Thou with WebRTC?

bloggeek - Mon, 06/15/2015 - 12:00

I’d expect LinkedIn to add WebRTC already.

Last week, I received an email from LinkedIn. Apparently, they acquired a learning company called Lynda. It did beg the question, with so many WebRTC acquisitions – where is LinkedIn in all this?

The company deals with professionals, revolving around a digital CV. They enable people to connect in order to conduct business. So why do they want me to revert to things like phone calls or Skype in 2015?

They an internal messaging/email system. Not the best one. Probably requires an overhaul to be an effective tool. So where’s the rest of my interactions with people? Where’s the “click here to call” or “schedule a meeting”?

LiveNinja tried being an experts marketplace. An aggregator of people with skillz. You searching for a guitar teacher? A developer for advice? A yoga lesson? Search them on LiveNinja, interact, schedule a meeting. Hell, it even allows you to pay online (taking part of that revenue and giving the rest to the expert). It is now morphing into Katana, leaving its aggregator vision towards embeddable experiences.

Google Helpouts tried and closed shop. Something to do with it trying to be everything for everyone.

But you know what? LinkedIn can be that marketplace for many. Easily. It already is. It just needs to have that integration with real time communication. Be it for communicating between professionals or for conducting job interviews as part of its jobs board.

So where is it exactly? Am I the only one missing a blue “Call me” button in LinkedIn? Should I make do with their posts platform?

There are over 20 different expert marketplaces using WebRTC at the moment. None of them has the reach of LinkedIn. Would be nice if LinkedIn acquired one of them and be done with it.


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

The post LinkedIn – Where are Thou with WebRTC? appeared first on

2600Hz Announces early-bird pricing at KazooCon, the Communications Revolution

2600hz - Sat, 06/13/2015 - 00:35

We are proud to announce that we will be hosting KazooCon October 5th – 6th in San Francisco. This year’s event will bring together developers, managed service providers, carriers and telecom evangelists. Attendees will learn about the latest Kazoo news and announcements, take part in technical sessions and network with other Kazoo users throughout our two-day conference. Announcements will include 2600Hz’s new reseller platform, WebRTC, Cluster Manager and Infrastructure as a Service (IaaS). Oops, we’ve already said too much. Early-Bird tickets are for sale Now! 

KazooCon enables all members of the telecom community to engage in hands-on experiences around distributed communication networks. 2600hz has also announced a Call for Speakers, where interested candidates can apply to speak.

2600hz will also be hosting a Kazoo training following KazooCon, October 7-9. This three-day training will teach software engineers about Kazoo and the third-party components that power the platform. Attendees will deep dive into Kazoo APIs and learn how to set up a cluster, GUI, WhApps, FreeSWITCH, BigCouch and more. Register Here. If you cannot make it in October, we also have an earlier training, July 20-22. Register Here.

Those interested in sponsoring KazooCon will need to contact marketing(at)2600hz(dot)com.

To see some of KazooCon 2014, watch last year’s presentations or look at the photos.

WebRTC and Man in the Middle Attacks

webrtchacks - Fri, 06/12/2015 - 21:33

WebRTC is supposed to be secure. A lot more than previous VoIP standards. It isn’t because it uses any special new mechanism, but rather because it takes it seriously and mandates it for all sessions.

Alan Johnston decided to take WebRTC for a MitM spin – checking how easy is it to devise a man-in-the-middle attack on a naive implementation. This should be a reminder to all of us that while WebRTC may take care of security, we should secure our signaling path and the application as well.

{“editor”: “tsahi“}

Earlier this year, I was invited to teach a graduate class on WebRTC at IIT, the Illinois Institute of Technology in Chicago.  Many of you are probably familiar with IIT because of the excellent Real-Time Communications (RTC) Conference ( that has been hosted at IIT for the past ten years.

I’ve taught a class on SIP and RTC at Washington University in St. Louis for many years, but I was very excited to teach a class on WebRTC.  One of the key challenges in teaching is to come up with ways to make the important concepts come alive for your students.  Trying to make security more interesting for my students led me to write my first novel, Counting from Zero, a technothriller that introduces concepts in computer and Internet security (  For this new WebRTC class, I decided that when I lectured about security, I would – without any warning – launch a man-in-the-middle (MitM) attack ( on my students.

It turned out the be surprisingly easy to do, for two reasons.

  1. It is so quick and easy to prototype and test new ideas with WebRTC. JavaScript is such a fun language to program in, and node.js makes it really easy on the server side.
  1. Unfortunately, WebRTC media sessions have virtually no protection against MitM attacks. Not many people seem to be aware of the fact that although WebRTC uses DTLS to generate keys for the SRTP media session, the normal protections of TLS are not available.

So, a few weeks later, I had a WebRTC MitM attack ready to launch on my students that neither Chrome or Firefox could detect.

How did it work?  Very simple.  First, I compromised the signaling server.  I taught the class using the simple demo application from the WebRTC book ( that I wrote with Dan Burnett.  (You can try the app with a friend at  The demo app uses a simple HTTP polling signaling server that matches up two users that enter the same key and allows them to exchange SDP offers and answers.

I compromised the signaling server so that when I entered a key using my MitM JavaScript application, instead of the signaling server connecting the users who entered that key, those users would instead be connected to me.  When one of the users called the other, establishing a new WebRTC Peer Connection, I would actually receive the SDP offer, and I would answer it, and then create a new Peer Connection to the other user, sending them my SDP offer.  The net result was two Peer Connections instead of one, and both terminated on my MitM JavaScript application.  My application performs the SDP offer/answer negotiation and the DTLS Handshake with each of the users.  Each of the Peer Connections was considered fully authenticated by both browsers.  Unfortunately, the Peer Connections were fully authenticated to the MitM attacker, i.e. me.

Here’s how things look with no MitM attacker:


Here’s how things look with a MitM attacker who acts as a man-in-the-middle to both the signaling channel and DTLS:

How hard was it to write this code?  Really easy.  I just had to duplicate much of the code so that instead of one signaling channel, my MitM JavaScript had two.  Instead of one Peer Connection, there were two.  All I had to do was take the MediaStream I received incoming over one Peer Connection and attach it to the other Peer Connection as outgoing, and I was done.  Well, almost.  It turns out that Firefox doesn’t currently support this yet (but I’m sure it will one of these days) and Chrome has a bug in their audio stack so that the audio does not make it from one Peer Connection to another (see bug report  I tried every workaround I could think of, including cloning, but no success.  If anyone has a clever workaround for this bug, I’d love to hear about it.  But the video does work, and in the classroom, my students didn’t even notice that the MitM call had no audio.  They were too busy being astonished that after setting up their “secure WebRTC call” (we even used HTTPS which gave the green padlock – of course, this had no effect on the attack but showed even more clearly how clueless DTLS and the browsers were), I showed them my browser screen which had both of their video streams.

When I tweeted about this last month, I received lots of questions, some asking if I had disclosed this new vulnerability.  I answered that I had not, because it was not an exploit and was not anything new.  Everyone involved in designing WebRTC security was well aware of this situation.  This is WebRTC working as designed – believe it or not.

So how hard is it to compromise a signaling server?  Well, it was trivial for me since I did it to my own signaling server.  But remember that WebRTC does not mandate HTTPS (why is that, I wonder?).  So if HTTP or ordinary WebSocket is used, any attacker can MitM the signaling if they can get in the middle with a proxy.  If HTTPS or secure WebSocket is used, then the signaling server is the where the signaling would need to be compromised.  I can tell you from many years of working with VoIP and video signaling that signaling servers make very tempting targets for attackers.

So how did we get here?  Doesn’t TLS and DTLS have protection against MitM attacks?

Well, TLS as used in web browsing uses a certificate from the web server issued by a CA that can be verified and authenticated.  On the other hand, WebRTC uses self-signed certificates that can’t be verified or authenticated.  See below for examples of self-signed certificates used by DTLS in WebRTC from Chrome and Firefox.  I extracted these using Wireshark and displayed them on my Mac.  As you can see, there is nothing to verify.  As such, the DTLS-SRTP key agreement is vulnerable to an active MitM attack.

The original design of DTLS-SRTP relied on exchanging fingerprints (essentially a SHA-256 hash of the certificate, e.g. a=fingerprint:sha-256 C7:4A:8A:12:F8:68:9B:A8:2A:95:C9:5E:7A:2A:CE:64:3D:0A:95:8E:E9:93:AA:81:00:97:CE:33:C3:91:50:DB) in the SIP SDP offer/answer exchange, and then verifying that the certificates used in the DTLS Handshake matched the certificates in the SDP.  Of course, this assumes no MitM is present in the SIP signaling path.   The protection against a MitM in signaling recommended by DTLS-SRTP is to use RFC 4474 SIP Enhanced Identity for integrity protection of the SDP in the offer/answer exchange.  Unfortunately, there were major problems with RFC 4474 when it came to deployment, and the STIR Working Group in the IETF ( is currently trying to fix these problems.  For now, there is no SIP Enhanced Identity and no protection against a MitM when DTLS-SRTP is used with SIP.   Of course, WebRTC doesn’t mandate SIP or any signaling protocol, so even this approach is not available.

For WebRTC, a new identity mechanism, known as Identity Provider, is currently proposed (  I will hold off on an analysis of this protocol for now, as it is still under development in an Internet-Draft, and is also not available yet.  Firefox Nightly has some implementation, but I’m not aware of any Identity Service Providers, either real or test, that can be used to try it out yet.  I do have serious concerns about this approach, but that is a topic for another day.

So are we out of luck with MitM protection for WebRTC for now?  Fortunately, we aren’t.

There is a security protocol for real-time communications which was designed with protection against MitM – it is ZRTP ( invented by Phil Zimmermann, the inventor of PGP.   ZRTP was designed to not rely on and not trust the signaling channel, and uses a variety of techniques to protect against MitM attacks.

Two years ago, I described how ZRTP, implemented in JavaScript and run over a WebRTC data channel, could be used to provide WebRTC the MitM protection it currently lacks (  During TADHack 2015(, if my team sacrifices enough sleep and drinks enough coffee, we hope to have running code to show how ZRTP can detect exactly this MitM attack.

But that also is a subject for another post…

{“author”: “Alan Johnston“}

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart@reidstidolph, @victorpascual and @tsahil.

The post WebRTC and Man in the Middle Attacks appeared first on webrtcHacks.

Join me for a Free TokBox Webinar to Learn More About WebRTC Multiparty

bloggeek - Fri, 06/12/2015 - 15:52

See you on June 24!

Just a quick note before we head into the weekend.

I’ve partnered with TokBox for a webinar on the various use cases where multiparty video calling is desired.

The webinar will address an area I love, which is the various topologies and architectures to choose from when dealing with multiparty video. Badri Rajasekar, CTO of TokBox, will be there with me and we’re planning to have an interesting conversation.

If this topic is close to your heart, or just something you wish to learn more about – register online – it’s free.

See you online on 24 June at 10:00am PDT. And if you can’t make it – just register to watch it offline.

The post Join me for a Free TokBox Webinar to Learn More About WebRTC Multiparty appeared first on

Book Review: WebRTC Cookbook

bloggeek - Thu, 06/11/2015 - 12:00

If you are looking for some quick WebRTC recipes, then this is the book for you.

Consider this another post in a series of posts about WebRTC related books. To see previous  reviews, check out the search tag book review.

The WebRTC Cookbook is the second book by Andrii Sergiienko. His first book was WebRTC Blueprints, was a hard core book – the first one with guts to take WebRTC books to the extreme topics at that time.

WebRTC Cookbook takes a more orderly approach, where Andrii picks several topics and explains them briefly, in a step by step manual. He also provides good follow up material for those who wish to learn more.

Things you will find in this book:

  • Peer connection related topic, with the interesting bits in the STUN and TURN configuration
  • Security issues – HTTPS, TURN server security, firewalls, etc.
  • VoIP – integrating with Asterisk and FreeSWITCH
  • Debugging – stats, webrtc-internals, Wireshark, …
  • Video filters (unfortunately no audio ones)
  • Native apps – iOS, Android and
  • Integrating with some of the WebRTC frameworks and services out there
  • “advanced” stuff – things you’d want to do to add polish to your service

This is a good book for your WebRTC library. It acts as a nice reference to go to when you need to quickly skim a topic.


Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post Book Review: WebRTC Cookbook appeared first on

Kamailio v4.3.0 Released

miconda - Wed, 06/10/2015 - 23:00
June 10, 2015Kamailio v4.3.0 is out –  a new major release, collecting new features and improvements added during about six months of development and one and a half month of testing.In short, this major release brings 9 new modules and enhancements to more than 50 existing modules, plus components of the core and internal libraries. Detailed release notes are available at:Development for next major release, 4.4.0 (expected to be out in the first part of 2016) has started already, even a new module is already present in master branch: smsops. Watch the project’s web site closely for further updates and news about evolution of Kamailio.Enjoy SIP routing in a secure, flexible and easier way with Kamailio v4.3.0!Thank you for flying Kamailio!

Facetime doesn’t face WebRTC

webrtchacks - Tue, 06/09/2015 - 16:03

This is the next decode and analysis in Philipp Hancke’s Blackbox Exploration series conducted by &yet in collaboration with Google. Please see our previous posts covering WhatsApp and Facebook Messenger for more details on these services and this series. {“editor”: “chad“}


FaceTime is Apple’s answer to video chat, coming preinstalled on all modern iPhones and iPads. It allows audio and video calls over WiFi and, since 2011, 3G too. Since Apple does not talk much about WebRTC (or anything else), maybe we can find out if they are using WebRTC behind the scenes?

As part of the series of deconstructions, the full analysis (another sixteen pages) is available for download here, including the Wireshark dumps.
If you prefer watching videos, check out the recording of this talk I did at Twilio’s Signal conference where I touch on this analysis and the others in this series.

In a nutshell, FaceTime

  • is quite impressive in terms of quality,
  • requires an open port (16402) in your firewall as documented here,
  • supports iOS and MacOS devices only,
  • supports simultaneous ring on multiple devices,
  • is separate from the messaging application, unlike WhatsApp and Facebook Messenger,
  • announces itself by sending metrics over an unencrypted HTTP connection (Dear Apple, have you heard about pervasive monitoring?)
  • presumably still uses SDES (no signs of DTLS handshakes, but I have not seen a=crypto lines in the SDP either).

Since privacy is important, it is sad to see a complete lack of encryption in the HTTP metrics call like this one:

Example of an unencrypted keep alive packet that could be intercepted by a 3rd party to track a user


FaceTime has been analyzed earlier- first when it was introduced back in 2010 and more recently in 2013. While the general architecture is still the same, FaceTime has evolved over the years like adding new codecs like H.265 when calling over cellular data.

What else has changed? And how much of the changes can we observe? Is there anything those changes tell us about potential compatibility with WebRTC?

Still using SDES

It is sad that Apple continuing to use SDES almost two years after the IETF at it’s Berlin meeting where it was decided that WebRTC MUST NOT Support SDES. The consensus on this topic during the meeting was unanimous. For more background information, see either Victor’s article on why SDES should not be used or dive into Eric Rescorla’s presentation from that meeting comparing the security properties of both systems.

NAT traversal

Like WebRTC, FaceTime is using the ICE protocol to work around NATs and provide a seamless user experience. However, Apple is still asking users to open a certain number of ports to make things works. Yes, in 2015.

Their interpretation of ICE is slightly different from the standard. In a way similar to WhatsApp, it has a strong preference for using a TURN servers to provide a faster call setup. Most likely, SDES is used for encryption.


For video, both the H.264 and the H.265 codecs are supported, but only H.264 was observed when making a call on a WiFi. The reason for that is probably that, while saving bandwidth, H.265 is more computationally expensive. One of the nice features is that the optimal image size to display on the remote device is negotiated by both clients.


For audio, the AAC-ELD codec from Fraunhofer is used as outlined on the Fraunhofer website.
In nonscientific testing, the codec did show behaviour of playing out static noise during wifi periods of packet loss between two updated iPhone 6 devices.


The signaling is pretty interesting, using XMPP to establish a peer-to-peer connection and then using SIP to negotiate the video call over that peer-to-peer connection (without encrypting the SIP negotiation).

This is a rather complicated and awkward construct that I have seen in the past when people tried to avoid making changes to their existing SIP stack. Does that mean Apple will take a long time to make the library used by FaceTime generally usable for the variety of use cases arising in the context of WebRTC? That is hard to predict, but this seems overly complex.

Quality of Experience

FaceTime offers an impressive quality and user experience. Hardware and software are perfectly attuned to achieve this. As well as the networking stack as you can see in the full story.


{“author”: “Philipp Hancke“}

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart@reidstidolph, @victorpascual and @tsahil.

The post Facetime doesn’t face WebRTC appeared first on webrtcHacks.


Subscribe to OpenTelecom.IT aggregator

Using the greatness of Parallax

Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.

Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.

Get free trial

Wow, this most certainly is a great a theme.

John Smith
Company name

Yet more available pages

Responsive grid

Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.

More »


Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.

More »

Startup Growth Lite is a free theme, contributed to the Drupal Community by More than Themes.