News from Industry

They really truly are.

Whenever someone whines to me that WebRTC isn’t a standard yet so it isn’t ready it makes me laugh. Who the hell cares about such a thing anymore?

The standard is whoever’s got the clout and strength in the market. Ask any marketer – would they want to be able to interact with the carrier’s standardized, federated (and almost non-existent) RCS client to send a message – or would they rather be able to interact with WhatsApp users. The answer, for countries where WhatsApp is popular will be WhatsApp. Marketers don’t care about the standard. The users don’t care about the standard. And most developers don’t care either – as long as the interface is adequately documented.

Enter WebRTC.

No. The IETF hasn’t gone through the motions and finalized the spec yet.

Yes. It might change.

No. I couldn’t care less.

You see, there are already billions of users available to me via WebRTC. There’s source code I can take, compile and run anywhere I want. There’s a vibrant ecosystem of developers and vendors ready to assist. There’s a large and growing number of companies and use cases that make use of WebRTC.

Who am I to say that WebRTC doesn’t exist because someone didn’t put their “standard” stamp on it?

For the last 3 years I’ve been using WebRTC almost daily to communicate with others using various services. I didn’t think for once that this isn’t working because there’s no standard.

Whenever companies band together to create a standard, I begin to question their motive. These days, it usually comes from a point of weakness – a place where there is one (or more) vendors who are strong in a domain and the only way the smaller kids can have a go at it is by specifying a standard to rally all small players to fight the dominant force.

Whenever you see a standard being announced – ask who isn’t there – that’s the one with the power.

In the case of codecs, the MPEG-LA asserts its power and dominance over H.264 and H.265/HEVC for video codecs. Which is why the aomedia was created and announced – to find an alternative codec and win the market back.

The examples are countless.

In the domain of real time communications, everyone were using H.323 or SIP. Then Skype came out, ignoring standards altogether. The industry tried its best to explain that Skype isn’t federated. There’s no standard there. To no avail. So companies (the same ones) tried connecting to Skype, to offer that as part of their service.

The same is happening today with WhatsApp and other social networks. They are so big, that they are the standard.

WebRTC is making the same distinction. It is taking away the hegemony on VoIP from VoIP vendors and putting the weight of this industry on the browser vendors. And now, these vendors are complaining that WebRTC isn’t interoperable. Doesn’t fit their needs. They don’t understand that they are neither in control here nor influencers. They lost control over that part of technology.

This isn’t to say that WebRTC won’t stabilize or get standardized – it is just that it doesn’t matter when it comes to adoption.

Standards? They are for the losers to run after to make sure they get to play the game. The winners don’t really need them.

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

The post Standards are for Losers appeared first on BlogGeek.me.

With no major issues reported, Kamailio is on a good track for releasing stable v4.4.0. Next week a lot of people prepare for Easter, therefore I propose to do the release on Wednesday, March 30, 2016. If new things pop up, the exact date can be adjusted a bit before or after the current proposal.Any new discovered issue should be reported to bug trucker:

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

Help to complete the upgrade guide would be very appreciated:

• https://www.kamailio.org/wiki/install/upgrade/stable-to-devel

A draft list of what is new in 4.4 is already available at:

• https://www.kamailio.org/wiki/features/new-in-4.4.x

Enjoy upcoming v4.4.0 and thank you for flying Kamailio!

An install script for Raspbian and Debian 8 is now available.

This script makes it easy to deploy FreeSWITCH from source on your Raspberry Pi running Raspbian or on a standard machine running Debian Jessie.

Along with installing FreeSWITCH, Verto Communicator and LetsEncrypt are installed and configured. (Note: For LetsEncrypt to be configured you must have a valid public IP and hostname in DNS pointed at the machine.)

To use this script:

wget -O FreeSWITCH-debian-raspbian-installer.sh "https://freeswitch.org/stash/projects/FS/repos/freeswitch/browse/scripts/FreeSWITCH-debian-raspbian-installer.sh?raw"
chmod +x ./FreeSWITCH-debian-raspbian-installer.sh
./FreeSWITCH-debian-raspbian-installer.sh

Once the script completes, you will have FreeSWITCH installed to /usr/local/freeswitch, Verto Communicator in /var/www/html/vc, and if you set up the public IP and DNS name, LetsEncrypt SSL certificates installed.

Most of the accepted speakers at Kamailio World 2016 are now listed on the event website. There are many new speakers, several involved in the early stage of SER-Kamailio development, ready to reveal insides about project evolution. See more details at:

• https://www.kamailioworld.com/k04/speakers/

