Disruptive Telephony

Looking for a New Gig? Consider a Job at the Internet Society!

Interested in a new work role? Looking to make a change from what you are doing now?

If you have a passion for the Internet - and for protecting the openness of the Internet - then please consider applying for one of open positions at the Internet Society. We have several new positions open, including:

• Sr. Manager, Next Generation Leaders Programme
• Internet Development Manager for Africa
• Application Development Specialist
• Sr. Director of Business Development and Resource Mobilization

I'm excited about joining the Internet Society and would love to welcome others onboard!

---

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

---

Is Skype Soon To Release New APIs? Skype Renames Public API And Extends "Plugged into Skype" Partner Program

Today brings two changes from Skype to their developer programs. First, in an effort to bring some clarity to their existing application programming interfaces (APIs), they have renamed the "Skype Public API" to be called the "Skype Desktop API." As noted in a Skype blog post:

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.

UPDATE: Multiple friends pointed out to me that SkypeKit is a bit more nuanced than this. SkypeKit does NOT require a "full" Skype client, i.e. a full working version of the Skype program. It does, however, require a "runtime" component to be running on a local system. It is that runtime (for Linux, MacOS X, Windows) that then makes the connection out to the Skype cloud. While this may not be a "client", per se, it does still require Skype code running alongside your application. Many of us would like to see "web APIs" from Skype that let you connect in to Skype's cloud without any kind of additional required Skype software. It is those kind of APIs to which I am referring in the paragraph below.

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

---

The Creepy - And Insecure - Side of iOS and Android Apps

Want to see the dark side of mobile apps? Just read this great bit of research from Troy Hunt:

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

---

150 Years Ago Today, the USA Got Wired!

A great article in the San Francisco Examiner today about the completion, 150 years ago today, of the transcontinental telegraph here in the United States:

150 years ago, a primitive Internet united the USA

I think "a primitive Internet" might be a bit of a stretch... but then again I'm one of those network people who think of the "Internet" as a "network of networks"... and this first interconnection was really just creating that initial network!

Nuances aside, it's an enjoyable article to read...

I found this an interesting commentary on the disruption of the communication channels that came before:

Indeed, the Pony Express, which boasted it could deliver a letter from Sacramento to St. Joseph, Mo., in the unheard of time of 10 days when it began operations on April 3, 1860, shut down 19 months later — on the same day the transcontinental telegraph went live.

Though dramatic, that was a short-term effect. "But the longer-term effect was we connected the nation in real time. ...," says Fischer. "For the first time, businesses could do business nationally. The government could communicate nationally in almost real time."

Well worth a read to understand the challenges that went into the first physical infrastructure for what would become "telecommunications".

---

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

---

My Rant: Who Are We Building RTCWEB/WebRTC For? Telephony Developers or Web Developers?

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>)...

---

Folks,

I need to rant. I've been lurking on this list from the beginning but with a new job I haven't been able to really keep up with the volume of messages... and every time I get ready to reply I find that others like Hadriel, Tim, Neil, Tolga or others have made the points I was going to make...

But I find myself increasingly frustrated with the ongoing discussions and want to ask a fundamental question:

- WHO ARE WE BUILDING RTCWEB/WEBRTC FOR?

Is it for:

1. Telephony developers who are tired of writing code in traditional languages and want to do things in new web ways;

2. Web developers who want to add real-time comms (as in voice, video and chat) to their existing or new web applications;

3. Both 1 and 2.

If the answer is #1, then I think everything is going along just wonderfully. We can go ahead and use the SIP/SDP/etc. stuff that we all in the RAI area are all used to and understand just fine. Heck, let's just all end the discussions about a signalling protocol and agree on SIP... get the browser vendors to agree on baking a SIP UA into their browsers... and call it a day and go have a beer. Simple. Easy. Done.

And the only people who will ever use it will be people who work for RTC/UC/VoIP vendors and random other programmers who actually care about telephony, etc.

But that's okay, because the people who do use it (and their employers) will be really happy and life will be good.

If the answer is #2, then I think we need to step back and ask -

HOW DO "WEB DEVELOPERS" REALLY WANT TO WORK?

Here's the thing... in my experience...

99% OF WEB DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY!

Never have. Never will. (In fact, I may be understating that. It may actually be 99.99999%.)

If they are with startups, they want to build nice bright shiny objects that people will chase and use. They want to make the next Twitter or FourSquare or (pick your cool service that everyone salivates over). If they are with more established companies, they want to create easy-to-use interfaces that expose data or information in new and interesting ways or allow users to interact with their web apps in new and useful ways.

