News from Industry

Dumb pipe or not, data services thrive mainly out of the telecom world these days.

Can Telecom Services survive the Internet?

Telecom Services are an interesting notion. For over a hundred years we’ve been taught that Telecom Services=Phone calls. Then messaging was added to it in the form of SMS on mobile. Telecom services themselves assume that their role in life is to sell us our communication services.

This is no longer true.

I remember working on 3G-324M. A circuit switched video protocol, now dead to the world at large. In many of my discussions, people complained about their inability to add services on top of what a carrier provided – there were too many layers of debilitating bureaucracies.

Today? Everything operates over an IP network. Most of us don’t even care if it is cellular, landline, wireless, or whatever – as long as we get our bits on the line – we’re happy.

While we are all happy using VoIP services and discussing how disruptive it is to carriers, we haven’t seen nothing yet.

The wheel has turned. In the past, advantage lay in owning the network and offering managed services on top of the network. Today, and moving forward, advantage lay with those who can operate their service across networks.

This means that carriers are left with their own network, and a DNA of working inside their own managed network – something that makes it harder for them to operate in this new reality.

Here are two areas that drive the message home:

#1 – Google Fi

Google Fi is how mobile phones should operate. It is Google being an MVNO and offering mobile plans to its customers. Instead of buying a plan (and maybe a subsidized handset) from a carrier, you can just purchase a plan from Google – and use a Nexus smartphone.

What makes Google Fi so different is that it operates on 3 different networks:

1. Sprint
2. T-Mobile
3. Any Wi-Fi it can get connected to

Read the FAQ for this one – it is quite telling.

Here’s one piece of it:

What happens if I start a call over Wi-Fi and then lose my Wi-Fi connection?
On your Project Fi device, if you start a call over Wi-Fi and then your connection weakens or drops (such as when you leave your home or office), Project Fi seamlessly transitions your call to a cellular network (if one is available) so you can keep talking.

Calling is no longer tied to a cellular network. Fi has 2 cellular network and whatever Wi-Fi you happen to be on. And it decides what to use based on past experience of Google – and is able to change that dynamically mid-call.

Fi is not your typical MVNO. Or your typical VoIP provider. Or your typical carrier.

It is just how things should be.

#2 – Internet of Things

The Internet of Things to me is everything but a carrier. The hint to that is in that first word – Internet. You don’t really need a carrier for that – just an IP connection. Any IP connection.

While there are use cases that will necessitate a carrier (or just his SIM cards?), most of them don’t have a carrier as a prerequisite for their existence.

I like this slide of Octoblu – an IOT platform that was acquired by Citrix:

It shows the various players in the IOT space:

• IOT frameworks
• Smartphones (control points of us humans)
• Embedded devices and sensors
• Messaging, aggregation and rules engine for all the data flowing around
• Storage and analytics
• Applications and integration

Nothing about the underlying network. No one really cares what that ends up being. Which makes sense. For this to work, you need an ubiquitous network. Not necessarily one with high bandwidth or no packet loss – but one that you can assume exist. Which is what we have in most of the modern world now.

Final Thoughts

No. This isn’t the end of carriers.

Yes. They will still make boatloads of money.

Much like electricity is a utility, access to the Internet is a utility.

The services on top of it though? They don’t necessarily belong to the carriers.

The post Google Fi, Internet of Things and the Bleak Realities of Telecom Services appeared first on BlogGeek.me.

This week mod_vpx saw some cool tweaks and mod_conference saw some improvements to the auto bitrate in personal canvas mode.  Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we have Simon Woodhead from Simwood! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8688 [mod_vpx] Add more detailed logs and tweak some params for the coming libvpx 1.5.0
• FS-8595 [mod_conference] Improve auto bitrate in personal canvas mode and do not let auto bitrate exceed native picture size

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

• FS-8782 [mod_verto] Fixed build error for missing __bswap_64 on Solaris
• FS-8195 [src] Allow Solaris privileges to work on both Solaris and derivatives
• FS-8776 [build] Support GNU make parallel builds
• FS-8788 [Debian] Enabling stacksize limits for Debian packaging

The following bugs were squashed:

