News from Industry

A new module named NSQ has been imported in Kamailio’s GIT repository, authored by Emmanuel Schmidbauer from Weave Communications. Emmanuel has become also a registered developed in order to maintain the module.In short, the module provides a NSQ connector for Kamailio configuration file, allowing to interact with NSQ servers from kamailio.cfg. NSQ is a real time distributed messaging platform, you can read about NSQ at nsq.io.More about the NSQ module is available at:

• http://www.kamailio.org/docs/modules/devel/modules/nsq.html

The module will be part of the future major release Kamailio v5.0.0! While waiting for that release you can play with NSQ using the git master branch.Thank you for flying Kamailio!

Progressing nicely – of course.

Checking the pulse of WebRTC

It’s been 5 years since WebRTC came to our lives. Different people count it from different times. I heard in the last month or two the years 2009, 2010 and 2011 stated as the year of birth of WebRTC. While no one should really care, for me, WebRTC started with Google’s announcement of WebRTC in May 2011. It was the first time Google publicly stated its plans for its GIPS acquisition, and it came out as an open source package that was planned to get integrated into browsers and be called WebRTC. I was a CTO at a business unit licensing VoIP products to developers. The moment I saw it, I knew everything was going to change. It was one of the main reasons I left that job, and got to where I am today, so it certainly changed everything for me.

As we head towards Mat of 2016, it is time to look a bit at the 5 years that passed – or more accurately the 5th year of WebRTC.

One one hand, it seems that nothing changed. A year ago, Chrome and Firefox supported WebRTC. That’s on Windows, Mac OS X, Linux and Android. Today, we’re pretty much in the same position.

On the other hand, adoption of WebRTC is huge and its impact on markets is profound; oh – and both Microsoft and Apple seem to be warming up to the idea of WebRTC – each in his own way.

If you are interested in a good visual, then my WebRTC infographic from December 2015 is what you’re looking for. If it is numbers and trends today, then read on.

951 Vendors and Project – and growing

I’ve been tracking the vendors and projects of WebRTC since 2013, actively looking for them and handpicking relevant projects that are more than 10 lines of code and any vendor I saw. It turned into one of the services I have on offer – access to this actively growing (and changing) dataset of WebRTC vendors.

Earlier this month, the WebRTC dataset had the following interesting numbers:

• 951 vendors and projects that I track
  • There are a few that shutdown throughout the years, but not many
  • There are a few that I know of and don’t make it into the list, because they want to remain private at this point
  • There are data points I’ve stored and haven’t processed yet – many of them additional vendors (got around 80 in my backlog at the moment)
• 2015’s average was 26 vendors added every month
• 2016 shows a slight increase to that average. 3-4 months aren’t enough to make this definitve yet
• For now, there are 41 acquisitions related to WebRTC in one way or another
  • Some of them are less relevant, such as Mitel acquiring Polycom
  • Others are all about WebRTC, such as Talko’s acquisition by Microsoft

What is interesting is that these vendors and projects are always evolving. They aren’t only limited to startups or large enterprises. They aren’t specific to a certain vertical. They cut through whole industries. Just this week a new use cases popped – movers who can give a price quote without being on site. Will it fly? Who knows.

We’ve been witnessing a surge in communication services. We are not limited today by concepts of Telephony or Unified Communications. These became use cases within a larger market.

What is different now is that the new projects and vendors don’t come with VoIP pedigree. They are no longer VoIP people who decided to do something with WebRTC. Most of them are experts in communications – not digital communications, but communications within their own market niche. Check out the interview from last week with Lori Van Deloo of BancSpace – she knows her way in banking.

API Platforms are Maturing

Communication API platforms using WebRTC are maturing. Many of them have the basics covered and are moving further – either vertically or horizontally. Vertically by deepening their support of a specific capability or horizontally by adding more communication means. You can read my WebRTC API report on it. I am in the process of updaing it.

What is interesting is how this space is being threatened from two different domains:

1. Unified Communication platforms turned Enterprise Messaging turned developer ecosystems. Cisco Spark and Unify’s Circuit are such examples. They are an enterprise UC solution that can be used (and is actively being marketed as) a long tail development platform for general communication needs
2. Specialized component vendors who are offering widgetized approach of their service, enabling its integration elsewhere. Gruveo, appear.in and Veeting do it a lot; Drum ShareAnywhere and a lot of others are also examples of it

This is affecting the decision making process of those who need to roll out their own services, making the technology more accessible, but at the same time more complex and confusing when the time comes to pick a vendor to lean on.

Verticals are Fragmenting Further

What does a communication solution in healthcare looks like?

If you ask a Unified Communications vendor, it will be able having a room system everywhere and enabling doctors/nurses/patients communicate.

I had conversations with these types of health related vendors:

• Contact centers for doctor visitations of a healthcare insurer
• IOT measurement device a user takes home, connects to the phone and from there to a doctor
• Online group treatment
• Serving rural areas from an established hospital in developing countries
• Assisting/learning/teaching/participating in remote surgery
• Medical tourism
• Counseling for enterprise employees
• Care for seniors
• Secure messaging for doctors
• Medical clowns
• Fitness related