The range of topics is again very broad, approaching scalability and security of VoIP platforms, WebRTC and VoLTE, various use case for Kamailio as well as integration with related projects such as Asterisk, FreeSwitch or SEMS.The majority of the speakers cover more than a decade of experience for each in real time communication services, being involved in building the past and shaping the future of this field. Another important reason to not miss the event!Join us for celebrating 15 years of development for Kamailio project!

This week the verto communicator link to previewing the camera and microphone in the settings, the ability to play background video while recording inbound video, and a re-design of the banner code in mod_conference.

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we have Doug Waller from Flowroute! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8908 [verto_communicator] Link to preview camera and microphone under settings
• FS-8909 [core] Add feature to play background video while recording inbound video. This feature is suitable to provide some kind of feedback like an animation of a glowing record light etc.
• FS-8921 [mod_conference] Re-designed the banner code

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

• FS-8878 [mod_amr] Fixed compiling without the library installed
• FS-7389 [CentOS] Correct the location of the freeswitch users homedir in the specfile

The following bugs were squashed:

• FS-8811 [mod_local_stream] Fixed a crash caused by dividing by 0
• FS-8905 [core] Fixed a heap buffer overflow issue
• FS-8910 [core] Properly negotiate SDES when receiving an SDP with a=crypto:0 with the wanted crypto suite, we should maintain that crypto tag in the local SDP in order for SDES setup to succeed.
• FS-8914 [core] Fixed mp4 recording cutting off the end in some cases by adding code to mitigate the sync of the end of the file encoding to add some padding to the end
• FS-8761 [core] Fixed a memory leak
• FS-8866 [mod_erlang_event] Fixed memory leaks caused by not destroying session event_hash and events in queue
• FS-8864 [mod_av] Fixed regression to recording to improve file playback
• FS-8868 [mod_av] Set recording app to respect bandwidth set in SDP
• FS-8916 [mod_av] Fixed an issue with newer x264 library returning Encoding Error -1 for newer x264 libraries
• FS-8836 [mod_av] Fixed to support ffmpeg 2.8 and 3.0 in addition to 2.6
• FS-8911 [mod_conference] Fixed a typo in conference_member
• FS-8752 [mod_conference] Fixed a pixelation issue in initial seconds of recording a conference
• FS-8898 [mod_sofia] Log setVariable at debug to easier tell what variables are being set from scripts
• FS-8915 [mod_smpp] Shortened event header name

This year started full engine with members of Kamailio community being present at various events world wide during January and February 2016 – among them:

• ITExpo and Digium Asterisk World in USA, where Fred Posner had a presentation about integration of Asterisk and Kamailio
• Fosdem in Brussels, Belgium, with presentations from Daniel-Constantin Mierla and Olle E. Johansson in the RTC Dev Room and an ad-hoc Kamailio developers meeting to discuss about version 5.0 with Camille Oudout, Federico Cabiddu, Daniel-Constantin Mierla, Giacomo Vacca, Henning Westerholt, Olle E. Johansson, Torey Searle
• Kamailio Development Workshop, Alicante, Spain, coordinated by Daniel-Constantin Mierla
• Call Center World, in Berlin, Germany, with Asipto participating to the event
• Mobile World Congress, in Barcelona, Spain, with our friends from Quobis and Voztelecom around at the show
• WebRTC Barcelona Meetup, co-organized by Quobis and Victor Pascual Avila at University of Barcelona

For the rest of the spring, couple of events will have some of the Kamailio friends engaged:

• CeBIT 2016, March 14-18, in Hannover, Germany
• SIP Master Class, March 28-April 1, in Miami, USA, by Olle E. Johansson
• IETF 95, April 3-8, Buenos Aires, Argentina
• Kamailio World 2016, May 18-20, in Berlin, Germany – celebrating 15 years of Kamailio development

Expect more to be added in the list very soon! Even if you don’t participate to the events, if you are in the area it may be a good opportunity to meet with other Kamailio community members for a chat and few drinks! Announce your availability via Kamailio mailing lists.Also, should you participate to an event related to VoIP, SIP, WebRTC, VoLTE and Kamailio is involved in a way or another, do not hesitate to contact us in order to be listed on the project website.Thank you for flying Kamailio!Looking forward to meeting many of you at Kamailio World in Berlin and other events around the globe!

Had to take this one out of my system.

Just in time for Enterprise Connect, Dave Michels decided to write a post to attract readers. The title? WebRTC is a distraction. It is hard to pin point what’s wrong with the arguments in this one, but most of them are just lacking in knowledge or understanding of this market and how it operates, which is sad – especially coming from Dave who I value very much.

The 4 main reasons why it is a distraction for Dave?

1. Limited support
2. Mobile is what really matters
3. Why bother?
4. WebRTC is dangerous