• FS-8775 [mod_say_de] Add function SST_SHORT_DATE_TIME to mod_say_de.c and some language tweaks
• 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-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-8796 [mod_verto] Fixed and cleaned up the mcast code

All roads lead to WebRTC.

Java in the browser no longer an option

This started happening in 2015, and is growing as a trend. Half a year ago we witnessed browsers killing off plugins and Flash with a slew of new security issues getting shunned by browsers for a few days.

This left developers with 4 available alternatives for VoIP in a browser:

1. Flash, with the assumption it is being declining in popularity and support
2. Plugin, which is getting harder and harder to build and maintain in a way that browsers will support it at all
3. Java, the promising technology from a decade or two ago that got outdated for frontend browsers, but still available
4. WebRTC

Oh and there’s this Java Web Start thing, but seriously – you planning on enticing your customers to INSTALL something on his desktop in 2016?

With Flash and Plugin options becoming deprecated as we move further, it seems that Java will be taking the deprecation plunge as well. Oracle just announced they won’t be supporting their Java plugin moving forward.

You are yet again left with WebRTC.

The real implications aren’t for those using WebRTC, but rather those who are trying to support browsers without WebRTC:

• Up until today, they were two ways of supporting non-WebRTC browsers: Flash or a plugin (Java or other)
• Flash was always a challenge due to the mismatch in media codecs between Flash and WebRTC, along with crappy echo cancellation
• Plugins meant you could support WebRTC by wrapping it as a plugin, but this is becoming harder to do with each passing day
• Java seemed like a good enough alternative:
  • Many organizations had to enable Java in browsers because their internal systems worked with Java applets and programs
  • With Java you could implement WebRTC on the network on your own – there was an implementation or two of this nature
• The problem is that Java will stop supporting plugins, so if you relied on Java to get WebRTC for you – that route is closing as well

The future of communications is in WebRTC.

 

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

The post First Plugins, then Flash and now Java – WebRTC is now the only alternative appeared first on BlogGeek.me.

It is. But it really isn’t.

Confused?

Still thinking WebRTC = P2P?

There’s so much misunderstanding about WebRTC that it is funny at times. People throw into a conversation sentences like “WebRTC is just peer-to-peer – it can’t do a large conference service like you can with [PLACE-YOUR-COMPANY-NAME-HERE]”.

As with anything else in life, such comparisons are plain wrong. As I always say: WebRTC is just a technology. It is up to you to develop your service on top of it. If that service happens to be a large conferencing service, then why not?

WebRTC being P2P is just as P2P as SIP is. Or H.323. The only difference is that you get to choose your own signaling and your own client. For the first time in history, you get to choose how the topology of your solution will look like from a media and signaling perspective while using a standard specification – and not be bogged down by how people decided to define SIP. Or XMPP. Or whatever.

I had a call with a customer recently. A question that was asked during that call is do I see anyone using WebRTC in mobile just because of cost inefficiencies – not because there’s a browser requirement hiding somewhere in there. The immediate answer I gave was “definitely”. Followed with a few examples to show the point.

WebRTC is P2P? WebRTC is for browsers only? WebRTC only works in Chrome and Firefox?

There are two ways to think of WebRTC:

1. A standard specification with a default implementation in browsers
2. An open source media engine

If you miss that second option of open source media engine then you are missing out on a lot of the use cases out there that are based on WebRTC.

The same applies for server implementations.

There are 3 main components to a WebRTC deployment on the server side:

1. Signalling – how do you get the WebRTC clients connected in the first place?
2. NAT traversal – STUN and TURN needs to be mediated
3. Media processing

The first two are mandatory. You’ll have them in all production services with WebRTC no matter what. The media processing one is a bit less obvious, but it is necessary in many use cases. I’ve touched this briefly recently on a post on Dialogic’s blog – oftentimes, you’ll need a server. Be it for recording, multiparty or something else. When that time comes – it isn’t that WebRTC doesn’t cut it for the job because it is P2P – it is that you’ll need to search beyond Google for a solution.

And when you search beyond Google, there are tons of different alternatives:

• DIY from Google’s WebRTC open source stack (or by other means)
• Open source frameworks and SDKs, with and without paid support options
• Commercial products, hardware and software based
• Commercial SaaS offerings for specific media components
• Commercial SaaS offerings for the whole shebang
• You can build/integrate it with your own developers or use outsourced developers or software houses

Next time someone dismisses WebRTC for his project because it is only peer-to-peer – tell them to check his initial hypothesis so he won’t miss out on some of the options he has available to him.

 

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

The post Get Over it: WebRTC isn’t Peer-to-Peer appeared first on BlogGeek.me.

FreeSWITCHers! ClueCon 2016 registration is open! Navigate over to Cluecon.com to get signed up!

This week mod_kazoo was merged into the build system and mod_conference now allows for multiple member arguments for related API commands. Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we have Randy Resnick from the VoIP Users Conference talking about all things communication! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-7776 [mod_kazoo] Integrate the module into build system
• FS-8737 [mod_kazoo] Add required variables to default filter
• 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’

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

• FS-8756[mod_say_nl] Improve dutch localisation
• 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

The following bugs were squashed:

• FS-8721 [core] Fixed a memory leak caused by bug removal at the end of the call
• FS-8759 [mod_sofia] Fixed a segfault caused by device or provider timing interactions
• FS-8571 [core] Add missing ENABLE_SRTP ifdef to allow building without SRTP

Messaging is a platform.

We’re used to messaging. All of us. SMS has been around for ages. And it feels like iMessage, WhatsApp and Facebook messenger were here in the last few decades as well – they are so ingrained in how so many of us behave that we fail to even acknowledge how new they are.

For those of us who have VoIP in their veins – who learned, worked and breathed VoIP in the beginning of the second millennium, messaging is just an extension of VoIP. A buddy list, with the ability to send a message to a buddy.

Some even believe you can charge for messages (RCS – I am looking at you).

The truth of the matter is, that today, messaging is free. It is an expected “utility”, where money is made elsewhere. Facebook spent countless of billions to own WhatsApp – a messaging service with boatloads of users and little by way of features and bells and whistles. Oh – and in most cases and places, WhatsApp never charge its users for the system, and now, it probably never will.

Facebook released earlier this month their “vision” for Messenger in 2016, and Josh Constine did a nice review of it on TechCrunch.

For me, these are the things that are important from these two posts:

1. That whole phone number replacement thing
   • Is irrelevant in many cases
   • It might work. It might not
   • But that’s not where the action or money is anyway
   • The future is in messaging services that may acknowledge the phone number but don’t rely on it alone
2. The business model is in the business
   • Messaging services doesn’t rely on consumers to pay. They rely on having a huge active subscribers base – attracting businesses to pay for the opportunity to interact with the users. Facebook is headed there. WhatsApp announced going there. WeChat is already there
   • This means having an API, a market place/discoverability, good integration points
3. B2C conversations
   • Should you build a website for your company? A smartphone app?
   • Maybe it needs to be embedded into the messaging services your customers are using instead?
   • And if it is, will it be as brand pages, or just direct messaging to users?
   • For the most part, messaging platforms will end up connecting people not only to other people, but to businesses and maybe even devices (for those of us in love with IOT concepts)
4. Artificial intelligence and messaging bots
   • Everyone is headed there in the past couple of months for some reason
   • Most don’t know what it means
   • I can’t say I grok it to the level I wish that I did
   • For me, this is about bringing a Siri/Cortana/Google Now like experience into the messaging platform
5. Delighting users
   • Focusing only on the job-to-be-done of the platform isn’t enough
   • Rationalizing a great UX and putting a polished design isn’t enough
   • Users need to enjoy the service – it is about experiences for them – even in a work environment
   • Here’s how Slack does it – which is a lot more telling than the Facebook examples

 

 

Messaging is a lot more than messaging and signaling protocols these days. It is less about the underlying network technology and more about business aspects and usability. It takes away a lot of the power and ego out of the VoIP guys. Just like that, they don’t really know what should be in their core competency. I come from this VoIP background, and I need to struggle with it daily.

What are your messaging plans for 2016?

 

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

The post Facebook and the Future of Messaging appeared first on BlogGeek.me.

S doesn’t stand for Simple in SFU.

What are you doing about your WebRTC SFU requirements?

