News from Industry

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.

Forecasts are overrated.

I’ve been asked time and again things related to the market sizing of WebRTC, and I’ve tried to shy away from it all the time. The Dilbert strip above explains why…

This whole notion of estimating the size of a market that is, to be frank, hard to define, without solid numbers, too new – all lead to the question: why bother?

What are you looking for? The market size of WebRTC contact centers? Is that only for the WebRTC piece of it? Greenfield ones? With or without call widgets in tiny WordPress sites? How do you place the monetary value on it? Is it the WebRTC part or the whole contact center you’re interested in? Do you want the number to amount to a billion $ and go backwards from there so it fits your desired strategy?

All useless.

2 billion users. X% CAGR. 15% YoY growth.

Sure.

Any day.

With something like WebRTC, such things are close to impossible as far as I can say, and probably not really worth it. Need to throw a number in the air? Generate it randomly.  It’s good enough for the TSA then why not for you?

Which leads me to something you won’t find in my WebRTC PaaS report – the one dealing with the WebRTC API market and assists developers in understanding if they should use a vendor and help picking up the right vendor (if that’s the course selected). These estimates don’t help in such a case. They are worse than useless.

Need estimates? Find some other report online. They will happily share their guesstimates in press releases out there (seen a few lately) so you can decide if it is worth paying for to get that “validation” you need for your management.

Need to make real decisions on how and what to implement? That probably won’t be in these reports.

The post You Won’t Find Guesstimates in My WebRTC PaaS Report appeared first on BlogGeek.me.

Losing customers because of issues with your network service is a bad thing. Sure you can gather data and try to prevent, but isn’t it better to prevent issues in the first place? What are the most common pitfalls to look out for? What’s a good benchmark? What WebRTC-specific user experience elements should you spend […]

The post The Big Churn – learning from real usage stats (Lasse Lumiaho and Varun Singh) appeared first on webrtcHacks.

There’s progress, but the real action will be in 2017.

There has been a lot of chatter lately around Apple’s snail-like progress in supporting WebRTC and Microsoft’s announcements at their BUILD conference. I am still left under-impressed but positive and confident. Here’s why.

Apple and WebRTC

Let’s start with Apple. The only official statement we will get from Apple will be “we have WebRTC”. Question is when, for what and if at all.

We have indications of progress in Apple, and Alex is keeping us updated on the goings with Apple and WebRTC.

I think Itay Rosenfeld  is making a good case why Apple needs WebRTC more than WebRTC needs Apple.

So we know WebRTC is of interest to Apple and we know it is being added to Safari.

We know one more thing. Apple is actually trying to refresh and update its Safari browser. Dare I say “modernize” it. They even recently started a Technology Preview for Safari, joining the rest of the gang of browser vendors to showcase their upcoming plans and intentions. That doesn’t include WebRTC, but WebKit indicates WebRTC as “in development” – and WebKit is the rendering engine used by Safari.

Will Safari include WebRTC? Yes.

When? My guess is end of 2016.

What will it include? WebRTC. H.264. No VPx “nonsense”.

Where? On Mac OS X, but not on iOS. That one will come in 2017.

Microsoft’s Romance with xRTC

Microsoft added ORTC to Edge. I shared my view about Edge already. To sum it up – great browser. No adoption.

To date, there has been little adoption of Edge/ORTC by vendors. If my memory serves me right, adopters include Twilio, &yet and Frozen Mountain. That’s less them impressive. And Microsoft knows that.

The problem here isn’t ORTC. It is Edge. And Microsoft seems to miss that minor detail.

At the recent Microsoft BUILD conference, a few announcement were made (thanks @hcornflower for the tip):

"We now have more than 150 million monthly active devices using Microsoft Edge" — @morris_charles #EdgeWebSummit pic.twitter.com/2q4ZVFeF9k

— Kenneth Auchenberg (@auchenberg) April 4, 2016

So. “150 million” monthly active devices. But no monthly minutes as in their last disclosure. I wonder what monthly active means and how many of them open it up just to get to IE when Chrome doesn’t work. I know that’s how I use it to get to a Silverlight site that my kid wants to use.

I guess this number was high and positive that the managers at Microsoft decided to focus on it instead of the more important number of average use time per user. This led them to this decision:

MS announces new WebRTC goodies coming to Edge:
H.264/AVC, VP8, MediaRecorder, DTLS 1.2, ECDSA certs pic.twitter.com/jDwRug2F13

— Justin Uberti (@juberti) April 4, 2016

1. Adding WebRTC and not ignoring it with an implementation of only ORTC. At long last, they got sense and decided to make it easier for developers to support Edge instead of having developers look at the abysmal market share of Edge. The challenge they face is that people who switch to Windows 10 opt for Chrome over Edge more often than not, and in the enterprise die hards stick with IE. Until this trend changes, there’s a real issue here
2. Supporting H.264, and not only their interanl H.264UC proprietary codec. This makes sense, as Chrome is adding H.264 and Firefox is already supporting it
3. VP8 is “under consideration”, so we will have it after H.264. Probably somewhere into 2017. Too late
4. No VP9. With current development speeds, I can see VP9 getting adopted en mass in many use cases and Microsoft Edge staying behind, with no Edge

It would have been better to just add WebRTC to IE11 in parallel than to entice users to switch altogether to Chrome.

When will vendors need to revisit Edge when it comes to WebRTC? Not before Q4 2016.

Microsoft Skype

Skype is interesting. Late to the market. 300 million active users. A lot, but unimpressive if you compare to the leading consumer communication services that are out there.

Skype for Web is what Google Hangouts did the first two or three years of WebRTC’s existence – took components of the WebRTC implementations, modified it to fit their needs and made a plugin for Hangouts out of it. Until they just made it “native” to the browser when they could.

As written in a recent comment I’ve read – they should have done this 5 years ago, but better late than never.

