Disruptive Telephony

Leaving aside the bizarre way to end the warning banner ("... to integrate with" and then nothing more), I went to the site because I received an email from Skype in the form of a "SkypeKit License Termination Notice". The email says in full:

Dear Dan ,

In July 2013, we notified you of our intention to end support for our SkypeKit SDK at the end of July 2014. With this date now approaching, this email serves as 30 days’ official notice of termination of the SkypeKit Licence Agreement (“Agreement”) pursuant to Section 13.2.4 of the Agreement. The Agreement will end on July 31st 2014. Upon termination of the Agreement you must promptly destroy all copies of the SkypeKit SDK in your possession or control, except that if you have already entered into the SkypeKit Distribution Terms and have received a commercialization keypair for your SkypeKit Product(s) then you may continue to distribute these SkypeKit Products(s).

Skype will not be issuing any new keypairs and we remind you that keypairs may only be used in connection with the SkypeKit Product for which they were issued. In addition, for hardware, keypairs may only be used for the specific version of the SkypeKit Product that was certified through our hardware certification program. Our hardware certification program for SkypeKit Products has now closed and no new hardware (including new models or versions of previously certified hardware) can be distributed.

Key investments in Skype’s application and service architecture may cause the Skype features to stop working without notice in SkypeKit products. As a result, we encourage you to end any further distribution of SkypeKit products.

We would also like to draw to your attention to the obligations that survive termination of the Agreement as described in Section 16.3 of the SkypeKit Licence Agreement.

The Skype Developer website will also close on July 31st, 2014. If you have any queries please contact Skype Developer Support.

Kind regards
Skype Developer Team

Looking back, I don't see the email from July 2013, but in truth I probably deleted it or it wound up in a spam folder. Sadly, I long ago lost much of my interest in Skype's latest developer follies.

If we jump back in time a bit, Skype first released a "preview" of their "SkypeKit" Software Development Kit (SDK) back in early 2011. Jim Courtney had a great writeup of their release of the public beta at eComm 2011. Like many others, I signed up and paid my $10 to see what was under the hood. I didn't do much with it but I remember looking at the python SDK a bit. Later in October 2011 I wrote about Skype's renaming of their public APIs and provided some clarification about what SkypeKit was all about.

And then I pretty much wrote nothing else about it... and much of the program gradually started fading away. In all my many posts about Skype, the only subsequent mention I find of SkypeKit was in a September 2010 post about Grandstream adding in Skype video to their IP phones.

In fairness, this was all happening before and then during the Microsoft acquisition of Skype in 2011 and so it was not surprising to see APIs created before Microsoft's acquisition being phased out.

What continues to surprise me is that there has never been any real replacement. Skype's 5th, 6th or 7th attempt (I lost track) at a developer program finally... just... died...

The folks at Skype wrote last November about the demise of the Desktop API and the need to support mobile devices. With that API's demise they also killed off their App Directory, which was their latest incarnation of a way to help developers get their apps out to Skype users.

Now Skype's entire "developer support" seems to be a category of pages on their support site, most of which seem to have answers about how the Skype Developer Program is no longer accepting registrations... or about why certain systems no longer work.

I get it... applications evolve. And Skype certainly has evolved away from its roots. It's just too bad, because once upon a time there seemed to be such promise for Skype as a communication platform that could be used widely by other companies and applications.

R.I.P. SkypeKit.

R.I.P. Skype Developer Program.

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

Want to hear the sound of Google further disrupting the world of telecom? If you have a Google Voice number and also use Google+ (as I do) with the Hangouts feature enabled, you'll soon be hearing this new sound if you haven't already.

An Unexpected Ringing

Yesterday a random PR person called the phone number in the sidebar of this blog to pitch me on why I should write about her client. This phone number is through Google Voice and I knew by the fact that my cell phone and Skype both started ringing simultaneously that someone was calling that number.

But as I was deciding whether or not to actually answer the call, I realized that there was another "ringing" sound coming from my computer that I had not heard before. Flipping quickly through my browser windows I found my Google+ window where this box appeared at the top of the "Hangouts" sidebar on the right:

Now, of course, I HAD to answer the call, even though I knew from experience that most calls to that number are PR pitches. I clicked the "Answer" button and in a moment a regular "Hangout" window appeared, complete with my own video, and with an audio connection to the phone call.

The PR person and I then had a pleasant conversation where I rather predictably determined quickly that she'd probably never actually readthis blog or she would have known that I've never written about her client's type of software. Be that as it may, the audio quality of the call was great and the call went on without any issues.

