News from Industry

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.

Check out the weekly conference call to see the latest news!

Given the roots and the tight relation of Kamailio project with the academic environment, we are offering three seats at Kamailio World Conference, May 27029, 2015, in Berlin, to students enrolled in universities or research institutes (both bachelor and PhD programs qualify).Last year we tried it locally with the universities in Berlin and this year we want to extend it, as there might be young people interested to travel a bit and attend the event.If you are a student and want to participate, email to registration@kamailio.org . Participation to
all the content of the event (workshops, conference and social event) is free, but you will have to take care of expenses for traveling and accommodation. Write a short description about your interest in real time communications and what is the university or the research institute you are affiliate to.Also, if you are not a student, but you are in touch with some or have access to students forums/mailing lists, it will be very appreciated if you forward these details.More information about Kamailio World is available on the web site:

• http://www.kamailioworld.com

Looking forward to meeting many of you in just few weeks in Berlin!

I needed to test some master-slave software in a situation that the master communicated to the slave over NAT (master’s IP address was replaced with the firewall’s external address), and then NAT would be removed, keeping master and slave addresses the same, but the slave would see the master directly.

This is the test scenario that worked on my desk, without having to add any routing to the LAN.

atom02 is the computer that emulates the slave system. It is connected back-to-back to alix102, and has only one IP address to communicate to:

ip link set dev eth0 up ip addr add 192.168.1.50/31 dev eth0

alix102 is a Linux box with multiple Ethernet ports: eth0 is connected to my home LAN and has a DHCP address 192.168.1.142/24. Also eth1 (192.168.1.51/31) is connected directly to atom02.

The following configuration makes alix102 answer to ARP requests for 192.168.1.50 and forward packets to atom02, replacing the source address with 192.168.1.51. Also atom02 can make an SSH connection to 192.168.1.51:3022 and it will be connected to another box in the LAN that emulates the software master (192.168.1.147:22).

# enable IP forwarding echo 1 > /proc/sys/net/ipv4/ip_forward # Bring up eth1 ip link set dev eth1 up ip addr add 192.168.1.51/31 dev eth1 # Enable proxy ARP on eth0 echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp # Set up the NAT translation iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 192.168.1.51 iptables -t nat -A PREROUTING -p tcp --dport 3022 -i eth1 -j DNAT --to 192.168.1.147:22

After that, atom02 can be re-connected directly into the LAN, keeping the address 192.168.1.50 with /24 network mask, and the software can be tested with direct communication. Alix102 has to be disconnected from the LAN, so that it does not pollute it with proxy ARP responses.

Filed under: Networking Tagged: linux

I needed to install CentOS 6 on one an old Acer Aspire One notebook (with Intel Atom CPU) for some software testing. The problem is, that it could not perform a reboot, and I needed to press the power button every time. These instructions for reboot=X parameter for kernel did not help at all.

What really helped, is `kernel-ml` package from elrepo.org repositories. At the moment of writing, it was version `4.0.0-1.el6.elrepo.x86_64`.

Keep in mind that after installing kernnel-ml package, you need to edit /etc/grub.conf and make this new kernel as default. No additional boot options are required.

Filed under: Hardware Tagged: linux

It is one month till the start of Kamailio World 2015, time has passed very fast since we announced the event, accelerated by April filled with many public holidays.The first draft of the schedule is now available, as usual, expect many speakers to tune the content of their presentation along the way to the day of the talk, to surprise the audience with challenging concepts and visions.At this edition we were pleasely surprised by the number of submissions, but it was an extremely hard task to select the sessions. To accommodate as much as possible, we are introducing the lightning talks, two of 10 minutes each, to give the opportunity to present shortly about interesting ideas or updates of applications used in Kamailio and VoIP eco-system.The two days of conference are filled with 28 sessions, the event being completed with 5 technical workshopsduring the pre-conference day. Several exhibitors will be available during the conference days with showcases of their products or solutions, ready with many demos on site.We are very grateful to our sponsors, which made possible to bring again a consistent number of speakers, ensuring first class quality content for the entire event.In about 4 weeks, we will be ready to welcome you in the beautiful city center of Berlin. Don’t miss the opportunity to attend this event, it is unique across Europe, bringing open source and real time communications industry together, bridging flexibility innovation with telecommunication businesses. It is now the right time to register!See you in Berlin at the end of May!

