bloggeek

WebRTC use cases? An endless list of opportunities.

Here are a few, off the top of my head, of use case I’ve came across in the past year or so, where WebRTC was used or seriously planned to be used.

• Simple video chat
• Web conferencing
• International voice calling
• Receiving a call in the browser
• Hospital clowns
• Performing digital art on stage
• Visiting a museum at night
• Praying
• Porn
• Adult gaming
• Gaming
• Doctor visitation
• Group therapy
• Jail visits
• Banking
• Retail
• Drug prescription
• Document signing
• Live broadcasting
• Radio stations
• Music jams
• Karaoke
• Gym classes
• Dance classes
• Teaching and learning online
• Expert consulting
• Contact centers
• CRM integration
• Job interviews
• Virtual classes
• One on one tutoring
• Web meetings
• Webinars
• Dating
• Video streaming
• P2P CDN
• Private messaging
• File sharing and sending
• Assisting hard of hearing people
• Assisting the blind
• Assisting people who need live translation
• Language learning from a tutor
• Practicing language with native speakers
• Security cameras
• Collecting sensor data

Did I miss any WebRTC use cases? Definitely.

What will you do with WebRTC today?

–

And if you built anything – might as well publicize it on the WebRTC Index.

The post WebRTC Use Cases appeared first on BlogGeek.me.

Not too big, but not small either.

Here’s a shocker – Facebook Messenger has been updated 19 times on Android in 2016. WhatsApp has had 25 releases in the same time span. And we’re not even in the middle of February.

We are talking about the two messaging applications with the largest number of monthly active users, with WhatsApp surpassing the one billion milestone. gulp.

Should we place messaging apps under weight watchers?

To deliver an app that weighs 26 MB to a billion people (I am thinking WhatsApp here), you end up sending over 23 petabytes of data (translation: a shitload of bits). Doing that 25 times since January 1st…

I took a stab at looking into the consumer messaging apps (some of the enterprise ones are larger, though less frequently updated). Here’s what I found:

#1 – They are all fattening up

The scatter graph above is a bit scattered, but it is easy to see that most apps are increasing in size over time. Since September 2014 until January 2016. They all migrated from the 10-20 MB sizes into the 20-40 MB sizes. That’s a doubling in their weight in less than two years.

We don’t think about it much, but we’re in a serious need of a diet here:

1. This loads our networks. Not as much as video traffic, but still significant
   • Most users have more than one such app on their phone
   • These apps update frequently
   • It adds up
2. With WhatsApp reaching the one billion mark, where will it be headed next?
   • To maintain its growth it needs to search for additional users
   • These need to come from developing countries
   • And there, bandwidth and data is scarce
   • The smaller the app, the easier it is on users to handle
3. Most of the messaging apps don’t seem to care about how fat they are

#2 – Size doesn’t equate feature richness

The bar chart above shows how big the latest version of each of these messaging apps is.

Te results are rater surprising:

• Skype is the bloated of them all at this point in time, but I don’t remember anything new or interesting that Skype on Mobile introduced in the last two years. And yet – it managed to double its size
• Those in the vicinity of one billion users/downloads are trying to stay on the skinny size – Facebook Messenger, WhatsApp and Hangouts are all rather small compared to the rest of the pack – and somehow, Facebook Messenger is even smaller than WhatsApp (I’d expect it to be the opposite)
• WeChat and LINE, which can be seen as e-commerce platforms are larger than most, but somehow Skype and Viber manged to be even bigger

–

I wonder when a diet will be called for. And maybe it already is.

 

Kranky Geek India takes place in Bangalore on 19 March 2016. Register to join us!

The post What’s the Size of Your Messaging app? appeared first on BlogGeek.me.

If you aren’t using AppRTC yet then you should start.

I had a few customers last month who had quality issues with their service. They were trying to understand the root cause of these issues, and at times, the question raised was “is WebRTC up for the task?”

• Does the poor audio quality we experience in our service derive from the codec, the browser’s implementation or something in our own backend?
• Are the video stutters stem from heavy packet loss and that’s just life – or are we adding some of our own issues into the mix?
• The average bitrate we reach in a call. Is it because the browser is limiting us? Is it because the connection is bad? Is it…

The list goes on.

