While you need to give direct access to your APIs, an SDK is a critical piece of your offering.
There was an article on the ProgrammableWeb on Sending.io NOT offering an SDK for their service. I think in most cases, this approach is wrong.
Sending.io decided to offer only an API layer for its customers. You can access their REST APIs, but how you do it is your problem – even when what they give is designed and built for mobile devices.
API and SDKI’ll start with a quick explanation of the two – at least in the scope of this post. There will be those who will definitely object my definitions here, but the idea is just to make the distinction I need here – and not to pontificate the meaning of the two.
Back to Sending.io and their reasons – from this article:
While this may work in the gaming industry, I think it is not workable in many other industries. Here are my thoughts on this one:
It all boils down to your executionThere are two ways to treat an SDK – as part of your offering or as an afterthought.
If you treat it as an afterthought, then performance issues, crashes and privacy issues will crop more frequently than not.
With most SDKs today built as frontends to a backend REST API, it makes perfect sense that some of them just aren’t written well: Backend developers are good at scaling a service to run in the cloud. For them, considerations of memory and performance of the single session in the same way that a native Android developer thinks about is foreign.
If you really want to offer an SDK, have a pro build it for you.
The customer’s controlAssuming what you have on offer is a closed binary SDK that the customer ends up using, then control may be an issue.
It doesn’t have to be this way.
There are 3 options you can take here, each with its own control points for customers:
There are several reasons that make an SDK so powerful:
Plan on offering a backend API for your customers?
You shouldn’t just ignore an SDK – especially not if you plan on having developers integrate with your APIs inside mobile apps.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post Why an SDK is Critical to your API Offering appeared first on BlogGeek.me.
Hello, again. This passed week in the FreeSWITCH master branch we had 37 commits. There was one feature this week with improvements to play_and_detect_speech to set the current_application_response channel variable.
Join us on 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:
This passed week in the FreeSWITCH 1.4 branch we had 30 commits merged in from master.
Security issues:
New features that were added:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
There are a lot of notable exceptions, but most WebRTC developers start with the web because well, Web RTC does start with web and development is much easier there. Market realities tells a very different story – there is more traffic on mobile than desktop and this trend is not going to change. So the next phase in most WebRTC deployments is inevitably figuring out how to support mobile. Unfortunately for WebRTC that has often meant finding the relatively rare native iOS and Android developer.
The team at eFace2Face decided to take a different route and build a hybrid plugin. Hybrid apps allows web developers to use their HTML, CSS, and JavaScript skills to build native mobile apps. They also open sourced the project and verified its functionality with the webrtc.org AppRTC reference. We asked them to give us some background on hybrid apps and to walk us through their project.
{“intro-by”, “chad“}
When deciding how to create a mobile application using WebRTC there is no obvious choice. There are several items that should be taken into consideration when faced with this difficult decision, like the existence of previous code base, the expertise, amount of resources and knowledge available. Maintenance and support are also a very important factors given the fragmentation of the mobile environment.
At eFace2Face we wanted to extend our service to mobile devices. We decided to choose our own path- exploring and filling in the gaps (developing new tools when needed) in order to create the solution that fitted us best.This post shares some of the knowledge and expertise we gained the hard way while doing so. We hope you find it useful!
What’s a hybrid application?There are two main approaches on how hybrid apps are built:
Creating Hybrid HTML5 app is the most extensive alternative and the one we prefer because it uses web specific technologies. You can get a deeper overview about native vs. HTML5 (and hybrid applications) in a recent blog post at Android Authority.
Hybrid App Pros & Cons Pros:From our point of view, a typical WebRTC application is not really graphic-intensive (i.e. it is not, for instance, a game with lots of animations and 3D effects). Most of the complex processes are done internally by the browser, not in JavaScript, so a graphical UX interface should be perfectly doable on a hybrid application and run without any significant perceptible slowdown. Instagram is a good example of a well-known hybrid app that uses web technologies in at least some of its components.
WebRTC on native mobile: current statusNative support in Android and iOS is a bit discouraging. Apple do not support it at all, and has no public information about when are they going to do so, if they decide to support it at all. On Android, the native WebView supported WebRTC starting in version 4.4 (but be cautious as it is based on Chromium 36) then in 5.0 and onwards.
Note that there are no “native WebRTC” APIs on Android or iOS yet, so you will have to use Google’s WebRTC library. Justin Uberti (@juberti) provides a very nice overview of how to do this (go here to see the slides).
SolutionsLet’s take a look at the conclusions of our research.
Android: CrosswalkIn Android, using the native WebView seems like a good approach; in fact we used it during our first attempt to create our application. But then we decided to switch to Intel’s Crosswalk, which includes what’s best described as a “full Chrome browser”. It actually allows us to use a fully updated version of native Chromium instead of WebView.
These were our reasons for choosing Crosswalk:
An advanced reader could think: “Ok, this is cool but I need to use different console clients (Cordova and Crosswalk) to generate my project, and I don’t like the idea of that.” You’re right, it would be a hassle, but we also found another trick here. This project allows us to add Crosswalk support to a Cordova project; it uses a new Cordova feature to provide different engines like any other plugin. This way we don’t need to have different baselines in the source code.
iOS: Cordova pluginAs explained before, there are frameworks that provide hybrid applications with the device functionality code via plugins. You can use them in your JavaScript code but they are implemented using native code. So, it should be possible to add the missing WebRTC JavaScript APIs.
There are several options available, but most of them provide custom APIs or are tightly coupled with some proprietary signaling from a service provider. That’s the reason that we released an open source WebRTC Cordova plugin for iOS.
The plugin is built on top of Google’s native WebRTC code and exposes the W3C WebRTC APIs. Also, as it is a Cordova plugin, it allows you to have the same Cordova application running on Android with Crosswalk, and on iOS with the WebRTC plugin. And both of them reuse all of the code base you are already using for your web application.
Show me the code!“Yes, I have heard this already”, you might say, so let’s get some hands-on experience. In order to demonstrate that it’s trivial to reuse your current code and have your mobile application running in a matter of days (if not hours), we decided to take Google’s AppRTC HTML5 application and create a mobile application using the very same source code.
You can find the iOS code on github, Here are the steps required to get everything we’re talking about working in minutes:
We needed to make some minor changes in order to make it work properly in the Cordova environment. Each of these changes didn’t require more than a couple of js/html/css lines:
Deciding whether to go hybrid or native for your WebRTC app is up to you. It depends on the kind of resources and relevant experience your company has, the kind of application that you want to implement, and the existing codebase and infrastructure you already have in place. The good news is our results show that using WebRTC is not a key factor in this decision, and you can have the mobile app version of your WebRTC web service ready in much less time than you probably expected.
References
{“authors”, [“Jesus Perez“,”Iñaki Baz“, “Sergio Garcia Murillo“]}
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 Developing mobile WebRTC hybrid applications appeared first on webrtcHacks.
Friction.
A true story…
I had a meeting the other day. It was with a company that has been offering WebRTC video chat as part of its own services to their own customers for some time now, but internally, they used some other vendor for their own business meetings. My invitation was on that other vendor’s platform.
At the time of the meeting, I opened the calendar invitation, searching for the link to press.
Found it. Clicked it.
Got using my Chrome browser on my home desktop Ubuntu machine to the web page.
Clicked to join the meeting using my browser.
Was greeted with a message telling me Chrome isn’t supported due to a Chrome bug (with a link to a page detailing the issue on Chrome’s bug tracker) AND suggesting me to use Firefox.
Good.
Opened up Firefox, pasted the link to it.
Clicked to join the meeting using my browser.
Was greeted with a message telling me that only Windows and Mac are supported.
Great.
Opened my laptop to join. It runs Windows 8, so no issues there (I hoped).
Clicked the link on the email there, just to get Chrome opened there.
Somehow, the system knew this time that I should be able to use Chrome, so it happily instructed me to wait to download and then run the executable they were sending me.
Ok.
It took a minute or two to get that executable to run and start installing *something*.
But it got lost in all my windows. A bit of searching and I found the pesky window telling me to open the link yet again.
So I did.
It then went into this seemingly endless loop of trying to open up a meeting, failing and reopening.
This is when I noticed that the window being opened was an Internet Explorer one.
I cut the loop short and opened the link to the meeting on Internet Explorer.
It worked.
10 minutes later, frustrated, with another crappy installation of a client lurking around my Windows machine, I got to talk to the people who invited me.
Two were there with video – me one of them – we actually installed and executed that “plugin”.
Others joined by phone.
—
I am a technical person.
I worked in the video conferencing industry.
Why the hell should we use such broken tools and technologies in 2015?
I couldn’t care less if the video conferencing equipment that have been purchased ions ago don’t support VP8 or require conversion of SRTP to RTP or require translation from REST/WebSocket to H.323 signaling. I really don’t.
The only thing I want is to open a browser to a specific URL and have that URL just work.
On Ubuntu please.
—
The service in question?
Wasn’t a new one. They’ve been around for a decade or so.
They started with the desktop, so why can’t they get that experience to work well?
—
Yes. Internet Explorer and Safari are missing. I know. But I couldn’t care less.
If you want to provide a broken plugin experience for IE and Safari, then please do. But wherever possible make it easier for me to use.
It really isn’t hard. I attend a lot of video calls these days. The crushing majority of them are through WebRTC based services. Most of the services I used weren’t built by billion dollar companies.
Get your act together.
Start using WebRTC for your own business meetings.
The post Why I Hate Video Conferencing Plugins and LOVE WebRTC Services appeared first on BlogGeek.me.
As newly appointed co-chair in the W3C WebRTC WG, I just participated in my first Editor’s Call, and I’m impressed.
We had to address nearly dozens of Pull Requests and Issues on the associated github repos. We managed to knock down quite a few that ended up getting merged and a few that were closed today, despite not having 1 co-chair and 1 editor present.
There were some suggestions on how we could make the processes a bit more effective, allowing everyone to understand more what’s expected of them. It’s going to take a few meetings I suspect to get a real feel for how I can be adding the most value possible.
Overall, it feels like we are all trying our best to do what the new charter has set out, to get 1.0 done before getting on with the next chapter. I am excited to be part of it and look forward to continue helping!
If you have any thoughts on how the WebRTC Working Group could be doing things differently to be more effective and efficient, I would like to hear your thoughts.
Companies care little about standards. Unless it serves their selfish objectives.
The main complaint around WebRTC? When is Apple/Microsoft going to support it.
How can that be when WebRTC is being defined by the IETF and W3C? When it is part of HTML5?
WebAssemblyWe learned last week on a brand new initiative: WebAssembly. The concept? Have a binary format to replace JavaScript, act as a kind of byte-code. The result?
If the publication on TheNextWeb is accurate, then this WebAssembly thing is endorsed by all the relevant browser vendors (that’s Google, Apple, Microsoft & Mozilla).
WebAssembly is still just a thought. Nothing substantiate as WebRTC is. And yet…
WebAssembly yes and WebRTC no. Why is that?
Why is that?
Decisions happen to be subjective and selfish. It isn’t about what’s good for the web and end users. Or rather, it is, as long as it fits our objects and doesn’t give competitors an advantage or removes an advantage we have.
WebAssembly benefits almost everyone:
Google has no issue with this – they thrive on things running in browsers
Microsoft are switching towards the cloud, and are in a losing game with their dated IE – they switched to Microsoft Edge and are showing some real internet in modernizing the experience of their browser. So this fits them
Mozilla are trying to lead the pack, being the underdog. They will be all for such an initiative, especially when WebAssembly takes their efforts in asm.js and build assets from there. It validates their credibility and their innovation
Apple. TechCrunch failed to mention Apple in their article of WebAssembly. A mistake? On purpose? I am not sure. They seem to have the most to lose: Better web means less reliance on native apps, where they rule with current iOS first focus of most developers
All in all, browser vendors have little to lose from WebAssembly while users theoretically have a lot to gain from it.
WebRTCWith WebRTC this is different. What WebRTC has to offer for the most part:
The problem stems from the voice and video capability.
Google have Hangouts, but make money from people accessing web pages. Having ALL voice and video interactions happen in the web is an advantage to Google. No wonder they are so heavily invested in WebRTC
Mozilla has/had nothing to lose. They had no voice or video assets to speak of. At the time, most of their revenue also came from Google. Money explains a lot of decisions…
Microsoft has Skype and Lync. They sell Lync to enterprises and paid 8.5 billions for Skype. Why would they open up the door to competitors so fast? They are now headed there, making sure Skype supports it as well
Apple. They have FaceTime. They care about the Apple ecosystem. Having access to it from Android for anything that isn’t a Move to iOS app won’t make sense to them. Apple will wait for the last moment to support it, making sure everyone who wishes to develop anything remotely related to FaceTime (which was supposed to be standardized and open) have a hard time doing that
All in all, WebRTC doesn’t benefit all browser vendors the same way, so it hasn’t been adopted in the same zealousness that WebAssembly seems to attract.
Why is it important?Back to where I started: Companies care little about standards. Unless it serves their selfish objectives.
This is why getting WebRTC to all browser vendors will take time.
This is why federating VoIP/WebRTC isn’t on the table at this point in time – the successful vendors who you want to federate with wouldn’t like that to happen.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post How the Politics of Standardization Plays in WebRTC, WebAssembly and Web Browsers appeared first on BlogGeek.me.
Hello, again. This passed week in the FreeSWITCH master branch we had 94 commits! We had a large amount of work done this week and a few of the highlights are: added mod_local_stream video support, added member status in json format to the conference live array, added function to enable debug information about Opus payload, and a security issue concerning enabling cert CN/SAN validation.
Join us on Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support.
Security issues:
FS-7708 Fixed docs on enabling cert CN/SAN validation
New features that were added:
FS-7656 [mod_localstream] Added mod_local_stream video support, and make mod_conference move the video in and out of a layer when the stream has video or not, scan for relative file in art/eg.wav.png and display it as video when playing audio files, put video banner up if artist or title is set, and fixed a/v sync on first connection
FS-7629 [mod_conference] Added member status in json format to the conference live array, add livearray-json-status to conference-flags to enable
FS-7517 FS-7519 [mod_av] [mod_openh264] Added H264 STAP-A packeting support so it would work with FireFox
FS-7664 [mod_verto] Set ICE candidate timeout to wait for only 1 second to fix media delays
FS-7660 [mod_opus] Enabled with new API command “opus_debug” to show information about Opus payload for debugging.
FS-7519 [mod_av] Fixed bitrate and added some presets
FS-7693 [mod_conference] Lower the default energy level in sample configs to improve voice quality
Improvements in build system, cross platform support, and packaging:
FS-7648 More work toward setting up a QA testing configuration, add condition testing for regex all and xor cases, adding profile-variable for testing cases , add lipsync tests for playback and local stream, add stereo, and configuration for mcu test
FS-7338 Fixed bug in Debian packaging when trying to build against custom repo
FS-7609 Enable building of mod_sangoma_codec for Debian Wheezy/Jessie
FS-7667 [mod_java] Fixed include directory detection when using Debian java packages and use detected directory
FS-7655 Make libvpx and libyuv optional (none of the video features will work without them) The following modules require these libraries to be installed still: mod_av mod_cv mod_fsv mod_mp4v2 mod_openh264 mod_vpx mod_imagick mod_vpx mod_yuv mod_png mod_vlc, fix build issue w/ strict prototypes, and fix a few functions that need to be disabled without YUV
FS-7605 Fixed default configuration directory in Debian packages and fixed Debian packaging dependencies on libyuv and libvpx
FS-7669 When installing from Debian packaging if you don’t have the /etc/freeswitch directory, we will install the default packages for you. If you already have this directory, we’ll let you deal with your own configs.
FS-7297 [mod_com_g729] Updated the make target installer
FS-7644 Added a working windows build without video support for msvc 2013
FS-7666 [mod_managed] Fixed error building mod_managed on non windows platforms
The following bugs were squashed:
FS-7641 Fixed a segfault in eavesdrop video support
FS-7649 [mod_verto] Fixed issue with h264 codec not being configured in verto.conf.xml
FS-7657 [mod_verto] Fixed a bug with TURN not being used. Note, you can pass an array of stun servers, including TURN, to the verto when you start it up. (see verto.js where iceServers is passed)
FS-7665 [mod_conference] Fixed a bug with the video floor settings not giving the video floor to the speaker
FS-7650 [mod_verto] Fixed crash when making a call from a verto user with profile-variables in their user profile
FS-7710 [mod_conference] Added the ability to set bandwidth to “auto” for conference config
FS-7432 Fixed dtls/srtp, use correct a=setup parameter on recovering channels
FS-7678 Fixed for fail_on_single_reject not working with | bridge
FS-7709 [mod_verto] Verto compatibility fixes for Firefox
FS-7689 [mod_lua] Fixed a bug with lua not loading directory configurations
FS-7694 [mod_av] Fixed for leaking file handles when the file is closed.
Jitsi switching to the Apache open source license is what the doctor ordered.
Blue Jimp, and with it Jitsi, was acquired by Atlassian in April this year. I wrote at the time about Jitsi’s open source license:
The problem with getting the Jitsi Videobridge to larger corporations was its open source license
You can read my explanation on open source licenses. If you read the comments as well, you’ll see how complex and mired with landmines this domain is.
Last week, an announcement was made in the jitsi-dev mailing list: Jitsi is switching from LGPL to Apache license:
LGPL, our current license allows everyone to integrate and ship our various jars. Once you start making changes and distributing them however, then you you need to make sure these changes are also available under LGPL, AKA the LGPL reciprocity clause.
What I found interesting weer the next two paragraphs:
As the copyright holder, in BlueJimp we have been been exempt from this reciprocity clause. Even though we rarely use it, we had the liberty to modify our code without making our changes public. No one else had this option.
Switching to Apache ends our advantage in this regard, and allows everyone to use, integrate and distribute Jitsi with a lot less limitations.
Some things to notice here:
All in all, this is a great move to our WebRTC ecosystem. Atlassian is doing the right moves in maintaining the Jitsi community happy and engaged while attracting the larger players in the market. I wouldn’t have done it any other way if I were in their shoes.
Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.
The post Why Did Atlassian Switch Jitsi’s Open Source License from LGPL to Apache? appeared first on BlogGeek.me.
Big thanks to everyone (especially Bernard) for putting in the extra work required here for our next CG meeting:
Draft Community Group Report 22 June 2015B.1 Changes since 7 May 2015
While our smartphones aren’t phone anymore, their phone-calling real estate is still a prime asset.
VoLTE stands for Voice over LTE. It has been in the making for quite some time, but haven’t made its grand public appearance yet. While carriers around the globe boast LTE adoption stats, this says NOTHING about the lag of the carrier’s once main service – the humble voice call.
Today, in almost all cases where you open your smartphone greeted with an LTE network, if you make a phone call, it will go over 3G or GSM. Why? Because for voice to traverse LTE it requires VoLTE – or some other workaround means. Once VoLTE makes it into the scene, it will need to replace the voice calls today – and be a part of the smartphone’s dialer.
But there are other means of making calls these days, and I am not talking about Skype buddy lists.
Here is how the different players on the market redefining how we make calls, and trying to win the real-estate of the phone’s dialer by… replacing it.
AppleIn some ways, Apple is dependent on carriers selling its smartphones through contract agreements. So it can’t piss off their channel to market too much. But they can are treading on a very fine line here.
It started with FaceTime. Apple’s video chat service. Which then grew to iMessage, and later an introduction of FaceTime Audio.
Apple controls the iPhone’s UI, which means it decides how the dialer looks like and what functions it exposes to the user.
The end result?
Google has Hangouts. You get it pre-installed in Android devices. Many never use it, but it is there.
Google tried making Hangouts sticky in the past, so they allowed it to receive and send SMS – similar in some ways to how Apple does iMessage, but different as the experience isn’t as seamless.
On a mobile phone, think of Hangouts as a step in the way. Google’s Project Fi, their new MVNO initiative, probably uses Hangouts internally – it does connect with Hangouts as their website explains:
Connect any device that supports Google Hangouts (Android, iOS, Windows, Mac, or Chromebook) to your number. Then, talk and text with anyone—it doesn’t matter what device they’re using.
Google is bulking up its communication chops nicely these past few years, and Fi is the next step. I am certain that part of the tech and learnings that Google gains from Fi will find its way back to their general Hangouts service.
FacebookFacebook had its share of romance with mobile. From rumors of Facebook smartphones, to a failed Facebook Home app.
For Facebook mobile is critical. Many of its customers use it exclusively on mobile. How do you increase your share in a digital life pie if you are Facebook? You try to control the smartphone experience.
Building a smartphone is hard (ask Amazon), so Facebook tried controlling the home screen by developing a Facebook centric Android launcher. This didn’t work, but wasn’t a failure at the scale of a smartphone launch.
Next up, is their relatively new Hello app. It looks rather innocuous – you receive calls through their Hello app to get a “social ID” – Facebook will match the phone number to a person’s Facebook account to show to you on incoming calls.
The end result?
Whatsapp is a part of Facebook, but it took a very different approach. It simply added voice calling to its app.
If you are interested in understanding the size of Whatsapp, then there’s a good bulleted list on Mobile Industry Review.
Think of this move in the following context:
What is your dialer now? The traditional phone dialer with its contacts app or Whatsapp?
Why is it important?Communication is being redefined. Switching from voice and video towards data access and messaging.
This brings with it a bigger change of what is considered prime real estate on one smartphone’s display, and there are non-telco vendors who are positioned nicely to displace the carriers from the dialer as well. Where would that leave the carrier’s efforts with VoLTE?
Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.
The post How OTTs are Challenging VoLTE’s Prime Asset on Smartphones appeared first on BlogGeek.me.
With the forthcoming re-charter @W3C WebRTC Working Group, there were also a few managerial changes:
I am personally flattered and over the moon excited to have been asked to co-chair the WebRTC Working Group and look forward to working with Harald and Stefan to help usher in the next era of WebRTC standards work.
/Erik
To paraphrase Seth Godin, WebRTC is about breaking things.
Seth Godin (who you should definitely read) had an interesting post this week, titled Abandoning perfection. It is short so go over and read it. I’ll just put one of the paragraphs of this post here, to serve as my context:
Perfect is the ideal defense mechanism, the work of Pressfield’s Resistance, the lizard brain giving you an out. Perfect lets you stall, ask more questions, do more reviews, dumb it down, safe it up and generally avoid doing anything that might fail (or anything important).
Now that we have it here, why don’t we check on the excuses people (and companies) give for not using WebRTC?
Got a lizard brain? Make sure you use the excuses above in the next weekly meeting with your boss. Want to break things and be useful? Check out what WebRTC can do for you.
Oh, and when someone tells you that WebRTC isn’t ready for prime time yet, but will be in 2-3 years – and a lot sooner than you expect – tell him it is ready. Today.
I’ve seen companies using WebRTC daily – in ways that advances their business – adding more flexibility – enabling them to make better decisions – lowers their costs – or allow them to exist in the first place.
Got a good use case that requires real time communications? First check if WebRTC fits your needs – REALLY check. 80% or more of the time – it will.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
Trying to understand how to get your service to mobile with WebRTC? Read my WebRTC Mobile Adoption report, written specifically to assist you with this task.
Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.
Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.
Looking for a WebRTC related job? Need the best WebRTC developer out there? You should definitely try out the WebRTC Job Board - satisfaction guaranteed!The post Why You Should Start Using WebRTC TODAY and Abandon Perfection? appeared first on BlogGeek.me.
Android got a lot of WebRTC’s mobile development attention in the early days. As a result a lot of the blogosphere’s attention has turned to the harder iOS problem and Android is often overlooked for those that want to get started with WebRTC. Dag-Inge Aas of appear.in has not forgotten about the Android WebRTC developer. He recently published an awesome walkthrough post explaining how to get started with WebRTC on Android. (Dag’s colleague Thomas Bruun also put out an equally awesome getting started walkthrough for iOS.) Earlier this month Google also announced some updates on how WebRTC permissions interaction will work on the new Android. Dag-Inge provides another great walkthrough below, this time covering the new permission model.
{“editor”: “chad“}
At this year’s Google I/O, Google released the Android M Developer Preview with lots of new features. One of them is called App Permissions, and will have an impact on how you design your WebRTC powered applications. In this article, we will go through how you can design your applications to work with this new permissions model.
To give you the gist of App Permissions, they allow the user to explicitly grant access to certain high-profile permissions. These include permissions such as Calendar, Sensors, SMS, Camera and Microphone. The permissions are granted at runtime, for example, when the user has pressed the video call-button in your application. A user can also at any time, without the app being notified, revoke permissions through the app settings, as seen on the right. If the app requests access to the camera again after being revoked, the user is prompted to once again grant permission.
This model is very similar to how iOS has worked their permission model for years. User’s can feel safe that their camera and microphone are only used if they have given explicit consent at a time that is relevant for them and the action they are trying to perform.
However, this does mean that WebRTC apps built for Android now have to face the same challenges that developers on iOS have to face. What if the user does not grant access?
To get started, let’s make sure our application is built for the new Android M release. To do this, you have to edit your application’s build.gradle file with the following values:
targetSdkVersion "MNC" compileSdkVersion "android-MNC" minSdkVersion "MNC" // For testing on Android M Preview only.Note that these values are prone to change once the finalized version of Android M is out.
In addition, I had to update my Android Studio to the Canary version (1.3 Preview 2) and add the following properties to my build.gradle to get my sources to compile successfully:
compileOptions { sourceCompatibility JavaVersion.VERSION_1_7 targetCompatibility JavaVersion.VERSION_1_7 }However, your mileage may vary. With all that said and done, and the M version SDK installed, you can compile your app to your Android device running Android M.
Checking and asking for permissionsIf you start your application and enable its audio and video capabilities, you will notice that the camera stream is black, and that no audio is being recorded. This is because you haven’t asked for permission to use those APIs from your user yet. To do this, you have to call requestPermissions(permissions, yourRequestCode) in your activity, where permissions is a String[] of android permission identifiers, and yourRequestCode is a unique integer to identify this specific request for permissions.
String[] permissions = { "android.permission.CAMERA", "android.permission.RECORD_AUDIO" }; int yourRequestId = 1; requestPermissions(permissions, yourRequestCode);Calling requestPermissions will spawn two dialogs to the user, as shown below.
When the user has denied or allowed access to the APIs you request, the Activity’s onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) method is called. Here we can recognize the requestCode we sent when asking for permissions, the String[] of permissions we asked for access to, and an int[] of results from the grant permission dialog. We now need to inspect what permissions the user granted us, and act accordingly. To act on this data, your Activity needs to override this method.
@Override public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) { switch (requestCode) { case YOUR_REQUEST_CODE: { if (grantResults[0] == PackageManager.PERMISSION_GRANTED){ // permission was granted, woho! } else { // permission denied, boo! Disable the // functionality that depends on this permission. } return; } } }Handling denied permissions will be up to your app how you want to handle, but best practices dictate that you should disable any functions that rely on these permissions being granted. For example, if the user denies access to the camera, but enables the microphone, the toggle video button should be disabled, or alternatively trigger the request again, should the user wish to add their camera stream at a later point in the conversation. Disabling access to video also means that you can avoid doing the VideoCapturer dance to get the camera stream, it will be black anyway.
One thing to note is that you don’t always need to ask for permission. If the user has already granted access to the camera and microphone previously, you can skip this step entirely. To determine if you need to ask for permission, you can use checkSelfPermission(PERMISSION_STRING) in your Activity. This will return PackageManager.PERMISSION_GRANTED if the permission has been granted, and PackageManager.PERMISSION_DENIED if the request was denied. If the request was denied, you may ask for permission using requestPermissions.
if (checkSelfPermission(Manifest.permission.CAMERA) == PackageManager.PERMISSION_DENIED) { requestPermissions(new String[]{Manifest.permission.CAMERA}, YOUR_REQUEST_CODE); } When to ask for permissionThe biggest question with this approach is when to ask for permission. When are the user’s more likely to understand what they are agreeing to, and therefore more likely to accept your request for permissions?
To me, best practices really depend on what your application does. If your applications primary purpose is to enable video communication, for example a video chat application, then you should at initial app startup prime the user for setting up their permissions. However, you must at the same time make sure that permissions are still valid, and if necessary, reprompt the user in whatever context is natural for permissions should you need it. For example, a video chat application based on rooms may prompt the user to enable video and audio before entering a video room. If the user has already granted access, the application should proceed to the next step. If not, the application should explain in clear terms why it needs audio and video access, and ask the user to press a button to get prompted. This makes the user much more likely to trust the application, and grant access.
If your application’s secondary purpose is video communication, for example in a text messaging app with video capabilities, best practices dictate that the user should get prompted when clicking the video icon for starting a video conversation. This has a clear benefit, as the user knows their original intention, and will therefore be likely to grant access to their camera and microphone.
And remember, camera and microphone access can be revoked at any time without the app’s knowledge, so you have to run the permission check every time.
But do I have to do it all now?Yes and no. Android M is still a ways off, so there is no immediate rush. In addition, the new permission style only affects applications built for, or targeting, Android M or greater API levels. This means that your application with the old permission model will still work and be available to devices running Android M. The user will instead be asked to grant access at install time. Note that the user may still explicitly disable access through the app settings, at which point your application will show black video or no sound. So unless you wish to use any of the new features made available in Android M, you can safely hold off for a little while longer.
{“author”: “Dag-Inge Aas“}
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, @reidstidolph, @victorpascual and @tsahil.
The post The new Android M App Permissions – Dag-Inge Aas appeared first on webrtcHacks.
Is Comverse becoming a serious WebRTC player?
Comverse is a company in transition. It has been catering the world’s telcos for many years. In recent years, it had its share of issues. Why are they important in the context of this blog?
Comverse is a company searching for their way. Their current focus is digital services with the set of customers being Telcos.
Digital focus means APIs and platforms that enable rapid creation of services.
The interesting part here is that Comverse is getting a sales team and an operation that knows how to sell to enterprises and not only to Telcos. I do hope they will be smart enough to keep that part of the business alive and leverage it.
Open questions include: Will Comverse merge Acision assets with Solaiemes? Try to build one on top of the other?
What does this say about Acision?Acision got acquired for their SMS and voice business more than for their WebRTC or API platform components. No one gets acquired for that much money for WebRTC. Yet.
It is funny to note that Acision Forge platform, which runs their WebRTC PaaS part, was an acquisition of Crocodile RCS.
Comverse being focused on Telcos, how will they view the Forge platform?
This isn’t the first or last WebRTC related acquisition of the year. We had a few already.
If you are looking to use any vendor for your WebRTC technology, you need to consider the possibility of acquisition seriously.
It also led me to updating my WebRTC dataset subscription service: as of today, its subscribers also receive an updated acquisitions table, detailing all acquisitions related to WebRTC since 2012.
Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.
The post Comverse Acquires Acision, Framing Digital an APIs Around WebRTC appeared first on BlogGeek.me.
La nuova major release di 3CX Phone System è pronta! Il nostro team Ricerca&Sviluppo c’è riuscito un’altra volta e ci ha fornito una versione straordinaria: pronta per il Cloud e corredata di una serie di miglioramenti e funzionalità innovative.
Di particolare interesse per i partners e i Service Providers sono le nuove funzionalità di centralino virtuale contenute in 3CX Phone System v14. Il vecchio 3CX Cloud Server fa ormai parte del passato e questa funzionalità è ora integrata nel setup principale, consentedovi di scegliere se installare una v14 come sistema on-premise o come centralino virtuale in grado di gestire fino a 25 istanze per ogni macchina. L’installazione e la gestione delle istanze virtuali possono da ora essere effettuate attraverso il nostro sistema ERP o via API. Entra in competizione con altri fornitori di centralini virtuali con una piattaforma migliore e più ricca di funzioni, pur mantenendo il controllo dei dati del cliente e potendo scegliere il VoIP Provider più adatto!
Breve elenco delle nuove funzionalità:
Download Links e Documentazione
Scarica la 3CX Phone System v14 Technical Preview: http://downloads.3cx.com/downloads/3CXPhoneSystem14.exe
Scarica 3CXPhone per Android
Scarica 3CXPhone per Windows
Scarica 3CXPhone per Mac – Si prega di notare che il nuovo client per Mac sarà rilasciato nella prossima build
Scarica 3CXPhone per iOS
Scarica 3CX Session Border Controller per Windows
Manuale Amministratore: Capitolo 8 : ‘Deploying 3CX Phone System as a Virtual PBX Server’
Demo Key: 3CXP-DEMO-EDIT-VEI4
Fedele alla sua reputazione di azienda innovatrice, 3CX è uno dei primi produttori di centralini telefonici ad offrire un client per Mac completo di funzionalità professionali. Con il nuovo aggiornamento del popolare [...]
Hello, again. This passed week in the FreeSWITCH master branch we had 51 commits! Some of the new commits this week include: the addition of a new reserve-agents param to mod_callcenter, allowing for custom exchange name and type for mod_amqp producers, a sample build system for a stand alone(out of tree) FreeSWITCH module, and added video support to eavesdrop.
Join us on 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:
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.