News from Industry

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

Join us this eve at Launch Academy for the very first Vancouver WebRTC meetup!

This inaugural meetup should be a real fun event! I will be providing an introduction to WebRTC and Tobias Noiges (QHR Technologies) will be walking us through the creation of Medeo, a medical virtual visit application based on WebRTC.

Join us and learn about WebRTC and how it’s forever changing communications on the web!

 

Meeting info:

Location: Launch Academy #300 – 128 West Hastings Street, Vancouver, BC

Date and Time: Wednesday May 27, 2015 6-8pm

Buzz in Code: #300 or DM @elagerway on twitter

 

Agenda:

– Welcome!

– WebRTC Introduction; Erik Lagerway, Hookflash

– WebRTC in the real world; Tobias Noiges, QHR Technologies

– WebRTC Demo; Tobias Noiges

– Q&A

 

Hope to see you there!

/Erik Lagerway

The world of browsers and how they work is both complex and fascinating. For those that are new to the browser engine landscape, Google, Apple, and many others collaborated on an open source web rendering engine for many years known as WebKit.  WebKit has active community with many less well known browsers that use it, so the WebKit community was shocked when Google announced they would fork WebKit into a new engine for Chrome called Blink.

Emphasis for implementing WebRTC shifted with Google into Blink at the expense of WebKit. To date, Apple has not given any indications it was going to add  WebRTC into WebKit (see this post for an idea on nudging them). This is not good for the eclectic WebKit development community that would like to start working with WebRTC or those hoping for WebRTC support in Apple’s browsers.

Then an interesting project by Ericsson, Temasys, and Igalia was announced –  webrtcinwebkit. As the name implies, the goal of this project was to put WebRTC in WebKit, by themselves. Many questions come to mind, but the most important may be is this a worthwhile effort and one that other WebRTC developers should be involved in?

I asked webrtcinwebkit contributors Alex Gouaillard and Stefan Håkansson to give some more background and help answer who should care about this project and why they are working on this.

{“intro-by”, “chad“}

 

 

 

webrtcHacks: For those who are not familiar, can you describe the webrtcinwebkit project?

Alex:  webrtcinwebkit is a project aiming at bringing WebRTC support in WebKit which is the foundation of a lot of web browsers like Safari and web browsing frameworks like WebView used extensively in Mobile applications.

webrtcHacks: How did this come together? Who are the major contributors to this project?

Alex:  in 2014, Ericsson had an initial implementation to flesh out and was thinking about open sourcing the underlying engine now known as OpenWebRTC. Igalia’s Philippe Normand had been trying to integrate WebRTC in WebKitgtk+ using Ericsson’s 2011 code base for some time, Temasys was trying to find a way to enable WebRTC in iOS and remove the need for a plugin in desktop Safari. At a W3C meeting in Santa Clara in November 2014, a discussion happened with an Apple employee that make the parties believe that there was a way. The project was born.

webrtcHacks: Why do you think Apple has not implemented WebRTC already? How will webrtcinwebkit change that?

Alex:  Those who know can’t talk and those who talk likely don’t know.

Our answer is: we don’t know for sure.

webrtcHacks: How much of this project is about Apple vs. other WebKit users?

Alex:  Not at all about Apple. We’re working on adding WebRTC API’s to WebKit, and to back it with OpenWebRTC for the WebKitgtk+ port. To what extent other ports make use of the WebRTC API’s is up to them, but of course we hope they will use them.

webrtcHacks: was there a lot of WebRTC in WebKit already from before Google forked blink?

Stefan:  Yes, there was quite a bit of WebRTC in there, contributed by Ericsson, Google, Igalia and others. Some parts can be re-used, but largely the standard has evolved so much that we had to start over.

 

WebKit commits per month after Blink. Source: Juan J Sanchez, Igalia (May 2014)

webrtcHacks: Can you comment on how your perspective of how Google’s forking of webkit has impacted the webkit community? Isn’t everyone just moving to blink now?

Stefan:  Just looking at the revision history of the WebKit source code will immediately show that the WebKit project is very much alive.

webrtcHacks: Is there value in webrtcinwebkit for other developers even if Apple ignores this?

Alex:  the WebKit community itself is pretty big, and again as far as mobile and embedded devices are concerned, this is the main way of handling web pages. Whether Apple adopt the changes or not, this is good news for many people.

Stefan: I agree fully. I would also like to add the value for the WebRTC community and the standardization effort of a second, independent implementation, as the initial back end used will be OpenWebRTC. The current WebRTC implementations in Chrome, Firefox and Opera all to a large extent use the same webrtc.org backend so we think it is a point in using OpenWebRTC as the backend as it gives a second, truly independent, implementation of the standard.

