News from Industry

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 [...]

Sì è conclusa oggi la due giorni organizzata dal nostro distributore ALLNET Italia: l’evento ICT Solutions Days.

Una serie di incontri, presentazioni e sessioni di lavoro che hanno riguardato le diverse aree di attività di ALLNET, ma quest’anno si è dato particolare risalto alla Unified Communication & Collaboration, oggetto della sessione plenaria che, nella mattinata del 12 Maggio, ha visto l’apertura dell’evento.

3CX c’era e ha potuto presentare le proprie soluzioni, 3CX Phone System e 3CX WebMeeting, ad una vasta platea di professionisti IT, partner e rivenditori.

L’evento si è svolto nella splendida cornice del Savoia Hotel Regency di Bologna ed è stata perfettamente organizzato dal professionalissimo staff di ALLNET. Due splendide giornate hanno poi contribuito al completo successo dell’iniziativa.

A conferma della solida partnership che lega da anni 3Cx e ALLNET Italia, nel corso degli ICT Solution Days abbiamo incontrato tantissime persone: partner “storici”, nuove aziende e professionisti. In sintesi: un’ottima occasione per presentare le nostre soluzioni e per raccogliere feedback da chi è tutti i giorni sul mercato delle telecomunicazioni e della Unified Communication

Approfondimenti

• 3CX è sponsor al Microsoft Ignite 2015!
  

  3CX è Silver Sponsor al Microsoft Ignite 2015, che si terrà a Chicago dal 4 all’8 Maggio.

  Il focus principale del Microsoft Ignite di quest’anno è la tecnologia Cloud, la Unified Communication e [...]

• Numeri nomadici interconnessi con telecom italia
  

  Mentre tutti si era al mare Telecom Italia ha garantito che entro Luglio le proprie utenze sarebbero state interconnesse con le numerazioni nomadiche in decade 55 degli altri operatori del settore. Quando [...]

• Ribbit conclude la fase beta e apre la propria piattaforma agli sviluppatori
  

  Dopo la recente acquisizione da parte di British Telecom, Ribbit annuncia l’uscita dalla fase beta della propria piattaforma che permette di integrare e sviluppare soluzioni per il traffico voce nel proprio sito [...]

Recently a new command line tool for Kamailio management was published by Asipto, named kamcli, available at:

• https://github.com/asipto/kamcli

It is written in Python and at this stage it is more an attempt to see if the community finds it useful and worth to get it developed further as part of Kamailio project.

• Short about the benefits/flexibility:
• python is by default installed on OSes (including Mac OS X) (as opposite to Lua, for example)
• became rather fast since Google invested in it
• lot more knowledge base and developers out there (as opposite to Lua or Perl), along with tons of extensions
• implementation is based on a CLI framework (Click) that makes it extremely easy to add new commands in a plugin-like fashion, therefore is easy to have custom commands when having specific needs (e.g., managing a custom database table used in kamailio.cfg via sqlops => add a new cmd_xyz.py in commands subfolder, without touching other files, not even the config)
• help message is embedded in the command code file, making it easier to document commands
• easy to validate parameters as well as format the output
• handling kamcli configuration file options is also easy (ini format)

One of the reasons of pushing this out was in the perspective of deprecating MI and working with JSONRPC fifo from command line — there is not an easy ways to manage json docs with shell and common tools (e.g., cat, echo, grep, awk) only. Kamcli has implemented the JSONRPC over fifo command (see also jsonrpc-s kamailio module). Still, given the old initial implementation, at this moment, kamcli is relying on MI via fifo (mi_fifo) for some of the commands (e.g., dumping usrloc records from memory).So far, couple of commands were implemented when comparing with kamctl:

• subscriber management (kamctl add/rm/passwd…)
• user location management (kamctl ul …)
• database querying (kamctl db …)
• statistics (kamctl stats …)
• mi commands (kamctl mi …)
• jsonrpc commands (not in kamctl)

If there is enough interest in developing this tool further, it can be migrated to Kamailio organization on Github to have all developers able to work on it.For further discussions about this tool, email to development mailing list .

We are holding our ninth CG meeting on the 24th of June…