The fact that now you get a fully implemented media engine in the browser for free is great. The problem is, it gives you (or your developers) the opportunity to blame the browser: It isn’t us. Google’s engineers did such a crap job with X that we just can’t fix it.

More often than not – this won’t be the problem.

When in doubt – check AppRTC

Google launched AppRTC quite some time ago.

AppRTC is Google’s way of showcasing WebRTC in their simplest version of the “Hello World” program. This being WebRTC, there are many moving parts, but to some extent, AppRTC is rather baseline – especially in its dealings with media.

This makes AppRTC a great baseline reference when you have issues with the media paths of your own service or just want something to compare it with.

Got an issue? Test what happens when you run AppRTC and compare it with your own service. If you see that your service isn’t performing in the same manner, chances are the problem is on your end – and now you can start diverting focus and resources towards searching the problem instead of blaming the browser.

Where to look for the problems?

• Your NAT traversal servers, if they are being used
• Are you doing any backend processing for the media? Map your pipeline there. Check each step of that pipeline to see if it is to blame
• Transcoding never fails to fail you – check there if you use it
• Jitter buffers are notoriously… jittery. Make sure the implementation fits your use case
• Network routes and handling dynamic bitrates and packet losses might be handled nicely by the browser, but is your backend up for the task as well?

Don’t forget test.webrtc.org either

Google has another great analysis tool – test.webrtc.org

You open the settings, insert your own STUN and TURN server configuration – and start the test.

It will then check the system and network connections to give you a nice view of what the browser is experiencing – something you can later use to understand the environment you operate in.

Why is this important?

With WebRTC, it is easy for developers to blame the browser. This isn’t productive.

Your first task should be to create a baseline reference you can trust. One that enables isolating the issues you are experiencing systematically.

AppRTC is a good place to start.

The post Are You Using AppRTC as Your WebRTC Baseline Reference? appeared first on BlogGeek.me.

Our next Kranky Geek event is taking place in India.

Kranky Geek events? We did them twice. Both times in San Francisco. Both were very successful events. In both we didn’t know if these are one time gigs or something we want to continue doing.

Then we sat down to plan 2016, and came up with three planned events. The first one is taking place in Bangalore, India.

As with any Kranky Geek, this one is about developers of real time communications.

Like previous Kranky Geek events, it is free to attend. Sponsors take the burden of enabling us to plan this event and then pay for everything around it.

Google has been taking the lead here and helping us a lot in getting these events off the ground – in a way taking the leap of faith in our ability to manage these events.

India

Google asked us to do an event in India, so we happily obliged. For me, it would be the first time in India, making the excitement on my end even higher.

India makes sense in a lot of ways. Many of the vendors I end up looking are vendors that are local to India. Others are vendors with large development teams in India who end up doing a lot of the WebRTC development. Kranky Geek India gives me personally a great opportunity to meet many of these people in person.

To make things short:

Where? Bangalore, India

Exact location: MLR Convention Center

Date and time: March 19, 11:00 until we finish

How do I register? here

 

Our sponsors this time are Google, TokBox and IBM. Expect a large cadre of interesting speakers and topics – some local and some international in nature.

I’d love to see you with us at the event!

The post Join us for Kranky Geek India: March 19 appeared first on BlogGeek.me.

Just making sure you’re not missing out…

If you don’t know, in the last year I’ve been part of a great team of partners. We are building together a WebRTC monitoring and testing service called testRTC. The service is up and running for some time now with an increasing number of customers.

The most crappy part of our service was our website (not the one customers are using, but rather the one potential customers look at). So we updated it recently.

One of the main additions to that website is the new blog there. I’ve got an editorial calendar for it running until March with weekly content that I want to share with you, but felt that BlogGeek.me isn’t the best of places for it – it was too focused on testing or too related to testRTC.

What will you find in our testRTC blog?

• Announcements about our service and the versions we are rolling out
• Useful tips for testers, like the one we published yesterday about .y4m files and Chrome
• Things we think you should take care of in your testing practices
• Insights into our design decisions for our internal architecture
• Test script samples of how testRTC can be used to handle certain WebRTC testing issues

So some of the content will be relevant to everyone while other parts of it for those using testRTC.

Subscribe now and follow us

If this sounds interesting, I suggest you subscribe to our blog or social media link(s):

