Hookflash CEO – Trent Johnsen on stage at WebRTC meetup in Boston recently.
Hookflash CEO – Trent Johnsen on stage at WebRTC meetup in Boston recently.
Early purveyors of VoIP (Voice over IP) promised great things and many have built respectable businesses. Still, we hang onto the networks of old (PSTN) which come with baggage and metered minutes remain.
We are in a “mobile first” world now, where mobile messenger applications reign supreme eg. WhatsApp, WeChat, Facebook Messenger, Snapchat etc. For good or for bad, these new chat apps are forever changing the way we think of communications. The next generation expects a certain level of service that comes for free, and that will become the new norm.
This new “free mobile communication” mantra can come at a price for providers.
Traditional VoIP networks are primarily built using client-server methodologies, which means the calls (signalling at least) and text messages pass through a server. That server must be hosted somewhere and that data transfer cost must be accounted for, somehow. More and more chat apps are supporting Voice and Video calls, the overhead involved in providing for those features on the back end is not trivial.
If there were a way to provide these features without having the calls and messages go through a server, it should be much cheaper (or free) to deliver those features to the users. P2P (peer to peer) communication services allow providers to cut costs and deliver rich communication features more affordably. We know this to be true because we have built countless VoIP networks on traditional client-server technology and also with P2P technology, in this case Open Peer.
Keep in mind a P2P-centric network does not take into consideration interoperability with the PSTN (Public Switched Telephone Network), so that I can call my mom and dad for instance. From a smartphone users perspective, this is not much of a problem. Data / wifi networks are nearly boundless. Just ask yourself “When was the last time you weren’t connected?” As a provider, the moment we bridge P2P with PSTN, we increase our costs enormously and lose all the rich features in the process.
Is there a way we get the benefits of P2P and still interoperate with the networks of yesterday?
If you want the real benefits that a Peer-to-Peer communications network will provide, you must get past the idea of interop with the PSTN. There are plenty of providers out there who refuse or simply cannot make the move to P2P due to their business model or the like and to you I say, “Very sorry for your troubles”.
The middle ground.
Leveraging P2P in your network where it makes sense (mobile) and using gateways to negotiate to the PSTN is certainly possible and we have helped network providers do just that. This helps them to prepare for an OTT (Over The Top) model that is more P2P centric and efficient while still servicing their customer of old.
When will metered minutes truly become a thing of the past? When the carriers wake up? God help us all.
If you are a modern mobile developer working on iOS or Android, you can say “goodbye” to metered minutes today.
This is hands down our favorite event of the year. IIT has produced a great “no bs” technical event. If you want to know what is happening inside the industry, you will want to attend this one. Excerpt from their website..
The IIT RTC Conference and Expo is a globally recognized collaborative event, where industry and academia connect. Leveraging its unique academic setting, this annual conference brings together technical professionals and business executives from the data and telecommunications industry, standards bodies, policy and regulatory institutions, and academic educators and researchers to promote an open exchange of ideas to lead future development in the rapidly changing field of real-time communications.
Robin Raymond will be speaking on a few topics:
IIT RTC Conference Schedule: http://www.rtc-conference.com/conference-schedule-listings/
We have run preliminary tests between the iOS app in the iTunes App Store and Android app in the Play Store. Messaging & voice works well, video on iOS has been there for some time now. As you can see from the screenshot video still needs a bit of tweaking on android, as so it has been temporarily disabled in the reference app.
We are looking forward to working with mobile developers on Android now in addition to iOS. Never has it been so easy to create a scalable mobile messenger with RTC (Real-time Communications) features that other messenger platforms would die for! So come and create something cool! Developers, join up and get started for free today!
Not a developer? No problem, we provide a white label service as well. Send us a note with your project ideas.
Name one popular messenger app that has launched in last 2 years that does not ask you for your mobile phone number when signing up. You will be hard pressed to do so. Ok, I might be exaggerating a wee bit but I think you get the point.
If we think about this for a minute it starts to sound a bit odd. New messaging apps mandate that you have a mobile number where you can receive a SMS message so you can join their OTT (Over The Top) community? That’s a bit weird isn’t it? Why not ask them to sign in with identities not tied to a cell phone? Email is certainly more prolific than connected cell phones, right?
So, why is this?
Onboarding is the process used to describe bringing a new user from the discovery process to an active user inside the app/service.
Our smartphone OSs (android, iOS) have made it very easy for devs to take the user’s mobile number and entire address book and upload that to their cloud, which most apps do today. Once in the cloud that data can be used to connect you with others that have done the same thing. Depending on your level of paranoia this can get a bit creepy or you have simply accepted it as the new normal.
To replicate the simplicity of this onboarding process in other forms is not so easy and not near as effective, it would seem.
Other developers defer to the largest social networks as a method for authenticating users, we have done this for our reference apps. Although, there have been plenty of reasons why users may not be interested in signing into your app using their social identity; privacy issues, hijacked accounts to name a couple. Also, why would you as a developer hand over your entire user base to a social network?
Virality is how easily the app spreads through the network. If the virality of your app hits a point where users are simply adding the app to keep up with their buddies, network effect kicks in, but that generally does not happen for the majority of the apps produced.
SMS messages have a much higher open rate than email and other forms of messaging, for various reasons, which makes SMS a great way to send app invites. It’s also dead easy for the app vendor to enable. If you are on a mobile phone, the dev need not come up with a 3rd party system to send invites, they just use your phone’s own capabilities to send the invites. Less expense for them, open rates increase due to the fact that it looks like its coming from you.
Social messaging has abysmal open rates. Much of the time Social Messages relies on notifications and push messages that are usually ignored or turned off by the user, current company included.
So what options do devs have when creating a messenger app or messenger feature in a app (text messaging, real-time voice or video) where we do not want to rely on phone companies for that initial base of users?
Why not a combination of all the above?
The future lies within federated identity models that allow your users to sign in with whatever ID they prefer and communicate without being pigeon holed into handing over their phone number if they do not feel comfortable doing so.
Developers have their reasons for choosing one ID model versus another, some reasons I have captured in this article. Thankfully, there is no reason to force users into making choices they are not comfortable making. Supporting multiple IDs in a federated model that will allow your LinkedIn authenticated user to communicate with the Phone number authenticated users, exists today.
Imagine a world where devs can tie custom IDs (your own 3rd party ID model) to social and traditional IDs like phone numbers to electrify a mobile communications paradise. A world where we need not hand the keys of the entire user base over to a social network.
Yep, its real, if you want more information, send us a note we’ll be happy to fill you in.
PS. If you feel compelled to weigh in on Net Neutrality and safeguarding the Open Internet, its not too late. Do so here: Email Chairman Tom Wheeler at the FCC, some of the recent comments of the more than 650,000 comments already received.
The ORTC API (http://ortc.org) was conceptualized by Robin Raymond – Chief Architect, Hookflash Inc. It’s no secret that we have been opposed to SDP in the WebRTC 1.0 spec, but instead of derailing progress there we decided to create a W3C Community Group where we could apply our passion. We are getting closer on a Public Draft of that API and when I look at the progress we have made since forming the Community Group a mere 9 months ago, I am satisfied we are moving at a good pace. Our list of participants continues to grow and its great to see ORTC on the list of considered technologies in the Internet Explorer group at Microsoft!
We are hopeful that we make some material progress at this next meeting, I know we are all itching to get this API implementable so we can build ORTC into some cool apps.
The next ORTC Community Group Meeting is scheduled for April 17, 2014 at 10am Pacific. Agenda and meeting details to follow.
Vancouver BC, Canada (PRWEB) November 01, 2013
Hookflash joins over 20 technology companies and thought leaders from around the globe this Sunday, November 3, 2013, to review “ORTC” the new Object RTC API (Object Real-Time Communications Application Programming Interface). Hookflash Chief Architect Robin Raymond will provide an introduction and overview of the new ORTC API, as well as demos and sample application reviews. This event will be streamed live: http://www.ustream.tv/channel/ortc-live.
Hookflash Co-founder, Erik Lagerway explains “Microsoft has expressed concerns regarding the current WebRTC specification. If the current WebRTC specification isn’t included in Internet Explorer, it creates a massive gap in the Enterprise and global marketplace. Hookflash is providing both ORTC, WebRTC and mobile compatibility in Hookflash toolkits to deliver Voice, Video and Messaging without plugins to Internet Explorer (assuming integration of ORTC), Google Chrome, Mozilla Firefox, iOS and android. This makes Hookflash the first company to fill that gap for Enterprise, developers and consumers. But it doesn’t end there,” says Lagerway, “The optimal solution for web developers and customers will be to have all the browser vendors integrate support for ORTC directly. Since ORTC supports both Object and SDP Offer/Answer models, everyone wins.”
Hookflash will be making another announcement on Sunday during the ORTC Walkthroughhttp://blog.webrtc.is/2013/10/28/ortc-walk-through-ietf-88/, regarding the availability of source code for ORTC/WebRTC implementations. This event will be streamed live: http://www.ustream.tv/channel/ortc-live.
Hookflash enables real-time social, mobile, and web communications with “Open Peer” for integration of voice, video, messaging with federated identity into world leading software, enterprise, applications, networks, mobile and computing devices. Hookflash and Open Peer are trademarks of Hookflash Inc.
Developers can register at (http://fly.hookflash.me) to start using the Open Peer SDKs today.
For more information and an Open Peer/WebRTC White Paper please visit Hookflash http://hookflash.com.
Press Contact: Trent Johnsen
855-HOOKFLASH (466-5352) ext 1
A 3-hour, executive format meeting where up to 100 telecom experts discuss how Over The Top, OTT, content and services are changing the ecosystem and creating opportunities.
The rise of OTT content and services has been a bittersweet affair for network operators. On the one hand, OTT content is what has driven the demand for mobile data subscriptions which have provided the only growing data source in an era of dropping voice revenues. OTOH, OTT content soaks up most of the networks capacity, and increases CapEx and OpEx for carriers.
Making matters worse, network operators are being cut out of “owning” the customer relationship, being the provider of new services, and building churn-reducing loyalty. Resistance is mostly futile, so entrenched players need to select, partner, and compete. Companies are looking for areas they can be a top player, and compete to win a portion of the OTT business. Partnerships are key to this strategy, so in today’s meeting, we will examine strategies such as that of Telefónica Digital, look at a variety of potential operator partners like Cloudscaling, and look at carrier-consortium efforts such as Joyn. We’re going to examine this from both a mobile and fixed perspective.
No matter what camp you are in, pro-SDP or Object API, WebRTC feels like it’s here to stay. The fact that there is so much push-back on an Object-centric API in the WebRTC working groups tells us that there are many who are concerned about delaying v1 any longer than is necessary, there is a feeling of urgency, which seems like a good thing.
WebRTC is in its early infancy, building a commercial service using WebRTC in the browser today is not only unlikely it might even be a little silly. That’s not to say that the work being done in and around WebRTC today isn’t valid, far from it. It’s just that WebRTC “in browsers” is far from being ready for any service to deploy commercially and scale.
Where are we most likely to see traction early on?
What WebRTC, or specifically Google, has given us is a great media stack that we can leverage in apps.
Mobile is where WebRTC can be put to work easily and quickly. Any iOS, android or even BB10 application developer can now make use of new mobile developer toolkits that include the WebRTC media stack plus other features like social identity federation, p2p signaling and the like. Mobile is where WebRTC technology shines today.
Building for mobile first is not just convenient it’s smart. By building on mobile ahead of the browsers the developer somewhat “future proofs” the life cycle of the product being developed. When WebRTC is ready for prime time, those mobile developers will be in a perfect position to deploy to the browser, potentially edging out their competition.
When will the browsers be ready?
It’s going to be the better part of a year (some say years) before some of the hard problems are solved in the respective WebRTC working groups and even then the v1 features supported will be somewhat minimal. Even I thought this would have been done by now, but we are a long way from done.
Questions remain unanswered: Where is Apple? What will Microsoft do with CU-RTC-Web? What video codec will be chosen as MTI?
Regardless of how much work there is left to do, the bureaucracy and politics inherent in the standards bodies will ensure that we will not see this in production across all major browsers anytime soon.
As an example, let’s take a look at XMPP. Before it became a standard XMPP was the Jabber protocol, an open technology used primarily for instant messaging and presence. Since Jabber was already defined and deployed heavily all across the globe you would think the standardization would go rather quickly, right? Nope. That process took more than 2 years in the IETF and very little was changed.
If you are a mobile developer looking to leverage WebRTC for a mobile project, you’re in luck! There are some good mobile SDKs available today. You might want to hold off on deployment plans for all the major browsers anytime soon, especially not if you are focusing your efforts in the Enterprise markets where MS Windows and Internet Explorer still rule the roost.