The more interesting part here is the newly minted Skype SDK. I think this is Skype’s third attempt at an SDK – there may have been more. Previous ones were failures. Not because of lack of adoption, but rather because the way developers were treated. This doesn’t bode well for this round. Especially not if you couple it with the current numbers and the size of Skype.

That said, I can easily see Lync/Skype for Business enterprises adopting the SDK to deal with customer support related requirements, taking a bit of the market from WebRTC PaaS vendors. To go beyond this use case, it will take more effort from Microsoft.

The Microsoft Skype for Web and SDK initiatives need to be viewed in the light of other players as well.

Cisco Spark

Cisco Spark (along with their Telepresence and UC offering) goes head to head against Lync/Skype for Business.

Cisco made several interesting moves lately:

• Acquired Tropo, to beef its Communication APIs and integrate them with Spark
• Acquired Acano, which fits nicely into high-end paying customers who use WebRTC
• Acquired Synata, to offer better search capabilities to Spark, to better compete with Slack
• Created the Cisco Spark Innovation Fund, and placed $150 million to developers building use cases on top of Spark

That’s a lot of milage to go against Skype for Web and the Skype SDK.

You can easily say that when it comes to publicizing and marketing their investment in communication services and enables, Cisco is ahead of Microsoft.

Google Hangouts

Google Hangouts is a shadow of what it can be when it comes to usage.

As a platform, it has it all. Everything you need to communicate, at a fraction of the cost of other solutions or for free. We use it daily at testRTC – both internally and to host meetings with customers and potential customers. We have no incentive to switch to anything else.

Hangouts adopted WebRTC from the beginning. First by embedding the WebRTC stack into the Hangouts plugin, using the components of WebRTC that it could, until it was able to just use WebRTC natively in Chrome. It still runs as a plugin on other browsers, but I assume that will change when WebRTC will be supported with all of the nuances of Hangouts.

What Hangouts is lacking is the traffic and the APIs to go along with its service. I am assuming Google are aware of it.

Apple FaceTime

Apple has FaceTime. Its proprietary service that should have been standardized at some point.

I’ll be surprised if Apple did anything interesting or serious when it comes to connecting FaceTime to WebRTC or adding an SDK to it. Or god forbid, let the poor people of the world who use Android – or a 5 year old Windows PC, connect to FaceTime.

Slack

Slack just added voice support with WebRTC and intends to add video. I’ve written about Slack a few times before, and how WebRTC is a logical investment for them. If they add integration points in their API that can access their real time communication capabilities it might become a very interesting player in the SDK/API space.

The real question in this case: Will a vendor using Slack continue using Skype in the long run?

Facebook and WhatsApp

Facebook Messenger uses WebRTC. WhatsApp somewhat uses it.

Skype has 300 million monthly active users. That’s way smaller than WhatsApp’s billion and Messenger’s 800 million. I am assuming there’s more voice and video calling happening on Skype on average per user than on either Messenger or WhatsApp, but the trend is probably towards Facebook and not Microsoft here.

The reason Facebook is so strong here is their new initiatives towards enabling businesses connect with their user base – the Facebook user base directly, which is the largest social network at the moment. If they want, they can throw in voice or video interactions with an SDK on top of it.

WeChat, LINE, ooVoo and Viber

All have integration points. All heading in multiple directions for monetization. Be it businesses connecting to their user base, market places, digital currency or bots.

Leveraging Skype as an SDK means you want their reach and users base. But all of these messaging plaforms have their user bases in the hundreds of millions of active users as well. They essentially compete over similar mind share and budgets of enterprises.

What’s in store for us in 2016?

More chatter and talks about Apple and Microsoft, but little in the way of progress by developers making use of Edge or Safari WebRTC capabilities. That will wait for 2017.

For Skype, there’s a challenge here, but also an opportunity. They can leverage WebRTC, focus on developers and come with use cases and success stories that will be hard to compete against. Microsoft is doing a lot already in this space, but there’s a lot more they need to be doing when you look at the competition they have.

 

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 Microsoft, Apple and WebRTC in 2016 appeared first on BlogGeek.me.

Messaging is used too much to stay only in the browser.

There seems to be a few conflicting trends going on at the moment:

• Most people on mobile consume their services through apps they install on the device
• People don’t install apps on their desktops and laptops anymore. They expect everything (most things?) to be available in the browser
• A new approach of Progressive Web Applications is on the rise, while at the same time, frameworks like React are becoming trendy
• Chrome dropping support for their app launcher due to limited use by users – at least from their own experience – people prefer launching their services from inside the browser than let it live on their desktop
• Mobile (and to some extent web) based messaging is leaving the browsers in favor of apps on desktops and laptops

This last trend is what I want to focus here. When all of the apps we use are now browser web apps on the PC, there are generally two types of apps I still install on my laptop:

1. Microsoft Office
   • I use Google apps whenever I can, but official documents to most of my customers still necessitate a Word file
   • Oh, and Powerpoint is a lot faster for me to create presentations with than the Google alternative
2. Developer tools
   • There’s something about development that still doesn’t fit in the browser
   • Oftentimes, I just need things locally or more responsiveness. Can’t explain why. Maybe I am just old fashioned

When it comes to communications, though, I prefer pinning tabs to the browser for the most common tasks I have – or just leave it to my phone. WhatsApp, Slack, Gmail – all get a pinned tab on Chrome for me. Whenever I need to use messaging in other domains (Facebook, LinkedIn, Meetup, Upwork, etc) – I just open a new tab in Chrome “on demand” and then close it once done.

I assume others install apps locally on Windows for things they want to use frequently. Which brings me to two interesting developments from the last year or so:

• Slack introducing a Windows app a year ago, essentially, it looks and acts like a glorified browser window dedicated to Slack
• Facebook introducing a Messenger app for Windows 10, which is just like their Messenger web app with the addition support for Windows 10 tiles

Great.

