News from Industry

Huawei ME909s-120 is the newest modem of Huawei LTE/UMTS family, and it is sold for around $70 at TechShip.se and at Aliexpress.

The modem is immediately recognized as CDC Ethernet device in Debian 8 kernel, and is visible as usb0 interface. In the scripts below, the ttyUSBx serial ports are aliased to ttyWWANxx, and usb0 is renamed to lte0, in order to avoid any naming conflicts with other devices, and also to avoid possible name changes  due to a kernel upgrade.

cat >/etc/udev/rules.d/99-huawei-wwan.rules <<'EOT' SUBSYSTEM=="tty", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", SYMLINK+="ttyWWAN%E{ID_USB_INTERFACE_NUM}" SUBSYSTEM=="net", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", NAME="lte0" EOT cat >/etc/chatscripts/sunrise.HUAWEI <<'EOT' ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR TIMEOUT 10 '' ATZ OK 'AT+CFUN=1' OK 'AT+CMEE=1' OK 'AT\^NDISDUP=1,1,"internet"' OK EOT cat >/etc/chatscripts/gsm_off.HUAWEI <<'EOT' ABORT ERROR TIMEOUT 5 '' AT+CFUN=0 OK EOT cat >/etc/network/interfaces.d/lte0 <<'EOT' allow-hotplug lte0 iface lte0 inet dhcp     pre-up /usr/sbin/chat -v -f /etc/chatscripts/sunrise.HUAWEI >/dev/ttyWWAN02 </dev/ttyWWAN02     post-down /usr/sbin/chat -v -f /etc/chatscripts/gsm_off.HUAWEI >/dev/ttyWWAN02 </dev/ttyWWAN02 EOT
Filed under: Networking Tagged: 3G, GSM, pcengines

Kamailio SIP Server v4.3.6 stable is out – a minor release including fixes in code and documentation since v4.3.5. The configuration file and database schema compatibility is preserved.Kamailio (former OpenSER) v4.3.6 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.6Source tarballs are available at:

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

Detailed changelog:

• http://www.kamailio.org/pub/kamailio/4.3.6/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.6/

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/

Note: the branch 4.3 is the previous stable branch. The latest stable branch is 4.4, at this time with v4.4.2 being released out of it. The project is officially maintaining the last two stable branches, these are 4.4 and 4.3. Therefore an alternative is to upgrade to latest 4.4.x – be aware that you may need to change the configuration files and database structures from 4.3.x to 4.4.x. See more details about it at:

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

Thanks for flying Kamailio and enjoy the summer holidays!

Sometimes there’s a need to reset a GSM module on a Yeastar GSM gateway. For example, SIM cards of one of our providers get into faulty state every few weeks, and only a reset helps.

The GSM module can either be rebooted via Web GUI, or from the Asterisk console. But the Asterisk console can only work on the same host where the asterisk daemon runs, so you need to make an SSH connection into the Yeastar box to do that. Also it’s impossible to save a public SSH key in a Yeastar box, so only password authentication works.

Ansible is a powerful toolset for managing remote hosts, and it appears to be perfectly suitable for managing the GSM gateways.

Ansible 2.x is available for Debian 8 from jessie-backports repository. There are some important differences from version 1.7 that is installed from default repositories, and in particular, ansible_host and ansible_port variables.

After installing Ansible, uncomment host_key_checking = False in /etc/ansible/ansible.cfg , so that the SSH client stops verifying the remote host SSH signatures. Otherwise the host signatures should be listed in your known_hosts file.

The following lines in /etc/ansible/hosts list your GSM gateways:

[yeastar] gsm01 ansible_host=192.168.99.66 ansible_ssh_pass=kljckhjeswvdfesv gsm02 ansible_host=192.168.99.67 ansible_ssh_pass=dmnckjfvrever gsm03 ansible_host=192.168.99.68 ansible_ssh_pass=dcmnkljdfhfe [yeastar:vars] ansible_user=root ansible_port=8022

If you use the same root password on all devices, the password variable can be moved to the group variables.

Ansible uses SFTP for ad-hoc commands, and SFTP is not available on Yestar gateways. But the raw module works just fine, and resetting a GSM module can now be done with a simple command from your management server:

ansible gsm03 -m raw -a '/bin/asterisk -rx "gsm power reset 2"'

 

Filed under: Networking Tagged: GSM, linux, pbx, sip, voip

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

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

What is new in 4.4.x release series is summarized in the announcement of v4.4.0:

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

Thanks for flying Kamailio!

This week there was an improvement to mod_spandsp with a channel variable added to make spandsp_start_tone_detect easier to use from the dialplan or embedded scripts

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-9287 [mod_spandsp] Add channel variable to make spandsp_start_tone_detect easier to use from dialplan/embedded scripts.