https://www.w3.org/community/ortc/

Where: Online (TBD)

When: June 24, 2015 10am PDT

Agenda

Review action items from last meeting:

– RTCIceCandidateComplete dictionary
https://github.com/openpeer/ortc/issues/207

– RTCIceGatherer.close affect on RTCIceTransport / RTCDtlsTransport
https://github.com/openpeer/ortc/issues/208

– Comments added to #200
Incoming media prior to Remote Fingerprint Verification
https://github.com/openpeer/ortc/issues/200

– Comments added to #170, Peter to send fuller proposal to list
Response to connectivity checks prior to calling iceTransport.start()?
https://github.com/openpeer/ortc/issues/170#issuecomment-105629219

– Original #188 – Priority Calculation, new bug #209
Trying to remove RTCIceTransport.createAssociatedTransport(component)
https://github.com/openpeer/ortc/issues/209

– Philipp Hancke’s Review Comments
https://github.com/openpeer/ortc/issues/198

Review open issues: https://github.com/openpeer/ortc/issues?q=is%3Aopen

Review current draft: http://ortc.org (upper right hand side)

Review implementation progress: ORTC Lib, MS Edge, Google ?

Review ORTC CG alignment with WebRTC WG and 1.0 spec.

Questions, comments?

Plan next meeting.

Next major version of Kamailio (v4.3.0) is planned to be out on Wednesday (June 10) or Thursday (June 11). The pool of things to fix is minor, deb packaging for 4.3 is ready, thanks to Victor Seva. Some bits are still left to do: add docs for 4.3 series in wiki, prepare RPM packaging and build
proper ‘what is new’ list of features.Testing didn’t reveal new issues in the recent past as we run in two servers with live traffic. If you have issues with 4.3 branch, be sure you report them on Github tracker:

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

Meanwhile, contributions to enhance the related pages on the wiki are very appreciated:

• http://www.kamailio.org/wiki

Stay tuned for updates!

A customer has requested to set up a QA service that would continuously monitor the voice quality in their telephony infrastructure. They use a number of telephony carriers, and a set of applications on top of Plivo and FreeSWITCH. Also the conference module in FreeSWITCH is actively used.

Measuring jitter and packet loss, like it’s done in VoIPmonitor, is not sufficient, as we need to monitor end-to-end performance, including that of the FreeSWITCH server itself. So, there has to be a software component that compares the source audio with the recording on the other end of a call.

There are currently two major player on the market for voice quality measurements:

1. ITU-T PESQ algorithm is proposed as an ITU recommendation P.862. Its source code is available at the ITU website and on Github. But the algorithm is patented, and the source code license does not allow any production use. The evaluation went quite smoothly, and the algorithm was able to detect even minor distortions, like one 20ms frame loss in a 2-minute call. The PESQ algorithm is designed and calibrated to be used for audio files of 6 to 20 seconds in length. Processing of a 2-minute recording takes approximately 5 seconds on a modern Xeon CPU. Commercial software is provided by OPTICOM and PsyTechnics.
2. Sevana Oy is a Finnish/Estonian company that provides their own algorithms and software product for voice quality assessment. Their AQuA (Audio Quality Analyzer) software provides a fast and reliable way to compare the audio files: processing of a 2-minutes recording took about half a second on a modern CPU. Sevana has kindly provided a 10-days evaluation license and a fully functional software package, and the customer decided to go ahead with purchasing the license.

The simplest single-server license for Sevana AQuA allows running only one AQuA process at a time, so we wrapped its execution into a Perl script that utilizes a simple exclusive locking mechanism and performs audio file processing one at a time.

AQuA produces two scores in each measurement: the similarity percentage, and the MOS score. Both metrics are useful for quality analysis (for example, a 20ms frame added or lost inside of a silent pause influences the similarity score more significantly than MOS). It also takes a number of command-line options which can increase its tolerance to certain types of distortions, such as frequencies outside of G.711 range.