So we are now taking HTML5 web apps, wrapping them as Windows apps and install them locally.

It probably makes sense for a lot of the enterprise messaging apps – instead of just living inside the browser, be part of the installed set of apps on the desktop. Purists of WebRTC will complain that this is not how its done. Detractors of WebRTC will say it isn’t WebRTC at all. I’ll say it is just another way of using the technology.

If you want to take your own communication web apps and make a desktop application out of them, then the most popular approach these days that I know of is CEF – Chromium Embedded Framework. It takes your web app, and packages it with Chromium so that they both get downloaded and installed together.

I assume that this is what Slack used. I am not sure about the Facebook Messenger one though – the addition of Windows tiles is a complication, but probably solvable.

In a way, web and HTML5 have already took over our desktop. Even in apps what you get is HTML5 these days.

I wonder if and when will this trend hit mobile, and if so, will it be achieved via the new Progressive Web Apps approach.

The post Messaging is Migrating from the Browser to the Desktop appeared first on BlogGeek.me.

This week we had a number of awesome new features, but the most work went into adding translations to the verto communicator application! And we definitely couldn’t have done it without help from our wonderful community members! So far, we have translations for English, Spanish, Portuguese, Italian, French, Danish, German, Polish, Russian, Swedish, Indonesian, and Chinese. If you speak another language and would like to see that language available please submit a pull request with a translation!

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we have Chad Phillips talking about his FreeSWITCH Kickstart project! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8983 [mod_avmd] Enable on outbound channel to make debugging easier
• FS-8875 [mod_avmd] Enable faster beep detection
• FS-8688 [mod_vpx] Implement vp9 processing to avoid chrome hang
• FS-8972 [verto_communicator] Add i18n using angular-translate and static file loader
• FS-7125 [mod_sofia] Added an event “wrong_calls_state”. This is for fail2ban logging.
• FS-8990 [mod_verto] Adding verto_login header to verto::client_disconnect event
• FS-8991 [verto_communicator] Adding translations for French. Thanks Tristan Mahé
• FS-8989 [verto_communicator] Adding Portuguese i18n translations
• FS-8991 [verto_communicator] Adding French Canadian
• FS-8998 [verto_communicator] Adding German, Spanish, Catalan, Chinese, Polish, Russian, Swedish and Indonesian translations.
• FS-8992 [core] Indicate end of candidates in SDP to aid in the resolution of an interop issue with Mozilla
• FS-9000 [mod_conference] Set conference flags or conference member flags with individual variables per flag

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

• FS-8988 [mod_avmd] Rename files to include avmd in their name.
• FS-8971 [mod_amqp] There are two different status variables with two different meanings. This splits them back apart.
• FS-8933 [scripts] WIP Fix some breakage on raspbian as we don’t want the FS repos there yet because we don’t have armhf packages at this time

The following bugs were squashed:

• FS-8982 [core] Fixed an issue with play_fsv and play_yuv writing blank_img in parallel
• FS-8918 [core] Fixed an issue with a 10 Second timeout after Notify during Proxy refer
• FS-9002 [core] Fixed an issue with rtp timeout code parsing on video but its designed for audio
• FS-8749 [mod_conference] Fixed an issue when loading a video (mp4) for a conference using the “conference play” command “conference pause_play”
• FS-8993 [mod_av][mod_conference] Fixed a sync issue on conference playback for a video that is faster frame rate than the conference
• FS-8995 [verto_communicator] Added missing toastr in settings controller
• FS-8990 [verto communicator] Added verto_client_address to verto and presence events
• FS-8996 [verto_communicator] Fixed a typo in CAMERA_SETTINGS id and added some Italian translation
• FS-8997 [verto_communicator] Fixed fallbackLanguage
• FS-9012 [verto_communicator] Fixing sidebar in narrow resolutions clipping the video
• FS-8999 [mod_erlang_event] Fixed broken outbound connection
• FS-8913 [mod_sofia] Fixed a transfer issue when using bypass_media + SRTP + Inbound late negotiation
• FS-9004 [mod_http_cache] Set http get timeout on thread that is actively downloading with the value from the download-timeout configuration and added download-timeout param to prevent http_get from waiting unbound time for downloading to finish. Prevented prefetch threads from blocking if another thread is already downloading the same URL.

It’s been a while since last session about Kamailio during the weekly VoIP Users Conference moderated by Randy Resnick. Next Friday, on April 8, 2016, join the VUC session starting at 12:00 EDT (17:00 in London, 18:00 in Berlin, Madrid Paris, Rome) to get updates about the new features introduced by the latest major releases of Kamailio, what are the plans for future development and get a preview of what’s going to happen at Kamailio World Conference (May 18-20, 2016, in Berlin).Daniel-Constantin Mierla, co-founder of Kamailio project, will be there to give the updates and answer the questions from the audience.You can join the conference remotely via SIP or dialling one the many local PSTN numbers as well as listening via web or watching the video live streaming. Questions can be posted also via IRC channel #vuc on freenode.net. You can see more details about the ways to connect on the VUC website:

• http://vuc.me

Book the date in your calendar and join the session next Friday!

Not all of them.

Who is investing in its platform?

Twilio. Added a slew of services in 2015.

TokBox. Got a new Spotlight live broadcast service. But not only.

VoxImplant. Added HD to its audio conferencing.

The rest? Not really sure?

Most of the time, when people talk to me about their use case, and the need to pick a specific platform, it boils down to a shopping list of features. They want everything. Usually more than any single vendor can offer. When prodded further, they reduce the need to a small set of requirements. But then again, they do see in their future these added set of features.

In many cases, selecting a vendor means understanding which of them might have what you need in the future down the road in their roadmap – not necessarily in their service today, but they will get there by the time you will.

Guess what – this is another factor that needs to included to the list of requirements you need to look at when selecting a vendor to work with.