Each of these is a world unto its own, and to think we’ve looked at them all through the prism of Unified Communications or even the “healthcare vertical”.

WebRTC brought with it the ability to hone in on specific market needs.

–

WebRTC is already ubiquitous. As with any technology, its has its rough edges and challenges.

I’ve dealt with developing VoIP products for the better part of the last two decades – I can tell you hands down that never before did we have the alternatives to do what we can today. If you have VoIP on your mind, then WebRTC should be the first thing to try out as a component in your solution.

The post Where are we with WebRTC? appeared first on BlogGeek.me.

Lorenzo will be talking about the SIPCAPTURE stack HOMER. “A robust, carrier-grade and modular VoIP and RTC Capture Framework for Analysis and Monitoring with native support for all major OSS Voice platforms and vendor-agnostic Capture agents. HOMER counts thousands of deployments worldwide including notorious industry vendors, voice network operators and fortune 500 enterprises, providing advanced search, end-to-end analysis and packet drill-down capabilities for ITSPs, VoIP Providers and Trunk Suppliers using and relying on VoIP services and RTC technologies – All 100% Open-Source.”

The kamailio.org website has been updated to use a responsive theme. The old skin was built during 2010-2011, the corresponding wordpress theme was not updated for few years, lacking the responsive layout.The new look keeps the same clean and clear approach. One of the major changes was the need to widget-ize the sidebar on the right, which used to be the main navigation menu for most of the resources provided by Kamailio project. Several of them were left on the new right sidebar and the rest along with new resources were indexed by the menus at the bottom of the pages.The main page for kamailio.org is planned to be reorganized with a fresh design in the near future as well, building on top of the framework provided by the new wordpress template.Suggestions on how to organize the website and its menus for better accessibility or more suggestive navigation are very welcome! Email us to .Thank you for flying Kamailio!

This week we added support for hepv2 and hepv3 in sofia! Also, mod_spy now works with verto channels.

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-9078 [libsofia] Added hepv2 and hepv3 support and added #pragma for MSVC compiler
• FS-9083 [mod-sofia] Pass On SIP headers from leg A to B
• FS-9080 [mod_spy] Making mod_spy work with Verto channels
• FS-9024 [avmd] Add events on session start/stop

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

• FS-9091 [build][libyuv] Update libyuv to hash 69245902 from https://chromium.googlesource.com/libyuv/libyuv/ and build all platform files so we don’t have missing symbols on some platforms
• FS-9093 [mod_cv] Remove unneeded includes
• FS-9081 [Debian] Use turbo if available for newer jpeg over falling back to old jpeg62-dev

The following bugs were squashed:

• FS-8757 [core] Fixed a buffer overflow in switch_channel_expand_variables_check and switch_event_expand_headers_check
• FS-9057 [mod_rtmp] Fixed an issue with screen share feed not taking the floor if the webcam is muted and un-muted
• FS-9082 [mod_java] Fixed an issue with loading prerequisites if modules are not placed in prefix/mod directory
• FS-9060 [mod_sofia] Correct issues with hold and broken soa negotiations after performing a bypass media re-invite

Well… Almost.

For those who haven’t been following the path Skype is taking, here’s a quick recap of the last year or so:

• Lync got “merged” with Skype, rebranding it as Skype for Business – so now all of Microsoft’s voice and video calling services are Skype
• Skype for Web was announced at about the same time
• A Skype SDK was launched
• And now, Skype for Web is running on Microsoft Edge without any plugin installation
• Oh, and they announced bots too

Skype on Edge sans plugins was to be expected

That last bit near the end? Of Skype not needing plugins when executed on Edge? That was rather expected.

Microsoft is hard at work on adding RTC to Edge – be it ORTC or WebRTC – or both.

The main UC and consumer messaging service of Microsoft are based on Skype, so it is only reasonable to assume that Skype would be utilizing Edge capabilities in this are AND that Edge would be accommodating for Skype’s needs.

This accommodation comes by way of the first video codec that Edge supports – H.264UC – Skype’s own proprietary video codec. Edge doesn’t interoperate with any other browser when it comes to video calling due to this decision. In a way, The Edge team sacrificed interoperability for Skype support.

Browser vendors tend to care for themselves first. And then for the rest of the industry:

• Google Chrome does that by having undocumented features for Google Hangouts
• Mozilla Firefox does that by working with Cisco on H.264 & Telefonica on Hello
• Microsoft Edge does that by sacrificing video interoperability for Skype support
• Apple Safari does that… by not doing WebRTC favoring its FaceTime?

Google Hangouts route to plugin-less world

Hangouts today is in the same predicament as Skype in a lot of ways.

1. Its support for the browser of the mothership is native (Chrome-Hangouts; Microsoft-Skype)
2. Both require plugins on browsers other than their own – and will stay that way for the forseable future
3. Both are no consumer/enterprise services, trying to cater both
4. Both aren’t as big or as active as their newer competitors (Facebook, WhatsApp and WeChat to be specific)

Where do they diverge?

No Plugin+SDK=Interesting

Skype has added the SDK bit before Hangouts.