FreeSWITCH software is used as the SIP server for sending and terminating voice calls and for recording the received audio. It allows recording in several different formats: a) raw codec recording, done in the same thread as RTP processing; b) 16-bit signed PCM in WAV format, and file writing is done in a separate thread; c) compressed voice in a number of formats. The first two options produce similar results (raw codec recording had difficulties in the beginning). In case of raw codec recording, an additional step is required to convert the input files into 16-bit PCM WAV.

The call recording server requires to have a precise clock reference, so a baremetal hardware is required. Virtualized environments add up some uncontrollable imprecision to the virtual machines, although a thorough lab test is requires to verify this. It also depends on the type of hypervisor, as they implement the system clock differently.

The Linux kernel provides access to various clock sources. TSC is commonly used as default, and there is also HPET clock on modern hardware platforms. HPET is supposed to provide a more precise clock source, but it appears that it depends on CPU load: we accidentally discovered that audio recording in FreeSWITCH is significantly distorted when there’s some CPU activity is done in parallel (Debian package builder was working on the same 8-core machine). So far, TSC clock on a baremetal server provided the most reliable results.

The recording is done into a tmpfs mounted partition, in order to avoid any dependency on I/O load. The processing script performs the quality assessment on recorded files, and then moves or deletes them, depending on the measured score.

The SIP service was attached to an unusual UDP port, as port 5060 is frequently accessed by port scanners in public Internet. The DNS NAPTR and SRV records are used in order to use a universal SIP URI string, without having to reconfigure the remote servers if the IP address or UDP port changes.

Jitter buffer is disabled by default in FreeSWITCH, and it has to be activated whenever the calls are terminated on the server. In our case, the “jitterbuffer_msec” variable is set to “50:50″ in the dialplan before answering and recording the call. With this, the jitter buffer is not allowed to grow dynamically above 50ms. So, we tolerate most of typical Internet-imposed jitter, but clock drift on the sending side would cause packet drop on the receiver.

The dialplan is designed to accept direct SIP calls from remote servers, and PSTN calls from telephony providers. If a remote server calls our QA service directly, it encodes the source name in the user part of the SIP URI. Also there are two options for a QA call: it can playback the test audio, or send silence. In case of PSTN calls, the caller ID is used as the source identifier. The dialplan activates audio recording into a WAV file on a tmpfs partition, and launches the processing script after the hangup.

The conference dialer is used for testing the conferencing performance on a production FreeSWITCH server. It requires a conferencing profile that does not play any greetings to conference participants. Also in case of more than two participants, only one has to be chosen as a speaker, and all others would be listeners. A dedicated SIP URI on the QA server is reserved to playback the test audio and not to perform any recording.

Each measurement result for QA calls is stored in an SQL database for further processing, and also sent to Syslog for real-time monitoring.

The test audio is a concatenation of speech samples from ITU-T Recommendation P.50 Appendix I, resampled from 16KHz to 8KHz and stored as 16-bit signed PCM audio.

 

Filed under: Networking Tagged: freeswitch, monitoring, network monitoring, pbx, testing, voip

Hello, again. This passed week in the FreeSWITCH master branch we had 648 commits! Most of those commits came from the merged 1.6 video branch and bring in a lot of new features. First and foremost, check out the new video functionality! The merge of 1.6 video branch means FreeSWITCH master now has the ability to transcode video and this means two different devices using different video codecs can use FreeSWITCH to translate between them. Some of the many other new features are the ability to live stream, record calls to a video file, and playback videos into a call with mod_av, overlaying logos or images with mod_cv, desktop sharing through mod_verto, and PDF and GIF rendered as video with mod_imagick. FreeSWITCH master also has MCU support for mod_conference!

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-7499 core RTCP improvements
• FS-7585 added video support to mod_rtmp
• FS-7500 core video transcoding support
• FS-7501 core video jitterbuffer
• FS-7502 core video media bugs
• FS-7503 core file interface video support
• FS-7504 codecs let you choose which codec module to use
• FS-7505 file interface to let you specify which format module to use when multiple types are supported
• FS-7506 core text rendering
• FS-7507 added new global directory variables and configure directory behavior changes
• FS-7508 mod_vpx transcoding vp8/vp9 and replace mod_v8
• FS-7509 mod_verto improvements allow for desktop share with the installation of this chrome extension https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing/ and improved bandwith and resolution handling.
• FS-7512 mod_png allows for image overlays for video mute
• FS-7513 mod_conference MCU feature and avatar support
• FS-7514 mod_vlc video support
• FS-7515 mod_cv is a video media bug module that uses video recognition and facial recognition technology to allow you to modify a video stream by adding overlapping images and text or to silently detect and fire events
• FS-7516 mod_imagick allows for PDF and GIF rendered as video
• FS-7517 mod_openh264 h264 codec module
• FS-7519 mod_av a file format and codec module that uses libav or ffmpeg and allows you to live stream, record calls to a video file, and playback videos into a call.
• FS-7494 default avatar and mute images for video MCU
• FS-7471 improved configs for video
• FS-7338 removed external library dependencies