I have noticed recently that more and more companies are attempting the creation of their own SFU. SFU stands for Selective Forwarding Unit, and it is by far the most popular and cost efficient architecture today for multiparty video with WebRTC. With it, all participants send their video to a single entity (usually in multiple resolutions/bitrates), and that single entity decides (selectively) how to route the incoming video to all the participants.

One such popular framework is the Jitsi Videobridge.

Up until today, an SFU for WebRTC was rather simplistic. You had VP8 to contend with as a developer but that’s about it. Life was good. You built your service and mostly whined about incompatibility between browsers.

Things have changed.

Here are a few things that you need to take into consideration when you either build your own WebRTC SFU or adopt/acquire one from others:

• Do you use VP8 or VP9 in your SFU?
  • Google is already adding VP9 to Chrome
  • How long will it take until it catches on for some use cases?
  • VP9 is a better codec, so why not use it?
• Can it support multiple codecs simultaneously?
  • Before the end of this year, we will have VP8, VP9 and H.264 available to us in browsers
  • Not all browsers will support them all
  • VP8 seems like the lowest common denominator at the moment
  • This may change to H.264 when Microsoft Edge and Chrome support it though
  • An SFU supporting only VP8 will start looking old pretty fast – and won’t work on Edge
  • Staying in H.264/VP8 land will not perform as well as VP9 in terms of perceived quality for the users
  • So it would be beneficial to be able to use whatever is available at the best possible quality
  • Which makes it a lot more complex for an SFU – more decisions to make with more data points to take into consideration
• Mobile
  • Mobile doesn’t like multiple, simultaneous video decoders
  • Especially not when this is hardware accelerated – not all smartphone hardware can work this way
  • For mobile devices, you just might want to select a single video stream to send it – or combine multiple video streams to a single one (which looks more like an MCU, but who cares?)
• Broadcast
  • In many new use cases, people want to have multiple participants chatting, but many more passively viewing
  • Can an SFU scale there? And if it can’t, what will you do instead?

 

Like any other technology, once you get down to it, there’s more to do than the proof of concept. Consider these aspects at the beginning of your project – and not when you need to seriously rethink your architecture.

 

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

The post What are the Challenges of DIY your WebRTC SFU? appeared first on BlogGeek.me.

Do you really want to trust companies like Google or Facebook, or other large organizations with your private communications? They rely on employees to dig into and analyze information when a back door is opened to them. They claim to need to be able to sift through information to pinpoint nefarious activities or corporate opportunities, but that means they are subjecting safety to human limitations. And that door is now available for anyone else that finds a key. How many examples of “hackers” accessing private information such as credit card numbers or social security numbers do we need before we stop trusting external organizations to keep us safe. Who holds them accountable if not the user? Wouldn’t we be truly safer by not putting in a back door at all? Weakening encryption to allow one entity in means weakening security across the board. That is why many believe that “if you don’t pay for the service, you’re more than likely the product!” And, as of yet there is not a very reliable way for the average user to counter this idea and monitor proprietary software to ensure they aren’t selling you and your data. Check out what users on a Slashdot forum had to say about the U.K.’s encryption standard and why having a middle man is not a secure option.

Trailrunner7 posted, “The U.K. government’s standard for encrypted voice communications, which already is in use in intelligence and other sectors and could be mandated for use in critical infrastructure applications, is set up to enable easy key escrow, according to new research. The standard is known as Secure Chorus, which implements an encryption protocol called MIKEY-SAKKE. The protocol was designed by GCHQ, the U.K.’s signals intelligence agency, the equivalent in many ways to the National Security Agency in the United States. MIKEY-SAKKE is designed for voice and video encryption specifically, and is an extension of the MIKEY (Multimedia Internet Keying) protocol, which supports the use of EDH (Ephemeral Diffie Hellman) for key exchange.

‘MIKEY supports EDH but MIKEY-SAKKE works in a way much closer to email encryption. The initiator of a call generates key material, uses SAKKE to encrypt it to the other communication partner (responder), and sends this message to the responder during the set-up of the call. However, SAKKE does not require that the initiator discover the responder’s public key because it uses identity-based encryption (IBE),’ Dr. Steven Murdoch of University College London’s Department of Computer Science, wrote in a new analysis of the security of the Secure Chorus standard. ‘By design there is always a third party who generates and distributes the private keys for all users. This third party therefore always has the ability to decrypt conversations which are encrypted using these private keys,’ Murdoch said by email. He added that the design of Secure Chorus ‘is not an accident.'”