The development (aka master) branch of Kamailio now enter the pre-release phase for version 4.3.0. No new features are allowed to be pushed to GIT master branch until we create a dedicated branch for 4.3 (expected to be in about 4 weeks or so).The focus moves now on testing the code, to get it in a stable, rock solid state at the time of release. We hope to get many people from the community involved in testing. If you want to get involved and need assistance about what and how to do it, please don’t hesitate to write to mailing lists. The first step is to get Kamailio installed from sources, details at:

• http://www.kamailio.org/wiki/install/devel/git

Stay tuned for updates to the wiki pages with guidelines for migration from 4.2 to 4.3 as well as what is new in version 4.3.The release of v4.3.0 is expected to be out few weeks after Kamailio World Conference — more or less about mid of June 2015.

Vancouver is one of the hotbeds for IP communication technology and is home to many developers. With the advent of WebRTC, integration of voice and video chat into almost any application is within reach but as always, there are always pitfalls. Sounds like a great reason to start a WebRTC meetup in Vancouver!

As of today Vancouver now has its own WebRTC meetup group. If you are interested in linking up and talking to like-minded RTC geeks implementing real time comm using WebRTC please join and let’s get together. We will also be looking for meetup facilities & sponsors (snacks, drinks etc.).

I am thinking our first meetup will be in May sometime, not sure on exact dates yet.

Agenda and topic for the first meeting is wide open. Topics like, “WebRTC 101″ or “Dos and Don’ts” come to mind, but we can decide on that when we have heard from some active members.

We will also be bringing in some live guests from time to time via what else, WebRTC!

Hope to see you soon!

/Erik

One of our first posts was a Wireshark analysis of Amazon’s Mayday service to see if it was actually using WebRTC. In the very early days of WebRTC, verifying a major deployment like this was an important milestone for the WebRTC community. More recently, Philipp Hancke – aka Fippo – did several great posts analyzing Google Hangouts and Mozilla’s Hello service in Firefox. These analyses validate that WebRTC can be successfully deployed by major companies at scale. They also provide valuable insight for developers and architects on how to build a WebRTC service.

These posts are awesome and of course we want more.

I am happy to say many more are coming. In an effort to disseminate factual information about WebRTC, Google’s WebRTC team has asked &yet – Fippo’s employer – to write a series of publicly available, in-depth, reverse engineering and trace analysis reports. Philipp has agreed to write summary posts outlining the findings and implications for the WebRTC community here at webrtcHacks. This analysis is very time consuming. Making it consumable for a broad audience is even more intensive, so webrtcHacks is happy to help with this effort in our usual impartial, non-commercial fashion.

Please see below for Fippo’s deconstruction of WhatsApp voice calling.

{“editor”: “chad“}

 

Philipp Hancke deconstructs WhatsApp to search for WebRTC

 

After some rumors (e.g. on TechCrunch), WhatsApp recently launched voice calls for Android. This spurred some interest in the WebRTC world with the usual suspects like Tsahi Levent-Levi chiming in and starting a heated debate. Unfortunately, the comment box on Tsahi’s BlogGeek.Me blog was too narrow for my comments so I came back here to webrtchacks.

At that point, I had considered doing an analysis of some mobile services already and, thanks to support from the Google WebRTC team, I was able to spend a number of days looking at Wireshark traces from WhatsApp in a variety of scenarios.

Initially, I was merely trying to validate the capture setup (to be explained in a future blog post) but it turned out that there is quite a lot of interesting information here and even some lessons for WebRTC. So I ended up writing a full fifteen page report which you can get here. It is a long story of packets (available for download here) which will be very boring if you are not an engineer so let me try to summarize the key points here.

Summary

WhatsApp is using the PJSIP library to implement Voice over IP (VoIP) functionality. The captures shows no signs of DTLS, which suggests the use of SDES encryption (see here for Victor’s past post on this).  Even though STUN is used, the binding requests do not contain ICE-specific attributes. RTP and RTCP are multiplexed on the same port.

The audio codec can not be fully determined. The sampling rate is 16kHz, the codec bandwidth of about 20kbit/s and the bandwidth was the same when muted.

An inspection of the binary using the strings tool shows both PJSIP and several strings hinting at the use of elements from the webrtc.org voice engine such as the acoustic echo cancellation (AEC), AECM, gain control (AGC), noise suppression and the high-pass filter.