Skype now offers its large user base and infrastructure to 3rd party developers to build their own services. The documentation is quite extensive (too much to go through to get things done if you ask me – especially compared to the WebRTC API platforms) and the intent is clear.

Skype doesn’t have a glorious record with developers. Maybe this time around it will be different.

And it added bots.

They did that ahead of the rumored bot support by Google.

Where’s Hangouts?

Meanwhile, Hangouts is just the same as it were two or three years ago.

The backend probably changed. It now sometimes do P2P calling. And it has a new UI. And the old one. And you can never know which one will pop up for you. Or where to write (or read) that text message.

Something needs to change and improve with Hangouts.

Skype seems to be moving forward at a nice pace. Cisco Spark has its own forward motion.

But Hangouts has stalled – especially considering we’re talking about Google – a company that can move at breakneck speeds when needed.

I wonder what’s ahead of us from both these services.

The post Skype will go the Hangouts Route with WebRTC (or vice versa?) appeared first on BlogGeek.me.

Since July, 2013, the W3C Object Real-Time Communications (ORTC) Community Group has been actively working on a next generation WebRTC API, called ORTC. Robin will discuss the latest updates of the ORTC API, the remaining challenge areas, and the implementation status of ORTC-lib. And he will show the detailed event capabilities for ORTC-lib.

Links:
http://ortc.org/
http://hookflash.com/

Two weeks ago Microsoft’s Bernard Aboba (and former webrtcHack’s interviewee) gave an update on Edge’s ORTC and WebRTC at the Microsoft Build conference. He covered some big topics including VP8 and WebRTC 1.0 support. You can see the update video here or read the follow-up post for details. Then last week Microsoft announced plug-in free Skype […]

The post Sharpening the Edge – extended Q&A with Microsoft for RTC devs appeared first on webrtcHacks.

isVisible=false; function show_hide_searchbox(w){ if(isVisible){ document.getElementById('filterBoxSelection').style.display = 'none'; w.innerText='Filter ▼'; }else{ document.getElementById('filterBoxSelection').style.display = 'block'; w.innerText='Filter ▲'; } isVisible=!isVisible; } function checkIfSelected(chk){ if(chk.checked==1) chk.parentNode.className = "selected"; else chk.parentNode.className = "notselected"; getSelectedValues(); } function getSelectedValues(){ var a=document.getElementsByClassName('selected'); var vtVal=[] , ctVal=[] , ftVal=[]; var ct=0,vt=0,ft=0; for (x = 0; x < a.length; ++x) { try{ if(a[x].getElementsByTagName('input')[0].className=='companyType'){ ctVal[ct]= a[x].getElementsByTagName('input')[0].value; ct++; } if(a[x].getElementsByTagName('input')[0].className=='vendorType'){ vtVal[vt]= a[x].getElementsByTagName('input')[0].value; vt++; } if(a[x].getElementsByTagName('input')[0].className=='focusType'){ ftVal[ft]= a[x].getElementsByTagName('input')[0].value; ft++; } }catch(err){ } } search_VType(vtVal); search_CType(ctVal); search_FType(ftVal); } function search_VType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null){ a[x].style.display='block'; } } if(val.length==0){ a[x].style.display='block'; } } } function search_CType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } } function search_FType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } }Check out all webRTC interviews >>

BancSpace: Lori Van Deloo

April 2016

Banking

Vertical

Small

Voice, Video, Data

Banking and WebRTC done right.

[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]

I had my fair share of demos where a banking or a contact center application felt boring and Spartan. Too many times, the focus is on how to get video to show and when that happens – the developers are so happy they forget about the bigger picture – the service.

When I met Lori Van Deloo, Founder & CEO of BancSpace, I thought I was in for the same kind of an experience. But boy, was I wrong. She started off in the best way possible. She just explained that she worked for many years at VISA and then decided to found BancSpace. This is always a good sign – a founder who comes from the vertical he or she wants to serve instead of a VoIP engineer who decides to fix and disrupt industries.

The rest of the demo was an eye opener on how things could be done in a way that looks so simple but is devilishly complex. I of course wanted an interview, and Lori was kind enough to oblige.

 

What is BancSpace all about?

BancSpace is a WebRTC digital banking communications and collaboration platform that facilitates live access and engagement with qualified specialists, anytime, anywhere.

Prior to founding BancSpace, I spent a number of years working in software, including mobile and most recently, payments.  These and other technologies have become increasingly important in the delivery of financial services for both consumers and businesses.  However, when it comes to critical decisions or complex tasks, many prefer to consult with an expert to get financial advice or to get assistance such as when opening an account or applying for a loan.  The idea behind BancSpace is to allow Financial Services providers to deliver innovative customer experiences that combine both – the best of digital technology and live service expertise.

BancSpace provides a full suite of real-time capabilities to enable advisors/specialists to connect and collaborate with their customers just as if they were meeting face-to-face.  It’s basically video banking + deep, two-way collaboration.  Since the service is cloud-based, both advisors and customers can access the platform from any device (and thanks to WebRTC, no downloads or plugins on either side!)