For more information click here: http://it.slashdot.org/story/16/01/19/2151215/uk-voice-crypto-standard-built-for-key-escrow-mass-surveillance

Last edition of Kamailio Development Workshop happened about three years ago. Several people asked about it from time to time, therefore I thought of trying to organize a new edition. Rather short term by now due to various constraints, so the plan is to do it again in Alicante, Spain, during February 15-16, 2016.More details are available at:

• http://www.kamailio.org/w/development-workshop/

Besides spending 2 days digging into Kamailio C code, such event is also good for discovering and sharing development resources among participants, as well as meeting people from community — at the previous editions we met for first time with Victor Seva, Vicente Hernando and Seudin Kasumovic, which in turn contributed a lot of Kamailio code afterwards. It will be also testing phase for upcoming major release v4.4.0, maybe we can plan some stress testing session on site.Right now the goal is to see if there is any interest in such event in order to nail down organizing it or not. Should anyone consider to participate, write an email to:registration [at] kamailio.orgThank you for flying Kamailio!

Last Thursday we had the first virtual w3c webrtc wg interim meeting. Once we sorted out a few technical details it went quite well!

Meeting Home Page:
https://www.w3.org/2011/04/webrtc/wiki/January_14_2016#Virtual_Interim

Nobody cares anymore.

Nobody cares if you are a silo or federated as long as you’ve got an API

It used to be important. Interoperability. Federation. Communication across networks, devices and vendors. All useless now.

We’ve got our lowest common denominator: IP, HTTP – the web. We have our point of federation/aggregation – they now call it the home screen of a smartphone.

People got all riled up on my blog last week something about Wire needing to federate – check the comments. My view? Federating wouldn’t move an inch in their user’s base needle.

Today’s openness and messaging is all about being the platform and enabling others to connect to you. How is that achieved? By way of APIs. And by this new stupid word – “Bots” – which most probably stands for automation.

Why is Bots stupid? Because it just means using the API in a certain fashion.

Back to Messaging.

Silo

If you have a service. What happens if it is a silo?

You gain users to it. Slowly or faster. Doesn’t matter that much (though it probably does to you).

One day you want to add more utility to the service – some stickiness – making sure people don’t leave. So you add features. But you understand at some point that going it alone won’t move you fast enough, so you open it up to external developers and services.

You publish an open API.

Federation

Federation you say? You make your service accessible to other networks by interacting with them using the same protocol?

Great.

But what does that give you exactly? Same set of features you have, give or take a feature or two. Same utility. No stickiness. No differentiation. Not enough.

So you again wish to add features, but getting out of the core you’ve federated just places you in the position of proprietary features. And again you’ll one day understand it isn’t enough. Faster “innovation” and growth are required on that front – you can’t cater all of your customers’ needs. So you… open up! Slap an API on top of your service.

No one cares

Two alternatives. Same end result.

Time to move on. Nothing here to see.

Just make sure you have a solid infrastructure – and an API on top of it for others to integrate with.

 

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

The post Messaging. Federated? Silo? Does it Matter with an API and Bots? appeared first on BlogGeek.me.

The features this week include: the addition of profile logging, functionality, and default configurations for mod_amqp and display update support for Panasonic devices in mod_sofia. Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we are talking about 3D printing! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8728 [mod_amqp] Adding logging profile and functionality and added default configurations
• FS-8735 [mod_sofia] Display update support for Panasonic devices

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-8720 [core] Fixed a segmentation fault when switch_channel_str2cause is called
• 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-8736 [spandsp] Fixed missing MEMMOVE macro in spandsp autoconf
• 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

Interesting how vendors define themselves.

Oftentimes, when you ask companies to define themselves, you get a complete shopping list. The end result is that you are left without an answer that you can use. Enter Twitter, with its razor sharp 140 character descriptions of the account.