The following bugs were squashed:

• FS-9283 [mod_hiredis] Fixed an issue with using hiredis_raw on channels without media such as an originate
• FS-9292 [core] Fixed a core dump while playing videos or showing images usually with a high number of callers
• FS-9296 [mod_httapi] Fixed video support
• FS-9297 [mod_sofia] Fixed multiple crashes from passing invalid null values in sofia.conf

This week we had a new feature in mod_sofia. A new parameter was added, renegotiate-codec-on-hold, for proxy hold when proxy media and proxy mode are disabled; its similar to proxy-refer.

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-9192 [mod_sofia] Added renegotiate-codec-on-hold parameter for proxy hold when proxy media and proxy mode are disabled; its similar to proxy-refer

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

• FS-9263 [build] Attempting to find the proper lua5.2 version on openbsd
• FS-9260 [build] Fixed make detection to not fail on openbsed,  fixed libtoolize detection to attempt to find libtoolize the same version as specified libtool, and added -ltermcap for openbsd so it can correctly link to libedit

The following bugs were squashed:

• FS-9244 [core] Fixed debug lines
• FS-9265 [core] Fixed an issue with receiving INCOMPATIBLE_DESTINATION when there is no RTCP
• FS-9271 [mod_conference] Fixed a segfault trying to record a canvas that does not exist
• FS-9267 [mod_cv] Fixed an issue where the VPX codec returns the same image to the core when doing repeated decoding. Updates to that image match the updates to the stream so if a media bug modifies the image between key frames it messes up the picture until the next key frame is received.

Hardware acceleration for video codecs is almost mandatory.

VP9 is getting a performance boost

There are three things that keep VP8 in the game when compared to H.264:

1. It was the only video codec in Chrome for WebRTC in the last 5 years, giving it a headstart in deployments
2. H.264 while available in mobile chipsets isn’t always accessible for the developer (or works as it should when it is accessible)
3. VP8 and H.264 are rather old now, so software implementations of them are quite decent

 

With VP9, the main worry was that it will be left behind and not get the love and attention from chipset vendors – leading it to the same fate as VP8 – abysmal, if any, hardware acceleration support. It is probably why Google went to great lengths to make it running on YouTube so soon and is publicizing its stats all the time.

This worry is now rather behind us. Recent signs show some serious adoption from the companies that we should really care about:

#1 – ARM

Mobile=ARM

Without checking stats, I’d say that 99% or more of all smartphones sold in the past 5 years are based on ARM.

If and when ARM decides to support a feature directly, that brings said feature very close towards world domination in future smartpones.

Which is somewhat what happened last week – ARM announced its Mali Egil Video Processor with VP9 acceleration.

Here’s a deck they shared:

ARM Mali "Egil" technical preview from Phil Hughes

Being farther away from chipsets than I were 5 years ago, it is hard for me to say if this is an integral part of an ARM processor, but I believe that it isn’t. It is an add-on component that takes care of video processing that chipset vendors add next to their ARM core. They can source the design from ARM or other suppliers – or they can develop their own.

Not sure how popular the ARM alternative is for video processing, but they have the advantage of being the first alternative for any chipset vendor (hell – they already source the ARM core itself, so why not bundle?). Which also means every other vendor needs to match up to their feature set – and improve on it.

Now that VP9 encode/decode capabilities are front and center in the ARM Mali Egil, it has become a mandatory checkmark for everyone else as well.

#2 – Intel

If ARM is the king of mobile, then Intel rules the desktop.

As with ARM, I haven’t been following up on Intel CPU acceleration lately. And as with ARM, it was Fippo who got my attention with this link here: the new Intel Media SDK.

For those who don’t know, Intel is providing several interesting software packages that make direct use of its chipset capabilities. Especially when it comes to optimizing different types of workloads. The Intel IPP and Media SDKs handle media related processing, and are quite popular by low level developers who need access to such facilities.

From the release page itself:

With this release we are happy to announce new full hardware accelerated support for HEVC and VP9.

• HEVC Main 10 (10-bit) encoder and decoder support
• VP9 8-bit and 10-bit decoder support

So… HEVC (=H.265) has encode and decode while VP9 only has decode support.

Probably because HEVC has been in the works for a lot longer than VP9, but there’s hope still.

#3 – Alliance of Open Media

The Alliance of Open Media. I’ve published a recent update on the alliance.

Intel was there from the start. The recent additions include ARM, AMD and NVIDIA.

I am sure additional chipset vendors will be joining in the coming months – there seems to be a ramp up in memerships there, with Ateme and Adobe added to their logos just last week.

While the alliance is about what comes after VP9, it is easy to see how these vendors may sway to using VP9 in the interim.

The Future

The future is most definitely one of royalty free video codecs. We’ve got there with voice, now that we have OPUS (though Speex and SILK were there before to pave the way). We will get there with video as well.

Coding technologies need to be accessible and available to everyone – freely – if we are to achieve Benedict Evans’ latest claims: Video is the new HTML. But for that, I’ll need another post.

 

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

The post VP9 Hardware Acceleration is Real appeared first on BlogGeek.me.

Our good old Samsung Galaxy Tab 3 7.0 Kids Tablet has finally died after over 3 years of everyday heavy use, so I needed a new solution. So far, here is the best combination that I could find:

This silicon case for Samsung Galaxy TAB A 7″ SM-T280 is a solid and protective piece, and it allows the kids hold the tablet with their little hands without slipping off. It also works as a stand, so it’s very convenient for watching videos.

The Samsung Galaxy Tab A (7″, 8GB, Metallic Black) fits perfectly into the protective case. The tablet is coming with preinstalled “Kids Mode” application, which is pretty neat, but very restrictive: the kid can watch only the videos on SD card that you mark as safe, and YouTube is not available. You can install kid-safe YouTube wrappers from the Play market, but it’s a bit too much hassle to my taste.

So, instead of the Samsung Kids Mode, I installed Kids Place by kiddoware. With a little payment, you get a good child protection mode, and you can enable YouTube directly on the child screen. The payment is also transferable to other devices under your account.

Also, this portable Bluetooth speaker works as a stand for a tablet, and it produces a much better sound than the tablet’s own speaker. Unfortunately the silicon case is too thick for this stand, but it’s a minor issue, and the speaker can easily be placed behind the tablet.

 

Filed under: Hardware Tagged: kids

Bridging in Asterisk 13:
Over the past several years, major architectural changes have been
done in the core of Asterisk to facilitate better APIs and
functionality. Matt Jordan will talk about one of these core
improvements, the Bridging Framework, and how it evolved during the
development of Asterisk 13.

Dealing with multi-party video infrastructure can be pretty daunting. The good news is the technology, products, and standards to enable economical multiparty video in WebRTC has matured quite a bit in the past few years. One of the key underlying technologies enabling some of this change is called simulcast. Simulcast has been an occasional sub-topic […]

The post Optimizing video quality using Simulcast (Oscar Divorra) appeared first on webrtcHacks.

In my particular case, there are two physical USB devices that are represented as TTY devices in the kernel: a Gobi2000 3G modem, and a 4-port USB-to-serial adapter. The modem is presented by two ttyUSB devices, and the USB-to-serial adapter adds four more. At the machine boot, these devices get assigned random numbers ttyUSB0 to ttyUSB5, and this assignment changes between reboots.

So, this needs udev rules which would assign symlinks to these devices, and the symlinks should remain valid between the reboots.

As there’s only one physical device of each type attached to the host, we can base our udev rules on idVendor and idProduct attributes. If you need to distinguish between multiple physical devices of the same type, you have to match serial numbers in your udev rules.

The next task is to distinguish between virtual TTY devices within the same physical device. The easiest way to perform this is to extract all available attributes for two devices and look at the difference between them:

udevadm info -a -n /dev/ttyUSB4 >x4 udevadm info -a -n /dev/ttyUSB5 >x5 diff -u x4 x5

The challenge with the 3G modem is that the two TTY devices are only differing in bInterfaceNumber attribute:

-    ATTRS{bInterfaceNumber}=="01" +    ATTRS{bInterfaceNumber}=="02"

This attribute is derived during the device initialization and is not available for udev matching rules. Instead, there is environment variable ID_USB_INTERFACE_NUM which represents these values. The following commands help in identifying the needed match. The full device strings are taken from the output of “udevadm info” command:

udevadm test '/devices/pci0000:00/0000:00:13.0/usb3/3-1/3-1.3/3-1.3:1.1/ttyUSB4/tty/ttyUSB4' >z4 udevadm test '/devices/pci0000:00/0000:00:13.0/usb3/3-1/3-1.3/3-1.3:1.2/ttyUSB5/tty/ttyUSB5' >z5 diff -u z4 z

The output identifies clearly that ID_USB_INTERFACE_NUM is the variable that we can rely upon in fixing to a particular port inside the 3G modem.

Analogous comparison for the USB-to-Serial adapter shows that the ports are differing in “devpath” attribute.

So, we add the following udev rules:

cat >/etc/udev/rules.d/99-usb-serial.rules <<'EOT' SUBSYSTEM=="tty", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="251d", SYMLINK+="ttyGOBI%E{ID_USB_INTERFACE_NUM}" SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyFTDI%s{devpath}" EOT

The “udevadm test” commands as specified above help in testing udev rules without the need to reboot the host.

After rebooting, we get the following devices with persistent names:

# ls -al /dev/tty* | grep USB lrwxrwxrwx 1 root root          7 Jun 14 11:22 /dev/ttyFTDI1.1 -> ttyUSB0 lrwxrwxrwx 1 root root          7 Jun 14 11:22 /dev/ttyFTDI1.2 -> ttyUSB1 lrwxrwxrwx 1 root root          7 Jun 14 11:22 /dev/ttyFTDI1.3 -> ttyUSB2 lrwxrwxrwx 1 root root          7 Jun 14 11:22 /dev/ttyFTDI1.4 -> ttyUSB3 lrwxrwxrwx 1 root root          7 Jun 14 11:33 /dev/ttyGOBI01 -> ttyUSB4 lrwxrwxrwx 1 root root          7 Jun 14 11:35 /dev/ttyGOBI02 -> ttyUSB5 crw-rw---- 1 root dialout 188,  0 Jun 14 11:22 /dev/ttyUSB0 crw-rw---- 1 root dialout 188,  1 Jun 14 11:22 /dev/ttyUSB1 crw-rw---- 1 root dialout 188,  2 Jun 14 11:22 /dev/ttyUSB2 crw-rw---- 1 root dialout 188,  3 Jun 14 11:22 /dev/ttyUSB3 crw-rw---- 1 root dialout 188,  4 Jun 14 11:33 /dev/ttyUSB4 crw-rw---- 1 root dialout 188,  5 Jun 14 11:35 /dev/ttyUSB5

 

Filed under: Networking Tagged: 3G, linux, pcengines

It’s good to have Fippo when there’s lack of ideas in your head.

While there are synergies abound, a flawless execution is necessary

Yap. Fippo again prodded me about a topic, so here comes the post for it.

If you missed it, yesterday Microsoft acquired LinkedIn. $26.2B.

In some ways, Microsoft now rules the enterprise space – communication, collaboration and creation:

• Microsoft Office suite (Excel, PowerPoint and Word as the main pillars)
• Microsoft Outlook and the Exchange server (Email)
• Yammer (Enterprise communications)
• Skype (Voice and video communications)
• LinkedIn (User identities and profiles)

Dean Bubley puts it nicely:

The @microsoft / @linkedin deal has nailed enterprise comms federation. Complete map of who knows whom. Add Skype4B & goodbye telephony

— Dean Bubley (@disruptivedean) June 13, 2016

There’s a longform here, but I am less convinced.

I am more inclined to how Radio Free Mobile sees this:

However, for all of this to work, LinkedIn’s systems and data has to become deeply integrated with those of Microsoft which with the companies remaining independent, will be orders of magnitude more difficult.

Microsoft of late has an issue with the ability to execute and follow through.

Skype, while huge, isn’t growing since Microsoft’s acquisition. It is actually letting others take its place.

Same with Yammer. Have you heard anything about it in the last few years? The news is all about Slack, and worse still – it is about how Atlassian’s HipChat is struggling because of Slack – Yammer isn’t even mentioned as a competitor/contender in this space.

Which brings us to LinkedIn, Microsoft’s intents for it and its ability and willingness to follow through.

Back to LinkedIn

I wrote about LinkedIn exactly a year ago. It was about their acquisition at the time of Lynda, a learning company, and me griping on why LinkedIn isn’t doing anything about comms (and WebRTC).

The people at LinkedIn aren’t stupid. They are $26.2B smarter than I am. And frankly, that’s also $17.7B smarter than Skype.

What does that tell us?

• LinkedIn saw no real value in real time communications
  • Not enough to invest in it and build something with WebRTC
  • Not enough to acquire someone outright
  • Not enough to partner and integrate someone like Skype (Facebook did that in the past for example)
• That decision played well for LinkedIn – they just got acquired
• Messaging isn’t that important to LinkedIn either
  • They have rudimentary messaging capability in their platform
  • But it is lacking in so many ways that it is hard to enumerate them
  • And you can’t call its messaging anything similar to… messaging. If feels more like emails

If LinkedIn can’t find value in real time communications for its platform on its own, can Microsoft do a better job at it?

I don’t know.

–

Now lets look at the Microsoft assets that canbe integrated with LinkedIn.

Skype and LinkedIn

As Dean suggested, there is some synergy in Skype connecting to LinkedIn.

LinkedIn can slap a Skype button on its profiles, making it easy to connect to the people you’re connected with on LinkedIn.