Having spent more than a decade working closely with large Financial Institutions, we also knew that any service we developed must address industry needs for greater management and controls.  As such, multiple layers of authentication, security and permissions have been built into the BancSpace service platform.  These additional features help support compliance with industry standards to confirm a customer’s identity and help protect the access to and exchange of information during a BancSpace session.

  

Why WebRTC, and why in banking?

Unlike other communications technologies, WebRTC was purpose-built from inception to specifically address security considerations through the framework of the WebRTC technology architecture.  For example, encryption is a mandatory feature of all data and media streams sent over WebRTC.  Features like this are especially important when you are working in highly sensitive, highly regulated environments such as banking and other financial services.

We also chose WebRTC for its ability to deliver on the important benefits of quality and convenience.  The real-time nature results in a high quality voice-video-data exchange, and the convenience of no downloads / no plugins makes for a superior customer experience.

 

Backend. What technologies and architecture are you using there?

We have developed an intricate service platform that integrates a number of different technologies and a proprietary advisor-customer interaction model.  Our developers are strong advocates for node.js.  It is great for use with WebRTC, as well as more broadly to support our full suite of real-time collaboration capabilities.  The underlying service architecture also includes support for managing the controls and permissions that govern the access and use of the service.

 

In your service, you have an interesting co-browsing and collaboration mechanism. Can you elaborate a bit about it?

Yes.  Our two-way collaboration workspace is a core aspect of the BancSpace service.  The workspace allows advisors or specialists to engage and assist their customers to immediately complete important tasks or transactions, all in a secure 1:1 session.

A number of services provide one-way screen sharing tools or applications, but as we looked at the requirements for our customers’ use cases, we needed a solution that went well beyond that.  It called for something that enabled a more intimate, two-way interaction because our goal was to replicate the same high quality, engaging experience that typically has been associated with in-person or in-branch service and then extend it to every customer interaction, on any device.

We also needed something that was more secure in terms of managing session content.  The basic “open desktop” format offered by other services just doesn’t work for many Financial Services transactions.  Think about how many times someone running an online meeting inadvertently shared the wrong file?  Or had a personal email or IM pop up in the middle of a meeting?  BancSpace’s approach allows providers to completely prevent these issues and only allow approved content to be shared in a given session.

 

Where do you see WebRTC going in 2-5 years?

For WebRTC-based vertical applications it is still early days.  Especially for those in highly regulated industries, WebRTC needs to be viewed within the broader technology adoption landscape – many Financial Services providers are still getting comfortable with cloud and SaaS.  Focused pilots and test programs will be important for applications in Financial Services to ensure bank-grade quality before expanding to full, generally available (GA) services.  A real opportunity to accelerate efforts here is for leading Financial Services providers to partner with Fintech-focused start-ups developing WebRTC-based applications and establish a beachhead for the industry.

Getting to an agreed standard with ubiquitous access for all end-customers is also critically important for driving enterprise adoption.  Financial Institutions, and really any large enterprise, need to be able to provide solutions that serve their broader customer base (not just the majority), and do so in a way that maintains a consistent experience for customers across any channel.  It’s also more efficient from a back-office operational perspective.

 

If you had one piece of advice for those thinking of adopting WebRTC, what would it be?

If you are thinking about creating a mobile/web application or service that includes WebRTC, it’s important to understand the problems that your clients are trying to solve.  WebRTC is an enabling technology and we believe a foundational one, but consideration should be given for how to best incorporate it into the design of your service to ensure it delivers the desired functionality and provides a great experience.  Once this is determined, then there is much to be leveraged from the vast resources, libraries and community supporting WebRTC globally.

For BancSpace, we are 100% focused on the end customer experience (CX).  Any WebRTC functionality we include must address a specific need and support the scenarios for which our clients are looking to employ our service. We then spend time on the UX design so that using our service (and WebRTC) is an effortless experience for both advisors and customers.

 

Given the opportunity, what would you change in WebRTC?

Our experience with WebRTC has been very positive thus far, especially when you compare to the early days of video banking.  For years the industry has been experimenting with various instantiations of video banking applications.  WebRTC unlocks the potential to truly bring together technology + live expertise and provide a modern, cost-effective option for Financial Institutions to expand their footprint without the legacy CAPEX and OPEX of a fixed, physical branch network.

So what would I change?  Well, I guess continuing to drive toward a foundational set of standards so that WebRTC can become a ubiquitous enabling technology.

 

What’s next for BancSpace?

Driving the next wave of Digital Banking!  The ability to combine communications and collaboration technologies with live expertise is allowing us to re-imagine the delivery of Financial Services in ways that can have immediate impact on growth.

We are actively engaged with Financial Institutions and other Financial Services providers, and believe there is a real opportunity to reinvent the advisor-customer experience.  WebRTC is central to this proposition and we expect it will play an increasingly important role in the BancSpace technology strategy as we expand our use of it and create new capabilities to support a growing client base.

–

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.

The post BancSpace and WebRTC: An Interview With Lori Van Deloo appeared first on BlogGeek.me.

Since July, 2013, the W3C Object Real-Time Communications (ORTC) Community Group has been actively working on a next generation WebRTC API, called ORTC. Robin will discuss the latest updates of the ORTC API, the remaining challenge areas, and the implementation status of ORTC-lib. I will show the detailed event capabilities for ORTC-lib.Links:
http://ortc.org/
http://hookflash.com/