Here’s what the WebRTC PaaS vendors I covered in my report (that weren’t taken off market) and how they define themselves:

#Cloud #Communications #WebRTC #API Start building on https://developers.apidaze.io Makers of @ottspott_co. Happy New YearApizee is a provider of real-time communications on webFollow us for mobile app development news, hackathons & events. Check out our community link below. For questions about your device tweet our experts @ATTCaresPlatform as a service and free APIs, SDKs to integrate text, audio, video chat, web conferencing and more into your websites and applications.Bit6 revolutionizes how developers integrate communications into their mobile & web applications. Download beta SDK for iOS now!WebRTC pioneer, real-time communication for mobile & web, customer & workforce contextual collaboration, in-app video & live assistance, visual self-serviceUnify delivers world leading collaboration & unified comms solutions. Talk to us about #NewWayToWork #NW2W #futureofwork Tweets by Sally ^SH & Jett ^JMMaking the future of digital communications services happen. #Mobile #Messaging #Telecom #Cloud #IoT #WebRTC #SS7 #Monetizing #MessagingSecurityPowerful, Intuitive #RealTimeCommunications for an all IP-World #WebRTC #OTT #mobile #cloud #KandyMobile #Disruptor50OnSIP is a leading provider of real-time communications services for businessesThe SDK that has everyone talking. Grab yours at http://developer.oovoo.com . Now with in-call messaging and filters too!Communications for Internet of Apps. Open, cloud based video, voice, data communications for enterprise, social, consumer apps across #WebRTC and mobile.Plivo is a Cloud API Platform and a Global Carrier Services Provider for Voice Calls and SMS. Sign up for a free trial today.Add video, voice, and messaging features to your app in minutes with #respokeShow What You See! Deliver a better experience by adding real-time interactions to your web or mobile app. #CX, #FieldService #Telehealth, #CustServ & moreUse the Sinch APIs to enhance your app with Voice, SMS, Verification, Video, and Instant Messaging.Skylink – WebRTC, audio, video, embeddable real-time communication.TokBox,a @tefdigital company, operates the #OpenTok Platform, making it quick and easy to integrate real- time communications into your websites and mobile appsTropo, now part of Cisco, is a cloud communications API that makes it easy to build voice & text messaging apps. Completely free to try, pay-as-you-grow pricingChanging communications forever by empowering software people to build the future of our modern communications apps. For support: @TwilioHelpCloud platform for real-time communication app development

A few interesting observations:

• Some don’t have an API specific Twitter account – rather a corporate wide account. This makes it hard for developers to understand they have an existing offering for developers
• Some explain their position in the organization and not what they do, which is somewhat sad
• Some definitely are pivoting

As these vendors are in the same place, there’s obviously a lot of shared use of words. I’ve taken the Twitter definitions above, removed unique words and placed them in a tag cloud – the bigger the word – the more appearances in makes:

Community is the derivation of communications, which makes a lot of appearances.

Most focus on Mobile.

To be expected.

WebRTC was less popular in the description. Refreshing and interesting.

Messaging isn’t high on the agenda of most platforms.

Some suggestions to the vendors are in order:

1. If you are a service within a larger organization, make sure to have a Twitter account dedicated to developers
2. Focus on the developer who reads the description and needs to understand what you can do for them, and not who you are within the company
3. Bring the same clarity that Twitter description forces you to all your marketing collateral

 

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

The post WebRTC PaaS Vendors as Twitter One-Liners appeared first on BlogGeek.me.

2016 will be the year of video!

I heard that in 2005 I think. And then 2006. And then in almost every following year.

I used to work in a video conferencing company. So it really mattered.

When video did happen… it happened outside of the domain of enterprise video conferencing systems. And it continues to grow predominantly there.

But the thing is – video still is minuscule. Voice isn’t that interesting or important as it used to be either.

If I had to chart the use of our basic communications options these days, it would probably look like this:

I’d also say that the only reason video is almost as big as voice is due to WebRTC and the passing of time – It is easier today than ever before to implement and add video chat capabilities anywhere. And there are people who tend to do video calls instead of voice ones – because they can, but not because video is that critical, mystical part we’re often led to believe.