Comparison with WebRTC  Feature WebRTC/RTCWeb Specifications WhatsApp SDES MUST NOT offer SDES probably uses SDES ICE RFC 5245 no ICE, STUN connectivity checks TURN usage used as last resort uses a similar mechanism first Audio codec Opus or G.711 unclear, 16khz with 20kbps bitrate Switching from a relayed session to a p2p session

The most impressive thing I found is the optimization for a fast call setup by using a relay initially and then switching to a peer-to-peer session. This also opens up the possibility for a future multi-party VoIP call which would certainly be supported by this architecture. The relay server is called “conf bridge” in the binary.

Lets look at the first session to illustrate this (see the PDF for the full, lengthy description):

1. The session kicks off (in packet #70) by sending TURN ALLOCATE requests to eight different servers. This request doesn’t use any standard STUN attributes which is easy to miss.
2. After getting a response the client is exchanging some signaling traffic with the signaling server, so this is basically gathering a relayed candidate and sending an offer to the peer.
3. Packet #132 shows the client sending something to one of those TURN servers. This turns out to be an RTCP packet, followed by some RTP packets, which can be seen by using Wiresharks “decode as” functionality. This is somewhat unusual and misleading, as it is not using standard TURN functionality like send or data indications. Instead, it just does raw RTP on that.
4. Packet #146 shows the first RTP packet from the peer. For about three seconds, the RTP traffic is relayed over this server.
5. In the mean time, packet #294 shows the client sending a STUN binding request to the peer’s public IP address. Using a filter (ip.addr eq 172.16.42.124 and ip.addr eq 83.209.197.82) and (udp.port eq 45395 and udp.port eq 35574)  clearly shows this traffic.
6. The first response is received in packet #300.
7. Now something really interesting happens. The client switches the destination of the RTP stream between packets #298 and #305. By decoding those as RTP we can see that the RTP sequence number increases just by one. See this screenshot:
   

Now, if we have decoded everything as RTP (which is something Wireshark doesn’t get right by default so it needs a little help), we can change the filter to rtp.ssrc == 0x0088a82d  and see this clearly. The intent here is to try a connection that is almost guaranteed to work first (I used a similar rationale in the minimal viable SDP post recently even) and then switch to a peer-to-peer connection in order to minimize the load on the TURN servers.

Wow, that is pretty slick. It likely reduces the call setup time the user perceives. Let me repeat that: this is a hack which makes the user experience better!

By how much is hard to quantify. Only a large-scale measurement of both this approach and the standard approach can answer that.

Lessons for WebRTC

In WebRTC, we can do something similar, but it is a little more effort right now. We can setup the call with iceTransports: ‘relay’ which will skip host and server-reflexive candidates. Also, using a relay helps to guarantee the connetion will work (in conditions where WebRTC will work at all).

There are some drawbacks to this approach in terms of round-trip-times due to TURN’s permission mechanism. Basically when creating a TURN-relayed candidate the following happens (in Chrome; Firefox’s behavior differs slightly):

1. Chrome tries to create an allocation without authentication
2. the TURN server asks for authentication
3. Chrome retries to create an allocation with authentication
4. the TURN server tells chrome the address and port of the candidate.
5. Chrome signals the candidate to the JavaScript layer via the onicecandidate callback. That is two full round-trip times.
6. after adding a remote candidate, Chrome will create a TURN permission on the server before the server will relay traffic from the peer. This is a security mechanism described here.
7. now STUN binding requests can happen over the relayed address. This uses TURN send and data indications. These add the peer’s address and port to each packet received.
8. when agreeing on a candidate, Chrome creates a TURN channel for the peer’s address which is more efficient in terms of overhead.

Compared to this, the proprietary mechanism used by Whatsapp saves a number of roundtrips.

this is a hack which makes the user experience better!

If we started with just relay candidates, then, since this hides the IP addresses of the parties involved from each other, we might even establish the relayed connection and do the DTLS handshake before the callee accepts the call. This is known as transport warmup, it reduces the perceived time until media starts flowing.

Once the relayed connection is established, we can call setConfiguration (formerly known as updateIce; which is currently not implemented) to remove the restriction to relay candidates and do an ICE restart by calling createOffer again with the iceRestart flag set to true. This would trigger an ICE restart which might determine that a P2P connection can be established.

Despite updateIce not being implemented, we can still switch from a relay to peer-to-peer today. ICE restarts work in Chrome so the only bit we’re missing is the iceTransports ‘relay’ which just generates relay candidates. Now the same effect can be simulated in Javascript by dropping any non-relay candidates during the first iteration. It was pretty easy to implement this behaviour in my favorite sdp munging sample. The switch from relayed to P2P just works. The code is committed here.

While ICE restart is inefficient currently, the actual media switch (which is hard) happens very seamlessly.

 

In my humble opinion

Whatsapp’s usage of STUN and RTP seems a little out of date. Arguably, the way STUN is used is very straightforward and makes things like implementing the switch from relayed calls to P2P mode easier. But ICE provides methods to accomplish the same thing, in a more robust way. Using a custom TURN-like functionality that delivers raw RTP from the conference bridge saves some bytes’ overhead for TURN channels, but that overhead is typically negligible.

Not using DTLS-SRTP with ciphers capable of perfect forward secrecy is a pretty big issue in terms of privacy. SDES is known to have drawbacks and can be decrypted retroactively if the key (which is transmitted via the signaling server) is known. Note that the signaling exchange might still be protected the same way it is done for text messages.

In terms of user experience, the mid-call blocking of P2P showed that this scenario had been considered which shows quite some thought. Echo cancellation is a serious problem though. The webrtc.org echo cancellation is capable of a much better job and seems to be included in the binary already. Maybe the team there would even offer their help in exchange for an acknowledgement… or awesome chocolate.

 

{“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 What’s up with WhatsApp and WebRTC? appeared first on webrtcHacks.

WebRTC-based services are seeing new and larger deployments every week. One of the challenges I’m personally facing is troubleshooting as many different problems might occur (network, device, components…) and it’s not always easy to get useful diagnostic data from users.

troubleshooting (Image source: google)

Earlier this week, Tsahi, Chad and I participated at the WebRTC Global Summit in London and had the chance to catch up with some friends from Google, who publicly announced the launch of test.webrtc.org. This is great diagnostic tool but, to me, the best thing is that it can be easily integrated into your own applications; in fact, we are already integrating this in some of our WebRTC apps.

Sam, André and Christoffer from Google are providing here a brief description of the tool. Enjoy it and happy troubleshooting!

{“intro-by”: “victor“}

The WebRTC Troubleshooter: test.webrtc.org (by Google) Why did we decide to build this?

We have spent countless hours debugging things when a bug report comes in for a real-time application. Besides the application itself, there are many other components (audio, video, network) that can and will eventually go wrong due to the huge diversity among users’ system configurations.

By running small tests targeted at each component we hoped to identify issues and create the possibility to gather information on the system reducing the need for round-trips between developers and users to resolve bug reports.

Test with audio problem

What did we build?

It was important to be able to run this diagnostic tool without installing any software and ideally one should be able to integrate very closely with an application, thus making it possible to clearly identify bugs in an application from the components that power it.

To accomplish this, we created a collection of tests that verify basic real-time functionality from within a web page: video capture, audio capture, connectivity, network limitations, stats on encode time, supported resolutions, etc… See details here. 

We then bundled the tests on a web page that enables the user to download a report, or make it available via a URL that can be shared with developers looking into the issue.

How can you use it?

Take a look at test.webrtc.org and find out what tests you could incorporate in your app to help detect or diagnose user issues. For example, simple tests to distinguish application failures from system components failures, or more complex tests such as detecting if the camera is delivering frozen frames, or tell the user that their network signal quality is weak. 

https://webrtchacks.com/wp-content/uploads/2015/04/test.webrtc.org_.mp4

You are encouraged by us to take ideas and code from GitHub and integrate similar functionality in your own UX. Using test.webrtc.org should be part of any “support request” flow for real-time applications. We encourage developers to contribute! 

In particular we’d love some help getting a uniform getStats API between browsers.

test.webrtc.org repo

What’s next?

Working on adding more tests (e.g. network analysis detecting issues that affect audio and video performance is on the way).

We want to learn how developers integrate our tests into their apps and we want to make them easier to use!

{“authors”: [“Sam“, “André“, “Christoffer”]}

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

The post The WebRTC Troubleshooter: test.webrtc.org appeared first on webrtcHacks.