This is why in the latest release of my “WebRTC PaaS report”, I am adding a new section, which will give a quick indication to which vendors made changes to their platform (and if these changes were serious or not). The information there will date back two years, giving some perspective.

If you are thinking of stating to use one of the WebRTC API platforms out there and not sure which one to use, then this report may come in handy. Until this next updated release, I’ve taken the price down considerably – if you purchase now you pay $1250 instead of $1950 and you get a year of updates (so that the updated version will be yours next month the moment it gets published).

Check the WebRTC PaaS report page to decide if you need.

The post Which WebRTC PaaS Vendor is Investing in His Platform? appeared first on BlogGeek.me.

Novatel E371 (also known as Dell DW5804) is sold for less than $30 at Aliexpress, and it’s so far the cheapest 4G/LTE WWAN card suitable for PC-Engines APU.

The initialization is fairly simple, although it was tricky to find the right command (AT$NWQMICONNECT=,,).

cat >/etc/chatscripts/lte_on.E371 <<'EOT' ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR TIMEOUT 10 '' ATZ OK 'AT+CFUN=1' OK 'AT+CMEE=1' OK 'AT\$NWQMICONNECT=,,' OK EOT cat >/etc/chatscripts/lte_off.E371 <<'EOT' ABORT ERROR TIMEOUT 5 '' AT\$NWQMIDISCONNECT OK AT+CFUN=0 OK EOT cat >/etc/network/interfaces.d/wwan0 <<'EOT' allow-hotplug wwan0 iface wwan0 inet dhcp     pre-up /usr/sbin/chat -v -f /etc/chatscripts/lte_on.E371 >/dev/ttyUSB0 </dev/ttyUSB0     post-down /usr/sbin/chat -v -f /etc/chatscripts/lte_off.E371 >/dev/ttyUSB0 </dev/ttyUSB0 EOT
Filed under: Networking Tagged: 3G, lte, pcengines, UMTS

Qualcomm Gobi 2000 is quite old (released 2009), but decent 3G modem, able to deliver up to 7Mbps in downstream in PPP mode. These modems in mini-pcie packaging are available at Aliexpress for less than $10, and make up a great option for 3G connectivity for PC Engines APU boards.

The modem needs a binary firmware to be loaded at the start. Numerous sources in Internet describe the ways to retrieve these files. The kernel driver in Debian 8 recognizes the modem as generic Qualcomm one, and sets up a QMI device (wwan0). But this model does not support packet mode, and you need to run PPP over ttyUSB1 device.

apt-get install -y gobi-loader wvdial mkdir /lib/firmware/gobi cd /lib/firmware/gobi wget --no-check-certificate -nd -nc https://www.nerdstube.de/lenovo/treiber/gobi/{amss.mbn,apps.mbn,UQCN.mbn} cat >/etc/wvdial.conf <<'EOT' [Dialer Defaults] Init1 = ATZ Init2 = AT+CGDCONT=1,"IP","internet" Phone = *99# New PPPD = yes Modem = /dev/ttyUSB1 Dial Command = ATDT Baud = 9600 Username = '' Password = '' Ask Password = 0 Stupid Mode = 1 Compuserve = 0 Idle Seconds = 0 ISDN = 0 Auto DNS = 1  EOT cat >/etc/network/interfaces.d/ppp0 <<'EOT' auto ppp0 iface ppp0 inet wvdial EOT

Also this script is useful for 3G connections, because with some providers, the Internet connection gets stalled every few days and needs to be re-connected.

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

San Francisco, CA - April 1st, 2016 - With skyrocketing demand for integrations between different services, 2600Hz is staying ahead of the competition with a unique integration named “Carrier Pigeons”.  This service allows customers to place calls to a specific number/extension where you then leave a voicemail.  2600Hz seamlessly transfers the voicemail to a thumb drive. Via automated, scalable, elastic engineering robots, the thumb drive is attached to a pigeon who is dispatched automatically to the specific location determined by the extension.  Using 2600Hz Mobile services, Carrier Pigeons are tracked via GPS until they reach their destination. Their progress is shown in an amazing user interface, the Monster Pigeon app.

2600Hz’s Co-Founder Darren Schreiber explains “We’ve seen what employing contract workers has done for the transportation industry, with services like Uber and Lyft. We see no reason why this can’t be adopted in the communications industry. The challenge in our industry is that people want their voicemail messages quickly - faster than a person or a car can deliver the message. We realized that Carrier Pigeons were a natural choice.“

Co-Founder Patrick Sullivan expanded on the project further: "We are always on the bleeding edge.  Now that we have integration with Voice, Video and SMS/MMS we had to think outside the box.  When sitting in our conference room talking about the future of business communication, we noticed a vast amount of resources sitting outside our window – Pigeons.  Most see dirty animals with wings. We see a way to deliver secure messages to places that might not have fiber or any other transit to get information to.  We also believe everyone has a crazy uncle or aunt ‘living off the grid’ and you might want to communicate with them.  We now have a way to do just that. This gives us a huge advantage over the typical CLEC/ILEC infrastructure.  The opportunities are endless.”

The program is in Beta and is invite only. Project “Carrier Pigeon” will launch publicly in the next couple months.  2600hz has already received multiple Silicon Valley investment offers and hopes to display the technology live, on stage, at TechCrunch, with other successful projects such as Pied Piper.

For questions and information requests please contact:

Captain Crunch
[email protected]
140 Geary St.
San Francisco, CA
Ph: 415-886-7900

The FreeSWITCH 1.6.7 release is here! This is a routine maintenance release and the resources are located here:

Release files are located here:

• Tarball: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.6.7.tar.gz
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation (Please Note the updated location for 1.6 packages)

New features that were added:

• FS-8908 [verto communicator] Link to preview camera and microphone under settings
• FS-7800 [verto communicator] Added support for calling extra screens with same extension as the original and place the parameter conferenceCanvasID with the desired canvas id into the call parameters in the same place bandwidth preferences are added
• FS-8972 [verto_communicator] Fixed mute video translation and added i18n using angular-translate and static file loader
• FS-8989 [verto_communicator] Adding Portuguese i18n translations
• FS-8991 [verto_communicator]Adding translations for French and added French Canadian. Thanks Tristan Mahé
• FS-8998 [verto_communicator] Adding German, Catalan, Polish, Russian, Swedish, Chinese, and Indonesian translations.
• FS-8990 [mod_verto] Adding verto_login header to verto::client_disconnect event
• FS-8735 [mod_sofia] Display update support for Panasonic devices
• FS-6833 [mod_sofia] Allow FreeSWITCH to initiate late offer calls
• FS-8879 [mod_sofia] Work on SIP UPDATE and attended transfer for IPv6
• FS-8964 [mod_sofia] Make it possible to disable picture_fast_update INFO requests to de-clutter trace and logs
• FS-7125 [mod_sofia] Added an event “wrong_calls_state”. This is for fail2ban logging
• FS-8864 [core][mod_av] Improve video file playback
• FS-8977 [mod_av][core] Add functionality to support the NVENC hardware encoded h264 in codec and files and  set default to enable hardware encoder on conference too
• FS-8862 [core] Auto adjust on passthru
• FS-8876 [core] Add CPU affinity to each video thread in a round robin fashion.
• FS-8909 [core] Add feature to play background video while recording inbound video. This feature is suitable to provide some kind of feedback like an animation of a glowing record light etc.
• FS-8870 [core] Add human-readable call quality statistics logs on call hangup
• FS-7776 [mod_kazoo] Integrate the module into build system
• FS-8737 [mod_kazoo] Add required variables to default filter
• FS-8595 [mod_conference] Improve auto bitrate in personal canvas mode and do not let auto bitrate exceed native picture size
• FS-8921 [mod_conference] Re-designed the banner code
• FS-8685 [mod_conference] Multiple member arguments for conference related API command. The new format is: ‘conference foo relate 1 2,3,4 nohear’ or ‘conference foo relate 1,2 3 nospeak
• FS-9000 [mod_conference] Set conference flags or conference member flags with individual variables per flag
• FS-8822 [mod_callcenter] Added a real-time counter for calls in a queue.
• FS-8903 [mod_local_stream] Add a logo image and some parameters to control its behavior
• FS-8932 [mod_managed] Add in process load in-process plugins
• FS-8688 [mod_vpx] Add more detailed logs and tweak some parameters for the coming libvpx 1.5.0 and implement vp9 processing to avoid chrome hang
• FS-8728 [mod_amqp] Adding logging profile and functionality and added default configurations
• FS-8971 [mod_amqp] There are two different status variables with two different meanings. This splits them back apart.
• FS-8983 [mod_avmd] Enable avmd on outbound channel to make debugging easier
• FS-8875 [mod_avmd] Enable faster beep detection

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

• FS-8111 [mod_sofia] ‘sofia’ API command auto-complete cleanup
• FS-8763 [mod_sofia] Changed to set is_auth only after the results for switch_ivr_set_user
• FS-8782 [mod_verto] Fixed build error for missing __bswap_64 on Solaris
• FS-8778 [mod_verto] Define __bswap_64 for FreeBSD as well
• FS-8195 [src] Allow Solaris privileges to work on both Solaris and derivatives
• FS-8776 [build] Support GNU make parallel builds
• FS-8942 [build] Pass compiler to libvpx configure to account for environments without gcc
• FS-8871 [configuration] Fixed encoding “&” and “<” symbols in vanilla configuration
• FS-8808 [core] Fixed ^D in fs_cli with editline to delete char under cursor, not just backspace
• FS-8818 [core] Refactor X-PRE include to not toss error if there are no files that match the include.
• FS-8992 [core] Indicate end of candidates in SDP to aid in the resolution of an interop issue with Mozilla
• FS-8788 [Debian] Enabling stacksize limits for Debian packaging
• FS-8933 [Debian] Basic FreeSWITCH from source installer that works on Raspian and Debian. Also installs VertoCommunicator and LetsEncrypt SSL Certs. LetsEncrypt requires the machine to have a public IP and DNS for the FDQN functioning properly in public DNS
• FS-8948 [Debian] Handle non-existent configuration in Debian postinst causing failure to copy vanilla configuration on installation
• FS-8841 [Debian] Prevent hanging by pushing events to another queue to be processed in a different sofia thread.
• FS-7389 [CentOS] Correct the location of the freeswitch users homedir in the specfile
• FS-8186 [Windows] Fixed build with –disable-libyuv to ensure projects don’t incorrectly depend on libapr directly
• FS-8952 [Windows] Fixed an issue with unreachable code preventing build and simplify conditions
• FS-8779 [mod_shout] Properly detect lame/lame.h for FreeBSD
• FS-8808 [mod_avmd] Code refactor to fix indentation and conditional loops
• FS-8961 [mod_avmd] Add optional requirement of consecutive streak of estimations in SMA buffer to avoid false positives, fix definitions, and add options to control debugging/printing
• FS-8988 [mod_avmd] Rename files to include avmd in their name.
• FS-8878 [mod_amr] Fixed compiling without the library installed
• FS-8756[mod_say_nl] Improve dutch localisation
• FS-8933 [scripts] WIP Fixed some breakage on Raspbian as we don’t want the FS repos there yet as we don’t have armhf packages at this time

The following bugs were squashed:

