Founder and CEO Mikhail Rodionov discusses all the projects and code contributions that they have built for Kazoo over the past year.
The Voxter team discuss code contributions to the Kazoo platform, discuss how they are utilizing the platform, and give an in-depth demo of WhApps.
Telnexus CEO Vernon Keenan discuss how he built the Managed Service Provider Telnexus from the ground up and the lessons he has learned in the process.
In a competitive market, high quality voice services alone are rarely enough. Lon Baker speaks about the customer lifecycle, back office systems from Sales to CRM to deployment, and how to drive profitable growth while delivering an excellent customer experience.
Product Director Aaron Gunn discusses billing options for SaaS and IaaS customers. This includes CDR API, AMPQ, and integrating VoIP billing platforms.
People love to talk about scale. Some vendors pitch that their systems easily support 100,000 simultaneous calls, or 500 calls per second, etc. The reality is, in the real world, people’s behaviors vary and the feature sets they use can cut these numbers down quickly. For example, ask that same vendor claiming 100,000 simultaneous calls if it can be done while call recording, call statistics and other features are turned on at the same time, and you’ll usually get a very different, cautious, qualified response.
In this presentation, we’ll show you how to set up your infrastructure to support 100,000 simultaneous calls.
This is an overview of VoIP fraud, different types of fraud and what telecommunication carriers are doing to combat this issue. Types of fraud include International / Premium Number Fraud, Impersonation / Social Engineering, Service Degradation / Denial of service. Presented by Mark Magnusson at KazooCon 2015.
CTO Karl Anderson discusses the state of Kazoo. This includes integrations with FreeSWITCH, erlang, and Kamailio. Reseller milestones include the release of whitelabeling, webhooks, migration, carriers, debugging, account management and more.
A clash of worlds.
With the gazillions of devices said to be part of the IOT world, how they interact and speak to each other is going to be important. When we talk about the Internet of Things, there are generally 3 network architectures that are available:
The star topology means that each device gets connected to the data center – the cloud service. This is how most of our interent works today anyway – when you came to this website here, you got connected to my server and its hosting company to read this post. When you chat on Facebook, your messages goes through Facebook’s data centers. When your heat sensor has something to say… it will probably tell it to its server in the cloud.
ProsP2P means devices communication directly with each other. No need for mediation. The garage sensor needs to open the lights in the house and start the heating? Sure thing – it just tells them to do so. No need to go through the cloud.
ProsAs with all technology, there are middle ground alternatives. In this case, a hubs and spokes model. In most connected home initiatives today, here’s a hub device that sits somewhere in the house. For example, Samsung’s SmartThings revolves around a Hub, where all devices connect to it locally. While I am sure this hub connects to the cloud, it could send less or more data to the cloud, based on whatever Samsung decided to do with it. It serves as a gateway to the home devices that reduces the load from the cloud service and makes it easier to develop and communicate locally across home devices.
ProsIn the recent Kranky Geek event, Tim Panton, our magician, decided to show how WebRTC’s data channel can be used to couple devices using a duckling protocol. To keep things short, he showed how a device you just purchased can be hooked up to your phone and make that phone the only way to control and access the purchased device.
You can watch the video below – it is definitely interesting.
To me this means that:
Kranky and I are planning the next Kranky Geek - Q1 2016. Interested in speaking? Just ping me through my contact page.
The post IOT Messaging – Should we Head for the Cloud or P2P? appeared first on BlogGeek.me.
The FreeSWITCH team added some neat new features this week including: expanded support for limit_* functionality in mod_hiredis and the addition of the field conferenceMemberID to the event broadcasted to inform a verto client about joining a conference.
Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support.
New features that were added:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
The FreeSWITCH 1.4 branch had a few bug fixes added this week.
The following bugs were squashed:
Learn to run faster.
WebRTC isn’t yet standardized. It is on the way there. That said, there are already more than 800 different vendors and services out there that are making use of it – many in production, with commercial services.
There are main 3 approaches to a WebRTC-based service:
That third alternative is the most challenging. The reason for the challenge isn’t a technical one, but rather one of mind set.
Fippo, who knows about the WebRCT testing service I am a part of, sends me every once in awhile issues he bumps into. This one that he shared with me recently from the webrtc-discuss group was an eye opener: someone running a native C++ app got WebRTC compiled and linked to his own app, and assuming it will work with browsers. And it did. Up until recently:
Chrome 46 started sending UDP/TLS/RTP/SAVPF in the profile field of the m-line as has been announced a while back in https://groups.google.com/forum/#!topic/discuss-webrtc/ZOjSMolpP40
Your library version has to be pretty old to be affected by this (parsing this should have been supported since mid-2014).
Here are some thoughts about this one:
It means that mobile apps must run at the speed of the browser – whenever a new browser version gets released, you must be sure it works with your own version of WebRTC in your app. You should probably get your version updated at the same speed (that’s every 6 weeks or even less, once we’ll have 3 full browsers supporting it properly).
What are you to do if that’s your use case? Here are some suggestions:
#1 – DIY only if you can commitDon’t put someone in your team to port WebRTC on your own.
If you do, then make sure you know this isn’t a one-time effort. You’ll need to make investments in upgrading the ported library quite frequently.
To be on the safe side, I’d suggest putting the ongoing investment (not the initial porting) at around 50% of a developer’s capacity.
Also remember you have two platforms to deal with – Android and iOS.
Can’t commit to the ongoing maintenance effort? This alternative isn’t for you.
#2 – Outsource to an independent developer with careIf you decide to use someone externally, who would take the WebRTC library, port it for you, assist you in integrating and optimizing it to your needs – make sure he will be there for the long run.
Same as you’ll need to invest internally to maintain this code, you’ll need to be able to call upon that person in the future.
Things to consider:
The other alternative? Use an official product that gets you WebRTC as an SDK to mobile. Frozen Mountain’s IceLink comes to mind as a good solution.
You essentially outsource the headache of maintaining WebRTC’s interoperability with browsers to someone who does that for a living in a product package.
Make sure in the agreement with such vendors that you get regular updates and upgrades – and that these are guaranteed to work with the latest versions of the browsers (and even with the available beta versions of the browsers).
Check how regularly the vendor releases a new SDK and which ones are mandatory to upgrade to due to browser interoperability issues. Plan accordingly on your end.
#4 – Go for a WebRTC API PlatformHave your worries of this whole mess outsourced to someone else. Not only the mobile SDK part, but the whole real time comms platform.
You need to pick a vendor out of a very large set of potential vendors, which is why I’ve written and updated my own report on WebRTC APIs over the years.
Make sure to take a look at how well the vendor you select works with mobile and is committed to upgrading his own support for it.
It ain’t easyGetting WebRTC to work well for the long run on mobile and web at the same time isn’t easy. It requires commitment as opposed to a one time effort. Be prepared, and make sure you take the approach that fits you best.
At least until WebRTC stabilizes (no reason for this to happen in the coming year), you’ll need to keep running at the speed of the browsers.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post WebRTC Mobile to Web? Make Sure You Think at Web Speeds appeared first on BlogGeek.me.
Here’s what to expect during November.
Just wanted to share two things during this weekend.
WebRTC Summit, testing and San FranciscoI am traveling on the first week of November to San Francisco. The idea is to talk about WebRTC testing (and testRTC) at the WebRTC Summit.
I’ll be touching the challenges of testing WebRTC, which is somethings that isn’t discussed a lot out there:
I think there needs to be more focus in that area, and not just because I co-founded a WebRTC testing company.
I plan on being at the WebRTC Summit in Santa Clara on November 3-4. Here’s more about my session if you need. I am already filling up my days around that summit with meetings in both Santa Clara and San Francisco – if you wish to meet – contact me and I’ll see if I can still squeeze you in to my agenda.
Virtual Coffee with TsahiThe first Virtual Coffee event took place a bit over a week ago. The recording of that session still isn’t available, but will be in a week or two.
It went well and I truly enjoyed the experience – the ability to handpick the people who can participate, get them signed in through my membership area on this website, and do it all under my own brand – it was great.
I’d like to thank (again) Drum’s team with their Share Anywhere service. It is as close to what I needed as could be – and easily customizable. Their team is great to work with as well (and no – they haven’t paid for me to say this).
The next sessionWhen? November 11, 13:30 EDT
Where? Online, of course
Agenda:
Who?
I noticed recently people contacting me and asking me not to share their stories on this blog.
To make it clear – there are three reasons for me to share stories here:
I put the bread on the table mainly through consulting. This means being able to assist vendors, and that requires doing things in confidence and without sharing strategies, roadmaps, status and intents with others. If you contact me through my site, my immediate assumption is that what you share is private unless you say otherwise.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post Upcoming: WebRTC Summit and my Next Virtual Coffee appeared first on BlogGeek.me.
Daniel Constantin Mierla discusses Kamailio and Kazoo integrations at KazooCon
Why reminisce in the future when we’ve got so much to do in the here and now.
This week Chad wrote a post titled What’s Next for WebRTC? It is a good post, so don’t get this one as a rant or a critique about Chad. It is just the moment I saw the title and some of the words on the accompanying visual (AR, VR, drones, Industrial, Computer Vision, 3D, Connected Cars) – I immediately knew there’s something that bugs me.
It wasn’t about the fact that WebRTC isn’t used for any of these things. It was due to two reasons:
The second one, of buzzword abuse, I can only say this: WebRTC may play a role in each and everyone of these buzzwords, but its place in these market will be minuscule compared to the market itself. For many use cases in these markets, it won’t be needed at all.
For the first one, I have decided to write this.
There are many challenges for those who wish to use WebRTC today. This is something I tried to address in the last Kranky Geek event – WebRTC is both easy and hard – depending on your pedigree.
VoIP developers will see it as the easiest way to implement VoIP. Web developers will find it hard – it is the hardest thing that you can add to a browser these days, with many moving parts.
Here’s the whole session if you are interested:
Here’s what I think we should strive for with WebRTC and even ask those who work to make it available for us as a technology:
#1 – Become TCPTCP works. We expect it to work. There are no interoperability issues with TCP. And if there are, they are limited to a minuscule number of people who need to deal with it. WebRTC isn’t like it today.
WebRTC requires a lot of care and attention. This fresh interview with Dan about the WebRTC standard shows that. You’ll find there words about versioning, deprecation, spec changes, etc. – and the problem is they affect us all.
This brings us to this minor nagging issue – if you want to use and practice WebRTC, you need to be on top of your game and have your hand on the WebRTC pulse at all times – it isn’t going to be a one-off project where you invest in developing a web app or an app and then monetize and bask in the sun for years.
The other alternative is to use a WebRTC API vendor, who needs to take care of all that on his own. This can’t be easily achieved by those who need an on premise deployment or more control over the data. This alternative also speaks louder to developers than it does to IT managers in enterprises, leaving out part of the industry of potential adopters of WebRTC.
The faster WebRTC becomes like TCP the better.
#2 – More success stories of a variety of simple use casesThere are a lot of areas where I see vendors using WebRTC. Healthcare, learning, marketplaces, contact centers, etc.
In many cases, these are startups trying to create a new market or change how the market works today. While great, it isn’t enough. What we really need is stories of enterprises who took the plunge – like the story told by AMEX last year. We also need to see these startups grow and become profitable companies – or larger vendors who acquire technology (I am talking to you Slack, Atlassian and Blackboard) use them in their products.
These stories that I am interested in? They should be able the business side of things – how using WebRTC transformed the business, improved it, got adopted by the end customers.
Where are we?With all the impressive numbers of WebRTC flying around, we still are in the early adopters phase.
We are also still struggling with the basics.
There are many great areas to explore with WebRTC – the large scale streaming space is extremely interesting to me. So is the potential of where WebRTC fits in IOT – which is even further out than the large scale streaming one. I love to be a part of these projects and those that seek them are at the forefront of this technology.
We’re not there yet.
But we will be.
There’s no stopping this train any time soon.
Test and Monitor your WebRTC Service like a pro - check out how testRTC can improve your service' stability and performance.
The post The What’s Next for WebRTC Can Wait Until We Deal With What’s Now appeared first on BlogGeek.me.
If you are new to WebRTC then you have missed out on years of drama in the standards bodies over various issues like SDP and codecs. These standards dictate what vendors must implement so they ultimately dictate the industry roadmap. To get a deep perspective and appreciation of the issues, we like to ask Dan Burnett, W3C editor to comment on where we are at with the standardization process. I caught up with Dan at this year’s IIT Real Time Communications Conference and had the more detailed Q&A with him shortly thereafter.
We asked Dan to comment on recent spec changes, ORTC, the next version of WebRTC, codecs, Apple, when the 1.0 spec might ever be finalized, and a whole lot more.
{“editor”, “chad hart“}
New GovernancewebrtcHacks: Hi Dan. Can you describe some of the recent changes to the W3C WebRTC governance?
Dan: Yes. There was a long-running but productive discussion among the members of the WebRTC Working Group (WG), ORTC Community Group (CG), and the some of the members of the W3C advisory committee – which is the group that officially determines group charters.
As part of the Charter renewal process, we decided that there would be one additional Chair of the WebRTC Working Group – Eric Lagerway of Hookflash who was one of the initiators of ORTC. Also the decision was that the WebRTC WG is the official group where all future standardization work in WebRTC will happen, meaning the ORTC work will gradually fold into that group.
Additionally, the group was chartered to work on another version beyond 1.0 – WebRTC Next Version or WebRTC-NV.
There are 2 requirements on that version:
One other thing has happened that is not official, but is probably good is that Bernard Aboba from Microsoft has joined the WebRTC 1.0 editing team.
The Next VersionwebrtcHacks: yeah, Bernard mentioned that in the interview I did with him last week. Can you explain WebRTC NV? Why didn’t you just call it 2.0, or 1.1, or whatever?
Dan: I have been working on standards for a long time. I have seen groups spend ridiculous amounts of time deciding on a name for a specification. In this particular case a “1.1” sounds like a minor change from “1.0” while “2.0” sounds like a major change. Some people want a minor change. Some people want a major change. If enough people want different minor changes it will end up being a 2.0 anyway because of the number of changes. The goal was to avoid that disagreement now so that we can move forward,.
webrtcHacks: So what is WebRTC NV then, beyond what you stated earlier about no SDP?
Dan: Nothing is officially decided but I expect that there will continue to be more low-level controls as in ORTC. This is complicated by the fact that new feature proposals are continuing to come in for 1.0. Many of these features are from ORTC.
In the Sapporo meeting coming up, Google will be sharing their idea for what should go into WebRTC-NV when we finally start working on it.
webrtcHacks: How do you see ORTC influencing the WebRTC spec? Is WebRTC-NV really just ORTC?
Dan: If it had to summarize WebRTC-NV I would say that it is the combination of WebRTC 1.0 and ORTC. It is a requirement that 1.0 applications continue to work in WebRTC-NV implementations. It is not required that ORTC applications work directly in WebRTC-NV.
I believe the ORTC community intends to modify ORTC as necessary to remain consistent with WebRTC as it evolves.
webrtcHacks: Is there an end-date to ORTC-then? When it is mostly merged with WebRTC-NV will it cease to exist?
Dan: I can’t speak for the ORTC group. I have not heard of an end date. You’ll have to ask one of the primary ORTC contributors.
Spec ChangeswebrtcHacks: What are some of changes made to the specs recently. Particularly those that impact the developers out there?
Dan: First I would like to give a little plug for my webrtcstandards.info site where I have been putting exactly that sort of information over the past few months. I will mention some things here, but you can get more details on that site.
webrtcHacks: ok, we’ll give you one plug (laughs)
Dan: One of the biggest and most relevant changes on what we were just talking about is the introduction of the RTCsenders and RTCreceivers. These are objects that allow for both information and more direct control over how tracks are sent over a PeerConnection. Notice as part of this that we have moved from a stream based API to a track based API.
webrtcHacks: And what advantage does the track approach provide?
Dan: It turns out developers want to have more control over exactly how tracks are sent and received. For example being able to specify which codecs are to be used and the parameters used to configure those codecs. They should be able to configure some transport properties as well on a per track basis such as FEC, retransmission, and bandwidth. Because of this it really didn’t make sense to talk about streams as the primary primitive being sent over a PeerConnection since they are really just a collection of tracks.
webrtcHacks: So the others?
Dan: First, on the one we just mentioned – that was a foundational change where we are going to be seeing many other changes later on. Now I’ll talk about the others that are not related to that.
One big change was the API’s have been converted to use ECMAScript Promises. I think I mentioned this last year.
webrtchacks: You did.
Dan: It has happened. It is now in the specifications.
Promises are now the recommended mechanism for WebRTC specifications and for web specifications in general for dealing with asynchronous function calls. Not so much for things that generate multiple events, but definitely for any single asynchronous function call.
This is part of the move of ECMAscript toward truly asynchronous function calls as you can see if you look at some of the thoughts or future versions of ECMAscript.
The original callback based API’s currently still exist but will eventually be deprecated. Developers should start using the Promise versions.
webrtcHacks: I know media capture from the DOM is another one.
Dan: There has been good progress on capturing media directly from media elements such as audio, video and canvas. Developers have had to use hacks up to this point to be able to capture a canvas for example. Maybe they would take snapshots, but that is not the same as a realtime media stream as you would get from a getUserMedia call.
The major changes going into the specification soon are to try to reproduce the resulting media stream as faithfully as possible to what a user would experience from that element. For example, if the user is playing a video and pauses it and then resumes, the resulting stream should show the paused video for the amount of time it was paused and then resume again.
This seems to be what developers are most interested in.
webrtcHacks: can you talk about some of the use cases that are being referenced around this feature?
Dan: Shared whiteboard is probably the best example, but there maybe some instances for training purposes where you want to capture how the user has interacted with existing elements – video or audio.
webrtcHacks: What about screensharing?
Dan: There is good progress happening there as well on the specification. It still has some tricky issues in terms of what apps should be able to request to be shared and what users should have control over. An example of this is Microsoft Powerpoint – if a user has 3 powerpoint documents up – say different presentations for different clients; they are likely to only want to share one one of those presentations – one window of that application. That works great until they go into presentation mode, which is far as the computer is concerned is a different window. So is this a case where the user should decide or is this a case where the application should decide what is shared?
In general the WG believes that the user should have the control, but browsers may have to make special cases for known applications such as Powerpoint so that it just works.
webrtcHacks: How about simulcast?
Dan: At the Seattle meeting there were some strong opinions on how simulcast should work and some proposals. Each time we get to the details the discussions diverge rather than converge. We all want it but we do not agree on how it should be signaled.
TimelineswebrtcHacks: Now for an easier one. When will 1.0 be done?
(laughs)
Dan: I am tempted to give a similar answer as last year.
There are 2 primary specifications. The media capture specification is right now finishing up addressing the comments from its Last Call review which is the wide range review that is required in order to go forward. There aren’t any new features being requested by group members – it’s just cleaning up and fixing.
It probably will be stable within another 6 months.
webrtcHacks: Stable meaning not changing any more?
Dan: Yes – meaning no contentful changes. Only editorial fixes.
Now the WebRTC specification has the problem that new features keep coming in.
werbrtcHacks: Just to clarify – the Media Capture group is the getUserMedia API and when you WebRTC, that means the RTCPeerConnection and DataChannel related API’s?
Dan: Yes.
These are features that have come from ORTC. At each meeting we have tried to finalize the list, but new proposals continue to creep in. Within 6 months we will know whether the chairs have been able to hold the line on the most recent list agreed to in Seattle.
webrtcHacks: So is this why it is taking so long?
Dan: Yes.. The good news about it is that the features that are going in are the most requested ones from ORTC.
IP LeakagewebrtcHacks: The IP leakage issue was a hot topic on webrtcHacks and elsewhere? Many have labeled it as a flaw; other say this behaviour was by design? Can you share the “standards” perspective on this topic and the considerations that were discussed?
Dan: The summary is this – there are 2 problems with IP leakage:
One kind is the leakage of public addresses that the user doesn’t want leaked. This can happen when a user is using a VPN and not all of the traffic is sent over the VPN – a so called split tunnel VPN. This is an issue if the user doesn’t want their non-VPN public address to be revealed. This is not a WebRTC problem; this is a split tunnel VPN problem. That doesn’t mean that people don’t blame the browser vendors even though it’s not their fault (laughs}
Technically any application running on your machine could do the same thing if you’re running a split tunnel VPN. There are extensions to turn off WebRTC for people who are very concerned about this.
The other kind of leakage is leakage of your local IP address. the reason this concerns some people is that it can be used to map the topology of your local network, say within an enterprise. However it turns out that applications can use an XmlHttpRequest to do the same thing. Despite that, the browser vendors are working on ways to turn off the reporting of these local addresses.
There will be more details coming up in an upcoming post on my site.
What’s Apple Doing?webrtcHacks: Now the only major browser vendor left is Apple. Can you comment on public participation by Apple?
Dan: It is clear that people from Apple are continue to follow the work, but they still don’t contribute.
webrtcHacks: Do you know if they contribute to other WG more actively.
Dan: Yes, Apple does contribute more actively in other WG within W3C.
CodecswebrtcHacks: Anything new with video codecs now that the market has had some time to react to the decision to include both VP8 & H.264 for browsers? How is the VP9 vs. H.265 and Alliance for Open Media (AOM) discussion changed the discussion?
Dan: The gauntlet has been thrown for the creation of free and open source video codecs. MPEG-LA needs to take notice that the media producers and distributors are serious about coming up with lower cost alternatives. This pressure just continually increases. The AOM is a prime example of that.
webrtcHacks: Has the Alliance for Open Media come up in standards discussion? In the past I know there was discussion of just allowing software codecs that could defined on the fly.
Dan: Codecs still need to be created. The discussions of VP8 vs H.265 and VP9 vs. H.265 are not really technical discussions. They are all about intellectual property because of the cost of licensing the codecs. The issue is not being able to select a codec – the issue is having a codec that you want to choose.
One API change that is just gone in is being able to choose which codec of the browser supported ones to use.
MicrosoftwebrtcHacks: Anything else to add?
Dan: I think we’re finally on a good track in respect to a path forward for ORTC and WebRTC and thus the inclusion of Microsoft as a true and complete WebRTC vendor eventually. We just need the feature inflow from ORTC to stop right now to be able to declare victory and move on.
I think this is evidence that the industry really does want this to happen.
I spoke with a number of people who talk to HTML developer groups and they all agree that even today no more than 50% of the developers have heard of WebRTC – still! It is likely that one reason for that is for many developers a technology isn’t real until it is in Internet Explorer or its successor – Edge.
So having Microsoft fully engaged on a plan that we can all agree on now is a good thing for everyone.
{
“Q&A”:{
“interviewer”:“chad hart“,
“interviewee”:“Dan Burnett“
}
}
Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart, @victorpascual and @tsahil.
The post Are we There Yet? WebRTC standards Q&A with Dan Burnett appeared first on webrtcHacks.
A lot more than pure messaging.
Messaging used to be about presence and IM. Then the VoIP people came and placed the voice and video chat stickers on it. That then became unified communications. Which is all nice and well, but it is both boring and useless at this point. Useless not because the utility of the service isn’t there, but because the expectation of such a service is to be free – or close to that. Or as I like saying, it has now become a feature within another service more than a service in its own right.
While this is killing unified communications, it doesn’t seem to be making much of a dent on messaging just yet. And the reason I think is the two very different trajectories these are taking:
This migration of messaging towards becoming platforms isn’t so easy to explain. There’s no silver bullet of how this is done. No secret recipe that gets you there.
Here are a few strategies that different messaging platforms are employing in their attempt to gain future growth.
Whatsapp and SimplicityWhatsapp is all about simplicity. It offers pure messaging that replaces the SMS for many, coupled with group messaging that makes it sticky and viral in many countries.
Features don’t make it into Whatsapp fast. The only thing that was added in the past two years of any notable value is voice calling.
With this approach, Whatsapp still is the largest player in town when it comes to messaging; and it is probably doing so with the smallest possible team size.
The problem with such an approach, is that there isn’t enough room for many such players – and soon, to be a viable player in this domain will require a billion monthly active users.
Apple and iMessageIn that same token, the Apple iMessage is similar. It is simple, and it is impossible to miss or ignore if you have an iPhone.
But it is limited to Apple’s ecosystem which only runs on iOS devices.
Google Hangout (and now Jibe Mobile)Google Hangouts was supposed to do the same/similar on Android, but didn’t live up to the expectation:
With the acquisition of Jibe Mobile, this may change in the future. Will others follow suit? Is there enough utility and need in connecting messaging with Telco messaging, and especially with RCS, that many (myself included, at least until this acquisition) see as dead on arrival?
Facebook and Artificial IntelligenceFacebook is experimenting with artificial intelligence that is embedded into their Facebook Messenger service – not the social network where e-commerce is the current focus.
This new AI initiative is called Facebook M and is planned to be driven by part machine part humans.
In many ways, this is akin to the integration LivePerson (a chat widget for contact centers) has with knowledge bases that can cater to customer’s needs without “harassing” live agents in some cases. But this one is built into the messaging service the customer uses.
It is compared to Siri and Cortana, but you can also compare it to Google Now – once Facebook fleshes out the service, they can open up APIs for third parties to integrate to it, making it a platform for engaging with businesses.
WeChat and the Digital Life PlatformWeChat is large in Asia and dominant in many ways. It is an e-commerce platform and a digital life ecosystem.
Connie Chan of Andreessen Horowitz gives a good overview of what makes WeChat a platform:
Along with its basic communication features, WeChat users in China can access services to hail a taxi, order food delivery, buy movie tickets, play casual games, check in for a flight, send money to friends, access fitness tracker data, book a doctor appointment, get banking statements, pay the water bill, find geo-targeted coupons, recognize music, search for a book at the local library, meet strangers around you, follow celebrity news, read magazine articles, and even donate to charity … all in a single, integrated app.
WeChat transitioned from being a communication tool to becoming a platform. It has APIs that makes it easy for third parties to integrate with it and offer their own services on top of WeChat’s platform.
While I use the term “from service to feature” when talking about VoIP and WebRTC, Connie Chan uses “where social is just a feature” to explain the transition WeChat has made in this space.
The ability to send messages back and forth and communicate in real time via voice and video is now considered table stakes. It is also not expected to be a paid service but a feature that gets monetized elsewhere.
Meanwhile in Enterprise MessagingSlack, which Connie Chan also briefly notes in his account of WeChat, is the guiding light of enterprise messaging these days.
Unlike other players in this space, Slack has built itself around the premise of three strong characteristics:
The enterprise platform is all about utility.
Slack is introducing AI and has its own marketplace of third party apps via integrations. The more enterprises use it, the more effect these two capabilities will have in enforcing its growth and effectiveness.
While the fight seems to be these days between Unified Communications and Enterprise Messaging, I believe that fight is already behind us. The winner will be Enterprise Messaging – either because UC vendors will evolve into Enterprise Messaging (or acquire such vendors) or because they will lose ground fast to Enterprise Messaging vendors.
The real fight will be between modern Enterprise Messaging platforms such as Slack and consumer messaging platforms such as WeChat – enterprises will choose one over the other to manage and run their internal workforce.
Kranky and I are planning the next Kranky Geek - Q1 2016. Interested in speaking? Just ping me through my contact page.
The post The Future of Messaging is… appeared first on BlogGeek.me.
Hello, again. This past week in the FreeSWITCH master branch we had 25 commits. Our feature this week in the verto communicator is the addition of ngSanitize as a dependency, vertoFilters module and picturify filter, and a change to the chat image display behavior (break line before rendering).
Join this Wednesdays at 12:00 CT for some more FreeSWITCH fun with Daniel-Constantin Mierla! And head over to freeswitch.com to learn more about FreeSWITCH support.
New features that were added:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
And, this past week in the FreeSWITCH 1.4 branch we had 2 new commits merged in from master. And the FreeSWITCH 1.4.23 release is here! Go check it out!
The following bugs were squashed:
We have an immediate WebRTC development contract opportunity that has just come up in the Seattle area. The contract requires 4-5 full-time developers onsite, remote will not fit the bill on this one.
For this contract we are looking for a team lead, 2 x Node.js, 2 x common JS developers
You have built commercial web applications using WebRTC libraries and are intimately familiar with the WebRTC and ORTC specs and respective libraries.
Start date: ASAP
If you are interested please forward your resume elagerway@gmail.com
Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.
Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.
Wow, this most certainly is a great a theme.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.