News from Industry

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.

These developers are working hard to bring you more great things from FreeSWITCH. Make their week a little easier by donating to keep them fed. Keep them firmly planted in front of their laptops! Donate today!

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.

Next European edition of Kamailio Advanced Training will take place in Berlin, Germany, during March 7-9, 2016.The content will be based on latest stable series of Kamailio 4.3.x, released in June 2015, the major version that brought a large set of new features, currently having the minor release number v4.3.3.The class in Berlin is organized by Asipto  and will be taught by Daniel-Constantin Mierla, co-founder and core developer of Kamailio SIP Server project.Read more details about the class and registration process at:

• http://www.asipto.com/sw/kamailio-advanced-training/

This week we saw the addition of FreeSWITCH initiating late offer calls. This week the FreeSWITCH developer team is meeting to discuss improvements and future features for FreeSWITCH. You can support this effort by donating to help keep them fed while they work. Donations can be made here: FreeSWITCH Developer Summit

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun!  And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-6833 [mod_sofia] Allow Freeswitch to initiate late offer calls

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

• FS-8778 [mod_verto] Define __bswap_64 for FreeBSD as well
• FS-8779 [mod_shout] Properly detect lame/lame.h for FreeBSD
• FS-8808 [mod_avmd] Code refactor to fix indentation and conditional loops.

The following bugs were squashed:

• FS-8768 [mod_callcenter] Releasing database handle after reserving agent
• FS-8802 [core] Fixed an issue caused by the sent timestamp of RTP rolling over to 0 and hitting an error condition causing it to stop sending audio
• FS-8726 [core] Fixed a spurious case of a thread stuck and saturating CPU
• FS-8789 [mod_conference][mod_av] Fix warning thats printed when it shouldn’t be and remove ability to swap to personal canvas while recording and prevent recording while personal canvas is on.
• FS-8805 [verto] Added a sanity check on array

The registration for the 4th edition of Kamailio World Conference & Exhibition is now open – more details and the registration form are available on the website of the event [1].
The event spans over three days, May 18-20, 2016, taking place in Berlin, Germany. The first day contains the technical tutorials, the following two days are for conference presentations and exhibition.The Call for Speakers is still in progress, however, a short list with a relevant group of speakers was made available [2]. The first version of the agenda will be published in the near future, for now you ca see the structure of the event.Looking forward to meeting many of you in Berlin!

• [1] – https://www.kamailioworld.com/k04/registration/
• [2] – https://www.kamailioworld.com/k04/speakers/

Back in October 2013,  the relative early days of WebRTC, I set out to get a better understanding of the getUserMedia API and camera constraints in one of my first and most popular posts. I discovered that working with getUserMedia constraints was not all that straight forward. A year later I gave an update after the […]

The post getUserMedia resolutions III – constraints unleashed appeared first on webrtcHacks.

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.

The development (master) branch of Kamailio enters now in pre-release phase for version 4.4.0. Therefore, no new feature are going to be pushed to master until a dedicated branch for 4.4 is created (in about 4 weeks or so). The full release should be out by mid of March 2016.If you are a registered developer and in doubt to push or not a commit to master, push it first on a personal branch (or attach to an email) and discuss it on sr-dev. The new modules can be a bit more dynamic if there is need to get them to the right shape (e.g., like decision to rename functions, parameters or adjust database structure).We hope to get many people involved in testing, to reach a stable state before releasing 4.4.0. If you want to get involved and need assistance, don’t hesitate to write to mailing lists. Based on my quick review, there were no major changes to old core components, meaning we should have preserved quite a good level of stability overall.Help with updating the wiki page for migration from 4.3 to 4.4 as well as what is new in 4.4 is very appreciated. We will post updates about them very soon.Many thanks to everyone involved in development of 4.4 and the early testers that played with master branch so far.Thank you for flying Kamailio!Looking forward to meeting many of you at Kamailio World 2016!

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.

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.