A subsequent test showed me that I also had access to the dialpad had I needed to send any button presses (for instance, in interacting with an IVR or robocall):

The only real "issue" with the phone call was that when I pressed the "Hang up" button I wound up still being in the Hangouts window with this message displayed:

The irony of course is that that phone number was never in the "video call"... at least via video. Regardless, I was now alone in the video call with my camera still running. I needed to press the "Exit" button in the upper right corner of the Hangouts window. Outside of that, the user experience for the phone call was fine.

The Future Of Google Voice?

Like many people interested in what Google is doing with Google+, I had read the announcement from Google of the new streams and Hangouts features last week and had gone ahead and installed the iOS Hangouts app onto my iPhone to try it out (marking Google's entrance into the OTT VoIP space). But nowhere in there had I seen that this connection was going to happen between Google Voice and Hangouts. I'd seen speculation in various media sites, but nothing direct.

So it was a bit of a surprise when it happened... particularly because I'd done nothing to enable it. Google had simply connected my Google Voice number to my Google+ account.

I admit that it is a pleasant surprise... although I do wish for the sake of my laptop's CPU that I could somehow configure it to NOT launch myvideo when I get an audio-only call. Yes, I can just go stop my video, but that's an annoying extra step.

It seems, though, that another feature removed from Hangouts, at least temporarily, was the ability to make outbound phone calls. Given that all signs of Google Voice were removed from Google's interface and replaced by "Hangouts", this has predictably upset people who used the service, particularly those who paid for credits to make outgoing calls. There does seem to be a way to restore the old Chat interfacefor those who want to make outgoing calls so that is at least a temporary workaround.

Google's Nikhyl Singhal posted to Google+ about the new Hangouts featuresstating these two points:

1) Today's version of Hangouts doesn't yet support outbound calls on the web and in the Chrome extension, but we do support inbound calls to your Google Voice number. We're working hard on supporting both, and outbound/inbound calls will soon be available. In the meantime, you can continue using Google Talk in Gmail.

2) Hangouts is designed to be the future of Google Voice, and making/receiving phone calls is just the beginning. Future versions of Hangouts will integrate Google Voice more seamlessly.

I'm sure that won't satisfy those who are troubled by the change, but it will be interesting to see where they go with Hangouts and voice communication.

(Note: the comment thread on Nikhyl Singhal's Google+ post makes for very interesting reading as people are sounding off there about what they'd like to see in a Hangouts / Google Voice merger.)

Will Hangouts Do SIP?

Of course, my big question will be... will Hangouts let us truly move beyond the traditional telephony of the PSTN and into the world of IP-based communications where can connect directly over the Internet? Google Voice once briefly let us receive VoIP calls using the SIP protocol - can Hangouts finally deliver on this capability? (And let us make outbound SIP calls as well?)

What do you think? Do you like this new linkage of Google Voice PSTN numbers to your Google+ account?

UPDATE #1 - I have written a follow-up post about XMPP support in Hangouts and confusion over what level of XMPP/Jabber support is still in Google+ Hangouts.

Audio commentary related to this post can be found in TDYR episode #009 on SoundCloud:

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

Voice calling through Facebook has the potential to be hugely disruptive... rather than calling on your phone over your regular phone connection - or even rather than using Skype, you can just call from directly within Facebook. This is the kind of "Over-The-Top (OTT)" app that gives telco operators a fit... goodbye, telco voice minutes!

Plus, it's using some HD voice codec so the sound quality is outstanding.

And since the folks at Facebook want you to live your life inside of their very pretty walls, this just provides yet one more reason for you to stay within those walls.

BUT... there's a big huge caveat that I'll get to in a moment.
 

A Quick Walkthrough

First, though, let's look at how it works. When you go into the Messenger app and open a chat with a friend (in this case, Jim Courtney), all you have to do is click the "i" button in the upper right:

After you do that you will get a window that I showed at the beginning of an article where you have a "Free Call" button.

When you press that, you begin a call experience very similar to any other call on your iPhone. First you are connecting to the other person and then you are in the actual call:

There is apparently the standard accept and decline buttons. (I neglected to have Jim call me back to get a screenshot.) While you are in the call you have a button to hang up, a speakerphone button and a microphone mute button. The last button is very nice in that it lets you remain in the call while using other features of your iPhone. In these two screenshots you can see that I could access our Messenger chat and also go back to my main iPhone screen to launch other applications. I can always tap the bar at the top to return to Messenger and the controls to our voice conversation:

The voice quality during the conversation was outstanding. It was crystal clear and rich enough that we knew it was some kind of HD voice codec being used.

All in all it was an excellent experience.

The Big, Huge Caveat

So what's the problem? Well... the reality is that right now trying to find someone to call is a struggle!

Going down through my contacts in the Messenger app was an exercise in futility. Person after person after person had the "Free Call" button greyed out:

Here's the fundamental problem:

You must be running the MESSENGER app on your iPhone!

It doesn't matter if you are running the Facebook application on your iPhone... you must be running Messenger.

And bizarrely there is no linkage between the two applications. If I am over in the Facebook application and go into a chat with Jim Courtney, notice that I have only the ability to "View Timeline":

And of course you must have an iPhone or iPad. If you have an Android device or some other device you are out of luck right now.

So the only people you can use this with are other people running Messenger on iOS.

Presumably Facebook is assuming people will just keep Messenger running... but I know that I, for one, try to limit the number of apps I keep running on my iPhone for battery life reasons.

More fundamentally, I never have used the Messenger app for chatting with other friends in Facebook. The Facebook app already provides the ability to chat... so why would I use the Messenger app? (And I know Facebook focuses on the speed that you can get to sending messages... but that's not critical for me.)

Potential For Disruption?

Now if Facebook gets their act together and makes this more intuitive and ubiquitous, the potential is there for more serious disruption. If it can be integrated into the main Facebook app... and can work for Android as well as iOS... and can work for people outside the US and Canada... THEN we might see more people shifting voice calls over into Facebook's voice service.

The potential is certainly huge, given Facebook's massive size.

Until then... it's an interesting option to have available... but I just don't see many people using it.

What About The Technology Behind It?

My other natural question was to wonder what they are using for the technology behind their voice service. As The Verge pointed out, Facebook and Skype have had a partnership to deliver video calling within Facebook's website. Could this be another component of that partnership? Is it a partnership with another VoIP provider? Is it something homegrown?

For now, I haven't seen any details that help explain that, but I'll certainly be watching to see what we can learn.

UPDATE: A tweet from Aswath Rao pointed me to a TechCrunch article from earlier this month when Facebook rolled out free voice calling in Canada that indicates that the technology is NOT from Skype. Separately I asked a Skype representative if Skype was involved in today's rollout and received the simple answer of "no".

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

Do you tell her you'll give her a call back when you get to a safe place? Or do you do the unsafe action of looking at your calendar on your phone?

What if there was a different way?

What if you could say something like "Let me check my calendar for tomorrow at 3pm" and then suddenly have a voice whisper back to you - on your call, but only heard by you - "your calendar is free at 3pm. You have meetings at 2 and 5."

You could then reply to your customer after just this brief pause letting her know that you could meet with her.

Sound like science fiction?

Perhaps... but that is the type of functionality that the team over at Voxeo Labs is looking to bring to calls with the launch of their new cloud service offering called Ameche. They are using the tagline "Apps in your Calls™" and produced this brief video to talk about what can be done:

I admit that I find their overview page and their introductory blog post a little bit over-the-top in terms of marketing-speak, but it starts to get interesting to me when you look at the page about apps in your calls. I'm not sure that I personally would get too excited about the "Social Calls Status Updates" example but it is extremely cool and valuable that they have this capability to connect with social networks. I find the other use cases such as Salesforce.com integration and context-based routing, and including the case I described at the beginning, far more compelling. It's also very important to note, as they do farther down that page, that Ameche is a platform and so can be used to build many different types of applications:

That platform itself, described on the Ameche technology page, sounds quite intriguing. As I understand it, they are essentially deploying a virtual machine running Node.js into a carriers network and then deploying applications inside that VM. They provide this network diagram showing how the pieces can fit together:

The outstanding part here is that they are using common web programming languages and fitting directly into existing carrier networks. This platform will let telcos create new services that can work with existing phone connections and existing phone numbers. No need for the customer to do anything except order the new service. No apps to download, no numbers to configure.

Obviously the primary market for this service is really the telecommunications service providers / carriers who are looking to offer additional services to their customers. At a time when those telcos are so threatened by the rise of various VoIP services and are looking for ways to build customer loyalty and keep the customers from leaving, Voxeo Labs' Ameche may just be the type of platform those carriers need right now.

Congrats to the team at Voxeo Labs on this launch - and I look forward to seeing what telcos will build with this new platform!

Full disclosure: I worked at Voxeo for 4 years and as a result am a small shareholder in the company. However, I would not write about the company or its products unless I thought they were worth writing about.

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

If you answered yes to any of the above questions, why not consider applying to be a speaker? The call for speakers is at:

http://adhearsionconf.com/call-for-speakers/

The only catch is ... the deadline is TOMORROW, Saturday, September 8th!

Ever since I first saw Jay Phillips present about Adhearsion back at one of the early ETel conferences in maybe 2006 or so I've been intrigued by how easy Adhearsion made it to develop telecom apps. It's just incredibly simple to make powerful apps.

If you are a Ruby developer (or want to be) and you are interested in building telephony apps, Adhearsion is definitely worth a look... and if you do use Adhearsion, why not consider signing up as a speaker?

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

Jumping online this morning I noticed this trio of great posts yesterday about Windows Phone 7 and why it hasn't taken off. The discussion was started off by Charlie Kindel, a former Microsoft general manager:

• Windows Phone is Superior; Why Hasn’t it Taken Off?

MG Siegler weighed in on his blog with:

• The Windows Phone Problem in Three Words: Way Too Late

And Robert Scoble posted a comment on Charlie's post that led then to his own post:

• Oh, Charlie, you should have been here for Christmas

The comments on both Charlie Kindel's and Robert Scoble's posts are also worth reading. There were other articles on this theme, but these were the three I found most useful.

As to my own opinion, I'm definitely in Scoble's camp (to which Siegler also agrees):

It's ALL about the apps!

The device formerly known as a "mobile phone" is now a device to access all sorts of services, information, games, Internet sites and to send messages to people... and, oh yeah, it can make phone calls sometimes if you really want it to.

It's all about the apps... and until Microsoft is able to truly foster a strong application developer ecosystem it will remain, like RIM, a minor player in the mobile market.

Image credit: microsoftsweden on Flickr

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

In Aug 2004, we made the Skype Desktop API available to encourage third-party innovation and integration with Skype. The Skype Desktop API allows Partners to access Skype functionality through the Skype desktop client via a text-based command protocol. The intent is not to duplicate Skype functionality but to complement the Skype desktop client with additional features and/or capabilities (e.g., call recording).

This is the API that pretty much all developers have had to use until recently where you application interacts directly with a Skype client. This also means that you have to have a Skype client running to use the API, which has been an additional annoyance for many developers. Developers have long desired an ability to connect directly into the Skype cloud without needing to run a client. Many of us had hoped that "SkypeKit" would be that client-less connection... but it, too, requires a client.

We know, though, from conversations at conferences and events that Skype has been working on developing new APIs... and perhaps this renaming is a precursor to the release of those new APIs. We can only hope... as they have been a l..o..n..g.. time in coming.

The other bit of news was that Skype is now promoting the use of the "plugged into Skype" logo for products using the newly-renamed Desktop API. Previously this program was promoted for SkypeKit products when SkypeKit emerged from beta back in June 2011 . Again from the post:

Plugged into Skype lets Skype users know that the application is built by a partner to work on Skype but was not built by Skype.

There is naturally a page in Skype's developer site (login required) all about how you can use the logo, original image files, etc., etc.

All of this is good to see as Skype, like everyone, is trying to woo developers to build apps on their platform (and add them to Skype's new "App Directory"). Making their program clearer can only help. (And hey, this is only their, what? ... 6th attempt at a developer program? Eventually they may figure it out.)

Meanwhile... is this renaming setting the stage for the release of some new client-less APIs? Let's hope so...

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

Secret iOS business; what you don’t know about your apps

As people have noted in the comments, "iOS" (Apple's operating system for iPhones and iPads) is purely the platform Troy Hunt did his research on... but he's really talking about issues with mobile applications.

I'm my unfortunately sure that these type of issues will also be there on apps on Android and probably on other mobile operating systems from Microsoft, RIM, WebOS, etc.

These are application design issues.

The article starts off with the incredibly inefficient case of stuffing large images from "regular" websites down the mobile pipe to the phone... and then simply "resizing" them with "width" and "height" attributes. This is just laziness"efficiency" on the app developers part in that they are simply "repurposing their existing content" for a mobile audience, i.e. it's too much work/effort for them to create and track a separate smaller image for a mobile environment so they will just send you the larger one and eat up your data plan bandwidth.

But Troy Hunt goes on to talk about far worse issues... he calls out the analytics sent back to Flurry.com in particular (and there are other similar players out there) that report what the user is doing. I agree with Troy Hunt's comment that where this gets "creepy" for me is not so much reporting data back for one application, but rather that all this data is being aggregated across applications inside of Flurry's databases.

And then the truly scary issue of how little security some applications use to protect login credentials (i.e. NONE!) or to protect confidentiality of the information people are seeing.

As Troy Hunt points out with regard to the Facebook app for iOS:

Unfortunately, the very security that is offered to browser-based Facebook users is not accessible on the iPhone client. You know, the device which is most likely to be carried around to wireless hotspots where insecure communications are most vulnerable.

Mobile devices are being brought to the worst possible WiFi environments... and per this article seem to have some awfully insecure apps running on them.

Every mobile developer needs to read this article - and start looking at how to secure their apps!

P.S. Thanks, Troy Hunt, for writing this piece!

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

Yesterday morning I did something I haven't done in eons. Many years, probably. (I can't remember.) I fired off a "rant" on an IETF mailing list.

I've been a huge proponent of the "RTCWEB/WebRTC" work going on in the "RTCWEB" Working of the IETF and the "WebRTC" of the W3C. I've mentioned it in many of my presentations. I've advocated for people to join the mailing lists. I've written about it a good bit on Voxeo's standards blog when I was at Voxeo.

We have an opportunity to make it easy for web developers to add "real-time communications" via voice, video, IM, etc., to web applications. We can make that work from directly within the browser.

Think of it... HTML5 with the ability to quickly add voice, video, chat... and without the need for a browser plugin or extension in Flash, Java, etc. (the limitation of all of today's proprietary options).

It's the opportunity to move real-time communications into the very fabric of the Web.

Awesome potential!

The work has been moving along quite rapidly in both the IETF and the W3C. Extremely active (high-volume!) mailing lists. Many Internet-Draft documents being created. Regular conference calls, interim meetings, face-to-face meetings. Some truly brilliant - and passionate - people involved. (Read the RTCWEB overview Internet-Draft for more background.)

But I still can't escape the feeling that the direction isn't quite right... as a friend said to me:

my feeling is that this is being appoached as SIP 5.6.2 - a minor tweak on an established standard - not WebRTC 0.9 - a new dawn in a new world.

I haven't honestly had the time to read all the messages with the crazy amount of traffic (which is good - shows people are passionate about the topic!), but I've felt increasingly frustrated with reading the messages that I have read that we're collectively in the midst of developing something that few developers will actually use.

So I ranted. Will it do any good? Maybe. Maybe not.

What the rant really needs is to be backed up by people who have the time to join in the process and contribute suggestions for how a RTC API that would appeal to "web developers" would look like.

Care to help out? The mailing list is open to anyone to join.

Anyway here's the rant... (and yes, for the truly pedantic, I am very aware that I ended with a </rant> but did not start with a <rant>)...

NOTE: And, as I suppose must be the case with any good rant, mine was not entirely accurate. As multiple people pointed out (one example), my ending where I ask about whether people would choose the RTCWEB/WebRTC API over Flash/Phono/Twilio/Java/whatever is not entirely on target. The question is really... will vendors creating libraries like Phono choose to use the RTCWEB/WebRTC protocols/APIs or will they continue to use their own proprietary solutions?

As people pointed out, there will be a hundred different JavaScript libraries created (like Phono) that will consume the RTCWEB work... and most web developers will use those libraries and not program directly with the RTWEB/WebRTC APIs and protocols.

Fair enough... but the question remains - will the RTCWEB work make it easy enough for all those JavaScript libraries to blossom?

Others pointed out that I'm really talking about the web API that would be exposed via the W3C's work versus the low-level API coming out of the IETF. And yes, that is perhaps technically true... but the reality is that it is the same set of people working in two different mailing lists... and both efforts are contributing to the end result.

In the end, I want to see a result of all this RTCWEB/WebRTC work that developers will actually deploy and use!

I want open standards to win.

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

Today my friend Alec Saunders, RIM's newly minted "VP of Developer Relations and Ecosystem Development", took to the stage of the Blackberry "DevCon Americas" event in San Francisco to make the case to the assembled crowd. Jim Courtney passed along to me the link to the livecast of the event and I did take a moment to tune in and check it out. (Apparently a recording will be available at some point.)

Alec has a theatre background and is always fun to watch present... he has a certain dynamic energy that is good to see. In the few minutes I watched he seemed very much in his element:

Now, whether he will actually have any success is another question... despite his stats that the BlackBerry AppStore is more profitable for developers than the Android Marketplace, I don't know if the broader world of developers will really notice. From what I see the momentum seems to be elsewhere...

I wish him the best, though... and Alec, when you read this, you can know that some of your friends did enjoy watching the live stream! :-)

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed