News from Industry

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.

H.264 is set to replace VP8 for WebRTC services.

You can thank Fippo for making me write this one.

Microsoft ended last week with an announcement of sorts on their Edge dev blog, indicating that H.264/AVC support for ORTC is now available in Edge.

• Yes. It is ORTC and not WebRTC
• Yes. It is only behind a runtime flag
• Yes. It is only on Edge. No IE

But then again, it is the only way today (or at least tomorrow) to get a video call running cross browser between Firefox, Chrome and Edge. VP8 or VP9 gets you as far as Chrome and Firefox.

Which got me to this one over here. Edge support for H.264 in ORTC isn’t much. It isn’t even interesting in the bigger scheme of things (Edge has literally no market share compared to the other browsers, so why bother with it?). And still it marks a turning point – one in which we can all ask ourselves what video codec should we be leaning towards if we started developing a product that uses WebRTC today?

Last year, the answer would have been “VP8”.

A few months ago, it was, “it depends”.

Today, it will lean towards “H.264, unless you must use VP8”.

Here are 4 reasons why this is happening:

#1 – Browser interop baseline

If you want your service to get the most coverage on as many browsers as possible and you need video, then H.264 is the way to go. In a few months, H.264 will get official support by all of these vendors and that will be the end of it. Furthermore, you can expect Apple to use H.264 first and contemplate VP8 – same as Microsoft is doing now with Edge.

#2 – Mobile

Mobile devices like H.264 more than they like VP8. Video codecs take up a lot of resources. To overcome this, mobile handsets use hardware acceleration for video codecs. They all have H.264 video acceleration (though you can’t always gain access to it as a developer). Many of them don’t even know how to spell VP8. This boils down to WebRTC implementations on mobile needing to implement VP8 using software.

Some developers ended up replacing VP8 with H.264 on mobile just because of this reason. Especially for mobile only products.

While I am sure support for VP8 is improving in new chipsets, there’s this pesky issue of supporting the billion and more devices that are already out there. And now that all browsers support H.264 in one way or another, what incentive do developers needing to support mobile apps have to use VP8?

#3 – Legacy video systems

All them video conferencing systems? They use H.264. Most don’t have VP8. Not even in their latest released products. The way they end up supporting WebRTC until today is via a specialized gateway, on the MCU or not at all.

Transcoding was one of the main barriers to getting WebRTC to legacy video systems. It just costs a lot. It would have been easier to just go H.264 all the way. Which is what is now available.

It is one of the reasons why Cisco first worked on Firefox with Spark. It made a decision to use H.264 for WebRTC instead of transcoding from VP8.

#4 – Streaming

Over 60% of the Internet traffic is video. Most of it isn’t real time video, but rather the YouTube or Netflix kind. Passive consumption.

Video streaming today is predominantly H.264 based, and at times VP9 (=YouTube whenever possible).

To get video content on an iPhone device, HLS is required, and that again means H.264.

So again we are left with the alternative of either transcoding our WebRTC generated content to H.264 when we want to stream it out – or to create it using H.264 to begin with.

Do you even care?

If your service is a 1:1 calling service with no server side media processing, then you shouldn’t even care. In such a case, whatever the browsers end up negotiating will be good enough for you (and most probably the best alternative for that specific situation).

Those who invested in server side media processing, be it recording, mixing, routing –  have made investments that are targeted at VP8. Modifying these to work with H.264 as well may not be trivial. For them, the decision of switching to H.264 is a harder one to make, but one that needs to be addressed.

The Future of Video Coding in WebRTC

Once we step into the future, we see VP9. And the SVC flavor of VP9.

And then there’s the Alliance of Open Media and the work they are doing towards a widely accepted next gen royalty free video codec. I’ve touched the progress they are making in my recent Virtual Coffee session

For the record, I rather hate H.264 and what it stands for. But now I must accept that it is here to stay and grow with WebRTC.

 

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

The post 4 Reasons to Choose H.264 for your WebRTC Service (or why H.264 Just won over VP8) appeared first on BlogGeek.me.