webrtcHacks: How much effort is  going into this project? Is it staffed adequately for success?

Alex:  Everybody is working on separate projects, so depending for example if you count people working on OpenWebRTC as being part of this project or not, the count will change. There are roughly the following Full-time-equivalent (FTE) staff:

• 4  at Ericsson
• 2 Ericsson contractors
• 2 Temasys
• 1 Igalia

Not all FTE are equal contributors though and the main technical leaders (for WebKit) are with Ericsson and Igalia.

webrtcHacks: How long will it take to complete?

Alex:  We have a version that includes getUserMedia already working a demoable in a separate fork. Ericsson is polishing the PeerConnection, while Temasys is handling Datachannel. It then takes a little bit of time to submit patches to upstream WebKit, so the nightly version of WebKit is still behind. OpenWebRTC and webrtc in WebKit is based on a very recent version of GStreamer, and updating that component in WebKit as far reaching consequences. It touches all the media functionalities of WebKit. We think this will take some time to get in, then the following patches should be self contained and easier to push. We aim at a June timeline.

webrtcHacks: I have heard many comments about GStreamer not being appropriate for real time applications. Can you address that topic?

Stefan:  That does not match our experience at all. We’ve been using GStreamer for many real time applications since back in 2010 when we showed our first implementation of what eventually became WebRTC, and we’ve consistenly got good real time performance. The fact that there is a lively GStreamer community is also a big plus, that enabled OpenWebRTC to quickly make use of the HW accelerated video codec that became available in iOS 8 – something I have heard webrtc.org still doesn’t for example.

webrtcHacks: How tightly coupled is webrtcinwebkit with OpenWebRTC? Is webrtcinwebkit really a derivative and dependant on OpenWebRTC?

Stefan: Although our initial implementation is backended by OpenWebRTC, the project is designed to fully support other implementations, so no, webrtcinwebkit is not a derivative on OpenWebRTC.

Alex:  Given enough time (and resource), the original plan was to have two back ends for webrtcinwebkit: both OWR from OpenWebRTC and libwebrtc from webrtc.org. It’s not clear yet if we will be able to make it happen, but it’s still a wish.

Browser Engine Share Chrome Blink 41% IE Trident 14% Safari Webkit 14% Android Browser Webkit 7% Firefox Gecko 12% Opera Blink 4% UC Browser ?? 3% Nokia Webkit 1% Browser Usage Share – May 2014 to Apr 2015
Source: http://gs.statcounter.com/#all-browser-ww-monthly-201405-201504-bar

webrtcHacks: How has the community developed in the month since you launched this project? How many contributors are outside of Ericsson and Temasys?

Alex:  We announced the project before before it was ready for others to contribute. Most of the WebRTC ecosystem was under the impression there was nothing being done on that side, which was just not true. We wanted to let people know something was brewing, and that they would be able to contribute soon. We also wanted to welcome early feedback.

We received a lot of interest by e-mail, from different companies. We eventually made our fork of WebKit, our working copy if you wish, public on GitHub. Today anybody can make a pull request. That being said, we believe it would be better to wait until we have a first implementation of getUserMedia, PeerConnection and DataChannel before they jump in. For most of the work, you need a first implementation of Offer/Answer, and the capacity to see on screen the video streams, or hear the audio stream before you can start to debug. That should happen in a matter of weeks now.

webrtcHacks: What does success of this project look like? How will you know when this succeeds?

Alex:  As soon as WebKitgtk+, one of the default Linux browsers, supports WebRTC, we think it will be a success. Eventually seeing other ports – other browsers using WebKit  adopting those changes will be very gratifying too.

{“interviewer”, “chad“}

{“interviewees”, [“Alex Gouaillard“, “Stefan Håkansson“]}

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 Why put WebRTC in Webkit? Q&A with the webrtcinwebkit team appeared first on webrtcHacks.

The next release of Kamailio will be 4.3 – a release with new module and many new functions! The GIT branch for the coming release 4.3 has been created. This branch  will host the release series 4.3.x. To help the developers, please download this branch and test it before the release!To get this branch from GIT, you can use: git clone https://github.com/kamailio/kamailio.git kamailio
cd kamailio
git checkout -b 4.3 origin/4.3Notes about installing Kamailio from this branch are available at:

• http://www.kamailio.org/wiki/install/4.3.x/git

Hopefully in about two weeks or so the full release of 4.3.0 will be out.The master branch is again ready for new features, to be part of the next future release, expected to be numbered 4.4.

Hello, again. This passed week in the FreeSWITCH master branch we had 7 commits. We saw some neat bug fixes go in this week and I hope everyone partaking in today’s holiday enjoys their long weekend!

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.

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