Fresh out of Google IO, Justin Uberti provides a WebRTC update via WebRTC Meetup in SFO at the Twilio HQ. Slides and demos are not visible, I am attempting to get a copy of the slides. UPDATE: Most of the slides were captured via photos.

Justin talking points:
– Renewed focus on mobile
– HD bitrates and bandwidth estimation
– Goal H.264 coming to Chrome 45 via Cisco’s OpenH264 (whoa!)
– VP9 & hardware support
– Demo on Nexus 6 using VP9 and hardware encoder

What’s coming next..
– Mobile performance
– Complete call setup should be 500ms
– Encryption (we don’t hold the keys)
– ECDSA coming soon!
– HW encode on android capable of 1080p
– New Echo Cancellation via DAEC (Delay Agnostic Echo Canceller)
– Mobile Networks
– Network Handoff
– Scaling Quality
– Better performance on lossy networks
New domain for “WebRTC and Web Audio resources”
– Appr.tc
– g.co/webrtc

Q&A

Q What’s the story on spec deviation?
A We want to make sure we add promises to the spec.

Q Get Stats?
A Working on it

Q Unified plan support
A Organizationally challenged and taking back seat to encoding performance and other “on fire” must fix immediately

Q What is going to evolve in screen sharing in spec and Chrome?
A Things work “ok” for screen sharing but not great for some things like scrolling, people are also interested in using in tabs versus window. Screen refresh is not as fast as we would like but we think we have fixed that.

Q Changing framerate and resolution mid-call?
A RTPSender gives you some of these knobs (Note: Object from ORTC Spec!), which is on its way.

Q Battery life for hw encoded apps?
A 3 categories, voice only, video on sw, video on hw. Video demo was on hw at 1080p at 30% of CPU. HW video will compete with a baseband voice call on wifi.