• Subscribe to our blog via RSS or email
• Follow us on twitter
• Follow us on LinkedIn

 

The post Subscribe to the New testRTC Blog appeared first on BlogGeek.me.

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.

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.

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.

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.

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.

Who needs to communicate in enterprises anyway?

Everyone.

Communication is… overrated

But do we really need to treat it as if it is the most critical piece of the enterprise world?

I use multiple systems to make my calls these days. They are WebRTC based or proprietary apps such as Skype, WebEx or GoToMeeting. I grumble when I have to use a proprietary system and install stuff on my laptop, but that’s life.

It was like that for me even when working for enterprises in the past – big and small. Somehow, you always need to have a “phone system” and be reachable. But other than that? I’d say “omnichannel” as a buzzword has stuck to the contact center but is just as important in unified communications.

But in Unified Communications, Omnichannel means something really different – it means that you can now reach out to people on lots of different channels and mediums – picking up the ones most suitable for the taks – which most often than not ends up being different than what the corporate IT has decided you should be using.

And you know what? I couldn’t be bothered with it.

The essence of Unified Communications is the here and now. Real time communications. If a minute passed, it is no longer interesting. It is lost.

Hangouts. Talky. A phone call (international or otherwise). Skype. Anything else.

Just pick one and lets meet.

—

Enterprise Messaging though is a different story.

It isn’t focused in the here and now, but rather in collecting data and making it accessible. It is about synchronizing teams and aligning them – asynchronously.

And “omnichannel” there? It means integrations with anything and everything that is enterprise software.

Which makes it the point of access for an employee to his daily life in the office.

It is a lot more sticky these days than unified communications.

—

Unified Communication is on another rebranding rampage. We used to call it “Convergence” a decade or two ago. And when that felt old, we started calling it Unified Communications. There are analysts that are now coining the term WCC – Workstream Communications and Collaboration. A mouthful that simply says Unified Communications need to look at the Enterprise Messaging space and copy it.

The end result will still be a focus on the here and now. And it will still be overrated.

 

[show promotion title=”strategy-session”]

The post Unified Communications is Overrated appeared first on BlogGeek.me.

Challenges ahead.

A shy over a year ago, I wrote about 3 startups: Talko, Wire and Switch

All of them looked promising. All were using WebRTC.

In 2015, Switch had a meeting with $35 million, along with quite a few successful deployments in businesses big and small.

A month ago, Talko got acquired by Microsoft. I’ve interviewed here the Talko team in the past. Selling to Microsoft shows. Shutting the company. With little objections from customers. It all points to a single conclusion – Talko has been a failure when it comes to the business side of it. It probably had a solid technology – otherwise – why would Microsoft acquihire the team and fold it into Skype? I am sure Ray Ozzie and the team of Microsoft veterans in Talko added to this acquisition, but there was no other value in this transaction.

The Talko Team expresses it best on their updated homepage:

However, as engaged as many of you have been, the reality is that the broad-based success of communications apps tends to be binary: A small number of apps earn and achieve great viral growth, while most fall into some stable niche.

Talko didn’t grow fast enough or big enough. Clementine’s acquisition by Dropbox is similar. A communication solution geared towards team/group/enterprise communications gets acquired for its team with the service being left behind, never to be seen again.

And that’s in the less competitive domain of the enterprise. What will be with Wire? The third company I wrote about.

On Android, Wire reportedly has 100K-500K installs. Assuming iOS has twice as much (I am trying to be positive), that still falls way short of any of the messaging services we usually hear about – they are measured by 100’s of millions. Of active monthly users – not installs.

It is hard to see how Wire can change its abysmal future without a serious pivot or a drastic change in current market trends. Some will say this is a matter of a directory service and network effects. I think it is a matter of strategy and luck. Where Wire failed to attract the crowds, a different messaging service – Telegram, with 50M-100M installs on Android and a reported 60M monthly active users.

Wire was formed in 2012 and Telegram in 2013. So we can’t say Telegram had any head start here.

WebRTC makes it too easy to build and launch a communication service, which in turn, makes it hard to build a viable business with it. The role of product managers and people who need to think of the business case is more important than the technologists building the service when it comes to WebRTC. At the same time, finding good developers who grok WebRTC isn’t easy either.

2016 is going to be crucial for Wire.