Time is passing and Kamailio World Conference 2016 is approaching at fast pace – only four weeks left till the start of the event!The schedule is pretty much nailed down, with some adjustments still expected to happen. The event starts like the past edition with a half a day of technical workshops, followed by two full conference days.A larger group of speakers is participating to this edition. There was a big number of speaking proposals and we wanted to highlight more of the people that had a relevant contribution to the evolution of the project. To accommodate properly, two more discussion panels were added, keeping also the classic VUC panel.The topics cover many of the interesting aspects of real time communications, from security and scalability to WebRTC and VoLTE, touching Kamailio and other open source projects like Asterisk or FreeSwitch.More details can be found on the website of the event:

• https://www.kamailioworld.com

Don’t forget that this year Kamailio celebrates 15 years of development, the party is at Kamailio World!We expect to fill the capacity of the conference room, if you haven’t registered yet and plan to attend, do it as soon as possible to secure your seat!Many thanks to our sponsors that made possible this event: FhG Fokus, Asipto, Sipwise, Matrix.org, Sipgate, Simwood, NG Voice, Digium, VoiceTel, Evariste Systems, Core Network Dynamics, Pascom, Didx.net.Thank you for flying Kamailio and looking forward to meeting many of you at Kamailio World 2016!

This week mod_hiredis had some wonderful improvements and the addition of session logging added to it.

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-9052 [mod_hiredis] Add connection pooling, improve dropped connection resiliency, and allow 0.10.0 of hiredis for CentOS 6
• FS-9054 [mod_hiredis] Add ignore-connect-fail profile parameter so that calls do not get killed if limit fails due to lost connection
• FS-9059 [mod_hiredis] Add session logging
• FS-9050 [avmd] Fixed APP interface so avmd now exposes single avmd_start_function() for handling APP calls and splits the function into independent calls
• FS-9039 [avmd] Use FS enumeration
• FS-9072 [mod_syslog] Allow logging of messages containing tab character
• FS-9077 [mod_verto] Adding verto_hangup_disposition variable to indicate who hangup

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

• FS-9075 [Debian] Re-worked the freeswitch-all package

The following bugs were squashed:

• FS-7317 [mod_event_socket] Fixed a hang caused by a series of blocks
• FS-9049 [mod_sofia] Fixed a DTMF issue
• FS-9058 [mod_hiredis] Allow auto decrement of non-interval limits on channel hangup and fixed rate counters so the keys expire after interval completes. Do not auto decrement rate counters. Do not log null responses.
• FS-9056 [mod_av] Fixed an issue causing mobile H.264 video to be blank
• FS-9074 [mod_skinny] Fixed incorrect location of free causing memory leak of xml when certain errors occur
• FS-8949 [core] Fixed an issue with the send end packet for DTMF RTP event not being recognized

The next Kamailio Devel Meeting on IRC has been planned for Thursday, April 21, 2016, at 14:00UTC (10:00 New York, 15:00 London, 16:00 Berlin), on #kamailio channel from freenode.net.As usual, it will be a chat session between all Kamailio community members, developers and users, to discuss the plans to next major releases and various admin bits related to the project. This time we are talking about Kamailio 5.0, which aims to bring some significant features, including the ability to write all the routing logic in a well known scripting language (e.g., Lua, Python), with the option to reload it without a restart and, of course, offering a larger set of statements, libraries and tools around it. The old config file will stay in place as well.A wiki page was set up to collect the topics and other details about the meeting:

• https://www.kamailio.org/wiki/devel/irc-meetings/2016a

Among announced participants: Alex Balashov, Daniel-Constantin Mierla, Fred Posner, Olle E. Johansson, Victor Seva.If have something to discuss, do not hesitate to add your topics and list your name in the page. Anyone can participate, even only for watching the discussions.

We can do better.

In 2012, when I started this blog, I had only 3 WebRTC related posts in mind. One of them was about the room system of the future. While this has never materialized in the 4 years since, things have definitely changed in the video conferencing space.

Let’s see what video conferencing vendors have done about WebRTC so far (vendors are listed in alphabetical order).

Avaya

Avaya’s assets in video conferencing comes from its acquisition of RADVISION.

A quick glance at the current website specs for its video conferencing line of products (mainly SCOPIA) shows a rather sad story. SCOPIA offers the best money can get, assuming we were 4 years after 2012 and WebRTC didn’t exist.

As the website states, you can “Experience crisp, smooth video quality with resolutions up to 1080p/60fps, stellar bandwidth efficiency, and error resiliency with H.265 High Efficiency Video Coding (HEVC) and Scalable Video Coding (SVC).”

Bolded tech words are my own.

Some things to note:

• 1080p is great, and the “de facto” thing these days – if you have the juice and the bandwidth for it. 60fps is more than 30fps, but I wonder if it is worth the additional effort to get there
• H.265 is betting the farm on the wrong codec
• SVC is where we’re headed. Getting one out of 3 main bullet points correct is a good start