• FS-7488 [mod_managed] Fix a build error with Windows and removed duplicate files

The following bugs were squashed:

• 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

 

One week before and we are ready to welcome the guests of the 3rd edition of Kamailio World Conference & Exhibition.The content is filled with excellent technical tutorials in the first day and vast range of hot topics covered during the two conference days — Kamailio, SIP, WebRTC, Asterisk, Sems, JsSIP, Performance and Traffic Monitoring, OpenStack, Kazoo, Erlang, Cloud PBX, OTT or VoLTE are among them.We are honoured to have an impressive list of speakers, from those that are involved in building the communications, able to share their expertise from deep technical aspects to market needs and business perspectives.Over all, the event has grown continuously from its first edition, special thanks to our sponsors : FhG Fokus, FhG Forum, Asipto, Sipwise, sipgate, Simwood, Obihai, Matrix, Digium, Tyntec, NG Voice, CoreNetDynamics, Pascom, VoiceTel, 2600hz and VUC. They made possible to host the event at a very nice location in the city center of Berlin and be able to bring a consistent number of experienced speakers.This is an event you must not miss!Looking forward to meeting many of you next week in Berlin!

Kamailio SIP Server v4.2.5 stable is out! This is a minor release including fixes in code and documentation since v4.2.4. Don’t worry about upgrading – the configuration file and database compatibility is preserved.Kamailio (former OpenSER) v4.2.5 is based on the latest version of GIT branch 4.2, therefore those running previous 4.2.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.2.x.Resources for Kamailio version 4.2.5Source tarballs are available at:

• http://www.kamailio.org/pub/kamailio/4.2.5/src/

Detailed changelog:

• http://www.kamailio.org/pub/kamailio/4.2.5/ChangeLog

Download via GIT: # git clone git://git.kamailio.org/kamailio kamailio
# cd kamailio
# git checkout -b 4.2 origin/4.2Binaries and packages will be uploaded at:

• http://www.kamailio.org/pub/kamailio/4.2.5/

Modules’ documentation:

• http://www.kamailio.org/docs/modules/4.2.x/

What is new in 4.2.x release series is summarized in the announcement of v4.2.0:

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

Looking forward to meeting many of you at Kamailio World 2015 next week!

Hello, again. This passed week in the FreeSWITCH master branch we had 14 commits. Our feature for this week is the addition of limit backend to mod_mongo. It needs some testing, so go check it out.

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-7557 [mod_mongo] Add limit backend

The following bugs were squashed:

• 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 un-needed 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

ORTC CG Meeting 8 will be held on May 13 at 10am – Pacific Daylight Time.