Feross Aboukhadijeh & John Hiesey (creators of PeerCDN

Talking points:

– https://github.com/feross/webtorrent
– Using WebRTC DataChannel to stream content
– Demo: can’t see the screen
– Hosting websites in Browsers via WebTorrent
– NAT traversal via regular STUN / TURN

Q&A

Q Justin asks, what will it take to have this work with existing bittorrent clients
A They need to add WebRTC, then it will work

Great news for our fellow FreeSWITCH users: in preparation for the 1.6 beta release, a lot of new functionality is being merged into the master branch. Some of these new features have new build requirements and dependencies, so please be sure to check the Confluence link here: https://freeswitch.org/confluence/display/FREESWITCH/FreeSWITCH+1.6+Video for platform specific instructions. Building and running FreeSWITCH will be easier if you are using Debian 8(Jessie). If you are not using Debian you can find some of the supporting dependencies tar.gz files here: http://files.freeswitch.org/downloads/libs/

Additionally, if you are using 1.4 in production, you need to be sure to switch to tracking the v1.4 branch, as master will be preparing for the 1.6 beta release.

Some of the new features and work that have gone into this release include:
FS-7499 core RTCP improvements
FS-7500 core video transcoding support
FS-7501 core video jitterbuffer
FS-7502 core video media bugs
FS-7503 core file interface video support
FS-7504 codecs let you choose which codec module to use
FS-7505 file interface to let you specify which format module to use when multiple types are supported
FS-7506 core text rendering
FS-7507 added new global directory variables and configure directory behavior changes
FS-7508 mod_vpx transcoding vp8/vp9 and replace mod_v8
FS-7509 mod_verto improvements allow for desktop share with the installation of this chrome extension https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing/ and improved bandwith and resolution handling.
FS-7512 mod_png allows for image overlays for logos and images for video mute
FS-7513 mod_conference MCU feature and avatar support
FS-7514 mod_vlc video support allows you to live stream, record calls to a video file, and playback videos into a call.
FS-7515 mod_cv is a video media bug module that uses video recognition and facial recognition technology to allow you to modify a video stream by adding overlapping images and text or to silently detect and fire events
FS-7516 mod_imagick allows for PDF and GIF rendered as video
FS-7517 mod_openh264 h264 codec module
FS-7519 mod_av a file format and codec module that uses libav or ffmpeg
FS-7494 default avatar and mute images for video MCU
FS-7471 improved configs for video
FS-7338 removed external library dependencies
FS-7585 added video support to mod_rtmp

The FreeSWITCH 1.4.19 release is here!

This is routine maintenance release and the source tarballs can be found: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.4.19.tar.bz2

The features for this release include:

• FS-7470 [mod_verto] Add a force-register-domain param
• FS-7526 [mod_amqp] Add enable_fallback_format_fields for mod_amqp producer profiles if the profile param is set and create the amqp exchange on the first startup of a clean platform.
• FS-7557 [mod_mongo] Add limit backend

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

• FS-7488 [mod_managed] Fixed a build error with Windows and removed duplicate files
• FS-7574 [build] Update to handle new download locations for sounds
• FS-7574 [build] Fixed it so curl has the proper flag to follow 3XX redirects for getg729 and getsounds

The following bugs were squashed:

• FS-7456 Fixed a bug in SDP parser, to allow it to handle sdp with m lines in any order
• FS-7460 [mod_sofia] Don’t force ICE in 3pcc-mode=proxy
• FS-7465 Fixed a crash in stereo file writing
• FS-7425 Fixed an audio Handshake failure 1 when using webrtc with PFS-only client (Firefox >=38)
• FS-7472 [mod_sofia] Fix for a bug where the rtp-digit-delay profile param was being ignored
• FS-7488 [mod_managed] Fixed a build error
• FS-7490 [mod_rayo] Fixed a bug with the format of mod_rayo generated regex not working with newer libpcre
• FS-7491 [mod_graylog2] Send timestamp with millisecond precision instead of microsecond as required by GELF
• FS-7466 Fixed a bug causing audio issues by repeated log lines printing when rtp_manual_rtp_bugs is set to ALWAYS_AUTO_ADJUST
• FS-7496 [mod_http_cache] Fixed an issue with the URL args being included in the cache file name and causing problems opening the files later
• FS-7425 Fixed a bug when using a cert with missing dhparams resulting in a segfault.
• FS-7523 [mod_json_cdr] Fixed a segfault caused by a missing config file.
• FS-7357 FAX now tolerates EOP and PPS messages being incorrectly echoed.
• FS-7552 [mod_amqp] Fixed a segfault on unload and when no connections were valid
• FS-7463 [mod_sofia] Conditionally allow intercept of replaced call-id when processing replaces header
• FS-7557 [mod_mongo] Fixed a crash when doing ‘limit_usage mongo foo bar’
• FS-7545 [mod_opus] Fixed RTP timestamps to prevent unneeded resampling when transcoding
• FS-7184 [mod_spandsp] Fixed a fax buffer overflow in t38 on failure condition with some fax machines
• FS-7546 [mod_spandsp] Fixed a crash when sending a fax when built using clang compiler
• FS-7541 Fixed an issue with audio gaps in native audio recordings
• FS-7562 [mod_sofia] Fixed an interop issue caused when using bypass media with t.38 passthru
• FS-7567 Fixed a rare segfault on shutdown caused by a race condition
• FS-7529 Fixed an error with call recording on G722 calls
• FS-7584 Fixed rtcp-mux interop issue with chrome canary causing video transport failure
• FS-7582 Fixed a bug with reINVITES not including a=setup:actpass in the SDP