Let’s try to dismantle each of these so called arguments one by one. Shall we?

#1 – Limited Support

WebRTC today runs on Chrome and Firefox. Microsoft went for ORTC (=WebRTC) and is now “considering” WebRTC as well.

Apple isn’t there, but frankly – I almost never hear complains about Safari not having WebRTC. For some reason, Mac uses have been trained to use Chrome when needed. Furthermore, there’s work been done at Apple about WebRTC, if you care about rumors.

Add to that the fact that no other solution runs on a browser. No other. None. Zilch. They are all getting thrown out from browsers who are stopping support for plugins, Java and probably Flash in the future. And what else have this amount of support anyway?

Now, you can use WebRTC as a desktop app, using a plugin, through Java – or in whatever other manner people use their comms today – so that limited support is wider than any other alternative to date.

#Doesn’t work for you? Don’t use it. But don’t complain that others are using it and are happy about it.

#2 – Mobile is what really matters

To whom?

And while at it, using WebRTC inside an app makes a lot of sense. You shouldn’t care about the technology – just your customers. If they want apps, give them apps. Wrap WebRTC and be done with it.

There’s no other serious media engine for mobile that can be considered – the price point for it will be too prohibitive as well as the investment made.

Mobile is what really matters, which is why Facebook Messenger uses WebRTC. In both mobile and desktop. And is probably larger in deployment, users, minutes, seconds and engagement than anything else the unified communications market has to show for its huge success in its 10+ years of existence.

You know what? I am tired of waiting for unified communications to happen. It is time we take matters into our own hands (with WebRTC) instead of waiting for these large stale companies to move at a reasonable pace and come up with a workable solution.

#3 – Why bother?

Dave says Google no longer cares or invests in WebRTC. I’d say this can’t be further away from the truth.

Google are heavily invested in WebRTC today, based on the number of new features and changes they bring with every new version of Chrome (which happens every 6-8 weeks as opposed to 12-18 months of the slow vendors Dave asks us to put our trust in).

The pace of change for WebRTC is staggering. Nothing comes close to it.

In the span of a year, we’ve seen the echo canceler getting replaced in WebRTC, VP9 introduced, H.264 is underway, ORTC related APIs getting added and that’s just what I can remember off the top of my head (and really took place in the last couple of months only).

Will Google continue at these breakneck speed? Who knows? For now, I’ll take what I am given – especially for free.

#4 – WebRTC is dangerous

Not sure where to start here.

With Unified Communications and its current cadre of vendors, the issues raised by Dave (things you don’t understand and control coupled with hard to patch and upgrade) are a lot more dangerous.

Do you know when your PBX was upgraded last for that critical security issue it had? Do you even know if it was upgraded at all? What about the router you have at home? This FUD about security in WebRTC wreaks of misundersanding of the technology.

We are living in a world where we move everything to the cloud and our mobile devices. In such a world, security needs to be taken seriously. Not by introducing stupid proprietary solutions that are hard to manage or maintain, but rather by introducing cloud based solutions that can upgrade and update automatically. Ones where security is taken into account from the ground up and not as a bolt on feature to show the buyer.

WebRTC has all that and more, so if you think WebRTC is dangerous – sure it is. To anyone who is trying to compete against the companies using it. In the long run, resistance is futile.

The truth of it

Google doesn’t care about the unified communication market when it comes to WebRTC.

They just couldn’t care less if this does headaches to Cisco or Polycom or anyone else in this market. The way vendors are bitching about WebRTC shows how they view VoIP and UC as their own, as if they are entitled to what goes on there and as if someone needs to think about their business models and legacy deployments so they don’t get hurt.

Get over it.

WebRTC is a huge distraction to those who aren’t built to embrace it. They are going to fade away. Just a matter of time. And Dave – you won’t need to wait much longer for it to happen.

 

[show promotion title=”strategy-session”]

The post WebRTC is a Distraction appeared first on BlogGeek.me.

The GIT branch 4.4 was created, it will host the Kamailio release series 4.4.x. To get this branch from GIT, you can use:git clone https://github.com/kamailio/kamailio.git kamailio
cd kamailio
git checkout -b 4.4 origin/4.4Notes about installing Kamailio from this branch are available at:

• https://www.kamailio.org/wiki/install/4.4.x/git

Hopefully in about two weeks or so the full release of 4.4.0 will be out.From now on, any corresponding fix has to be pushed first to master branch and then cherry-picked to branch 4.4. No new features can get in branch 4.4. Enhancements to documentation or helping tools are still allowed.

written by  Algis Salys

Original post can be found here: http://www.algissalys.com/how-to/freeswitch-1-7-raspberry-pi-2-voip-sip-server

Installing, Compiling and running FreeSWITCH on the Pi 2