Video definitely has its place in the world and is extremely useful. I do most of my own business through video calling with clients all over the world. Most of them have never met me in person and are still happy to work with me. With voice, it would be slightly harder to achieve.

What ticked me to this topic was a piece on Ars Technica about the adoption percentage of IPv6 in 20 years (hint: the smallest 2 digit number). While the two things are different, video hasn’t fared much better and has been around for even longer.

Video will be a slow process, but the end result will never be the pervasiveness of voice or the current ubiquity and growth of messaging in all of its forms.

You still waiting for video to happen?

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

Test and Monitor your WebRTC Service like a pro - check out how testRTC can improve your service' stability and performance.

The post 20XX will be the Year of Video! Not… and how is this related to IPv6? appeared first on BlogGeek.me.

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

Release files are located here:

• Tarball: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.6.6.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-8401 [verto_communicator] Added Speaker selection in settings model and video page and fixed model to modal
• FS-8545 [verto_communicator] Improve controls for screen share, fixed a read lock regression, do not allow video floor on a member with a reservation id set, and add missing code to deal with screen share part
• FS-8616 [verto_communicator] A new menu for moderator, added gain buttons, and removed the 3-dot-button, moving its behavior to member-name div
• FS-8264 [verto_communicator][verto] Adapted the layout select to new response, added a separated menu in members list to set its reservation id, and added all the reservation IDs in the return of “list-videoLayouts” command
• FS-8293 [verto][mod_conference] Made sanity level based on 1080p and added a video-quality conference profile parameter for specifying the motion factor when calculating video bitrate, defaulting to 1.
• FS-8595 [mod_conference] Improve auto bitrate in personal canvas mode and do not let auto bitrate exceed native picture size
• FS-8543 [mod_conference] Improve mute handling on conference and WebRTC
• FS-8546 [mod_conference][mod_verto] Make original video demo backward compatible with livearray-json-status
• FS-8529 [mod_conference] Added video-floor to personal canvas mode
• FS-8549 [mod_http_cache] Add support for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in S3 profiles
• FS-8547 [core] Add error log into stats to log when quality impacting events begin and end
• FS-8568 [core] Allow building using system OpenSSL without EC support
• FS-8632 [core] Add origination_audio_mode originate variable with options for sendonly, recvonly or sendrecv
• FS-8559 [mod_shout] Add “mpga” to the list of supported extensions
• FS-8433 [mod_sofia] Allow hangup cause to be set inside redirect data

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

• FS-8592 [Windows] Fixed some simple compiler errors
• FS-8333 [build][Debian] Added mod_hiredis.deb
• FS-8152 [Debian] Make sure to package the image directories too
• FS-8576 [Debian] Fixed a package upgrade issue related to the fonts being installed in multiple packages
• FS-8723 [Debian] Adding a file extension to the package build logs
• FS-8614 [verto_communicator] Add Debian developers install script and update README.md to reference it
• FS-8578 [mod_verto] Fixed build error for missing __bswap_64 on osx
• FS-8293 [verto] Add quality level 0 to conference (default is 1) and fix some logic in auto bandwidth

The following bugs were squashed:

• FS-8537 [mod_lua] Fixed a segfault caused by passing nil to various lua functions
• FS-8527 [mod_conference] Do not send the video of last_video_floor_holder to video_floor_holder if the videos are related
• FS-8569 [mod_conference] Fixed undefined symbol conference_cdr_test_mflag
• FS-8574 [mod_conference] Fixed a read write lock issue
• FS-8053 [mod_conference][mod_sofia] Fix for WebRTC’s SDP containing a=sendonly for video, but the client still receiving the video stream
• FS-8589 [mod_conference] Fixed using conference playback with full-screen=true not working correctly
• FS-8354 [mod_conference] Fixed G722 audio issues with mod_conference caused by previous commit fab43547
• FS-8602 [mod_conference] Fixed conference not auto-generating layouts properly when callers with no camera are present
• FS-8615 [mod_conference] Fixed a crash when quickly changing layouts and setting reservation ids
• FS-8542 [verto_communicator] Fixed the tooltips of video controls
• FS-8603 [verto_communicator] Added device validation to prevent lost microphones after reset
• FS-8640 [verto_communicator] Don’t clear conference member reservation id on members that don’t have a reservation ID
• FS-8590 [verto_communicator] Fixed sending malformed vid-res-id command when changing layouts by treating no res-id the same as clear
• FS-8556 [mod_verto] Screen shares are not recoverable so do not try
• FS-8293 [mod_verto] Fixed some regressions where speed test caused excessive downlink bandwidth
• FS-8633 [mod_verto] Fix for the first verto to join a conference does not get “conference-livearray-join” event
• FS-8599 [verto] Removed a workaround for Mozilla that is no longer needed for video size
• FS-8553 [config] Include verto_contact into the dial-string in the samples
• FS-8566 [core] Fixed calls failing when put on hold in bypass media mode with inbound late negotiation set to false
• FS-8573 [core] Fixed one way audio after resuming from hold in bypass media mode and fixed a core dump on playback after “Decode Codec is not initialized!” log message
• FS-8575 [core] Fixed DTMF not being passed from a to b during rfc 2833 events
• FS-8612 [core] Fixed a rare IVR originated calls crash due to read codec leak
• FS-8625 [core] Fixed a segfault caused by an external incoming call from Google Voice.
• FS-8642 [core] Fixed CF_VIDEO_READY being set on non-video calls
• FS-8713 [core] Fixed a crash caused by read exceeding buffer
• FS-8716 [core] Fixed the recording offset delayed by a few seconds for rtmp stream
• FS-8677 [core] Fixed a crash (possible memory corruption) after codec change
• FS-8585 [mod_commands] Expanded {} and <> to [] for each dial string in group_call to allow for multiple device registrations for the same user
• FS-8582 [mod_httapi] Fixed a crashed caused by null URL being passed
• FS-8588 [mod_httapi] Fixed a crash found while fixing unreliable digit collection
• FS-8619 [mod_rayo] Reply with conflict stanza error if bind is attempted with duplicate JID. Improve error handling when ‘ready’ callback fails.
• FS-8708 [mod_rayo] Fixed the example configuration to map to correct DETECTED_TONE event from spandsp_start_tone_detect
• FS-8621 [mod_av] Fixed H264 HD1080P video quality issues
• FS-8631 [mod_db] Updated the regex to allow DSN to match the rest of FS code
• FS-8643 [mod_sofia] Fixed some memory leaks
• FS-8715 [mod_sofia] Make the oubound_proxy on the profile consistent with how we do the same thing on the gateway
• FS-8679 [mod_sofia] Fixed sofia sending call completed elsewhere if not disabled by the option ignore_completed_elsewhere
• FS-8711 [mod_skinny] Fixed a couple of possible memory leaks in mod_skinny packet reading code
• FS-8722 [mod_skinny] Remove nested redundant mutex that could cause a hang

This week we had a number of bug fixes and a change to the packaging build logs.

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

• FS-8723 [Debian] Adding a file extension to the package build logs

The following bugs were squashed:

• FS-8708 [mod_rayo] Fixed the example configuration to map to correct DETECTED_TONE event from spandsp_start_tone_detect
• FS-8711 [mod_skinny] Fixed a couple of possible memory leaks in mod_skinny packet reading code
• FS-8722 [mod_skinny] Remove nested redundant mutex that could cause a hang
• FS-8713 [core] Fixed a crash caused by read exceeding buffer
• FS-8716 [core] Fixed the recording offset delayed by a few seconds for rtmp stream
• FS-8677 [core] Fixed a crash (possible memory corruption) after codec change
• FS-8673 [core] Fixed a core dump on playback after “Decode Codec is not initialized!” log message
• FS-8715 [mod_sofia] Make the oubound_proxy on the profile consistent with how we do the same thing on the gateway
• FS-8679 [mod_sofia] Fixed sofia sending call completed elsewhere if not disabled by the option ignore_completed_elsewhere

The FreeSWITCH 1.4 branch had a couple of bug fixes back ported. And again, keep in mind that 1.4 is quickly moving toward end of life and won’t be supported any longer except for high level security issues.

The following bugs were squashed:

• FS-8708 [mod_rayo] Fixed the example configuration to map to correct DETECTED_TONE event from spandsp_start_tone_detect