• FS-8719 [mod_conference] Fixed a segfault caused by building without video support, but specifying video_mute_png variable for a conference member
• FS-8752 [mod_conference] Fixed a pixelation issue in initial seconds of recording a conference
• FS-8354 [mod_conference] Fix for G722 audio issues
• FS-8938 [mod_conference] Clear res_id when setting the same res_id to another member
• FS-8951 [mod_conference] Video lockup in conference due to race condition
• FS-8957 [mod_conference] Fix for video image blipping on personal canvas mode when 1 participant is watching video on hold
• FS-8750 [mod_conference] Fixed a set but not used variable warning
• FS-8749 [mod_conference] Fixed an issue when loading a video (mp4) for a conference using the “conference play” command “conference pause_play”
• FS-7915 [mod_sofia] Parse and store multiple path fields
• FS-8663 [mod_sofia] Added saftey checks for ;fs_path= command
• FS-8759 [mod_sofia] Fixed a segfault caused by device or provider timing interactions
• FS-8879 [mod_sofia] Fixed SIP UPDATE and attended transfer for ipv6
• FS-8898 [mod_sofia] Log setVariable at debug to easier tell what variables are being set from scripts
• FS-8913 [mod_sofia] Fixed a transfer issue when using bypass_media + SRTP + Inbound late negotiation
• FS-8796 [mod_verto] Fixed and cleaned up the mcast code
• FS-7132 [mod_verto] Fixed an issue with multiple websockets overwriting the jsock hash entry for a given sessionid causing a disconnection with the verto javascript application.
• FS-8842 [verto] Fixed an issue where calls created using the originate command lose audio when left on hold for 45 seconds
• FS-8877 [verto] Fixed an issue caused by Chrome Canary removing some audio mandatory constraints that break Verto
• FS-8805 [verto] Added a sanity check on array
• FS-8945 [verto_communicator] Don’t show preview_settings window during a video conference call or you will lose conference video stream until you refresh the page
• FS-8842 [verto] Fixed an issue where calls created using the originate command lose audio when left on hold for 45 seconds
• FS-8877 [verto] Fixed an issue caused by Chrome Canary removing some audio mandatory constraints that break Verto
• FS-8839 [verto_communicator] Fixed screenshare not displaying in the proper conference when caller is transferred to another conference.
• FS-8963 [verto_communicator] Fixed the status call label
• FS-8966 [verto_communicator] Fixed the ability to cancel dialing while doing speed test
• FS-8970 [verto_communicator] Set useSpeak/useMic/useCamera to ‘none’ when calling a secondary canvas
• FS-8765 [verto_communicator] Make the preview button work properly
• FS-7800 [verto_communicator] Disable video floor changes on multi-canvas
• FS-8995 [verto_communicator] Added missing toastr in settings controller
• FS-8990 [verto communicator] Added verto_client_address to verto and presence events
• FS-8996 [verto_communicator] Fixed a typo in CAMERA_SETTINGS id and added some Italian translation
• FS-8997 [verto_communicator] Fixed fallbackLanguage
• FS-9012 [verto_communicator] Fixing sidebar in narrow resolutions clipping the video
• FS-8720 [core] Fixed a segmentation fault when switch_channel_str2cause is called
• FS-8960 [core] Reset the buffer position to zero to ensure correct calculation of average
• FS-8975 [core] Fixed the dtmf_type and sofia profile parameter dtmf-type variables
• FS-8731 [core] Fixed a crash when leg-b invite video in voice call
• FS-8734 [core] Cleaned up video jitter buffer by adding some formatting to the debugging logs so the text jumps around less and fixing sequence number rollover code to handle rollover better.
• FS-8713 [core] Fixed a crash on bad video rtp stream by pushing a patch to make the sizes match. This was the original intention since we want to preserve the packet as-is while in the jitter buffer
• FS-8721 [core] Fixed an eavesdrop memory leak caused by moving bug_remove_all after destroy where it’s more than safe to kill bugs indiscriminately
• FS-8673 [core] Fixed a core dump on playback after “Decode Codec is not initialized!” log message
• FS-8571 [core] Add missing ENABLE_SRTP ifdef to allow building without SRTP
• FS-8770 [core] Fixed media_bug_answer_req=true creating a file for unanswered calls
• FS-8786 [core] Fixed a fax hangup problem when testing long faxes over T.38 and rtp-timeout-sec is set to 300
• FS-8802 [core] Fixed an issue caused by the sent timestamp of RTP rolling over to 0 and hitting an error condition causing it to stop sending audio
• FS-8726 [core] Fixed a spurious case of a thread stuck and saturating CPU
• FS-8812 [core] Respect in_thread_only parameter in switch_channel_check_signal()
• FS-8809 [core] Fixed an undeclared MAP_POPULATE causing compliation failure
• FS-8816 [core] Fixed switch_core_hash_insert_destructor not checking switch_hashtable_insert_destructor() returns
• FS-8830 [core] Added SDP line separator fix for SDP generated by the core. Sofia when giving an SDP through SOA was parsing the SDP and rewriting it. For endpoints that use the core SDP as is will have more accurate SDP now.
• FS-8806 [core] Change group_confirm_cancel_timeout to apply only to the legs that answer the call to prevent the remaining legs ringing indefinitely if the answered leg hangs up while executing the group confirm script.
• FS-8821 [core] Fixed switch_core_hash_insert_locked and switch_core_hash_insert_wrlock to make sure they check the status of the operation before returning a switch_status.
• FS-8862 [core] Auto adjust on passthru
• FS-8811 [core] Fixed an intermittent crash
• FS-8851 [core] Fix for codec for recording negotiated before call answered
• FS-8904 [core] Fix memory leak in img_write_text
• FS-8905 [core] Fixed for a heap buffer overflow detected by ASAN in the img patch/img overlay and it may show up as a rare segfault when using video with banners
• FS-8864 [core] Set video ready on first push to avoid catch 22 on some video files and improve video file playback
• FS-8910 [core] Properly negotiate SDES when receiving an SDP with a=crypto:0 with the wanted crypto suite, we should maintain that crypto tag in the local SDP in order for SDES setup to succeed.
• FS-8914 [core] Fixed mp4 recording cutting off the end in some cases by adding code to mitigate the sync of the end of the file encoding to add some padding to the end
• FS-8761 [core] Fixed a memory leak
• FS-8855 [core] Fixed the calculation of variance of tone’s frequency estimator to prevent flawed audio
• FS-8928 [core] Flag a binding error when using EventConsumer::bind with invalid event name instead of blindly using custom
• FS-8168 [core] Use copy image functions from libyuv instead of our home rolled versions as the libyuv versions have optimizations
• FS-8982 [core] Fixed an issue with play_fsv and play_yuv writing blank_img in parallel
• FS-8918 [core] Fixed an issue with a 10 Second timeout after Notify during Proxy refer
• FS-9002 [core] Fixed an issue with rtp timeout code parsing on video but its designed for audio
• FS-8847 [core] When a call ends sometimes the RTP stack complains of a bad poll. This is normal caused by shutting down the rtp on hangup. Add some code to catch the condition that is ok and still print the error otherwise
• FS-8789 [mod_conference][mod_av] Fix warning thats printed when it shouldn’t be and remove ability to swap to personal canvas while recording and prevent recording while personal canvas is on.
• FS-8864 [mod_av] Fixed regression to recording to improve file playback
• FS-8868 [mod_av] Set recording app to respect bandwidth set in SDP
• FS-8916 [mod_av] Fixed an issue with newer x264 library returning Encoding Error -1 for newer x264 libraries
• FS-8836 [mod_av] Fixed a deprecated warning on newer ffmpeg to support ffmpeg 2.8 and 3.0 in addition to 2.6
• FS-8914 [mod_av] Adding code to mitigate the sync of the end of the file encoding to add some padding to the end
• FS-8973 [mod_av] Enable libavcodec experimental native implementation features (such as AAC) by default
• FS-8959 [mod_av] Refactor to improve memory processing and prevent leaks in encoding h264
• FS-8993 [mod_av][mod_conference] Fixed a sync issue on conference playback for a video that is faster frame rate than the conference
• FS-8656 [src] Fix switch_event_channel_broadcast identifier redeclared
• FS-8777 [mod_redis] Add the missing netinet/in.h include required to build mod_redis/credis.c for FreeBSD
• FS-8768 [mod_callcenter] Releasing database handle after reserving agent
• FS-8856 [mod_callcenter] Updating a member fails because the agent_dispatch_thread removed the member just before it tried to update it.
• FS-8838 [mod_rayo] Improve logging and error handling when executing API on output component. Attempt to make output component stop a little more robust and do a better job of detecting when output component completed because of hangup and preventing operations on output component when call has ended.
• FS-8811 [mod_local_stream] Fixed an intermittent segfault and a crash caused by dividing by 0
• FS-8866 [mod_erlang_event] Fixed memory leaks caused by not destroying session event_hash and events in queue
• FS-8999 [mod_erlang_event] Fixed broken outbound connection
• FS-8871 [configuration] Fixed encoding “&” and “<” symbols in vanilla configuration
• FS-8943 [configuration] Fixed misspellings in two comments
• FS-8884 [build] Add –disable-libyuv and –disable-libvpx configure arguments to disable building these libraries on FreeBSD and smartos
• FS-8915 [mod_smpp] Shortened event header name
• FS-8950 [mod_skinny] Fixed a few memory leaks
• FS-8946 [mod_xml_cdr] Fixed a segfault on call after loading with no config file or event bind failure causing the module load to fail
• FS-8937 [mod_easyroute] Handle a segfault when using bad customer query or on query error
• FS-8775 [mod_say_de] Add function SST_SHORT_DATE_TIME to mod_say_de.c and some language tweaks
• FS-8406 [mod_rtmp] Add options to scale down cavas size, fps, and bandwidth
• FS-8736 [spandsp] Fixed missing MEMMOVE macro in spandsp autoconf
• FS-8891 [RTP] Fix for T38 fax failing between 2 freeswitch boxes with high cpu usage
• FS-8312 [mod_sangoma_codec] Some maintenance clean-up and reset the whole trans-coding session memory on destroy to make debugging easier
• FS-8971 [mod_amqp] Resolve global structure handling issue causing a core dump. Thanks to Ben Hood for reporting the issue.

