News from Industry

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 BlogGeek.me.

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 appear.in 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.

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 BlogGeek.me.

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: http://downloads.3cx.com/downloads/3CXPhoneSystem14.exe
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’
Demo Key: 3CXP-DEMO-EDIT-VEI4

Approfondimenti

• Mai più chiamate perse con il nuovo 3CXPhone per Mac
  

  Fedele alla sua reputazione di azienda innovatrice, 3CX è uno dei primi produttori di centralini telefonici ad offrire un client per Mac completo di funzionalità professionali. Con il nuovo aggiornamento del popolare [...]

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 freeswitch.com 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

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 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! 

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 BlogGeek.me.

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 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 (http://www.rtc-conference.com/) 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 (https://countingfromzero.net).  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 (https://en.wikipedia.org/wiki/Man-in-the-middle_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.

2. 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 (http://webrtcbook.com) that I wrote with Dan Burnett.  (You can try the app with a friend at http://demo.webrtcbook.com:5001/data.html?turnuri=1.)  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 https://code.google.com/p/webrtc/issues/detail?id=2192#c15).  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 (https://tools.ietf.org/wg/stir/) 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 (https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch).  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 (https://tools.ietf.org/html/rfc6189) 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 (https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp).  During TADHack 2015(http://tadhack.com/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.

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 BlogGeek.me.

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 OpenWebRTC.io
• 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 BlogGeek.me.

June 10, 2015: Kamailio 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:

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

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!

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

Details

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.

Video

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.

Audio

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.

Signaling

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.

Most probably yes.

In the last couple of weeks I’ve been working with people from the AT&T Developer Program on an Infographic. The idea behind it was to show the progress that WebRTC made in the past couple of years, trying to understand if it is time for people to join in. If you have been following me, you know that my answer is “start yesterday” when it comes to WebRTC.

The result is the WebRTC Infographic below:

For more information and some more verbosity around it, check out AT&T’s blog post on this WebRTC Infographic.

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 WebRTC Infographic: Are we at a Tipping Point? appeared first on BlogGeek.me.

Hello, again. This passed week in the FreeSWITCH master branch we had 74 commits! Quite a bit of work went in this week and some of the many new features are: added Perfect Forward Secrecy (DHE PFS) to mod_sofia, added new options to nibble bill for minimum charges and rounding, added ipv6 support to Verto / Websockets and keep sofia-sip ws lib in sync, and added new algorithms for offering calls to clients.

Join us on 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-7337 [mod_sofia] Add support for Remote-Party-ID header in UPDATE request.
• FS-7561 [mod_sofia] Add Perfect Forward Secrecy (DHE PFS)
• FS-7560 [mod_nibblebill] Added new options to nibble bill for minimum charges and rounding
• FS-7587 FS-7602 FS-7499 [mod_verto] Add ipv6 support to Verto / Websockets and additional support ice/dtls ipv6 functionality
• FS-6801 [mod_sofia] Add sip_watched_headers variable to launch events when a SIP message contains a given SIP header
• FS-7564 [mod_rayo] Added new algorithms for offering calls to clients
• FS-7436 FS-7601 [mod_opus] Added FEC support
• FS-7603 [mod_event_socket] Failover for socket application in dialplan
• FS-7585 [mod_rtmp] Increased AMF buffer for larger video and add bandwidth settings to flash video
• FS-7311 [mod_sofia] Updating display name is disabled when caller_id equal “_undef_”
• FS-7513 [mod_conference] Add video-auto-floor-msec param to control how long a member must have the audio floor before also taking the video floor and make sure user does not have auto avatar when not visible

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

• FS-7610 Fixed a gcc5 compilation issue
• FS-7499 Fixed a build error on 32bit platforms
• FS-7570 Fixed a compilation issue w/ zrtp enabled
• FS-7426 Only disable mod_amqp on Debian Squeeze and Wheezy

The following bugs were squashed:

• FS-7579 [mod_conference] Fixed a bug not allowing suppression of play-file-done
• FS-7462 [mod_opus] Fix FMTP in the INVITE to use values from opus.conf.xml
• FS-7593 [mod_skinny] Fixed a bug where skinny phones would stomp on each other in database when thundering herd occurs
• FS-7597 [mod_codec2] Fixed encoded_data_len for MODE 2400, it should be 6 bytes. Also replaced 2550 bps bitrate (obsoleted operation mode) by 2400
• FS-7604 [fs_cli] Fixed fs_cli tab completion concurrency issues on newer libedit
• FS-7258 FS-7571 [mod_xml_cdr] Properly encode xml cdr for post to web server
• FS-7584 More work on rtcp-mux interop issue with chrome canary causing video transport failure
• FS-7586 [mod_conference] Change the default min-required-recording-participants option for mod_conference from 2 to 1 and silence the warning when the value is set to 1 in the configs
• FS-7607 Update URLs to reflect https protocol on freeswitch.org websites and update additional URLs to avoid 301 redirects.
• FS-7479 Fixed a crash caused by large RTP/PCMA packets and resampling
• FS-7524 [mod_callcenter] Fixing tiers, level and position should default to 1 instead of 0
• FS-7613 Fixed a crash in core text rendering

With more than 40 members and growing, Vancouver WebRTC now has a new venue! Chris Simpson from PoF rallied to get us into their new presentation lounge, the “Aquarium”, thanks Chris!

 

Our next event is on June 25th from 6-8pm and we have a great evening planned with Omnistream and Perch presenting!

Come check it out!

It’s a quite common task that you need to translate an IP address into a prefix — for example, when creating an IP prefix list from a set of addresses. Here’s a simple Perl script that helps it:

sudo apt-get install libnetaddr-ip-perl cat >getprefix.pl <<'EOT' use strict; use warnings; use NetAddr::IP; if( scalar(@ARGV) == 0 ) {     die("Usage: $0 PREFIX ..."); } foreach my $pref (@ARGV) {     my $ip = NetAddr::IP->new($pref) or         die("Cannot create NetAddr::IP from $pref");     print $ip->network()->cidr(), "\n"; } EOT # testing cat >/tmp/x <<'EOT' 10.1.1.1/23 192.168.5.3/28 EOT cat /tmp/x | xargs perl getprefix.pl | awk '{print "set ", $1}' set  10.1.0.0/23 set  192.168.5.0/28
Filed under: Networking Tagged: network management, networking, perl

Another week, another WebRTC related acquisition took place.

Since the Tropo acquisition just a month ago, we had two more acquisitions:

1. Fuze acquired LiveMinutes – that at the same time it raised $20M more. Fuze itself made use of WebRTC as an access point to its video conferencing service, and LiveMinutes focused on collaboration and used WebRTC for video chat
2. Broadsoft acquired mPortal – an outsourcing vendor focusing on mobile communication apps, catering large enterprises and telcos

When Atlassian acquired Jitsi I was a bit worried. We were nearing the end of April with only 3 acquisitions in 2015. With 8 acquisitions in 2014, this looked like another “boring” year. Well… we’re now into the 7th acquisition of 2015 when it comes to WebRTC and we’re almost 6 months in.

The chart below shows the WebRTC related acquisitions we’ve had since WebRTC’s inception. We are growing steadily.

Most of the acquisitions this year are similar to the ones last year – they are about acquiring the market, the business models and the technology.  Only two of them have been technology/acquihires (ScreenHero and Jitsi).

How will the second half if this year shape out to be? Which kind of vendors are we going to see acquired next?

This is shaping up to be a pretty interesting year for WebRTC.

Customers of my WebRTC Dataset Subscription Plan will have access to detailed acquisition information from later this month.

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

 

The post WebRTC Related Acquisitions in Acceleration Mode appeared first on BlogGeek.me.

Ormai lo smartphone è entrato prepotentemente nella quotidianità di oltre 1,31 miliardi di persone in tutto il mondo, ma non solo, in una recente ricerca, eMarketer prevede una crescita del numero di utenti di fino a 2 miliardi entro il 2016, che corrisponde a circa il 25% della popolazione mondiale, per poi giungere fino a 2,58 miliardi di utenti entro il 2018.

Qual è la causa della „dipendenza“?

Il motivo per cui gli smartphone godono di tanta popolarità è ovvio. La dimensione e la connettività rendono dati e informazioni accessibili come mai prima. La possibilità di utilizzare il nostro smartphone ogni giorno come e per cosa vogliamo era impensabile fino a qualche anno fa. Inoltre, al giorno d‘oggi i costi di utilizzo non rappresentano più un ostacolo. Questi fattori spiegano la cosiddetta “dipendenza“ da smartphone e uno studio del Business Insider ha rilevato che il cittadino americano medio si perde almeno ogni due ore tra i meandri del proprio “aggeggio delle meraviglie”.

Smartphone multitalento

Lo smartphone serve anche da soluzione per le attuali piattaforme di comunicazione. Accanto alla telefonia l’utente accede a email, SMS e Internet. La rubrica è collegata alle reti dei Social Network e i dati dei contatti possono essere sincronizzati “on the go” tramite applicazioni come LinkedIn.

Unified Communication in formato tascabile

Gli operatori telefonici sono a conoscenza delle abitudini del loro target group e offrono soluzioni per le  Unified Communications (UC) che permettono alle aziende di svolgere le loro attività professionali anche attraverso lo smartphone, unendo interessi aziendali e privati. Un sistema UC ben ponderato assicura alle aziende numerosi vantaggi: la riduzione dei costi, la reperibilità pressoché totale durante l’orario lavorativo e la riduzione degli spostamenti.

Il 3CX Phone Client per iPhone e Android, è un client VoIP sviluppato ad hoc per operare senza soluzione di continuità con il 3CX Phone System – indipendentemente dal luogo in cui si trova l’utente. La configurazione da remoto lo rende semplicissimo da installare e da gestire, anche perché si integra perfettamente con tutti i firewall tramite il tunnel incorporato. Il client, oltre a non necessitare di costi di licenza, supporta pienamente i servizi PUSH, fondamentali per il risparmio della batteria. La App permette agli utenti di iPhone e iPad come di smartphone e tablet Android, di verificare la presenza dei colleghi, di impostare il proprio stato di presenza e di effettuare e ricevere chiamate gratuitamente all’interno della rete aziendale. Il concetto di “un solo numero” permette inoltre di rispondere alle chiamate col numero interno dell’ufficio e di trasferirle ai colleghi senza bisogno che l’interlocutore componga un nuovo numero. Le teleconferenze e la segreteria telefonica, infine, sono accessibili tramite rete WiFi e 3G.

Approfondimenti

• HP presenta il suo nuovo SmartPhone
  

  Anche Hp lancia un proprio smartphone. L’iPAQ 510 Voice Messenger è equipaggiato con Windows Mobile 6, permette la connessione a reti wi-fi, ed ha un hardware di tutto rispetto. Ultima chicca: un [...]

• Talkonaut voip e instant messaging per smartphone Nokia: arriva la concorrenza a Fring?
  

  Stanchi di utilizzare Fring? Bene, se possedete un cellulare Nokia S60 Serie3 presto potreste innamorarvi di Talkonaut, un client mobile con tutte le carte in regola per intaccare lo “scettro del re”: [...]

• il 12% delle connessioni broadband europee sono mobili (hsdpa)
  

  Il futuro della connettività internet è mobile: questo il trend che sembra delinearsi per il prossimo futuro. In un Europa ove già oggi il 12% delle connessioni avviene con tecnologia umts/hsdpa ci [...]