Cynicism aside, I have it from good sources that Avaya is working on adding WebRTC support to its gear. Where exactly does it fit in its bigger picture, and why so late is a different story altogether.

What bugs me the most here is that in the last 4 years, any advancement in the SCOPIA video conferencing product line was reliant solely on hardware capabilities. You can’t leapfrog in this way over competitors – especially when something like WebRTC comes into the scene.

It is sad, especially since Avaya does work and promote WebRTC in contact centers already. At least on the press release level.

Cisco

Cisco is a large and confusing company. If you look at its telepresence products, they resemble the ones coming from Avaya. Same highlights about speeds and feeds.

On the other hand, Cisco has thrown its weight behind a new product/service called Cisco Spark.

Cisco Spark is a Slack lookalike with a focus on voice and video communications by connecting to the massive line of products Cisco has in this domain. Cisco Spark uses WebRTC to drive its calling capabilities in browsers. What Spark enables is connectivity from web browsers using WebRTC to Cisco video conferencing products.

Cisco took the approach of using H.264, making it work only on Firefox and in future Chrome versions (unless you run the new Chrome 50 from command line with the necessary parameter to enable H.264).

Cisco has also been heavily investing in acquiring and nurturing its WebRTC chops:

• Tropo acquisition, to get an API and a developer ecosystem for Spark
• Acano acquisition, which fits perfectly well in offering native browser access to its existing infrastructure
• Spark fund, with $150M to entice developers to use its APIs

Cisco has a huge ship to steer away from hardware and it is pouring the money necessary to take it there.

Google Hangouts

WebRTC. Chrome. Hangouts. Google. All connected.

Google invested in WebRTC partly for its Hangouts service.

Today, Hangouts is using WebRTC natively in Chrome and uses a plugin elsewhere – until the specific support it needs is available on other browsers.

Google also introduced its Chromebox, its take on the room system. I am not sure how successful Chromebox is, but is refreshing to see it with all the high end systems out there that don’t know a word in WebRTC. It would have been nicer still if it could use any WebRTC service and not be tied to Hangouts.

The problem with Hangouts is its identity. Is it a consumer product or an enterprise product? This is hurting Hangouts adoption.

Lifesize

Lifesize was a Logitech division. It was focused on selling hardware room systems.

In 2014, Lifesize launched its own cloud service, starting to break from the traditional path of only selling on premise equipment and actually offering a video conferencing service.

In 2015, it introduced its WebRTC support, by enabling browsers to join its service via WebRTC – and connect to any room system while doing so.

2016 started with Lifesize leaving from the Logitech mothership and becoming an independent company.

Microsoft Skype

Skype has done nothing interesting until 2015. At least not when it comes to WebRTC. And then things changed.

Skype for Business, Skype for Web and the Skype SDK were all introduced recently.

Skype for Web started off as a plugin, which now runs natively on Microsoft Edge – the same initial steps Google took with Hangouts.

My own take here:

• Skype is investing in switching its backend and modernize it to fit something like WebRTC
• This process is taking too long, and probably isn’t coordinated properly
• It is coming, and it will give Skype a lot of flexibility in where to go and what to do next

Polycom

Or should I say Mitel?

Polycom added WebRTC support in its launch of RealPresence Web Suite. In traditional enterprise video conferencing fashion, it seems like a gateway that connects the browser to its existing set of products and tools.

At almost the same time, Polycom shed its Israel office, responsible for its MCU. This is telling as to how transformative is WebRTC in this market.

Vidyo

Vidyo had a love-hate relationship with WebRTC throughout the years but has done a lot of work in this space:

• In 2013, it announced collaborating with Google to bring SVC to WebRTC
• In 2014, it joined Google’s Chromebox release with its own VidyoH2O gateway
• In 2015 they launched a WebRTC server enabling application developers to integrate WebRTC calls into the Vidyo infrastructure
• In 2015, the company has also gone through management changes, replacing its CEO Ofer Shapiro (now a vice chairman) with Eran Westman. This brought with it new thinking
• 2016 started with Video launchng their VCaaS and PaaS cloud offerings

2016? Two things already happened this year with WebRTC:

1. VP9 is now in Chrome and Firefox for WebRTC, with plans of adding SVC to it. This is something that Google and Vidyo are working on together
2. Vidyo launched their VCaaS and PaaS cloud offerings

In a way, Vidyo is well positioned with its SVC partnership with Google to offer the best quality service the moment Chrome supports VP9/SVC. They also seem to be the only video conferencing vendor actively working on and with VP9 as well as supporting both VP8 and H.264. Others seem to be happy with H.264/VP8 or running after H.265 at the moment.

The New Entrants

There are also some new entrants into this field. Ones that started at the time WebRTC came to being or later. The ones I am interested in here are those that connect to enterprise video conferencing systems.

These include Unify, Pexip, Videxio and many others.

What defines them is their reliance on the cloud, and in many cases the use of WebRTC.

They also don’t “do” room systems. They are connecting to existing ones from other vendors, focusing on building the backend – and yes – offering software connectivity through browsers, plugins and applications.

My room system dreams

I’ll have to wait for my WebRTC room system for a few more years.