What do you see for your initiative in 2016? Do you have a business case and route to market and money, or are you tinkering with the technology, assuming that if you build it they will come?

 

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

The post Can Wire Succeed Where Talko Failed? appeared first on BlogGeek.me.

When it is the wrong metric to track.

Microsoft playing the number games with Edge adoption stats

44.5 billion.

minutes.

That’s how long people have been using Microsoft Edge “just last month”, according to Microsoft:

Over 44.5 billion minutes spent in Microsoft Edge across Windows 10 devices in just the last month.

That other number of 200 million monthly active devices using Windows 10 is much more impressive.

I am interested in Edge due to WebRTC and ORTC. It is one of the missing pieces of our puzzle to get adoption (or at least that’s what we’ve been told).

So how can 44.5 billion minutes can be so unimpressive?

Do the math.

Let’s assume only half of Windows 10 users make use of Microsoft Edge.

This gets us to an average of 445 minutes a month per user, placing it at less than 15 minutes a day (!)

How many of these minutes are spent with an idle browser? I got a laptop and a desktop open 24/7 with Chrome running on them. Even when I am engaged in other applications.

Microsoft decided to announce a largish number to hide the fact that Microsoft Edge isn’t really getting the love and adoption they expected, which is sad. I’ve used it a couple of times on my own Windows 10 laptop. It does what it is supposed to do and does it well, but that’s about it.

The challenge is migrating from Chrome. It stores my credentials to the many sites I visit, it has that nice search bar that often times just finds the URL I need without really searching (it automatically completes from its history), there are the few extensions I’ve got installed. All in all, it does the work. It is bloated and a memory hog, but the time when this mattered (a year or two ago) passed already, so there’s very little incentive for me to switch browsers.

Microsoft is killing Internet Explorer 8, 9 and 10 in the same day next week, pushing businesses into Internet Explorer 11 or Microsoft Edge. This might gain them a percentage or two more in adoption of Microsoft Edge – not nearly enough. Microsoft will probably announce end of life for Internet Explorer 11 in a year or two – the sooner the better if they want Microsoft Edge to grow.

What else can Microsoft do to improve its position? I don’t know. I don’t believe they can. The opportunity to surpass Google Chrome had come and gone. They will need to wait for the next opening when Google falters with Chrome or make something enticing enough for people to switch. It is sad, as Microsoft Edge is technically sound – it made browsers interesting again.

For WebRTC, Microsoft Edge still makes no difference at all. We’ve seen a few announcements of ORTC support by some vendors, but that’s about it. There’s no urgency in vendors to support it. The discussions are still about Internet Explorer when it comes to WebRTC.

Where does that leave us?

• Companies who waiting for Microsoft to adopt WebRTC will continue to wait
• Those who haven’t waited have made the correct choice – deal with what’s available and don’t wait for the forces that be to save you
• While Apple might get WebRTC properly, Microsoft hasn’t. Introducing ORTC into Internet Explorer is what the market needs, but it won’t happen by Microsoft
• Mobile is unaffected, as consumption there is done by apps, so browser adoption issues are irrelevant for most

 

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

The post When is 44.5 Billion a Small Number? appeared first on BlogGeek.me.

Time to fix the stupid notifications of all them apps. Especially messaging ones.

Push notification for messaging apps – not as easy as you thought

When it comes to messaging, they are probably the most chatty applications out there when it comes to push notifications (not including Candy Crush).

I’ve had my share of bad experiences with messaging and notifications to know what works for me and what annoys the hell out of me. This is also where you see the true leaders shine and the rest slumbering along.

IP messaging is considered by most developers a rather simple thing to implement. It isn’t.

Here are a few things you should incorporate into your push notifications implementation when you want to deal with messaging capabilities.

#1 – Synchronize devices

Your service is sending me messages? Great.

You are aware I am the proud owner of a smartphone, tablet, laptop and PC? And that I generally connect through all of them interchangeably.

So when I am receiving a message (or sending one for that matter), it would be nice if said messages would magically appear in all of my devices. And in a timely fashion.

One of the reasons I’ve been using Skype less and less this year is that it just didn’t synchronize properly – not showing messages on all devices, or popping notifications on the app on my laptop a day or two after I’ve already received them on my phone or on the PC. It seemed like Skype just weren’t seriously prepared for this world of multiple devices per person.