While that’s great, most communication today happens OUTSIDE of LinkedIn. You reach out to people on it, connect with them, and then shift to email and other means of communications. Especially once you know a person to some extent.

To make a point – I wouldn’t send a message to Dean over LinkedIn – I’ll make it over email. Or just ping him on Skype, because that’s where he is.

When someone asks me for an introduction, it usually goes like this: “I saw you are connected to John Doe on LinkedIn. Can you send an intro email for me?”. It happens a lot less on LinkedIn even when it is driven from LinkedIn.

Getting the communication back to LinkedIn will be hard. Getting slightly more communications from LinkedIn directly to Skype is possible, though I am not sure it will be widely accepted.

Yammer and LinkedIn

Yammer isn’t best of breed in enterprise messaging. Not even sure if doing anything with it and LinkedIn is worth the effort.

My suggestion is to open the coffers and take out a few more billions of dollars and acquire Slack. Then throw out all voice integrations and bolt Skype in there. But that has nothing to do with LinkedIn.

Outlook/Exchange and LinkedIn

Email is what drives LinkedIn in the most effective way.

Having the ability to embed and merge profiles properly into Outlook – without any ugly add-ons – that’s great.

But nothing earth shattering that we haven’t seen before with Rapportive on Gmail.

Office and LinkedIn

I guess that having a tighter integration between PowerPoint and Slideshare would be great. But that isn’t the reason LinkedIn was acquired.

Sarah Perez of TechCrunch wrote about the integration of Office and LinkedIn. It includes Outlook. Focuses on Outlook.

And mostly goes one-way: how LinkedIn can enrich Office/Outlook related information. A bit on how Office can enrich LinkedIn data by adding more users. But nothing about how LinkedIn’s functionality can grow. A shame.

If this is where things are headed – growing Office but not growing LinkedIn, then I am afraid LinkedIn is expecting a similar fate to Yammer and Skype. Its days of greatness will be behind it and its level of innovation and introduction of powerful features that can compete in the market – will come to an end.

Other Domains

Cortana and Microsoft’s CRM are areas I missed. You can read more about them in Richard’s analysis on Radio Free Mobile.

The Corporate Structure

It seems that LinkedIn will sit as an independent entity within Microsoft under Satya Nadella directly.

I wonder how that will make things easy for the tight integrations envisioned for LinkedIn and the rest of Microsoft’s assets. How easy will it get to get the Skype team to cooperate and assist the LinkedIn team to integrate Skype for Web? What will the Office team want in return for the data they will be passing to LinkedIn? Will legal even authorize it?

There will be a lot of coordination taking place here, and I do hope that along the way, they won’t lose what’s needed to be done – there’s a lot of synergies and power here, but this will require a lot of agility from a huge company.

Back to WebRTC

This affects larger players in the UC space. If (and that’s a big if) Microsoft can connect the dots of Office, Exchange, Skype and LinkedIn – this makes for a very compelling offering. One that can differentiate and top Cisco and Google.

If Microsoft can make LinkedIn into the congregation point of people across enterprises – and not only a place to find CVs – it will be in a position to expand its offering towards real time communications in ways that others will find hard to compete against. LinkedIn lacked this vision. I wonder if Microsoft can follow through – or will they as well see it as unnecessary.

 

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

The post Will Microsoft’s Acquisition of LinkedIn Change the WebRTC Landscape? appeared first on BlogGeek.me.

The FreeSWITCH 1.6.9 release is here!

This is also a routine maintenance release. Change Log and source tarball information below.

Release files are located here:

• Tarball: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.6.9.tar.gz
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation

New features that were added:

• FS-9079 [mod_callcenter] Add ring-progressively strategy which is a way to ring every agent similarly to a top-down strategy but without cancelling the previous calls.
• FS-9248 [mod_callcenter] Adding truncate-tiers-on-load and truncate-agents-on-load options
• FS-9216 [mod_sofia] Add Cisco SPA30X and Grandstream GXP user agents to send UPDATE
• FS-9225 [mod_sofia] Allow to force SIP REGISTER Expires: to be within configured range instead of specific value
• FS-9188 [mod_sofia] Added a channel variable to suppress auto-answer notify
• FS-8652 [mod_sofia] Add a optional parameter “early-only” to replaces header parsing and only intercept the call if it is not bridged if this parameter is set to true
• FS-9124 [mod_avmd] Extend XML config
• FS-9142 [mod_avmd] Dynamic settings addition of checking of per session settings with locking synced on avmd session mutex
• FS-9207 [core] Add ignore_sdp_ice=true to ignore ICE when parsing an SDP
• FS-9157 [verto] Added the possibility to create dedicated audio/video tags for each dialog in verto
• FS-9249 [verto_communicator] Close the settings panel if the user clicks outside the element
• FS-9184 [mod_commands] Allow show calls to be filtered by accountcode
• FS-8979 [mod_imagick] Added “lazy load” functionality to speed up the rendering of the first page of a PDF while continuing to load the following pages in the background
• FS-9199 [scripts] Small change to make memory allocation tracing of ALL allocations easier and a script to analyze logs

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