Until then, it is good to see progress.

The post How Video Conferencing Vendors Adapt to WebRTC? appeared first on BlogGeek.me.

Let’s Encrypt is a free certificate authority launched in the second part of 2015, recently leaving the beta stage – from September 2015 to April 2016, they issued over 1.7 millions certificates.Started by Mozilla and backed up by big IT players and organization (e.g., Internet Society, Cisco, HP, Microsoft, Facebook, …), it offers free TLS certificates that are trusted by all the major operating systems and browsers out there. In other words, you don’t have to pay for a TLS certificate, meaning that it is no reason to support HTTPS for your web server and SIP over TLS for your VoIP service.Our Fred Posner made a blog article showing how simple is to deploy a Let’s Encrypt certificate for Kamailio – you can read it at:

• http://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/

Kamailio has one of the best and scalable TLS implementations, with asynchronous support since 2008, already deployed by large IM mobile services servicing millions of active users. If you don’t have TLS enabled in your Kamailio, it’s time to act, it costs nothing now and brings full privacy to your customers connecting over the public internet!Of course, kamailio.org website is already using a Let’s Encrypt certificate.Thank you for flying Kamailio! And looking forward to meet some of you at Kamailio World Conference 2016!

Why and where do we use SVC exactly?

[When Alex Eleftheriadis, Ph.D., the Chief Scientist & Co-founder of Vidyo, approached me about writing a piece about SVC and WebRTC – how could I refuse? Someone had to give the explanation, and what better person than Alex to do that?]

Just when the infamous WebRTC video codec debate appears to have been settled, with both H.264 and VP8 being set as mandatory-to-implement by browsers, VP9 has started making inroads into the WebRTC software stack and into browsers themselves. Indeed, Chrome 48 includes, for the first time, VP9 support for WebRTC. Firefox also includes support for it in WebRTC in the Developer Version of Firefox 46.

Why is this relevant for the WebRTC community – users and developers? First off, VP9 offers significantly better compression efficiency compared with H.264, and even more so compared with VP8. This translates to better quality for the same bit rate, or a lower bit rate for the same quality (as low as 50%). This by itself is a big plus, but it does not tell even half of the story.

The Need for Scalability

When using WebRTC beyond two-way, peer-to-peer calls, or in networks with significant quality problems, system architects are encountering the same design issues that the videoconferencing industry has been dealing with for a long time now. It is not accidental then that WebRTC solutions designed for multi-point video gravitate towards those offered in videoconferencing, or that videoconferencing companies are adapting their systems to become WebRTC solutions. For the latter, this typically entails aligning with transport-level, security, and NAT traversal specifications, and of course providing a JavaScript library that enables WebRTC-enabled browsers to use their system’s facilities.

If we look at today’s architectural landscape for high-quality multi-point video, there are two main designs. One is based on transmission of a single stream of scalable coded video. Scalable means that the same bitstream contains subsets, called layers, that allow you to reconstruct the original at different resolutions. If you get the lowest, or base, layer you can decode the video at a certain resolution, whereas if you also get a higher, or enhancement layer, you can decode the video at a higher resolution. This is great for robustness and adaptability, because you do not need to process the video at all to get at the different resolutions.

The second design is based on simulcast transmission of two separate streams that encode the same video at different resolutions. Contrary to the scalable design, here we have two encoding passes rather than one, with the associated streams requiring a higher bitrate compared with scalable coding. It is also less error resilient. On the plus side, however, simulcast allows the use of older, non-scalable decoders. This has been an important consideration for systems that interface with legacy devices (not relevant for WebRTC).

Single Layer, Scalable, and Simulast Coding of Video. In scalable coding the various layers (“a” and “A”) are multiplexed in a single stream. In simulcast two or more independently encoded streams are produced and are transmitted separately.

Both of these designs utilize a special type of server for which I have coined the term “Selective Forwarding Unit” (SFU). This type of server was not known when the original RTP Topologies RFC was published in 2008 (RFC 5117), but it is now included in its 2015 update, RFC 7667.

The operation of the SFU, using the VidyoRouter as an example. In the diagram the SFU receives three scalable streams, and it selects to forward the full resolution for the blue participant (base and enhancement layers), but only the base layer for the green and yellow participants.

The SFU works in the following way: it receives scalable or simulcast video, and it decides which layer or which stream to forward to a receiving participant. There is no signal processing involved, and the operation incurs very little delay (less than 10 ms is typical). If we contrast this with the traditional architectures that are still being used and involve transcoding of multiple videos, the advantages are obvious – both in terms of processing complexity but also in terms of delay (150 ms delays would be typical for the traditional architectures). Minimizing delay is hugely important for perfecting the end-user experience.

What is interesting is also how the receiving endpoint operates. Contrary to legacy videoconferencing systems, it receives multiple streams that it has to individually decode, compose, and display on the screen. This multi-stream architecture perfectly matches WebRTC’s design.

The multi-stream architecture of an SFU endpoint – the endpoint receives multiple video streams that it has to individually decode, and composite on the user’s screen.