March 30, 2016: Kamailio v4.4.0 is out –  a new major release, bringing out new features and improvements added during about seven months of development and one and a half month of testing.In short, this major release brings 9 new modules and enhancements to more than 60 existing modules, plus components of the core and internal libraries. Detailed release notes are available at:

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

The release series 4.4.x is expected to be the last starting with number 4, next major release is planned to be 5.0.0, which should get Kamailio to a new era — there are already ongoing discussions on users mailing list about the changes to be done as well as a wiki page was created to collect the relevant ideas for 5.0.x. Join us to design and develop v5.0.0!Enjoy SIP routing in a secure, flexible and easier way with Kamailio v4.4.0!Thank you for flying Kamailio and looking forward to meeting you at Kamailio World Conference 2016!

This week we have added functionality to support the NVENC hardware encoded h264 codec, files, and default on conference.

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-8964 [mod_sofia] Make it possible to disable picture_fast_update INFO requests to de-clutter trace and logs
• FS-8977 [mod_av][core] Add functionality to support the NVENC hardware encoded h264 in codec and files and  set default to enable hardware encoder on conference too

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

• FS-8186 [Windows] Fixed build with –disable-libyuv to ensure projects don’t incorrectly depend on libapr directly
• FS-8961 [mod_avmd] Add optional requirement of consecutive streak of estimations in SMA buffer to avoid false positives, fix definitions, and add options to control debugging/printing

The following bugs were squashed:

• FS-8960 [core] Reset the buffer position to zero to ensure correct calculation of average
• FS-8975 [core] Fixed the dtmf_type and sofia profile parameter dtmf-type variables
• FS-8312 [mod_sangoma_codec] Some maintenance clean-up and reset the whole trans-coding session memory on destroy to make debugging easier
• FS-8963 [verto_communicator] Fixed the status call label
• FS-8966 [verto_communicator] Fixed the ability to cancel dialing while doing speed test
• FS-8970 [verto_communicator] Set useSpeak/useMic/useCamera to ‘none’ when calling a secondary canvas
• FS-8765 [verto_communicator] Make the preview button work properly
• FS-7800 [verto_communicator] Disable video floor changes on multi-canvas
• FS-8914 [mod_av] Adding code to mitigate the sync of the end of the file encoding to add some padding to the end
• FS-8973 [mod_av] Enable libavcodec experimental native implementation features (such as AAC) by default
• FS-8959 [mod_av] Refactor to improve memory processing and prevent leaks in encoding h264
• FS-8836 [mod_av] Fixed a deprecated warning on newer ffmpeg to support ffmpeg 2.8 and 3.0 in addition to 2.6
• FS-8750 [mod_conference] Fixed a set but not used variable warning
• FS-8971 [mod_amqp] Resolve global structure handling issue causing a core dump. Thanks to Ben Hood for reporting the issue.

No easy answer.

What route should your messaging implementation take?

If there’s something I like is to write code. I haven’t done so in years, but it still is my passion. A year or two ago, I’ve done a small coding project for something I needed. After a whole day of coding it dawned on me that I haven’t checked my email, social networks or notifications the whole time – and didn’t even miss it. The only thing these days that can focus me on a single task at a time is programming.

When I did develop, and manage developers, there was always that tension of NIH in the air – the Not Invented Here syndrome that we developers are so good at. We want to develop stuff on our own and not “outsource” it to others. Hell – if I wrote a piece of code a year ago it was crap the next year and had to be rewritten.

I had the chance to listen in to Apigee’s recent webcast on Build vs Buy API Management. See it here:

This webcast goes over a lot of reasoning I see going on in any development project when the decision needs to be building build and buy.

The funny thing is that I don’t hear this kind of a discussion enough when it comes to messaging. Somehow, people think it is trivial.

I took a few of the concepts in this webcast, and “translated” them into the realm of build vs but for messaging.

Limited view of the scope

When a project starts, it seems that adding messaging isn’t that hard. You have a bunch of people. Maybe some presence indication. Run around a few Websocket messages for the text involved in the conversation and you’re done.

But is it really true, or is there more to messaging? It is far from trivial. Even simple things like delivering messages while disconnected or handling push notifications are notoriously hard to get right – even for those who should be the experts in it.

When you define what it is you need to build for your messaging, most often than not, you’ll be doing it with the following “mistakes”:

• You will have a narrow scope of what is really needed
• You will focus on the functional part of messaging, but probably a lot less of the other requirements (such as a good backend to understand what your system is doing and how people end up using it)

With limited scope comes the challenge of not comparing the right things when deciding between build or buy.

RISK

Every development project is risky. Purchasing an off the shelf solution usually mitigates the risk by having it done by someone else where the payment and deliverables are known in advance.

Developers tend to ignore risk – especially if the project is interesting enough to build. And yes. A distributed, low latency, high efficiency, large scale messaging backend written in Lua or Go is highly interesting.

You are not WhatsApp. Or Netflix

Building your own messaging system is hard. It takes a lot of effort. WhatsApp seems so easy, but getting there is hard.

This shift towards in-app messaging that is occurring means that in most cases, messaging is becoming part of an IT project and not exactly an R&D project. As a company, this means the focus is elsewhere and that messaging is considered a commodity or a non-core technology.

In such cases, there is no real funding for ongoing development, support and maintenance of an in-house DIY messaging framework.

Can open source help?

Sure, but is it at the right level of maturity?

There are a few dozen open source messaging frameworks out there. They probably do the work, but barely.

And the main challenge is that messaging is rapidly changing, which means that whatever is out there today is probably somewhat obsoleted or out of sync with what you need anyway – and getting it to where you need it means more investment on your end. Probably.

To top it all, with most of these open source initiatives, what you’ll find out that they have one main contributor behind them. That contributor is most probably a vendor who is offering support and proprietary modules to take care of commercializing the open source offering. Things like reporting, scaling, maintenance, etc. – all these will fall in the domain of proprietary and payment.

So if the idea from the start was to use open source to refrain from having to negotiate and work with a vendor, where does that lead you down the road? Isn’t it better to acknowledge the fact from the onset and find a suitable solution out of a larger set of available vendors?

Time To Market

I know. I know.

If you write your own messaging system, it will take you the better part of a weekend. Adding a bit of code and stability around it clocks it at a month. Nothing can beat that.

But what is it you are comparing here? Are you concerned about your prototype implementation or is that like production grade we’re talking about?

Getting something to production requires a lot more time.

Why are you even going DIY?

Is it because it will be cheaper?

Because you’ll have more control over your future and destiny?

DIY is going to cost you in time and effort which you don’t necessarily have.

If and when this project of yours going to succeed, you’ll find out that with it more requirements and maintenance work is necessary. But what you’ll also find out is that the budget might not be there for you to handle that extra load in development. You promised the organization a working messaging system, and now that it is working – why are you asking for more funding exactly?

 

 

Easy? Hard? Core? Commodity?

I guess in most cases, deciding to develop your own messaging system requires a very good reason.

At testRTC we had that same need, though slightly different. We needed a way to communicate with the browser machines we’re running. It was all fine and well when the number of machines was rather small and their locations were simple. It became a real headache when we grew bigger and when customers started connecting machines in locations with flaky internet connections. We ended up using integrating one of the realtime messaging players for that purpose – and haven’t looked back at it since.

Messaging might seem easy, but it is pretty hard once you get to the details.

So why not outsource it and be done with it?

The post DIY or SaaS for Your In-App Messaging? appeared first on BlogGeek.me.