Assume that if I sign in from a new device, I don’t want a “fresh” start – I want all of the data and context that is available to me on my other devices to be availalbe in this new device of mine as well.

#2 – Clear notifications. Everywhere

You know that fuzzy feeling inside when you receive an email? My whole house is pinging (or used to ping), each device trying its best to be the first to announce that incoming email.

The main problem is, that handling the notification (=opening it) on one device didn’t necessarily clean it from all other devices.

Google Mail got it right after a year or two on Android. WhatsApp got it right the first time – it was almost a magical feeling when they came out with their web interface and messages got cleared on the web or on the phone automatically – and FAST.

The most annoying thing is an app that doesn’t clear its notifications. I know there are many who don’t care, but I like my notifications windows clean. Going over multiple devices to clean the same message is a show stopper for me these days (and again, up until a few months ago, Skype didn’t get this one right).

#3 – Mobile and web

Notifications should occur both in mobile apps and in web browsers. Modern browsers already support notifications, so make sure to utilize it when needed.

You need to remember that knowledge workers may sit all day in front of a computer – so why not leverage that to show notifications there instead of making them pick up the phone?

#4 – How urgent is it again?

Not. Every. Single. Message. Is. The. Same.

How are you going to report them? Or even notify them?

You may have them notified separately. Or bunch them up under a single icon.

Slack just added a Do Not Disturb feature. Great. I can now silence notifications in Slack. The problem is, they decided that my work day is 8am-10pm. Anything not in this timeframe isn’t notified to me. It would have been fine – but only if when 8am arrived – they’d pop up a notification about things I’ve missed.

Groups in Whatsapp can be silenced, or certain people. You can even do it for a period of time (I don’t really care about kindergarten related chatter when I am abroad). But it is manual. It would have been so much better if somehow, WhatsApp magically would decide what I prefer and what I didn’t when it came to notifications.

#5 – How do I reply?

The vinyl Android SMS application enabled me to mark messages as read – right from the notification. No need to enter the app just so it knows I’ve read it. Some other apps enable replying to notifications without getting into the app.

What are you doing regarding your app? Is the only thing I can do is enter the app, or can I act from the notification itself? (guess what I prefer)

#6 – Where in the view stack will I be landing?

Got the notification on my phone. Pressed it. Where will it lead me?

LinkedIn’s terrible app (even the latest incarnation of it) does a great job at putting you in the wrong view – try accepting an invite to connect and you’ll end up preferring to open it inside your browser.

Skype gets you to the conversation. Pressing the back button on Android leaves the app. But if you then enter the Skype app explicitly, after several incoming notifications of a group conversation there – it will lead you to the same conversation over and over again – at least to the same amount of times you pressed on the notification of new messages in that group. Something is terribly wrong there.

WhatsApp does a decent job here – there’s a single WhatsApp notification for everything. If all notifications are from the same conversation – that’s where you’ll land. If there are multiple conversations you are being notified of – you’ll land at the WhatsApp homepage. Oh – and if you press back? It takes you from the conversation view to the homepage of WhatsApp before letting you leave the app.Gmail does the same.

#7 – Think Offline

Bonus points for handling unconnected use cases. Many miss this one when it comes to notifications.

When you press the notification, the app is launched and it goes to the server to grab the actual reason for notification. But what if I am INSIDE an elevator? Some apps do a miserable job at making sure that the launched app can show me the message without being connected (you already got me that notification – why not get the whole damn message while at it?)

Why is it important?

IP Messaging is probably one of those areas where developers go NIH. They know it all. How can sending a couple of messages be hard? Oh – you also need push notifications on top? No worries! There’s that simple API in iOS that does that.

But that’s usually only the beginning of the saga when it comes to IP Messaging and push notifications. If you decide to develop it in-house – you better be ready to writing down the exact spec in detail to get it right. Otherwise, find someone who does that for a living.

 

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

The post Messaging and Push Notifications: Best Practices appeared first on BlogGeek.me.

Consider this my end of year review for WebRTC in 2015.

Tomorrow will mark the last day of 2015. As we head into 2016, it is time to review what we had this year in WebRTC. For me this year proved to be a real rollercoaster, but somehow I get a feeling 2016 won’t be any different.