The long and awaited for… FreeSWITCH 1.7 running on a Raspberry Pi 2 guide.

We’ll be using the latest (at the time of this writing) Raspbian image 2015-11-21-raspbian-jessie.img on a Raspberry Pi 2.  Thanks to the awesome FreeSWITCH team at https://freeswitch.org/ especially Brian West, Ken Rice, and William King for all of their efforts with the FreeSWITCH project and helping me to get this working.

 

Raspbian running on your Pi

You’ll first need to have the Raspbian image running on your Raspberry Pi.
 

Installing Dependencies

In order to compile FreeSWITCH and it’s modules, you need to install some dependencies.

Update your Pi packages

sudo apt-get update && sudo apt-get upgrade

The following packages were installed and I was able to successfully compile FreeSWITCH with the default modules in the modules.conf file, that were selected when I cloned the git master branch.  My default modules.conf of enabled modules is located at the bottom of this page for reference.  Note, If you enable/uncomment other modules in the modules.conf that gets created after running ./bootstrap.sh -j command below, you may require some additional dependencies.

sudo apt-get install autoconf automake devscripts gawk libjpeg-dev libncurses5-dev libtool-bin python-dev libtiff5-dev \
libperl-dev libgdbm-dev libdb-dev gettext libssl-dev libcurl4-openssl-dev libpcre3-dev libspeex-dev libspeexdsp-dev \
libsqlite3-dev libedit-dev libldns-dev libpq-dev libsndfile-dev libopus-dev liblua5.1-0-dev

These packages are required, but were already installed on my Raspbian (here for reference)

sudo apt-get install g++ git-core make pkg-config

These packages are required, but Installed by other packages. (here for reference)

sudo apt-get install libjpeg62-turbo-dev libtool

 

Clone git FreeSWITCH Repo

You can clone to any directory, but we’ll use the directory /usr/local/src and need to make it r/w to our user ($USER is a system variable, which will = the current user, pi in our case)

sudo chown $USER /usr/local/src

change to that directory

cd /usr/local/src

Clone the git repo (master branch)

git clone https://freeswitch.org/stash/scm/fs/freeswitch.git

 

Compile FreeSWITCH on the Raspberry Pi 2

Goto the FreeSWITCH source directory

cd /usr/local/src/freeswitch/

Confirm master branch

git checkout master

Returned: Already on ‘master’ Your branch is up-to-date with ‘origin/master’.

Build config files

./bootstrap.sh -j

Now we’re at the point where you can enable/disable custom modules to compile along with the FreeSWITCH framework.  In this build, I left all the modules in modules.conf default (My enabled modules in modules.conf file is located below for reference).  You can always compile additional modules at a later point when they are needed.  I recommend leaving the modules.conf file alone if this is your first time compiling, you can read more about it below in the section Enabling additional Modules in modules.conf

Run configure

./configure -C

Make (use jobs flag -j set to 3) in attempt to speed things up (this took ~30 minutes)

make -j3

Success!

Install FreeSWITCH

sudo make install

The FreeSWITCH binary is now located in the /usr/local/freeswitch/bin directory.

 

Compile sounds for FreeSWITCH

make cd-sounds-install cd-moh-install -j3

Goto FreeSWITCH bin directory

cd /usr/local/freeswitch/bin

Start FreeSWITCH

*It is advisable to skip this step if you are configuring FreeSWITCH to start up automatically at boot, as it creates files that are needed during run-time and it will fail when you use the init script/systemd to run it automatically. 

./freeswitch

check to see if it is running (just to make sure it compiled ok to this point)

ps aux | grep "freeswitch"

Auto Run FreeSWITCH at boot

We’ll add FreeSWITCH as a user, change a few permission, copy the startup script and test the auto start of Freeswitch.

Create FreeSWITCH user, add password and set permissions