This week we had some cool new features including a script to make memory allocation tracing easier and analyze logs, modifications to make vpx encoder use less cpu, and add an optional parameter “early-only” to only intercept the call if it is not bridged if  set to true in mod_sofia.

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-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-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-9106 [mod_vpx] Minor modifications to make vpx in dedicated encoder mode use less cpu
• FS-9199 [scripts] Small change to make memory allocation tracing of ALL allocations easier and a script to analyze logs
• FS-9207 [core] Add ignore_sdp_ice=true to ignore ICE when parsing an SDP

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

• FS-8788 [Debian] Fixed a compatibility issue with systemd 215 on Jessie as it turns out that suffixes are only introduced in systemd 228 which is not available in Debian Jessie

The following bugs were squashed:

• 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

Bernard Aboba, Principal Architect, Skype at Microsoft and Shijun Sun, Program Manager from Microsoft’s Edge RTC Team join the ClueCon Team to give an update on Microsoft Edge and its inclusion of ORTC and WebRTC technologies.

URLs from the show:
Edge RTC roadmap blog: https://blogs.windows.com/msedgedev/2…
Edge RTC FAQ: http://internaut.com:8080/~baboba/ort…
Plugin-free Skype for Web preview:
http://blogs.skype.com/2016/04/15/new…
adapter.js on GitHub: https://github.com/webrtc/adapter

And of course see you at ClueCon.com!

Dean Elwood CEO of Voxygen joins the ClueCon talk about how his company, Voxygen, provide value added services and products for Tier 1 mobile carriers and how FreeSWITCH has acted as an enabler for that.

[Luis Lopez is the face in front of Kurento, one of the popular open source media servers that can handle WebRTC. He wanted to share here the story of the new open source WebRTC PaaS – NUBOMEDIA]

When I first heard about WebRTC by 2011, I was fascinated by the idea of standardized APIs and protocols enabling the creation of interoperable RTC applications for the Web. However, I noticed very soon that my peer-to-peer services were too limited and that, as a developer, I was hungry for further features that could only be provided by a WebRTC infrastructure. This is why I got involved in the Kurento project for creating a media server. Kurento got nice traction but, as it was maturing, we found an increasing number of feature requests related to its scalability. The message was quite clear: a cloudification of Kurento was necessary.

With this in mind, by 2014 we got down to work and, with the financial support of the European Commission, we worked hard during a couple of years in cooperation with some of the most remarkable cloud experts around Europe. These efforts were worthy: NUBOMEDIA, the first open source WebRTC PaaS, is now a reality.

NUBOMEDIA: the first WebRTC PaaS

In the WebRTC ecosystem, scalable clouds for developers are not new. Providers such as Tokbox, Kandy, Twilio and many others offer them. These solutions are commonly called “WebRTC API PaaS”, “WebRTC Cloud APIs”, or just “Cloud APIs” as they expose a number of WebRTC capabilities through custom APIs that exhibit all the nice “-ilities” of cloud services (i.e. scalability, security, reliability, etc.)

For NUBOMEDIA we also considered this “Cloud API” concept as a solution. However, although APIs are the main building block developers use for creating applications, applications are more than just a set of API calls. After analyzing WebRTC developers’ needs, we felt more appealing the concept of platform than the concept of API. A platform is more than an API in the sense that it provides all the required facilities for executing applications. These typically include an operating system, some programming-language-specific runtime environments and some service APIs. The cloud version of a platform is commonly called a PaaS, which is (literally) a platform that is offered “as a Service”.

There are many such PaaSes in the market including Heroku, the Google App Engine or AWS Elastic Beanstalk. All of them expose to developers the ability of uploading, deploying, executing and managing applications written in different programming languages. These PaaS services are quite convenient as they let developers to concentrate on creating their applications’ logic while all the complex aspects of provisioning, scaling and securing them are assumed by the PaaS. In spite of the wide offer of PaaS services, we noticed that most common PaaS providers did not expose WebRTC capabilities as part of their APIs. Hence, WebRTC developers were not able to enjoy all the advantages of full PaaSes.