I dug some of the statistics I regularly collect, with differences and trends in 2015 in mind. From there, the road to an infographics about WebRTC State of the Market was a short one. For those who have membership access to my site, I will be spending the next Virtual Coffee discussing these findings in detail.

Feel free to share and embed this infographic (click to enlarge or download the PDF) if you wish:

Share this Image On Your Site

<p><strong>Please include attribution to BlogGeek.me with this graphic.</strong></p><br />
<p><a href=’https://bloggeek.me/webrtc-state-market-2015/’><img src=’https://bloggeek.me/wp-content/uploads/2015/12/201512-WebRTC-infographic.png’ alt=’WebRTC State of the Market – Are we there yet?’ width=’540px’ border=’0′ /></a></p><br />
<p>
See you all in 2016!

 

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

 

The post WebRTC State of the Market: End of 2015 appeared first on BlogGeek.me.

WebRTC Broadcast will be all the rage in 2016.

As I am working my way in analyzing the various use case categories for WebRTC, I decided to check what’s been important in 2015. The “winner” in attention was a relatively new category of WebRTC broadcast – one in which WebRTC is being used when what one is trying to achieve is sending a video stream to many viewers. These viewers can be passive, or they can interact with the creator of the broadcast.

Up until 2014, I had 4 such vendors in my list. 2015 brought 15 new vendors to it – call it “the fastest growing category”. And this is predominantly a US phenomena – only 3 of the new vendors aren’t US based startups.

Periscope and Meerkat are partly to “blame” here. The noise they made in the market stirred others to join the fray – especially if you consider many of them are based in San Francisco as well.

TokBox just introduced Spotlight – their own live broadcast APIs – for those who need. At its heart, Spotlight enables the types of interactions that we see on the market today for these kind of solutions:

1. Ability to produce video by using WebRTC – either from a browser or a mobile app
2. Ability to view the video content as a passive participant – usually via CDN by way of Flash, HLS or MPEG-DASH
3. Ability to “join” the producer, creating a 1:1 video chat or a video conference that gets broadcasted to others

Here are some of my thoughts on this new emerging category:

• Most of the focus today is using WebRTC broadcast on the producer’s side. The reasons are clear:
  • Flash is dying. HLS and MPEG-DASH are replacing it on the viewer side, but what is going to replace it in the producer side? Some go for specialized broadcasing applications, but WebRTC seems like a good alternative for many
  • This is where vendors have more control – they can force producers to use a certain browser – it is much harder to force the viewers
  • WebRTC plays nice in browsers and mobile. No other technology can achieve that today
• The producer side is also where most constraints/requirements come from today:
  • You may want to “pull in” a viewer for an interview during a session
  • Or have a panel of possible speakers
  • You may wish to split the producer from the “actor”, facilitating larger crews
  • All these fit well with the capabilities that WebRTC brings to the table versus the proprietary alternatives out there
• H.264 is the predominant requirement on the viewer side at the moment. VP9 is interesting. This means:
  • Trnascoding in necessary in the backend prior to sending the video to viewers
  • H.264 in Chrome can improve things for the vendors
• There’s a race towards zero-latency. Vendors are looking to reduce the 10-60 seconds of delay inherent in video streaming technologies to a second or less (not sure why)
  • This would require attempting to replace viewer end of the architecture to a WebRTC one
  • It will also necessitate someone building a backend that is optimized for this use case – something that wasn’t researched enough up until today
• Peer assisted delivery vendors such as Peer5 and Streamroot is another aspect. These kind of technologies sit “on top” of a video CDN and use WebRTC’s data channel to improve performance
• I’ve started noticing a few audio-only vendors joining the game as well. This will grow as a trend. The audio based solutions tend to be slightly different than the video ones and the technologies they employ are radically different. The technologies and architectures may converge, but not in 2016

2016 will be a continuation of what we’ve seen during 2015. More companies trying to define what live WebRTC broadcast looks like and aiming for different types of architectures to support it. In most cases, these architectures will combine WebRTC in them.

 

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

The post The Rise of WebRTC Broadcast and Live Streaming appeared first on BlogGeek.me.

Is it just me or are browsers fun again?

Who would have believed? Microsoft releasing their JavaScript engine as open source. And under a permissive MIT license.