• FS-9070 [configuration] Fix build on 64-bit arm
• FS-5936 [Debian] Add libesl-perl package containing and associated perl ESL bindings
• FS-9075 [Debian] Additional tweaks to help ease upgrading freeswitch-all
• FS-8788 [Debian] Fixed systemd error on Debian Jessie causing non enforcement of stack size limitation
• FS-9174 [Debian] Fix installation of mod_png when installing via the -all packages
• FS-8623 [build] Fix libvpx Solaris Studio build
• FS-9158 [build] Add include for Solaris to changes to build
• FS-9185 [build] Fixed the format of ifdefs for Solaris SPARC
• FS-9152 [mod_avmd] Fixed warnings on FreeBSD
• FS-9254 [mod_avmd] Fixed the windows build
• FS-9155 [Centos] Fixed lang_es and lang_pt package to have the right language module
• FS-9238 [mod_osp] Updated for OSP Toolkit 4.11.3.
• FS-9134 [core] Tweaked fscore_pb to use new pastebin API
• FS-9132 [mod_kazoo] Add more variables to default filter
• FS-9164 [core] Add Session-Per-Sec-Last to heartbeat event
• FS-9136 [core] Allow multiple instances of same video codec with different fmtp
• FS-9106 [mod_vpx] Improve efficiency when using dedicated encoder mode in conference with vpx codecs

The following bugs were squashed:

• FS-9131 [core] Improve validation of ice candidates to properly handle malformed candidates
• FS-9135 [core] Handle incorrect uses of switch_core_media_set_sdp_codec_string function passing null sdp gracefully
• FS-7783 [core] Properly handle NULL var_name for switch_play_and_get_digits
• FS-9222 [core] Added a small tweak to freeswitch console to strip leading spaces from commands and added a fix for FreeSWITCH not sending binding response to VoIP client causing a one way audio call
• FS-9235 [core] Fix sending RTCP in switch_core_media
• FS-9219 [core] Fixed an issue with Re-INVITE with no SDP by using bypass_media_after_bridge_oldschool=true to cause bypass_media_after_bridge to use a standard RE-INVITE with SDP, instead of the more reliable method of using 3pcc RE-INVITE
• FS-9246 [core] Fixed an issue with no audio after transferring a call
• FS-9244 [core] Fixed an issue where RFC2833 payload_type offered is ignored
• FS-9115 [mod_av] Initial work toward support for audio only mp4 recording
• FS-9151 [mod_av] Fixed playback a mp4 file on a session without video not ending
• FS-8795 [mod_png] Fixed an issue with audio only call
• FS-8584 [mod_callcenter] Request agents and tiers when reloading queue
• FS-9153 [mod_commands][mod_event_socket] Fixed a uuid_bridge issue on ESL
• FS-9034 [mod_sofia] Fixed register processing in a new thread
• FS-9160 [mod_sofia] Tweak sip_invite_failure_* chan vars for properly reporting last outbound call failure when there are multiple bridge attempts on a single call
• FS-9214 [mod_sofia] Fixed 3pcc behavior and callflow issues with 3pcc=true and 3pcc=proxy and interactions with sip_wait_for_aleg_ack removes passthrough of 183 on 3pcc=proxy (that was previously not functioning)
• FS-9227 [sofia-sip] Fixed wrong byte order in HEP packet for source and destination ports
• FS-9167 [mod_conference] Fixed an issue where playing a file when all video feeds are vmuted does not show file
• FS-9150 [mod_conference] Force the video-bridge-first-two only function when there are only 2 members who can watch video to prevent flipping between video feeds when video muting
• FS-9144 [mod_conference] Implement video-mute-exit-canvas and recording in personal-canvas mode to prevent users who video mute themselves missing feeds from their canvas
• FS-9212 [mod_conference] Fix conference recording api when using default canvas number
• FS-9198 [mod_skinny][mod_conference] Fixed small memory leaks
• FS-9201 [mod_skinny] Fixed a leak in API call to list devices
• FS-9202 [mod_skinny] Fixed a leak in speed dial
• FS-9156 [mod_hiredis] Code Improvement for the non-interval increment when limit reached
• FS-7397 [mod_translate] Fixed a segfault due to memory corruption on using app
• FS-8979 [mod_imagick] Set it to fire an event when finished
• FS-9250 [verto_communicator] Putting factory reset button back