The main difference between a WebRTC cloud API and a full WebRTC PaaS is illustrated in the following figure. As it can be observed, WebRTC Cloud API providers (left) do not host developers’ applications, but just expose some WebRTC capabilities through a network API that applications consume. On the other hand, full WebRTC PaaSes host application and take the responsibility of executing, scaling and managing them.

Based on these ideas, the NUBOMEDIA idea emerged clearly: instead of evolving Kurento into a cloud API we should rather create a full PaaS out of it, so that developers could enjoy the nice features of PaaSes (i.e. application deployment, execution, scaling, etc.) while consuming the Kurento APIs in a scalable and secure way.

Why NUBOMEDIA may be interesting for you

NUBOMEDIA is now a reality and it can be enjoyed openly by developers worldwide. Like solutions such as OpenShift, Cloud Foundry or Apprenda, NUBOMEDIA is a private PaaS in the sense that it consists of an open source software stack that can be downloaded, installed and executed on top of any OpenStack IaaS cloud.

If you are a developer, you may be interested in trying NUBOMEDIA for your next application as it combines the simplicity and ease of development of WebRTC Cloud APIs with the flexibility of full PaaSes. When doing so, consider that NUBOMEDIA is a Java PaaS. Hence, you will be able to leverage all the capabilities of the Java platform for creating your WebRTC application. The only difference with other Java PaaS services it that NUBOMEDIA will provide you a specific SDK through which you will be able to access the complete feature set of Kurento in a scalable way.

From a practical perspective, the main differences between NUBOMEDIA and other WebRTC cloud solutions are illustrated in the next figure. As it can be seen, there is a trade-off between flexibility and simplicity: the simplest the development, the less flexible the application is and the more difficult it is to adapt it to custom needs and requirements.

For example, most flexible solutions (IaaS on the bottom left corner of the image) require complex developments for creating fully operational WebRTC applications. On the other hand, SaaS solutions (top right corner) do not require much development efforts, but developers’ ability for customizing and adapting it to special requirements is typically very limited. For this reason, WebRTC developers tend to prefer WebRTC Cloud APIs that provide some flexibility but, at the same time, enable simple developments.

NUBOMEDIA also positions within this balance but giving more prevalence to flexibility. This makes NUBOMEDIA more suitable for developments requiring to comply with special or rare requirements. Just for illustration, these are some of the things you can make with NUBOMEDIA that are complex to achieve using the common WebRTC Cloud APIs:

• To use the signaling protocols you prefer (e.g. SIP, XMPP, custom, etc.)
• To have special communication topologies. For example, imagine that you need a videoconferencing room with “spy participants” that can view others but should not be noticed by the rest; or imagine that you need simultaneous translators that are not viewed but need to listen to some participants while being listened by others.
• To have custom AAA (Authentication, Authorization and Accounting). For example, imagine that you wish to implement rules customizing who can access the media capabilities (e.g. recording, viewing a specific stream, etc.) so that they depend on some non-trivial logic (e.g. context information, time-of-day, time-in-call, etc.).
• To go beyond calls. We may imagine lots of use-cases where WebRTC might be used beyond plain calls. For example, person-to-machine or machine-to-machine scenarios where you need cameras to connect to users or to other systems in a flexible way without restricting to the typical room videoconferencing models commonly exposed by WebRTC Cloud APIs.

As another interesting property, as NUBOMEDIA is a private PaaS, it can execute onto any OpenStack infrastructure. This means that the operational costs of an application running in NUBOMEDIA are fully under your control as you can decide in which IaaS to deploy the PaaS. This significantly reduces the operational costs with respect to an equivalent application consuming a Cloud API, as the Cloud API provider margins disappear.

The NUBOMEDIA Open Source Community

We have created NUBOMEDIA following the same open philosophy we used with Kurento. Currently, it is supported by an active and vibrant open source software community that is structured as an association of several projects providing different technological enablers including: the cloud orchestration mechanisms, the PaaS management technologies, the media server, many media processing modules and client SDKs for Android, iOS and Web.