cd /usr/local/ sudo adduser --quiet --gecos "FreeSWITCH Voice Platform" --ingroup daemon freeswitch sudo chmod -R ug=rwx,o= /usr/local/freeswitch/ sudo chmod -R u=rwx,g=rx /usr/local/freeswitch/bin/* sudo chown -R freeswitch:daemon /usr/local/freeswitch

 

Create link from source build to expected locations

sudo ln -s /usr/local/freeswitch/bin/freeswitch /usr/bin/freeswitch sudo ln -s /usr/local/freeswitch/bin/fs_cli /usr/bin/fs_cli sudo mkdir /etc/freeswitch sudo ln -s /usr/local/freeswitch/conf/freeswitch.xml /etc/freeswitch/freeswitch.xml sudo chmod ug=rwx,o= /etc/freeswitch sudo chown freeswitch:daemon /etc/freeswitch sudo mkdir /var/lib/freeswitch sudo chmod -R ug=rwx,o= /var/lib/freeswitch sudo chown freeswitch:daemon /var/lib/freeswitch sudo cp /usr/local/src/freeswitch/debian/freeswitch-sysvinit.freeswitch.default /etc/default/freeswitch sudo chmod ug=rw,o= /etc/default/freeswitch sudo chown freeswitch:daemon /etc/default/freeswitch

Create working log directory

sudo mkdir /var/log/freeswitch sudo chmod -R ug=rwx,o= /var/log/freeswitch sudo chown freeswitch:daemon /var/log/freeswitch

Copy the start-up script to /etc/init.d/ directory and change permissions

sudo cp /usr/local/src/freeswitch/debian/freeswitch-sysvinit.freeswitch.init  /etc/init.d/freeswitch sudo chmod u=rwx,g=rx,o= /etc/init.d/freeswitch sudo chown freeswitch:daemon /etc/init.d/freeswitch sudo update-rc.d freeswitch defaults

FreeSWITCH will now auto start when the Raspberry Pi boots up

 

Reboot to confirm everything is working

sudo reboot

Check the status of FreeSWITCH

sudo /etc/init.d/freeswitch status

Manually start FreeSWITCH (for reference)

sudo /etc/init.d/freeswitch start

You may also want to confirm FreeSWITCH is listening on port 5060 (for troubleshooting)

netstat -ln

 

Register to Extension 1000

FreeSWITCH has a few default extensions.  As a simple test to see if FreeSWITCH is working, we’ll register a sip client to extension 1000, with the default password is 1234.

Change to user FreeSWITCH for editing of files or logging into fs_cli, since we have changed permissions of the directories in the above steps.

su freeswitch

Log into FreeSWITCH command line to assist in troubleshooting (type /exit to exit the FreeSWITCH command line)

fs_cli

Using your favorite SIP client on the same network as the FreeSWITCH server, register with extension 1000

• SIP Proxy/Server = <raspberry-pi-ip-address>
• SIP Port = 5060
• User ID/Name = 1000
• Password/Authentication = 1234

While you are logged into the fs_cli, turn on sip trace debug

// sofia global siptrace on

Then from your SIP client, attempt to register, viewing the SIP trace can greatly assist in troubleshooting.

Once you are registered, try to call some test extensions

• 9198 = tetris music
• 9197 = mw tone
• 9196 = echo test
• 5000 = Default IVR

 

9198 was called from a sip client

 

References:

Raspberry Pi Model:

Raspberry Pi 2 Model B

Raspberry Pi Image:

2015-11-21-raspbian-jessie.img

cat /etc/*-release:

Raspbian GNU/Linux 8 (jessie)

Kernel (uname -ro):

4.1.19-v7+ GNU/Linux

FreeSWITCH Version:

FreeSWITCH Version 1.7.0+git~20160308T015910Z~b7227465b6~32bit (git b722746 2016-03-08 01:59:10Z 32bit)

 

Clean Git Folder (bring back to last commit state, deletes all untracked files, directories)

git clean -d -x -f

Get commit hash (only here for reference, on the specific commit that I used for compiling)

git log -1 --format="%H"

   Returned: b7227465b6943588bf7d1a1e61e0fcc829d6f43e

 

https://freeswitch.org/confluence/display/FREESWITCH/Debian+7

 

Who do you go to with your WebRTC needs?

That moment you realized you selected the wrong vendor

There are now over 20 vendors out there offering WebRTC APIs in the cloud.

20.

How the hell do you decide which one to pick for your service?

This question was rather “simple” to answer, but it is getting harder.

Two months ago, Facebook decided to shutdown Parse. This is something that should not be taken lightly.

In 2013, Facebook acquired Parse. Parse was a MBaaS(mobile backend as a service platform). If you want to build a mobile app, you’ll be needing some backend in high probability – a place to store account information, maybe sync data between users, etc. MBaaS does exactly that, and in this domain, Parse was one of the bigger platforms. They had around 60,000 applications on their platform at the time of acquisition – not something to take lightly.

Facebook didn’t acquire Parse for its great technology but rather for its developer ecosystem – for its popularity. In the two years since, Facebook invested more in the platform – just so it can close it.

In the context of communication API platforms with WebRTC capabilities, what we’ve seen so far are two kinds of acquisitions:

 

1. Acquiring a technology – Snapchat acquiring AddLive, Requestec getting acquired by Blackboard are such examples. So is Crocodile RCS acqisition by Acision and then Acision wrapped into Xuar
2. Acquiring a developer ecosystem – TokBox’s acquisition by Telefonica and the recent Cisco acquisition of Tropo

Will Cisco decide in a year or two to shutter down Tropo if it doesn’t bring the traction it wants or if it serves its purpose of getting enterprises to adopt Cisco Spark?

Would Telefonica stop investing in TokBox? Highly unlikely after 3 years, but who knows? I wouldn’t have bet on Facebook shedding Parse.

The thing about Parse is that Facebook didn’t even spun it off again – or sold it. It just closed the service. More akin to how Snapchat treated its own acquisition of AddLive.

Kin Lane explains nicely the false expectations people had from Facebook and Parse:

There is no basis for believing a platform or API will ALWAYS be there, no matter what you are promised. Companies go out of business, get acquired, and in this fast paced tech climate, companies are always looking to deliver the latest product, and features. Everything in the space points to disruption, change, and evolution, where the hell did we get the idea these services shouldn’t go away?

What can we deduce?

1. Platforms with large ecosystems aren’t impervious to being taken off market. TokBox may get shuttered. Twilio might get acquired
2. In the build vs buy decision of WebRTC, using a platform doesn’t mean write once and forget. You may need to update your code, switch vendors, etc. – be ready for it

–

As I start working on another update for my Choosing a WebRTC API Platform report, I will take the time to research the reasons for vendors selecting the less popular API platforms – what makes them take that plunge. If you are such a vendor – contact me.

Until this new update gets released (April-May timeframe), there’s a $700 USD discount on the report (which includes a 1-year update period).

The post Developer Ecosystem Acquisitions Makes Build vs Buy Decisions Harder appeared first on BlogGeek.me.

This week we had some fun new updates to mod_avmd and began the process of moving libvpx into tree. This is a big change and should be carefully noted. There were too many issues associated with maintaining and updating it so the developers decided to instead link to a static version in tree.

Join us 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-8852 [mod_avmd] Now we use predefined table length instead of hardcoded computation in stop condition of for loop
• FS-8854 [mod_avmd] Now all members of buffer are initialized in INIT_CIRC_BUFFER macro
• FS-8867 [mod_vpx][core] Build using in tree libvpx, vpx no longer optional and does not use system libvpx due to issues with having to update it, frequently conflicting with system libraries, now we link to the static in tree version instead. Also, mod_vpx is now a core module instead of a loadable module, so mod_vpx.so will no longer be built
• FS-8876 [core] Add CPU affinity to each Video thread in a round robin fashion.
• FS-8878 [mod_amr] Make AMR NB transcode in octet-align mode (when compiled with HAVE_AMR)

The following bugs were squashed:

• FS-8856 [mod_callcenter] Updating a member fails because the agent_dispatch_thread removed the member just before it tried to update it.
• FS-8842 [verto] Fixed an issue where calls created using the originate command lose audio when left on hold for 45 seconds
• FS-8877 [verto] Fixed an issue caused by Chrome Canary removing some audio mandatory constraints that break Verto
• FS-8862 [core] Auto adjust on passthru
• FS-8871 [configuration] Fixed encoding “&” and “<” symbols in vanilla configuration
• FS-8879 [mod_sofia] Fixed SIP UPDATE and attended transfer for ipv6
• FS-8864 [core][mod_av] Improve video file playback

Blake Priddy joins the ClueCon Weekly team to talk experiences deploying FreeSWITCH in rural public schools and some of the technical and political challenges he faced.

The scripts for integrating FreeSWITCH with Sevana AQuA software are now available at github: https://github.com/voxserv/fsqa

More details on what they are doing are available in this older post: https://txlab.wordpress.com/2015/06/02/quality-assurance-for-voip-calls-2/

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

Digital Voice Teleconferencing overt the ARPAnet 1978

This week we had the addition of CPU affinity to each video thread in a round robin fashion and a logo image and parameters were added to mod_local_stream.

Join us 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-8876 [core] Add CPU affinity to each video thread in a round robin fashion.
• FS-8903 [mod_local_stream] Add a logo image and some parameters to control its behavior

The following bugs were squashed:

• FS-8884 [build] Add –disable-libyuv and –disable-libvpx configure arguments to disable building these libraries on FreeBSD and smartos
• FS-8891 [RTP] Fix for T38 fax failing between 2 freeswitch boxes with high cpu usage
• FS-8354 [mod_conference] Fix for G722 audio issues
• FS-8811 [core] Fixed an intermittent crash
• FS-8851 [core] Fix for codec for recording negotiated before call answered
• FS-8904 [core] Fix memory leak in img_write_text
• FS-8905 [core] Fixed for a heap buffer overflow detected by ASAN in the img patch/img overlay and it may show up as a rare segfault when using video with banners
• FS-8864 [core] Set video ready on first push to avoid catch 22 on some video files

It’s the money stupid.

We all love to hate the model of an MCU (besides those who sell MCUs that is).

There are in general 3 main models of deploying a multiparty video conference:

1. Mesh – where each participant sends his media to all other participants
2. MCU – where a participant is “speaking” to a central entity who mixes all inputs and sends out a single stream towards each participant
3. SFU – where a participant sends his media to a central entity, who routes all incoming media as he sees fit to participants – each one of them receiving usually more than a single stream

I’ve taken the time to use testRTC to show the differences on the network between the 3 multiparty video alternatives on the network.

To sum things up:

• Mesh fails miserably relatively fast. Anything beyond 3 isn’t usable anywhre in a commercial product if you ask me
• MCU seems the best approach when it comes to load on the network
• SFU is asymmetric in nature – similar to how ADSL is (though this can be reduced, just not in Jitsi in the specific scenario I tried)

This being the case, how can I even say that SFU is the winning model for WebRTC?

It all comes down to the cost of operating the service.

Here’s what an MCU does in front of each participant:

How media gets processed by an MFU

Here’s what an SFU does in front of each participant:

How media gets processed by an SFU

To make things easy for you, I’ve marked with colors varying from green to red the amount of effort it puts on a CPU to deal with it.

The most taxing activity in an MCU is the encoding and decoding of the video. With the current and upcoming changes in video and displays, this isn’t going to lessen any time soon:

• Google just switched to VP9, which takes up more CPU
• 4K displays and cameras are becoming a reality. 8K is being discussed already. This means 4 times the resolutions of full HD

If anything – things are going to get worse here before they get any better.

It is no surprise then that MCUs scale on single machines in the 10’s of ports or low 100’s at best; while SFUs scale on single machines in the 1,000’s of ports or low 10,000’s.

Which brings us to two very important aspects of this:

1. Price per port, where an SFU will ALWAYS be lower than MCU – by several factors
2. Deployment complexity

The first reason is usually answered by people that if you want quality – you need to pay for it. Which is always true. Until you start reminding yourself that video calling today is priced at zero for the most part.

The second reason isn’t as easy to ignore. If you aim for cloud based services needing to serve multiple customers, your aim is to go to 10,000 or more parallel sessions. Sometimes millions or more. Here would be a good time to remind you that WhatsApp crossed the billion monthly active users and most messaging services become interesting when they cross 100 million monthly active users.

With such numbers, placing 100 times more machines to support an MCU architecture instead of an SFU one is… prohibitive. There are more costs that needs to be factored in, such as power consumption, rack space and higher administration costs.

The end result?

An SFU model is by far the most popular deployment today for WebRTC services.

Does it fit all use cases? No

Will it fit your use case? Maybe

Do customers care? No

 

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

The post WebRTC Multiparty Video Alternatives, and Why SFU is the Winning Model appeared first on BlogGeek.me.

  Dear Slack, There has been quite some buzz this week about you and WebRTC. WebRTC… kind of. Because actually you only do stuff in Chrome and your native apps: I’ve been there. Launching stuff only for Chrome. That was is late 2012. In 2016, you need to have a very good excuse to launch something […]

The post Dear Slack: why is your WebRTC so weak? appeared first on webrtcHacks.

Kamailio SIP Server v4.3.5 stable is out – a minor release including fixes in code and documentation since v4.3.4. The configuration file and database schema compatibility is preserved.Kamailio (former OpenSER) v4.3.5 is based on the latest version of GIT branch 4.3, therefore those running previous 4.3.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.3.x.Resources for Kamailio version 4.3.5Source tarballs are available at:

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

What is new in 4.3.x release series is summarized in the announcement of v4.3.0:

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

Thanks for flying Kamailio and looking forward to meeting many of you at Kamailio World Conference 2016!

It is a waste of time.

I’ve heard it more than one.  Security threats in WebRTC make it a bad alternative. You have MITM (man in the middle) attacks on it. It leaks IP addresses. You can screen share without the user’s knowledge. The list goes on.

It isn’t the first time I write about WebRTC security and it still pisses me off when I see such answers on Quora:

The WebRTC plugin (which means Web Real-Time Communication) allows to conduct audio and video teleconferencing just in a browser without any additional software installed. However, it reveals the true IP address. How to disable WebRTC in various browsers.

A few things about that one:

1. WebRTC isn’t a plugin…
2. Why would you want to disable it?

If you trust Skype or any other VoIP or messaging app more, then you are in for a big surprise.

I read the above Quora answer on the same day I read Troy Hunt’s piece on controlling a Nissan remotely – one that… well… isn’t YOUR Nissan.

The things Nissan got wrong here includes:

• Having cars get sequential serial numbers, so they are easy to guess
• Having an undocumented backend API that controls cars remotely – with no authentication on it

I don’t want to go into additional measures they could have added such as geolocation for the origination of the command or throttling to bar hackers from going berserk on their car fleet.

What would a leaked IP address on a WebRTC session in a browser do exactly compared to such stupidity?

The bane of security is developers and processes.

IOT (Internet of Things) is going to bring us many more such stories. That’s because it is based on developers and they make mistakes. Increase that a thousand fold, put it in a heating market where features and gadgets take center role, pushing back privacy and security – and you get hackable cars.

Telephony and video conferencing systems or old are devices sitting in networks. They need to “interoperate”. They have IT people who like controlling how things get deployed and updated. Are you sure these have been configured to work encrypted (I am sure most deployments aren’t). Are you sure the IT person really upgraded to the latest version that patches a bunch of security flaws?

And while we are talking about communications. The router you have at home that gives you WiFi on one end and connects you to the internet via ADSL or whatever on the other end – when did you last upgrade its firmware? Did you ever updated its password from the default? Is your service provider taking care of these things for you by any chance?

Here’s why:

• It is encrypted. By default. And there’s no way to remove that encryption from occurring (people complain about that one as well – go figure)
• It gets updated every 6-8 weeks with your browser. That update includes security patches when they are found
• It now forces (at least on Chrome) the sites using it to run over HTTPS instead of HTTP (did we say encryption?)
• It has permission mechanisms around camera and microphone access
• It has stricter permission mechanisms around screen sharing (white listing and extensions)
• Whenever someone peeps about security – it gets discussed and potentially updated in the implementation. Which gets to your browser in… 6-8 weeks
• Being a part of Chrome and other browsers means security gets front row and is prioritized properly

Yes. Developers can still do stupid things on top of WebRTC and botch it all, but that’s true about that snazzy new car you just bought or the smart TV that looks at you and hears what you say.

What more do you want?

If I wanted to hack you, WebRTC would be the last place I’d start.

The post Stop Whining about WebRTC Security Threats appeared first on BlogGeek.me.

No.

Now that we got that one out of the way, lets see why the recent announcement from Google and the GSMA isn’t relevant to WebRTC.

On February 22, the GSMA issued a press release titled Global Operators, Google and the GSMA Align Behind Adoption of Rich Communications Services. The subheading sums up the message:

Operators align on universal RCS profile; Google to provide RCS messaging client in Android

I was asked if this kills WebRTC – and the efforts of companies invested in WebRTC already.

There are two ways to view these questions:

1. People don’t understand what WebRTC (or RCS) is
2. People are just afraid of Google deciding on a whim to close WebRTC as just another experiment (think Google Reader, Wave, Buzz and a lot of other technologies and services in the Google graveyard)

Nothing really changed

I’ve written about the Google’s acquisition of Jibe. Nothing changed since then. I then assumed that Telcos will accept this and adopt it.

The recent press release shows that that has happened – at least by the GSMA. Time will tell which of the carriers will join this initiative.

I am not sure it will save RCS, but as I still believe it is the only alternative that brings RCS any future.

How is that different than WebRTC?

When I think about RCS, I think signaling, messaging and federation. It is about serving all people with a mobile device.

When I think about WebRTC, I think about media processing, business enablement. business processes and customizaton.

RCS isn’t about to win back the world in storm. It won’t beat WhatsApp or Facebook Messenger or WeChat or any of these other players any time soon. And if it does, it won’t be useful for most use cases I’ve seen with WebRTC anyway.

While both RCS and WebRTC can now be said to be promoted by Google, they aren’t serving the same needs in Google.

Will Google stop supporting WebRTC?

I don’t think that’s a possibility in the foreseeable future. How much investment will it put on WebRTC is another topic.

WebRTC is now part of HTML5. It is implemented by Google, Mozilla and Microsoft (don’t start with me on ORTC here please). Rumors abound about Apple, but I don’t really care at this point.

Google dropping WebRTC means back to plugin realm for things like Google Hangouts. And for things like RCS.

When you want to implement an RCS client on a browser, and initiative a voice call through it. From inside the browser. What are you going to use for it? Flash?

Google needs to continue its investment in WebRTC as long as it feels it needs Hangouts as part of its strategy. Messaging is  important to Google – check out their investments and acquisitions around messaging vendors. To that end, it can’t just drop WebRTC.

If, on the other hand, WebRTC gets to a point where it is good enough for Google, its investment in it may change. Until all browsers support WebRTC reasonably – there’s no threat of this happening.

The post Does Google’s Support of RCS Changes Anything for WebRTC? appeared first on BlogGeek.me.