Where: Online WebRTC Enable Meeting via Jitsi (https://jitsi.tools.ietf.org/ortc) Reverted to Google Hangouts

Agenda:

• Review Bugs:
  https://github.com/openpeer/ortc/issues?q=is%3Aopen
• Review current draft
  http://ortc.org/wp-content/uploads/2015/05/ortc.html
• Stefan requested we comment on this…
  The WebRTC and Device APIs Working Groups request feedback on the Last Call Working Draft of Media Capture and Streams, a JavaScript API that enables access to cameras and microphones from Web browsers as well as control of the use of the data generated (e.g. rendering what a camera captures in a html video element):
  http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/
• CG alignment with 1.0

Hello, again. This passed week in the FreeSWITCH master branch we had 6 commits. Some more work was done to mod_amqp this week as well as some bug fixes.

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-7526 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.

The following bugs were squashed:

• 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.

Two weeks ago Philipp Hancke,  lead WebRTC developer of Talky and part of the &yet‘s WebRTC consulting team, started a series of posts about detailed examinations he is doing on several major VoIP deployments to see if and how they may be using WebRTC. Please see that post on WhatsApp for some background on the series and below for another great analysis – this time on Facebook Messenger. {“editor”: “chad“}

 

Last week, Facebook announced support for video chats in their Messenger app. Given that Messenger claims to account for 10% of global mobile VoIP traffic, this made in a very interesting target for further investigation. As part of the series of deconstructions, the full analysis (another fifteen pages, using the full range of analysis techniques demonstrated earlier) is available for download here, including the wireshark dumps.

 

Facebook Messenger likes WebRTC

Facebook Messenger is an extremely popular messaging and communications app. It works in Chrome / Firefox and Opera as well as Android and iOS. The mobile versions use the WebRTC.org library and Messenger is optimized heavily for mobile use cases:

• Instead of DTLS, the older SDES encryption scheme is used between mobile clients. While not offering features such as perfect forward secrecy, it provides faster call setup time.
• The audio codec depends on platform and peer. Opus, iSAC and iSAC Low Complexity (LC) are used, with a packetization that prefers fewer, larger packets.
• VP8 is used as video codec on web, iOS and Android. Interestingly, Facebook chose VP8 over H.264 for iOS, even though VP8 has no hardware acceleration capability on Apple iOS devices.

Comparison with WebRTC  Feature WebRTC/RTCWeb Specifications Messenger SDES MUST NOT offer SDES uses SDES between mobile clients, DTLS with browsers ICE RFC 5245 RFC 5245 with some old google quirks TURN usage used as last resort TURN and old Google relay Audio codec Opus or G.711 Opus, iSAC, ISAC Low Complexity Video codec VP8 or H264 VP8 WebRTC fulfilling its promise: No plugins required

Back in 2011, Facebook launched Skype-powered video calling. It used a plugin. The need for a plugin is now gone, probably along with other parts of the integration as described in this announcement. Most platforms are supported without requiring users to install something. WebRTC is starting to fulfill its promise: no plugins needed.

The WebRTC rollout at Facebook has been done gradually, starting in early 2015. Chad Hart was one of the first people to notice in mid-January. I took a quick look and was not very impressed by what I found. Basically it was a simple 1-1 webchat akin to Google’s apprtc sample.

Recently, there has been a lot of news on Facebook’s Messenger. They launched messenger.com as a standalone website with support for voice and video between browsers. As Tsahi Levent-Levi pointed out already, it is using WebRTC.

On the mobile side, the Messenger client had been voice only. Video calling is available in the apps as well. All of this warrants a closer look. With WhatsApp and Messenger coming from the same company, we were expecting similarities, making this report easy. Well… that’s not how it ended up.

It turns out that unlike WhatsApp:

• Messenger uses the webrtc.org library provided by Google
• VP8 video codec is used for video calls
• Choice of the audio codec, which includes ISAC and Opus, varies based on the devices used and the other party in the call
• DTLS is used for encrypting the media between the app and the browsers
• DTLS is not used in calls between two mobile devices (surprisingly)

Mobile

While Messenger looks pretty standard, there are quite a number of optimizations here. Some gems are hidden to anyone glancing through the details. Chrome’s webrtc-internals are easily available and were used in the first scenarios tested. It allows looking at the implementation from a number of different angles, all the way from the captured packets, via the signaling protocol and up to the WebRTC API calls.

The iOS application offers a number of non-standardized codecs. In particular, when calling Chrome the iSAC audio codec will be used. Opus is used with Firefox, which does not implement iSAC. In both cases, the app tweaks the codec usage by sending larger frames than the browser. That is quite an interesting hack reminiscent of the WhatsApp behaviour of switching to a larger packetization. I can only speculate that this may show larger packets to be more robust on wireless networks?

Calls between two mobile devices turn out to be more interesting. Here, the optimizations for calling a browser come to bear fully.

Currently, video calls are only supported between either mobile devices or browsers, which will surely change soon. VP8 is used as the codec.

Unlike WhatsApp, Messenger can be run on multiple devices. So when calling someone who is logged in on multiple devices, all devices ring. This is nice behavior, as it allows the called user to choose where to take the call. This makes a lot more sense than previous approaches, e.g. Google Talk attempting to let the caller determine the recipients “most available device” from a UX point of view. In a world where mobile devices are disconnected frequently and need to be woken up via push messages, this is even more important than it was a decade ago.

Security

The most important takeaway is that instead of using DTLS, Messenger uses the older SDES encryption scheme between two mobile clients. This means media can flow as soon as ICE is done, eliminating a round-trip for the DTLS handshake. This shows a desire to reduce the session startup time, similar to what we saw with WhatsApp.
The widely known downside of that is that the encryption keys are sent via the signaling servers and can be used to retroactively decrypt traffic. Government agencies will surely rejoice at the news of this being applicable to 10% of the mobile VoIP traffic…

 

{“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 Facebook Messenger likes WebRTC appeared first on webrtcHacks.

Before freezing the development for next major release – Kamailio v4.3.0 – several modules and other relevant additions were pushed in a rather short period of time to git repository. Now, we are trying to look briefly at few of them in a series of posts in order to let everyone know about them.First to talk about it is the erlang module, contributed by Seudin Kasumovic of Bicom Systems. Erlang is a functional programming language tightly related to telecom environment, with built-in support for concurrency, distribution and fault toleranceThe module enables interaction of Kamailio with Erlang nodes, allowing to send and receive Erlang messages as well as RPC calls between each other. You can read more about it at:

• http://kamailio.org/docs/modules/devel/modules/erlang.html

Seudin will also present at Kamailio World Conference how this module can be used and its benefits for scalability and reliability.