If you are interested in knowing more about NUBOMEDIA you can check the community documentation where you will be able to find detailed information showing how to install and manage the platform and how to develop and deploy applications into the PaaS. You can also check the community YouTube channel and see one of the many videos with demos and tutorials illustrating how to develop and deploy NUBOMEDIA applications. If you want to know about the latest news of the NUBOMEDIA Community, you may follow it on Twitter.

 

Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

Get your Choosing a WebRTC Platform report at a $700 discount. Valid until the beginning of May.

The post NUBOMEDIA: the first open source WebRTC PaaS appeared first on BlogGeek.me.

The video recordings for all the session at Kamailio World Conference 2016 are available on Kamailio World Youtube Channel:

• https://www.youtube.com/channel/UCElq4JNTPd7bs2vbfAAYVJA

Enjoy!

And not only the development.

For too many years now we’ve been enamored with Agile. Supposedly the successor of the fountain development model, agile is all about short iterations and faster feedback.

In larger places, agile is usually just the next undertaking of the program manager – or whatever equivalent you have in the company that deals with processes. I remember hearing the term “we must be agile”. With the end result being… 18 to 24 months product release cycles.

That’s nice, but it isn’t really agile – at least not more than the Geek & Poke caricature above.

I had an interesting discussion with a consultant during the London WebRTC conference two months ago. He complained that browsers are moving too fast, making it hard for enterprises to follow suit and adopt WebRTC.

Here’s a quick reminder – WebRTC doesn’t care about enterprises. It cares about innovation and forward moving. If something breaks, then you’re just out of luck.

WebRTC today forces enterprises to think and act Agile

Why is this the case?

• Browsers are updating at the speed of light – every 6 to 8 weeks
  • Each time they do, something gets deprecated
  • And other things can get broken
  • This is doubly so with WebRTC, which is essentially a perpetual work in progress
  • And will stay that way well into 2017
  • Enterprises need to be prepared for it and willing to update their own deployments to keep pace
• WebRTC’s codecs are changing – and upgrading
  • VP9 is upon us
  • H.264 is here to stay
  • R&D teams need to adopt new codecs to keep their service pristine
  • Otherwise, competitors will do it and win the market simply by offering better user experience and media quality
• New capabilities
  • Browser side recording?
  • Playing video from a canvas?
  • Pipelining media?
  • WebRTC has it all, and things are only improving
  • Do these affect your product? Do you need someone to define how this changes things for you?

What Needs to Change

Enterprises need to change their stance. They aren’t in control anymore. They should act accordingly.

This means having product managers, developers, testers, support and IT all working in concert in an agile way – thinking about launched products as living and breathing entities that must be updated continuously.

Thinking of launchng a WebRTC based product? Especially if it is an on premise one – you must make sure you understand the implications AND that your customers understand the implications as wlel.

 

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

The post With WebRTC, Vendors Must Embrace True Aglie appeared first on BlogGeek.me.

This week we had a feature in mod_sofia with the addition of a channel variable to suppress auto-answer notify and another feature in mod_commands to allow show calls to be filtered by accountcode.

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-9188 [mod_sofia] Added a channel variable to suppress auto-answer notify
• FS-9184 [mod_commands] Allow show calls to be filtered by accountcode

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

• FS-9158 [build] Add include for Solaris to changes to build
• FS-9185 [build] Fixed the format of ifdefs for Solaris SPARC

The following bugs were squashed:

• FS-9153 [mod_commands][mod_event_socket] Fixed a uuid_bridge issue on ESL
• FS-9164 [core] Add Session-Per-Sec-Last to heartbeat event
• FS-9034 [mod_sofia] Fixed an issue in sofia.c that prevents register in new thread
• FS-9167 [mod_conference] Fixed an issue where playing a file when all video feeds are vmuted does not show file
• 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

Conference calling is a multi-billion dollar industry that is mostly powered by expensive, high-powered conferencing servers. Now you can replicate much of this functionality for free with a modern browser using the combination of WebRTC and WebAudio. Like with video, multi-party audio can utilize a few architectures: Full mesh – each client sends their audio […]

The post Your Browser as a Audio Conference Server with WebRTC & Web Audio (Alexey Aylarov) appeared first on webrtcHacks.