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.
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:
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.
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
Since privacy is important, it is sad to see a complete lack of encryption in the HTTP metrics call like this one:
DetailsFaceTime 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 SDESIt 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 traversalLike 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.
VideoFor 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.
AudioFor audio, the AAC-ELD codec from Fraunhofer is used as outlined on the Fraunhofer website.
In nonscientific testing, the codec did show behaviour of playing out static noise during wifi periods of packet loss between two updated iPhone 6 devices.
The signaling is pretty interesting, using XMPP to establish a peer-to-peer connection and then using SIP to negotiate the video call over that peer-to-peer connection (without encrypting the SIP negotiation).
This is a rather complicated and awkward construct that I have seen in the past when people tried to avoid making changes to their existing SIP stack. Does that mean Apple will take a long time to make the library used by FaceTime generally usable for the variety of use cases arising in the context of WebRTC? That is hard to predict, but this seems overly complex.
Quality of ExperienceFaceTime 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:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
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!
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/28Another week, another WebRTC related acquisition took place.
Since the Tropo acquisition just a month ago, we had two more acquisitions:
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 multitalentoLo 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 tascabileGli 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.
ApprofondimentiAnche 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 [...]
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 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
Approfondimenti3CX è 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 [...]
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 [...]
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 [...]
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.
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:
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.
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:
Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.
Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.
Wow, this most certainly is a great a theme.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.