And they want to do all this using the "languages of the web"... JavaScript, PHP, Ruby, Python, etc.

They want "easily consumable" APIs where they can just look at a web page of documentation and understand in a few minutes how they can add functionality to their app using simple REST calls or adding snippets of code to their web page. Their interaction with telephony is more along these lines:

"Wow, dude, all I have to do is get an authorization token and curl this URL with my token and a phone number and I can create a phone call!"

And the thing is... they can do this **TODAY** with existing proprietary products and services. You can code it all up in Flex/Flash. You can write it in Java. You can use Voxeo's Phono. You could probably do it in Microsoft's Silverlight. I seem to recall Twilio having a web browser client. A bunch of the carriers/operators are starting to offer their own ways of doing this. On any given week there are probably a dozen new startups out there with their own ideas for a new proprietary, locked-in way of doing RTC via web browsers.

Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time communications between browsers.

It can be done today. Now.

The drawback is that today you need to have some kind of applet/plugin/extension downloaded to the browser to allow access to the mic and speakers and make the RTC actually work. So you have to use some Flash or Java or something. AND... you are locked into some particular vendor's way of doing things and are reliant on that vendor being around.

THAT is what RTCWEB can overcome. Make it so that web developers can easily add RTC to their web apps without requiring any downloads, etc. Make it do-able in open standards that don't lock developers in to a specific product or vendor.

But if we are targeting "web developers", that is who we need to satisfy... and we need to understand that they *already* have ways to do what we are allowing them to do.

If we come out with something that is so "different" from what "web developers" are used to... that requires someone to, for instance, understand all of what SIP is about... that requires a whole bunch of lines of code, etc.... well...

... the web developers out there will NOT launch an "Occupy RTCWEB" movement claiming that they are the "99% who don't care about telephony"... they will simply... not... use.... RTCWEB!

They will continue to use proprietary products and services because those work in the ways that web developers are used to and they make it simple for a web developer to go add voice, video and chat to a web app. Sure... they will still require the dreaded plugin/extension, but so be it... the "open standard" way is far too complicated for them to look at.

And all the work and the zillions of hours of writing emails and I-Ds that this group has done will all be for nothing. Well, not nothing... some of the telephony-centric developers will use them. But the majority of the web developers out there may not because there are other simpler, easier ways to do what they need to do.

So I go back to the question - who are we building RTCWEB for?

Is the goal to enable the zillions of web developers out to be able to use real-time communications in new and innovative ways? Or is it solely to make it so that VoIP/UC/RTC vendors can make a softphone in the browser that calls into their call center software?

RTCWEB *can* enable both... but to me it's a question of where the priority is.

The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simple and easy that web developers will choose to use it over Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps?

If the answer is yes, we win. Open standards win. Maybe we upgrade from having a beer to having champagne.

If the answer is no, what are spending all this time for?

</rant>

Dan

---

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

---

Can Alec Saunder Woo Developers Back to the Blackberry Platform?

Can he do it? Can he get developers to actually care enough about the Blackberry / Playbook platform to come and build apps?

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

---

Awesome Comic -> The Bright Side to the Blackberry Outage

A truly awesome way to start my Monday... courtesy of RWW, this great cartoon from Rob Cottingham showing the "bright side" of the Blackberry outage:

Of course, we iPhone owners could have a similar discovery... although whether or not our phone connection would actually work is a different question... (but did any of us truly get an iPhone for the phone piece? ;-)

Great comic, Rob!

---

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

---

It's Official! For Better Or Worse, Skype Is Now Part of Microsoft

And so begins the next chapter of Skype... first it was a scruffy little startup taking on the telecom world... then it became somewhat bizarrely part of eBay... then it went back to a private company owned primarily by Silver Lake Partners... and then... to the utter amazement of so many of us... Skype announced it would be acquired by Microsoft!

And today that acquisition is official. Microsoft announced in a news release and Skype announced in a blog post and video from CEO Tony Bates that the acquisition has formally been concluded.

The deal is done. Skype CEO Tony Bates is now the president of the Skype Dvision within Microsoft reporting directly to Microsoft CEO Steve Ballmer. I found this phrase of the news release to be interesting (my emphasis added):

Microsoft and Skype will remain focused on their shared goal of connecting all people across all devices and accelerating both companies’ efforts to transform real-time communications for consumers and enterprise customers.

My interest was not only in the "across all devices", which has been a large part of Skype's goal for some time... but also in the use of "real-time communications". For a while that was a phrase that only the more technical-minded folks used, but now increasingly "real-time communications" seems to be the phrase of choice for many. I, for one, applaud the usage.

Skype and Microsoft also apparently wanted to be hype-compliant and so they released an infographic with recent stats about Skype. (Everyone seems to need to have an infographic these days, don't they?)

I admit to a degree of sadness that Skype is no longer the independent company that they were. They were always "fun" as a company because they were such the "outsider" that attacked the entrenched telecommunications industry - and succeeded in so massively disrupting the industry!

They've been fun to watch... and a constant source of stories to write about for those of us chronicling the changing communication industry. Somehow I don't think they'll be quite as "fun" or "wacky" as part of such a megalithic company as Microsoft.

Yet maybe that's okay.

Skype's reached a point in its growth where it has disrupted so much of telecom... and it has in fact become a critical communication tool for so many.

On one level they will now have the large-scale support they need, both from a financial point-of-view but also from a "systems" point-of-view. Microsoft does understand the needs of enterprise customers. I would think they will improve the support options... and improve the security reporting features.

Heck, maybe they'll actually put a phone number on Skype's website so that people will stop calling ME! (People still do... had two calls last week.)

More than that, though, Microsoft will give Skype a platform upon which to move into the enterprise. Not only in the potential integration with Microsoft Lync, but just in the "legitimacy" brought about by being part of "Microsoft". Skype is no longer some scrappy little outlaw-or-barely-legal company from somewhere in Eastern Europe who should be dismissed and blocked by IT departments everywhere.

Skype is now a Microsoft product. (with the associated microsoft.com product pages)

Enterprise IT departments understand, support and use Microsoft products... and so Skype may no longer be as dismissed and blocked as it has been. We'll have to see... but the name does help Skype overcome some of those issues.

Microsoft also has its wide array of other products and services... Lync, XBox, Office, Office 365, etc. So many places where Skype could be further integrated.

It will be intriguing to see where the "Skype Division of Microsoft" goes now. I'm pleased for my friends there that the acquisition has closed so that they have at least some degree of certainty of what is happening next. Kudos to all involved in making the acquisition a reality.

Now let's see what happens in the next chapter of the story of Skype...

---

UPDATE: Jim Courtney has a good post up, too: Microsoft Acquires Skype: Deal Closed!

---

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

---

Survey: Only 40% of Canadians Password-Protect Their Cell Phones

Only 40% of Canadian cell phone users password-protect their phones or use other privacy options, a survey by Canada's privacy commissioner found. The results of the 2000-person survey were released in August and written up in a Globe And Mail piece entitled "How private is that text message?".

When I saw the headline, I honestly thought it was going to be something about the security of SMS messages... but in fact it was about the security of the cell phones themselves. If the phones aren't secured then someone can go in and look at your text messages. Ergo... the link-bait title of the article. (And yes, it got me to look.)

Still, it had some interesting data points such as the fact that the users from age 18 to 34 were the ones most likely to use privacy tools, which is good to see, since they are probably the ones pumping the most information out online.

Nice to see, too, that 82 percent did not think police should have access to your online usage info without a warrant.

I was surprised, in all honestly, about the 40% number... I actually might have thought of it being lower as I know MANY people who don't password-protect their phones mostly because of the "inconvenience" of having to enter the password to get into the phone.

And in truth the % who password-protect their phones may be lower... the article says that "only four in 10 people password-protect their phones or adjust privacy settings on personal-information sharing via downloaded applications". The number of people who adjust privacy settings - but don't password-protect their phone - may be driving that % up.

I wonder what a survey like this might find in the United States?

Do you password-protect your phone? (I do)

---

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

---

Voxeo Customer Summit 2011, "Unlocked and Loaded", Launches Tonight!

Tonight I'll be thinking of all my friends and former colleagues at Voxeo as they launch the Voxeo Customer Summit 2011 at the JW Marriott Grande Lakes hotel in Orlando. With the great theme of "Unlocked and Loaded", they have an incredibly packed agenda that will make it truly an outstanding event. Lots of great technical talks mixed in with business talks... some voice biometrics... product announcements... plus a great party and other activities!

Plus the ever geeky and wacky Chris Pirillo as show emcee and Joseph Jaffe providing the keynote talk... it should be a great time for all!

While I'm no longer a Voxeon, I'll be thinking of the crew there and wishing them all the best. It's a big event and will really help the people who attend to learn so much more about building communication applications using Voxeo's platforms and services. Cool stuff!

---

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

---