This week we had two features including adding truncate-tiers-on-load and truncate-agents-on-load options to mod_callcenter and some improvements to the verto communicator.

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-9248 [mod_callcenter] Adding truncate-tiers-on-load and truncate-agents-on-load options
• FS-9249 [verto_communicator] Close the settings panel if the user clicks outside the element

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

• FS-9238 [mod_osp] Updated for OSP Toolkit 4.11.3.
• FS-9254 [avmd] Fixed the windows build

The following bugs were squashed:

• FS-9235 [core] Fix sending RTCP in switch_core_media
• FS-9214 [mod_sofia] Fixed 3pcc behavior and callflow issues with 3pcc=true and 3pcc=proxy and interactions with sip_wait_for_aleg_ack removes passthrough of 183 on 3pcc=proxy (that was previously not functioning)
• FS-7397 [mod_translate] Fixed a segfault due to memory corruption on using app. The session pool was being freed incorrectly after using the app instead of when the session pool was destroyed.
• FS-9227 [sofia-sip] Fixed wrong byte order in HEP packet for source and destination ports
• FS-9219 [core] Fixed an issue with Re-INVITE with no SDP by using bypass_media_after_bridge_oldschool=true to enable back-compat bypass media after bridge
• FS-8979 [mod_imagick] Set it to fire an event when finished
• FS-9144 [mod_conference] Implement video-mute-exit-canvas and recording in personal-canvas mode to prevent users who video mute themselves missing feeds from their canvas
• FS-9250 [verto_communicator] Putting factory reset button back
• FS-9246 [core] Fixed an issue with no audio after transferring a call
• FS-9244 [core] Fixed an issue where RFC2833 payload_type offered is ignored

 

Amandine and Matthew from the Matrix.org team join ClueCon Weekly with and update on Matrix.org and to announce the launch of Vector.im

Visit them on the web at http://matrix.org and http://vector.im

How time flies.

About 10 months ago, the announcement of the creation of a new alliance caught me off guard.

Somehow, Google, Microsoft and a few other companies put their differences aside and decided to create the Alliance of Open Media. The intent – create royalty free video codec to rival H.265/HEVC. I’ve written about the Aliance of Open Media. It is time to revisit the topic.

A few things happened these last few months that are worth mentioning:

1. We’ve learned more about the alliance – Jan Ozer  wrote a good progress report
2. AMD, ARM and Nvidia joined the alliance
3. Ittiam joined the alliance
4. Vidyo joined the alliance

I am told work is being done on the actual codec itself. From the report Jan Ozer wrote, the following is apparent:

• Baseline for the codec is VP10 (Google)
• Most contributions of technologies on top of it come from Mozilla and Cisco; though I assume Microsoft is contributing there as well
• Hardware vendors are putting their weight to make sure the algorithms used are easy to place in a hardware design
• There’s a focus on GPU acceleration, which is important
• Intent is to have it integrated into a browser by the beginning of 2017 and have hardware acceleration a year later

All the right moves.

ARM and Nvidia

Adding ARM and Nvidia is quite a catch.

ARM is in charge of the architecture of most smartphones on the market today, along with many of the IOT devices out there. Having them on board means that considerations for mobile and low power devices are taken into consideration by the alliance – but also that the work of the alliance will find its way into future designs of ARM.

Nvidia is where you find GPU processing power. They complement the attendance of Intel, brining the important GPU players to the table. In a recent whitepaper I’ve written for Surf, I touched the GPU issue briefly. I’ve done some research in that domain, and it does seem like the GPU is the best candidate to handle our future video coding – having GPUs relevant to this next generation codec fron the start is an important catch for the alliance.

Ittiam

Ittiam is a recent addition to the alliance.

I’ve had the chance to know Ittiam a decade ago, while competing head to head with their VoIP software. They have expertise in the multimedia space and in video compression, but they still are the smallest (or least relevant) player in this alliance. Having them is required to fill in the ranks and grow in numbers.

It would be nice to see others join such as Imagination Technologies (who are larger and a lot more meaningful).

Vidyo

Vidyo just join the alliance. On one hand, it surprised me. On the other hand, it should have.

Vidyo is collaborating with Google for a long time now in VPx and WebRTC. Recently it reiterated that with the work it is doing on VP9 SVC for WebRTC (you can find out more about it on a guest post Alex Eleftheriadis shared here on scalability and VP9).

Their addition to the alliance means several things:

• Vidyo is making itself an integral part of every initiative related to future video codecs. This is a smart move, as it maintains its lead in the backend side and the smarts that is placed on top of SVC capabilities
• This future codec will have SVC support in it, hopefully from the moment it is released to market
• While a smaller company compared to the other members, the contribution of Vidyo to the alliance can be larger than many others of its members

Qualcomm

Qualcomm is missing.

So is Samsung.

And a few other smaller mobile chipset vendors.

I think it is their loss, as well as a missed opportunity.

They both should have joined the alliance at its inception.

Apple

Apple being Apple, they aren’t a part of it. Putting ads in the App Store and changing subscription revenue sharing models were more important to them, which is understandable.

The thing I don’t understand here is that Apple has removed most of its support in H.265. What does it have to lose by joining the alliance?

There are three paths available to Apple:

1. Go with H.265. The current reduction in its support of H.265 can only be explained as a negotiation tactic in such a case
2. Go with the Alliance of Open Media. Which it could do at any point in time. But if that is the case, then why wait?
3. Release its own unique iCodec. Apple knows best, and it is time to lock its customers a bit further anyways

I wonder which route they are taking here.

Content Creators and Service Providers

We’ve got YouTub, Netflix and Amazon already covered. The internet may rejoice.

But what about Game of Thrones? Or the next movie blockbuster? Are they staying on the route of H.265 or will they veer away from it towards the alliance?

Hard to tell, though for the life of me, I can’t understand a long term decision of staying with H.265.

It would be nice to see the large studios and even Bollywood join the alliance – or at the very least back it publicly.

Timeline

If we look at the VP9 timeline, we havethe following estimates:

• 1 year – Chrome decoding, along with a small percentage of YouTube videos supported
• 2 years – First chipsets and reference designs support. My bet is on Nvidia and Intel here
• 2.5 years – Chrome official support of it for WebRTC

H.264 in WebRTC

H.264 is hear to stay. More worrying – H.264 will grow in popularity in WebRTC services during 2016.

This progress and success of the alliance changes nothing in the current ecosystem and the current video technology.

The future of H.265

The future of H.265 does look grim. I do hope the alliance will kill it.

H.265 is in a collision course with VP9. It is still the more “popular” choice in legacy businesses, but that may change, as commercial deployments of it are small or non-existent.

The alliance simply means that a future codec is based on the VPx line of codecs instead of the H.26x ones. Now developers shifting from H.264 to a better codec will need to decide if they switch codec lines now or just later.

The royalty issues around H.265 along with the progress made in the alliance should tip the scales towards VP9 on this one.

What’s next?

Money time.

Where does that leave us all?

• Vendors who handle codecs directly should join the alliance. The benefits outweigh the risks.
• Consumers and users can continue not caring
• Developers, especially those of backend media servers, need to decide if they shift towards VP9 or wait for the next generation to switch to a royalty free codecs. They also need to decide if they want to use VP8 or H.264 today

 

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

The post The Alliance of Open Media – 10 Months in appeared first on BlogGeek.me.

This week mod_sofia added Cisco SPA30X and Grandstream GXP user agents. Remember, ClueCon 2016 is coming up quickly so get registered today!

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-9142 [avmd] Dynamic settings addition of checking of per session settings with locking synced on avmd session mutex
• FS-9216 [mod_sofia] Add Cisco SPA30X and Grandstream GXP user agents to send UPDATE
• FS-9225 [mod_sofia] Allow to force SIP REGISTER Expires: to be within configured range instead of specific value

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

• FS-9174 [Debian] Add dependencies to meta-all for mod_png so its installed via the -all packages

The following bugs were squashed:

• FS-9212 [mod_conference] Fix conference recording api when using default canvas number
• FS-9150 [mod_conference] Force the video-bridge-first-two only function when there are only 2 members who can watch video to prevent flipping between video feeds when video muting
• FS-9156 [mod_hiredis] Code Improvement for the non-interval increment when limit reached
• FS-9222 [core] Added a small tweak to freeswitch console to strip leading spaces from commands and added a fix for FreeSWITCH not sending binding response to VoIP client causing a one way audio call
• FS-9136 [core] Allow multiple instances of same video codec with different fmtp

Update 1: some of the maintenance work will be performed in the afternoon of Monday, June 6, starting with 14:00 Berlin, Germany.In the near future, likely next week, kamailio.org server will receive a maintenance upgrade. The exact date will be decided soon and announced on Kamailio mailing lists and other online channels.Main affected services: website (including the wiki portal) and mailing lists.Hopefully there will only be short downtime intervals. Anyhow, if it happens that you are trying to access kamailio.org and it is not responding, retry a bit later.The #kamailio IRC channel on freenode.net server can be used for discussions during the upgrade interval.