I wonder. Can Apple maintain its lead without getting deep and dirty in analytics?
Apple decided to “take the higher ground”. It has pivoted this year focusing a lot around privacy. Not maintaining user keys for one, but also collecting little or no information from devices and doing as much as possible analytics on device. For now, it seems to be working.
But can it last?
Let’s head 5 or 10 years into the future.
Now lets look at Google and Facebook. Both have voracious appetite to data. Both are analytics driven to the extreme – they will analyze everything and anything possible to improve their service. Where improving it may mean increasing its stickiness, increasing ROI and ARPU, etc.
As time goes by, computing power increases, but also the technology and understanding we have at our disposal in sifting through and sorting out huge amounts of data. We call it Big Data and it is changing all the time. A year or two ago, most discussions on big data were around Hadoop and workloads. This year it was all about real time and Spark. There’s now a shift happening towards machine learning (as opposed to pure analytics), and from there, we will probably head towards artificial intelligence.
To get better at it, there are a few things that need to be in place as well as ingrained into a company’s culture:
These traits are already there for Google and Facebook. I am less certain regarding Apple.
Fast forward 5 to 10 years.
Where would that leave Apple?
If a smartphone (or whatever device we will have at that time) really becomes smart – would you pick out the shiny toy with the eye candy UI or the one that gets things done?
Can Apple stay long term with its stance towards data collection policies or will it have to end up collecting more data and analyzing it the way other companies do?
The post Can Apple’s On-Device Analytics Compete with Google and Facebook? appeared first on BlogGeek.me.
FreeSWITCH got some neat improvements this week with work going into improving the handling of vw and vh core file parameters in mod_av to avoid video cropping and crashing, the addition of a new configuration setting in mod_opus to show the decoder stats at the end of the call, and exposing SRTP and SRTCP crypto keys as channel variables to help with debugging.
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:
Someone should build a generic fallback…
If you don’t know Socket.io then here’s the gist of it:
It is also very popular – as a developer, it lets you assume a WebSocket like interface and develop on top of it; and it takes care of all the mess of answering the question “but what if my browser/proxy/whatever doesn’t support WebSocket?
I guess there are use cases where the WebRTC data channel is like that – you’d love to have the qualities it gives you, such as reduced server load and latency, but you can live without it if you must. It would be nice if we’d have a popular Socket.io-like interface to do just that – to attempt first to use WebRTC’s data channel, then fallback to either a TURN relay for it or to WebSocket (and degrading from there further along the line of older transport technologies).
The closest I’ve seen to it is what AirConsole is doing. They enable a smartphone to become the gamepad of a browser. You get a smartphone and your PC connected so that whatever you do in the phone can be used to control what’s on the PC. Such a thing requires low latency, especially for gaming purposes; and WebRTC probably is the most suitable solution. But WebRTC isn’t always available to us, so AirConsole just falls back to other mechanisms.
While a gaming console is an obvious use case, and I did see it in more instances lately, I think there’s merit to such a generic framework in other instances as well.
Time someone implemented it
The post Where’s the Socket.io of WebRTC’s Data Channel? appeared first on BlogGeek.me.
Links:
http://tldp.org/HOWTO/Traffic-Control-HOWTO/intro.html
Don’t wait up for Apple to get you WebRTC in the near future.
Like many others, I’ve seen the minor twitter storm of our minuscule world of WebRTC. The one in which a screenshot of an official Apple job description had the word WebRTC on it. Amir Zmora does a good job of outlining what’s ahead of Apple with adding WebRTC. The thing he forgot to mention is when should we be expecting anything.
The below are generally guesses of mine. They are the roadmap I’d put for Apple if I were the one calling the shots.
When will we see an Apple WebRTC implementation?Like anyone else, I am clueless to the inner workings of Apple. If the job postings tell us anything it is that Apple are just starting out. Based on my experience in implementations of media engines, the time it took Google, Mozilla and Microsoft to put a decent release out, I’d say:
We are at least 1 year away from a first, stable implementation
It takes time to implement WebRTC. And it needs to be done across a growing range of devices and hardware when it comes to the Apple ecosystem.
Where will we see an Apple WebRTC implementation?Safari on Mac OS X. The next official release of it.
The Safari browser on iPad and iPhone will come next. Appearing on iPhone 6 and onwards. Maybe iPhone 5, but I wouldn’t bet on it.
We will later see it supported in the iOS WebView support. Probably 9-12 months after the release of Safari on iOS.
The Apple TV would be left out of the WebRTC party. So will the Apple Watch.
Which Codecs will Apple be using?H.264, AAC-ELD and G.711. Essentially, what they use in FaceTime with the addition of G.711 for interoperability.
Apple sets its sights on Google. They now hold Microsoft as best-friends with the Office releasing on iOS.
On one hand, going with ORTC would be great:
On the other hand, going with WebRTC might be better:
Being adventurous, I’d go for ORTC if I were Apple. Vindictiveness goes a long way in decision making.
ExtraOn launch day, I am sure that Bono will be available on stage with Tim Cook. They will promise a personal video call over WebRTC running in WebKit inside Safari to the first 10 people who stand in line in Australia to purchase the next iPhone.
And then again, I might be mistaken and tomorrow, WebRTC will be soft launched on the Mac. Just don’t build your strategy on it really happening.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post Apple WebRTC Won’t Happen Soon appeared first on BlogGeek.me.
The team at ThinQ show how to set up your routing profile, carrier selection, high volume traffic management, and LCR routing.
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.
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.