To appreciate the significance of these architectures it suffices to point out that both Skype for Business and Google+ Hangouts use simulcasting (of H.264 and VP8, respectively). So does the open source VideoBridge by Jitsi. Vidyo, which first introduced the concept in its VidyoRouter product in 2008, is using scalability (with H.264 SVC). Simulcast support is now in the scope of the WebRTC 1.0 specification and it is being actively worked upon. Scalable coding is already supported by the ORTC specification, and will be addressed in WebRTC-NV (post 1.0).

Scalability, SVC and VP9

Now we can turn back to our original question regarding scalability and VP9. If you want to be able to use an SFU architecture with scalable coding, the codec itself must support scalability. That’s why back in 2013 Vidyo announced that it would be collaborating with Google to develop a scalable extension for the VP9 codec. This effort is now bearing fruits.

One may ask, “why care about VP9, I will just use whatever stock codec my browser has and be done with it.” The answer is that you do want to care, when quality matters. Depending on the codec used, and the type of multi-point server architecture deployed, the end user will get a vastly different quality of experience.

We can think of the WebRTC endpoint as a kitchen that has a bunch of ingredients. If your expectations are low, you can go for the raw vegetables and have a meal in no time. If you want a fine meal, you will want both the right ingredients as well as the right recipe. The standardization process will ensure that the WebRTC kitchen has all the right ingredients. The recipe and, in fact, the cook, are all part of whoever is offering the service. By taking into account all the realities of imperfect network transmission, heterogeneous clients, mobility, etc., they make sure that the users enjoy a great experience. If you go with a proprietary solution, you can then add plenty of secret sauce.

Endpoint Quality Scale: One ordering of relative quality of different codec and endpoint engine combinations.

Taking into account the different combinations of video codecs and endpoint engines, I put together an “Endpoint Quality Scale” diagram, shown above. You can think of it as the skeleton of the multi-point video kitchen menu. Vidyo is vigorously trying to be the three Michelin star restaurant; its proprietary engine uses a lot of secret sauce in addition to the standard ingredients. But together with the industry as a whole we want to make sure that the menu, especially when it comes to WebRTC, offers something for all tastes and price ranges.

Bottom line, when people select platform providers for their WebRTC-based solutions they need to be aware of these differences and, especially when quality matters, make an educated and well-informed choice. Bon appetit.

The post Scalability, VP9, and what it means for WebRTC appeared first on BlogGeek.me.

This week we had a number of wonderful improvements to mod_avmd as well as more work toward languages in mod_verto.

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-9019 [avmd] Extend syntax description to include “[start|stop]” at the end of AVMD_SYNTAX ” ”
• FS-9023 [avmd] Add console auto completion
• FS-9020 [avmd] Implement checking of proper configuration of avmd session being started on internal/external channels. Check for read/write codec, CF_MEDIA_SET
• FS-9027 [avmd] Remove assertion from INIT_CIRC_BUFFER and check buffer’s pointer to raw memory dynamically
• FS-9028 [avmd] Check SMA buffer for successful memory allocation
• FS-9031 [avmd] Check session initialization for errors
• FS-9038 [verto] Add translations to support Danish
• FS-9006 [verto_communicator] Add-combobox for languages
• FS-9025 [mod_callcenter] Bypass_media_after_bridge working for member channel
• FS-9043 [mod_kazoo] Add kz_export of multiple variables instead of calling export application

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

• FS-9000 [build] Fixed compiling on bsd and with libyuv disabled
• FS-8883 [build] Fixed compiling due to unused result failure on gnu compiler with –disable-debug
• FS-8780 [build] Fixed the include for Windows builds that point to in tree library
• FS-8623 [build] Fixed Solaris studio build errors building libvpx
• FS-8779 [Windows] Fixed the include for Windows builds that point to in tree library
• FS-8875 [mod_avmd] Fixed the windows build from this change
• FS-9036 [avmd] Fix warnings on Windows builds

The following bugs were squashed:

• FS-9015 [verto_communicator] Minor fixes in Polish translation
• FS-9016 [mod_avmd] Fixed a segfault on NULL read codec
• FS-8562 [mod_sofia] Add update support for Mitel user agents
• FS-8294 [freetdm] Pass in modinstdir to freetdm configure
• FS-8623 [configure] Fixed an issue with a necessary flag having issues with the libvpx configure
• FS-9042 [core] Fixed assert when recording native file

Today, the core architects of the Kazoo platform are in Milwaukee, WI working with the amazing FreeSWITCH team. The FreeSWITCH team runs an awesome open-source project that is on the bleeding edge of communications - always. Their software, libraries and RTP integrations allow us to power the audio portions of your call, and we’re working together to allow video and other features, too.

This year, our focus is on optimizing how Kazoo and FreeSWITCH integrate. We hope to expose more FreeSWITCH features natively. Our talks today will help shape the future of the Kazoo project in that regard.

We’re pleased to continue working with, and supporting where we can, the FreeSWITCH project. If you’re interested in learning more about the inner workings of how components of Kazoo work - FreeSWITCH being one of them - we’d encourage you to come to one of our upcoming FreeSWITCH trainings  or to join the FreeSWITCH team at their annual ClueCon conference in Chicago.