While there are many browsers and vendors out there, there are probably only 4 that matter: Chrome (Google), Firefox (Mozilla), Edge (Microsoft) and Safari (Apple).

Who haven’t I included?

• Microsoft’s Internet Explorer. Microsoft is actively transitioning away from it to Edge
• The rest of the pack, as far as I can tell, are nice wrappers around Chromium – and are negligible in their market share anyway

What should we expect in 2016 from the browsers? A lot.

Google Chrome

For Google, Chrome is an important piece of the puzzle. It lives in the web and the more control points it has over access to information the better positioned it is.

The ongoing activity of Google in WebRTC is part of the picture, and probably not the biggest one.

Google is the company with the least amount of regard to legacy code that there is. When something requires fixing, Google developers are not afraid to rewrite and refactor large components, and management allows and probably even encourages this behavior – something I haven’t seen anywhere else.

A few examples for recent years:

• Google forked WebKit into Blink, essentially replacing the page rendering inside the browser. The first order of the day after the fork? Spring cleaning – removing code that isn’t necessary for Chrome
• Google switched EVERYTHING from OpenSSL to BoringSSL. OpenSSL seemed to have some vulnerabilities lately, so Googlers took the time to fork it, clean it up – and deploy the new project across Google
• Introducing SPDY and getting HTTP/2 out the door

That said, it seems that Google have been somewhat complacent in the area of speed and size with Chrome. I am sure the Chrome team is aware of it and working hard to fix it, but the results haven’t been encouraging enough. This will change – mostly because of the actions of the other browser vendors.

Mozilla Firefox

Mozilla is in transition. From relying on Google as its main benefactor to spreading the risks.

In the past few months though, Mozilla has started trimming down its projects:

• Mozilla plans on splitting Thunderbird, its email client, from Mozilla
• Mozilla stopped developing and selling Firefox OS smartphones – I wonder how will this affect its relationship with Telefonica, TokBox and the Hello project

These changes indicate that Mozilla understood it can’t just try and replicate every cool new Google project and open source it – it will now focus on making Firefox better. This is a much needed focus, with Firefox slipping in market share for quite some time now.

On the browser front, the notable changes Firefox is making are around privacy and the pornprivacy mode.

Microsoft Edge

Edge is new. It is a complete rewrite of what a browser is. It is speedy, clean and with huge potential. It has its own adoption challenges to overcome (mainly people comfortable enough with Chrome and not caring to try out Edge).

What to do? Microsoft just open sourced the JavaScript engine in Edge – Chakra. It shows some interesting performance results that seem to rival Chrome’s V8. The more interesting aspect of it, is the clear intent in getting Chakra into Node.js as a V8 alternative. Not sure if it will work, but it does has merit. It shows to me that:

1. A browser/webapp today is split into two – frontend and backend (we already knew that). More often than not, these days the backend is based on a Node.js framework. Microsoft wants to be a part of that backend, probably to end up licensing Windows 10 on servers
2. JavaScript today is more than a browser scripting language. A JavaScript engine’s health/popularity/importance relies on the ecosystem around it – which is why Microsoft ended up open sourcing it

I am sure there’s an engineer at Google already tasked at reviewing the code of Chakra once it gets a public git repository.

Edge is trying to move the envelope. This will challenge Google further with Chrome – always a good thing.

Apple Safari

Safari seems second place at Apple. It is working, but not much is said or done about it.

We hear a lot of rumblings about WebRTC in Safari lately. How will this shape into Safari, iOS and Mac is anyone’s guess. The bigger question is will this be the only significant browser change to be introduced by Apple or part of a larger overhaul?

Why is this important?

The web isn’t standing still. It is evolving and changing. Earlier this year, WebAssembly was announced – an effort to speed up the interactive web.

While many believe that apps have won over the web when it comes to development, we need to remember two things:

1. There are times when an app won’t do – as Benedict Evans phrases it well in Apps versus to web: “Do people want to put your icon on their home screen?” – and sometimes they just don’t
2. Apps are sometimes built using HTML5 – usually because a developer wants a single code base for all platforms or just needs easier access for his service from a browser and mobile apps at the same time

An interesting road ahead of us.

 

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

The post The Browser Wars are Back appeared first on BlogGeek.me.