Disruptive Telephony

After my post yesterday about "Skype for Asterisk" (and the update post) and the potential it allows for SIP interoperability via Asterisk, I've received a few comments that seemed to interpret what I wrote as somehow indicating that the Skype announcement somehow meant that there was new "Skype to SIP" functionality in the "Skype for Asterisk" announcement.

Just to be clear, there isn't any new "Skype to SIP" functionality in the "Skype for Asterisk" piece announced yesterday by Digium and Skype. None.

It is purely a commercially-licensed software module (which most of us speculate will be a binary software module, i.e. we won't be able to actually see the code) that provides two-way connectivity from Asterisk to and from the Skype cloud. Skype users can call into an Asterisk system. Users connected to an Asterisk system can call out to Skype users. Users on the Asterisk system can also call to the PSTN (via what was called "SkypeOut") and receive calls from the PSTN (via what was called "SkypeIn").

That's it. That was the announcement yesterday. Period. End-of-story.

However, the point I was making in my post yesterday was this announcement has the potential to turn Asterisk into a two-way "Skype-to-SIP" gateway. Asterisk - with the "Skype For Asterisk" module installed - could be deployed into a network where it could provide interconnection between Skype users and SIP users.

Let me explain...

ASTERISK INTERCONNECTION EXPLAINED

Asterisk has a large number of "channel drivers" that allow phones and systems to be connected to the Asterisk system via various protocols. These systems include:

• SIP phones, systems and clouds
• Cisco phones and systems (via the SCCP channel driver)
• H.323 phones and systems
• MGCP phones
• other Asterisk systems (via the IAX channel driver)
• the PSTN and legacy TDM systems (using the various hardware channel drivers)

There is also an unsupported UNISTIM channel drivers to go into Nortel systems and various other channel drivers out there. (I know of someone who is using a radio channel-driver to interconnect two-way radios to Asterisk.)

The beautiful part about Asterisk is that you can simply and easily interconnect all these systems because the individual endpoints simply become extensions in the "extensions.conf" file inside of Asterisk. So extensions that use the SIP channel can call in and connect to an extension that uses H.323. H.323 endpoints can call Cisco IP phones. Cisco IP phones can call an IAX softphone (there are some out there). Any of those different types of endpoints can call the PSTN through either hardware cards or through SIP or IAX trunks. Graphically, the pictures looks something like this:

Although perhaps to better depict common scenarios, here's how it could look if you include various options for PSTN connectivity:

DIVING A BIT DEEPER

To dive a bit deeper into Asterisk configuration, when you decide to use one of the various "channel drivers" you essentially perform two steps:

1. Modify the channel driver configuration file
2. Add appropriate extensions or trunk settings to the 'extensions.conf' file.

Now you might be doing this by editing the configuration files directly using your favorite text editor - or more likely these days you are probably using one of the many different graphical user interfaces to do the actual configuration modification. In the end, the config files are being modified in some manner.

For the SIP channel driver, the config file is the aptly named sip.conf and in the file you enter information such as:

• Connection information to a SIP Service Provider if you are doing a "SIP trunk" for PSTN connectivity (username, password, connection details, etc.)
• Connection information to an IP-PBX or application server to which you are connecting via SIP
• Information about the different SIP phones connected to your Asterisk server

Note that you could use the SIP channel driver to connect individual SIP phones to Asterisk; you could connect your Asterisk server to the PSTN via a SIP trunk; or you could do have both SIP phones and a SIP trunk. In fact, you can have multiple SIP trunks. You could connect over to an existing IP-PBX or to an application server that supports SIP. Asterisk is incredibly flexible in the way that you can configure it.

The second step is to configure the extensions.conf file to have use this channel driver. For instance, to make it so that all calls starting with the digit "9" go out a SIP trunk, you might do something like this:

exten => _9.,1,Dial(SIP/${EXTEN:1}@mysipprovider-out,30,r)

To configure actual phones as extensions, you would enter something like this in extensions.conf (taken from the sample file on an Asterisk install I have around):

exten => 6245,1,Dial(SIP/Grandstream1,20,rt)   ; permit transfer
exten => 6245,1,Dial(SIP/Grandstream1&SIP/Xlite1,20,rtT)
exten => 6361,1,Dial(IAX2/JaneDoe,,rm)         ; ring without time limit
exten => 6389,1,Dial(MGCP/aaln/[email protected])

If someone dials one of these extensions, it would then ring the associated phone. Note that for extension 6245 it will actually ring two different phones. Note also that the phones will have to be configured themselves to register with Asterisk, etc.

Now, Asterisk dialplan creation is an enormous subject in and of itself... but this is the general idea. You configure the channel drivers to support connections to either (or both) service providers or endpoints (phones) using the given protocol. You then configure actual extensions or trunk connections in the extensions.conf file.

SO HOW *MIGHT* THIS WORK WITH 'SKYPE FOR ASTERISK'?

Now we don't have any information yet about how this new channel driver would work... but most all of the channel drivers work in a similar fashion. I would expect that there will be something like a skype.conf file that will let you establish what Skype user names are associated with the Skype For Asterisk module. You will probably need to include the login credentials, any restrictions on access (by Asterisk users), etc.

Separately, in the extensions.conf file, you will wind up probably putting in something like this to enable outbound connections:

exten => _9.,1,Dial(SKYPE/${EXTEN:1}@t,30,r)

Or something like that. Now all calls that start with 9 will go out the "Skype trunk".

If you wanted to associate a user ID on the Asterisk system with a Skype ID, you would possibly add something like this:

exten => 6400,1,Dial(SKYPE/danyork,,rm)

Now any calls to ext 6400 on that Asterisk system would go to my Skype ID. You could imagine getting a bit fancier with something like this:

exten => 6400,1,Dial(SKYPE/danyork,,rm)
exten => 6400,1,Dial(SIP/1234,,rm)

which would have the effect of calls to ext 6400 going to both my Skype ID and a SIP phone.

So Skype can just be another way for inbound or outbound calls to enter the Asterisk server - and Skype users can simply be added as extensions on an existing Asterisk server.

Returning to my graphic above (gotta love quick graphics via Skitch!), the picture now looks like this:

The "Skype For Asterisk" module allows two way connectivity into the Skype cloud and also the use of Skype as another mechanism for PSTN connectivity.

SO WHAT ABOUT "SKYPE-TO-SIP"?

The point of my post yesterday was now that two-way Skype connectivity becomes just another channel driver for Asterisk, you have all sorts of interconnection possibilities. As a standalone system, you could connect SIP phones on an Asterisk server out to the Skype cloud.

You can also deploy Asterisk as a "SIP-to-Skype" gateway. You could connect an Asterisk box via SIP to an existing IP-PBX and enable connectivity from that IP-PBX to Skype users. You could even be incredibly stupid (given existing security issues) and connect your Asterisk box directly to the Internet and provide a SIP-to-Skype gateway. (If you aren't aware of the SIP security issues, listen to any of my Blue Box podcast episodes or read the VOIPSA blog.)

If the Skype For Asterisk module delivers the functionality it sounds like it will, there are a whole range of possibilities now available for interconnection between the Skype cloud and other VoIP systems simply by putting an Asterisk box in the middle.

We'll see. All of this is mere speculation until we can actually use the Skype For Asterisk module.

Technorati Tags: skype, asterisk, skypeforasterisk, voip, sip, interoperability

Well, on an inbound call to your Skype username, both your Skype desktop client rings (if running) and your Asterisk IP phone rings. You can take the call using either your PC's Skype software or your IP phone. Similarly, if someone calls your SkypeIn number, both will ring. Further, if someone dials your corporate auto-attendant, and then enters an extension number, it will still ring both your Skype client and your regular IP phone.

His post discusses how you can assign Skype names to Asterisk call queues and then includes this intriguing text:

When asked how Skype IP-PBX gateway appliances are affected by this announcement, Stefan Öberg VP & GM Telecom for Skype said, "The appliances that are out there now have built their solutions on standard Linux client. They've used the public API on that and basically are running many instances of Skype Linux client. Obviously, that's not the way the Linux client was meant to be implemented. So those solutions are not scalable or reliable to the extend that businesses would want them to be. The difference with this solution is that we've built it together to scale and to be reliable."

If I understand this correctly, this has the potential to be huge! As far as I know, all the existing "Skype-to-PBX" solutions use the rather kludgey solution of basically running multiple instances of the Skype client on the system. Each "Skype trunk" is essentially just a separate instance of the Skype client. As Stefan Öberg indicates, there are serious scaling issues with this approach.

However, this has been the only options developers have had! Skype has not - prior to this (if it works how it sounds like it works) - provided any "back-end API" that would let a system interact directly with the Skype P2P cloud. The only API developers have had is the client API that lets them interact with a local Skype client. So that's how all the "Skype-to-X" products have been built.

Does this mean that Skype has exposed some additional API that is available through this Skype For Asterisk product? If so, this could be VERY interesting...

Kudos to Tom for providing the updated information.

Technorati Tags: asterisk, skype, sip, interoperability, voip, telecom

The announcement happened out at Astricon today and TMC's Tom Keating had one of the first posts about it - updated with info from TMC reporters who are at Astricon. Both the Digium news release and the Skype blog post highlight these four points that Asterisk users will be able to do:

• Make, receive and transfer Skype calls with multiple Skype names from within Asterisk phone systems, using existing hardware.
• Complement existing Asterisk services with low Skype global rates (as low as 1.7€¢ / 2.1US¢ per minute to more than 35 countries worldwide).
• Save money on inbound calling solutions such as free click-to-call from a website, as well as receive inbound calling from the PSTN throughcreate virtual offices all over world using Skype’s online numbers.
• Manage Skype calls using Asterisk applications such as call routing, conferencing, phone menus and voicemail.

I want to focus on one part of the first bullet. Recall that in my last post about Skype and SIP interoperability I talked about how Skype currently has one-way connectivity via SIP to external SIP clouds. A SIP system can receive calls from a Skype user, but cannot make calls into Skype's cloud. (My employer Voxeo's application platform is one example.) Yet here's the first bullet of the announcement:

• Make, receive and transfer Skype calls with multiple Skype names from within Asterisk phone systems, using existing hardware.

Ta da... two-way connectivity in and out of the Skype cloud.

What's more, because Asterisk is really a telephony platform that speaks multiple protocols, you could easily see the ability to interconnect into other systems... including SIP clouds. Here's a quick graphic showing how it could work:

I changed the color of the arrows to and from the PSTN to reflect the fact that PSTN connectivity could really occur from either the Skype cloud or directly from the Asterisk system. Conceivably you might have an Asterisk system with existing PSTN connectivity (through either hardware cards or SIP or IAX trunks) that only wants to use the Skype For Asterisk channel driver to communication to/from Skype users. On the other end, Asterisk can connect to systems running the protocols of SIP, H.323 or SCCP (Cisco Skinny), as well as whatever other protocols Asterisk sysadmins might add to their Asterisk box. They could be on-premise systems such as IP-PBXs or they could be hosted systems or "clouds" of network connectivity.

Now what is really being announced today is that you can register to join the beta program for Skype For Asterisk. You cannot download the code yet. You can't inspect it to see how it works. All we can do is speculate and sign up to join the beta program (which, it indicates, may involve an NDA).

Still, it's an interesting move and it will be intriguing to see how this actually works.

I'd like to understand, though, how this is or is not similar to what has been offered by Chanskype for a few years now. Is this the same code? i.e. did Skype buy or obtain the Chanskype code or team? Given the lack of any info in that regard in these announcements, I'm inclined to think it is separate code.... but how does it compare?

We'll have to see as the code becomes available. Tom Keating did say in his post that it will not be available as open source code but rather under a commercial license.

In the meantime, congrats to both the folks at Digium and Skype for making this happen - and I look forward to seeing it in action.

Technorati Tags: voip, skype, asterisk, sip, telecom

Odds are that if you are an IM user like me, you probably don't. Why not? Simple... we've unified the IM services on the client side and basically stopped caring about the various services and protocols.

I was reminded of this fact this morning when I received a message saying that an update was available for Adium on my Mac that solved a really annoying disconnection problem with Yahoo!Messenger. (And if you are a Yahoo IM user, you really need to get the 1.3.2b1 beta.)

[NOTE: An equivalent to Adium for Windows or Unix/Linux users is Pidgin.]

Somewhat ironically, there was a discussion going on in a Skype groupchat in which I participate about the various IM protocols and whether anyone really used GTalk, etc. Since I was updating Adium at the time, I took a moment to look at all the different protocols that Adium now supports... as seen in the screenshot on the right side of this post. If I look at my own usage, I use Adium to unify:

• AIM (two accounts)
• MSN/Windows Live Messenger
• Yahoo!Messenger (two accounts)
• Google Talk
• Jabber (two more other than GTalk)
• LiveJournal
• Facebook
• Bonjour

It's a beautiful thing.

Now you might say... so why do you have all these services, anyway? Well, I've been online since the mid-1980's and generally my work has always involved keeping up with new technology, so I've always dabbled in various services and slowly you develop this accretion of new IM accounts - each that different friends and others use. At one point I did run multiple clients but now just for my own sanity I use just one IM client (actually two, but more on that below).

THE ENTERPRISE ANGLE

The curious aspect that caught my attention was the support Adium has for enterprise IM systems. The list directly includes Lotus Sametime and Novell GroupWise. Jabber support can of course work with internal Jabber servers and SIP/SIMPLE support could work with platforms supporting SIMPLE. Does that include Microsoft OCS? I don't know, but it would be interesting if it did.

What's great about all this is that you again have a single IM client that lets you have a single directory for corporate contacts as well as personal contacts. Adium's interface nicely lets you have a single entry for a person with multiple IM contacts, so you can unify your directory to be able to reach people in different contexts.

THE DOWN SIDE

The down side of a single client is that of course you are in the old "jack of all trades, master of none" scenario. You can receive IM messages from all the various services. You can send IM messages to them. But you can't necessarily use all the features of the given service. You have one set of status states, which may or may not map to all the status states available on your service (for instance, maybe the IM service has a status "out for dinner"). I haven't tried it with recent Adium builds, but in the past when I wanted to do an encrypted Jabber session, I had to switch to using Psi. I haven't tried file transfer using the various services via Adium, so I don't know how that works. I'm not aware that voice and video works over those services via Adium. Each IM service tries to differentiate with unique features - and they aren't always supported by all-in-one clients like Adium.

The other down side is "status messages" or "mood messages" that you can set in the IM clients. I have absolutely no idea what my status message in GTalk is, for instance, because I never use it in its native form in a web browser or as a standalone client. I have no idea what my MSN advisory message is for the same reason. Now maybe there's a way to set that in Adium which I don't know about... but maybe not. It's the price you pay for using a unified client.

Now, on the plus side, you never see the ads that IM services wrap their own IM clients in. (Which of course is a down side for the service provider.)

THE MISSING IM SERVICE

If you look at that long list of IM services with which Adium can interconnect, there is one obvious glaring omission:

Skype

When I wrote earlier that I actually have to run two IM clients, it's because Skype does not allow Adium (or other all-in-one IM clients) to interconnect to its network. So I run two IM clients:

• Skype to IM with Skype contacts
• Adium to IM with contacts on all the other services

Now the reality is that I can't see technically how a client like Adium would join into the P2P clouds that make up Skype groupchats. Skype's P2P architecture is very different from the server-based architecture of all the services listed above. So it may be that such an interconnect may not be possible for group chats... and since I use those extensively, I might always have to be running the Skype client natively. Still, there might be a way to interconnect via SIP/SIMPLE... and perhaps that's something Skype will consider as part of the larger Skype interconnect issues.

SO DO WE CARE ABOUT IM PROTOCOL WARS?

I don't. I've opted out of the battle by using a unified IM client. Sure, I may lose out on some of the unique features of the different services... but I have one directory and one way to send and receive IM messages.

What about you? Do you use a unified IM client like Adium or Pidgin? Or do you run multiple clients? Or do you only use one service?

P.S. Walt Mossberg over at the Wall Street Journal had a post on this issue reviewing some other clients back in August.

Technorati Tags: im, adium, pidgin, yahoo, googletalk, aim, skype, jabber, collaboration

Now, being an advocate for a more "open" mobile Internet, I was pleased to see this:

Verizon Wireless’ new Month-to-Month agreement gives customers the freedom to purchase new devices at full-retail price, or use their own CDMA devices without the commitment of a one- or two-year contract. Additionally customers can terminate their agreement at the end of any month without paying an Early Termination Fee.

Not the "full-retail price", naturally, but the ability to simply end the agreement at the end of the month and to use any CDMA device.

The caveat to the ability to "bring your own phone" is that while it is good to see from a "freedom/choice" point-of-view, the reality is that really the only CDMA carriers in North America are Sprint and Verizon so the odds are that you have bought your phone from one or the other. I suppose this does make it so that Sprint users can easily move over to Verizon's network. Will this also encourage a market for third-party CDMA handsets? It will be interesting to see.

In the end, any steps that give consumers/users more choice of endpoints and the freedom to move carriers is, to me, a good thing and so it's great to see this move by Verizon.

Technorati Tags: verizon, cdma, sprint, wireless, mobility

Predictably, the blogosphere is buzzing with posts and articles.

I expect, quite honestly, to be a bit underwhelmed by the initial launch... after all, Android is still evolving. We'll see - the fact that stories are out that Amazon is launching a DRM-free music service along with the Android phone is certainly an interesting dynamic.

Today's launch aside, the launch of Android is really the next step in the ongoing discussion about what the future of the mobile Internet looks like. Will it be controlled by only the carriers? Or will we as consumers have the freedom and choice to use the apps we want? Android holds out that potential - if the carriers let it be used that way. This morning I recorded a short video on the subject:

If you would like, please do join us on today's Squawk Box at 11am US Eastern time to discuss what all this means. Undoubtedly I'll be writing more on this here as will others across the VoIP blogosphere in the weeks and months ahead. We are definitely living in VERY interesting times!

Technorati Tags: google, android, mobile, wireless, voip, internet, future

In the middle of last week, there was quite a little storm raised in the VoIP corner of the blogosphere after Andy Abramson published a letter from Gizmo Project founder Michael Robertson critical of Skype's openness after Skype continued to call upon the FCC to open the wireless network to applications. (See also here and this Skype blog post (and this one) for background.) Being at ITEXPO last week, I didn't have the chance to blog about this at the length I felt it deserved until today.

First, for some context, here are some of the blog posts last week:

• Andy in VoIPWatch: Gizmo Project's Michael Robertson Sounds Off
• Phil Wolff asks some pointed questions (of Michael) at Skype Journal: Michael Robertson says Skype should open to Gizmo Project
• Phil posts: Michael Robertson Responds where Michael responds to Phil's questions
• Andy responds: For the Record, Gizmo vs. Skype
• Alec Saunders had a whole cast of characters on Friday's SquawkBox, including Andy, Michael Robertson, Jim Courtney (Skype Journal) and a good number of others.
• Phil posts: A few thoughts on Skype interop tradeoffs

All of it makes for good reading. It's an important issue.

So I guess I'm somewhat of two minds on this issue.... while I agree with some of Michael Robertson's points, I guess I see the whole issue of "Skype openness" as quite orthogonal to the larger issue of open wireless spectrum. I'll write about both issues at some length below.

This is long. Don't plan on reading it on a crackberry or iPhone. Best get a cup of coffee and read it on a laptop or something like that.

To put it another way, I completely applaud Skype's letter to the FCC and think that the battle for opening up the wireless networks is probably the preeminent "battle" we who are advocates for an open Internet have before us. The wired carriers are well on their way to being commoditized big, fat, dumb pipes. The telcos started selling "data lines" and then soon the world of IP wound up increasingly removing them from the picture as anything other than a big pipe... and that's not the world they want. They are fighting (and will continue to fight) to retain relevance (and ARPU - Average Revenue Per User) but the IP train left the station a long time ago and the telcos are scrambling to catch up and stay on board rather than just being (some of) the providers of the track.

On the wireless side, not only do the carriers own the track, but they still own the train and they are still driving that train. They control who gets on and off... how fast or slow it goes... what color the train is, etc.

I, for one, don't want that. I want them to give us a solid set of tracks to use... but I want the train to be open to all. I want the wireless carriers to be big, fat, dumb pipes. I want choice. *I* want to be in control.

The carriers naturally don't want to relinquish this control. They see how they missed it on the wired side. They want to keep the wireless walled gardens for as long as they can.

The cracks are appearing... Apple's control over the iPhone and AppStore is a phenomenal crack in the telco walls...... although it ultimately really means exchanging the walled gardens of the telcos for the bright shiny walled garden based in Cupertino, CA. I'm not sure that ultimately is the best for all of us... but it does crack the telco walls. I think Google's Android has more potential... but we'll have to see later this month when those phones first come out.

So with that view, you can expect I applaud Skype's efforts to open up the wireless networks and allow consumers to have a choice of what apps they want to run. I want the *wireless* carriers to be big, fat, dump pipes... give me an IP address on the *mobile* Internet and let me do what I want with it. Sure, the carriers can offer their own services, and maybe if I like them I'll pay for them.... but I want the option to use other products and services - without degradation or prioritization...

To put it another way, I pay the wireless telcos for *dialtone* now. Once connected, I can call anyone and use any *voice service* over the PSTN. I could use someone else's voicemail if I want (like GrandCentral), although the carrier's offering may be more convenient (and is usually free). But I can call anyone on the PSTN and use any voice service I want. The carriers just provide me dialtone.

I want "IP dialtone". I want a Big, Fat, Dumb Pipe.

So... go, Skype, go!

Yet having said all this, I agree with Michael Robertson that Skype's got its own issues with openness.

I don't like walled gardens. Period. End-of-story.

I don't like telco walled gardens. I don't like Apple's walled garden. I don't like Facebook's walled garden. I didn't like the walled gardens of CompuServe, AOL, Prodigy, Genie, etc. and I rejoiced over time when the open standards of IP tore down those walls and brought about the Internet (with all of its warts) that we have today. [Tangent: I do worry, actually, that we are retreating a bit back into the walled garden world with things like Facebook and Myspace... but that's another topic I've blogged about.] I can somewhat see some value in walled gardens during the early stages of a product or technology as it reduces the set of parameters/variables and allows the service to be stablized/fixed/improved. But at some point the walls need to be reduced/eliminated. As a security guy, I don't like monocultures... I don't like homogenous systems (where one virus or issue could wipe out the whole system)... I like diversity... heterogenous systems. I don't like single-points-of-failure. I don't like single companies (or small sets) in control. I don't like walled gardens.

I don't like Skype's walled garden.

The PSTN run by the telcos of today does not provide the rich communication experience we want. We need to bypass it and leave it behind and build the massive interconnect of IP communications systems. Players like Skype have a key role in my opinion in building that new infrastructure.

But if we exchange the current PSTN walled garden controlled by the telcos for a new walled garden controlled by eBay/Skype, have we really gained anything?

Sure, it gives us a rich, multi-modal user experience. Sure, it's nice and pretty. Sure, it gives us a central user directory. Sure, it gives us wideband and encrypted audio. Sure, it's cool and all... but it's still a walled garden controlled by a single company.

Ultimately, I would like to see a new voice infrastructure that consists of many different "clouds" all interconnected and able to communicate between the clouds. Skype is one cloud. So are the SIP clouds being run now by various carriers. So are the Voice-over-IM clouds like MSN, AIM, etc. (that try vainly to compete with Skype). So are the various systems being built by vendors all over the place (including all the Microsoft OCS clouds starting to appear within enterprises).

We need to build the interconnect.

Yeah, there are a TON of issues out there that we still need to address to build that interconnect. There's a whole host of security issues... there are billing issues... there are trust issues... there are network plumbing issues. Yes, there are all those issues. But if we are to succeed in ultimately bringing about the rich communication experience we want, we need to make this happen.

And for that, Skype's walls need to come down.... at least a bit.

What we need is that Interconnect from Skype's cloud out to the emerging IP infrastructure. Think about it... Skype right now has a two-way interconnect between Skype's cloud and the cloud we know as the PSTN. It's called "SkypeOut" and "SkypeIn" (or whatever marketing names they are being called now). If you dial my SkypeIn number, you can reach me on Skype wherever I am. From my Skype client, I can call anyone on the PSTN. The two-way interconnect is already there.

So why not offer the same on the IP side?

Because I work at Voxeo and we were one of Skype's original Voice Services partners, I already know that Skype has a massive SIP infrastructure on the backend to do the the PSTN interconnect. Skype users can even dial a specific +99 number and the call goes from Skype's SIP cloud over to Voxeo's SIP cloud... and it works beautifully.

So one half of the interconnect is already there - although only for limited numbers of partners.

But where Skype already has the infrastructure, why not look at making that capability more accessible? What if someone in Skype could just type "sip:[email protected]" and the call would go out from Skype's cloud to the service providers? This could be a new feature as part of the unlimited calling plans, etc.

How many people would use it right now? Probably only a tiny few... today. But suddenly Skype becomes an enabler of the broader post-PSTN infrastructure. New companies can get their services up and running knowing that they can promote them to Skype users and have Skype users get to those services.

Plus, Skype can now connect to all those enterprise VoIP systems being deployed everywhere... so for all those IT managers blocking Skype now but allowing SIP gateways for remote teleworkers using IP phones... Skype can suddenly be that remote softphone being used in the sense that it could connect in to other people on the corporate enterprise system - they just become "sip:" entries in my Skype directory. Skype still is my overall directory and user agent.

And what about the other way? Wouldn't it be great if someone out there on a SIP system could just call something like "sip:[email protected]"? The call goes from their SIP cloud across the Internet to Skype's SIP gateways and into the Skype cloud.

The SIP system user can do this right now... via my SkypeIn number... but they have to use the crappy PSTN. Why not ditch the PSTN and go directly across the IP infrastructure? Hey, maybe some user of a "HD Voice" Polycom phone could call Skype's gateways via SIP and actually wind up talking via wideband audio? (Yeah, okay, I'm probably dreaming on that since Polycom supports G.722 for wideband and Skype uses its SVOPC codec.)

I personally would probably wind up using my Skype client more for a simple reason that I have a SIP IP phone on my desk... but I'm not at my desk all that much. Wouldn't it be great if I could forward that to the SIP URI of my Skype client? (Which I can do now by forwarding to my SkypeIn # but again I'm going across the crappy PSTN.) Or better yet because I have a SIP URI for Skype it becomes one of the various phones I ring when someone calls that number (it's not, now). The number on my business card would then wind up actually going to my Skype client.

Suddenly Skype can be a player in the enterprise "unified communications" market. People don't need Skype-to-PBX gateways or sacrifice chickens and utter weird incantations to get Skype connections working with open source VoIP systems. Skype users can talk to Microsoft OCS systems... or Cisco IP PBXs... or Avaya's or Nortel's or Mitel's or ShoreTel's or... or... or...

What if... even... I could do a SIP invite to make a video call to another system? (Okay, so now maybe I'm really dreaming...)

Suddenly people (like Michael Robertson) have fewer reasons to complain. Sure, the Skype client still uses it's own proprietary protocols and codecs for communication within the Skype cloud... but you can interconnect.

Suddenly Skype is a leader in building the broader overall next-generation IP communications system. Skype's not a walled garden but rather a player in the larger picture.

Sure, there's a whack of issues involved with doing this. On the technical side, Skype has got to build SIP gateways that could deal with the abuse they would undoubtedly suffer by being exposed on the public internet (like any or all of the VoIP security tools out there). They have got to make sure such gateways don't become a way to inject spam/SPIT into the Skype network. Skype has got to figure out how to package it... potentially charge for it, etc. And they have to deal with all the glorious interoperability issues that come with SIP... as the protocol increasingly becomes an unmanageable accretion of all sorts of crap. (And I say that as an advocate for the SIP protocol.)

Ultimately, I think that's the kind of openness Skype needs.

Skype needs to provide the same two-way interconnect to the evolving IP communications infrastructure (that is almost all becoming SIP-based, for better or worse) just as Skype provides the two-way interconnect to the PSTN.

Build it and Skype would silence many of the critics of Skype's lack of openness[1] and give Skype a (much-needed, IMHO) hype-boost among the early adopter crowd who also plays with all the other emerging tools. It would be a bold move that would also help Skype gain some credibility and recognition within the larger industry. In my opinion, outside of the technical issues it would go far in so many ways in helping Skype grow - and helping the industry grow.

Will Skype get there? Good question...

[1] Not all critics would be silenced naturally because someone would still complain that they can't connect their particular client to the Skype P2P overlay network. Or that they can't connect XYZ hard phone to the Skype cloud, etc., etc. But it would silence many of the critics of Skype as a "walled garden".

Technorati Tags: skype, sip, net neutrality, open, openness, voip, voice, telecom, telecommunications, gizmo, interop, interconnect

Voxeo will also have a booth and I expect to be there. I'm also doing some video interviews and other media work (actually on both sides of the camera). I'm looking forward to catching up with a good number of folks out at the show.

If you read this blog and are out there at either the Communications Developer Conference or ITEXPO, please do come by and say hello. I posted the schedule of talks over on Voxeo's blog site. You should be able to find out more about where precisely I am through either twitter.com/danyork or twitter.com/voxeo.

Technorati Tags: conferences, voip, itexpo, communicationsdeveloperconference, los angeles, dan york, voxeo, danyork, cloudcomputing, sip, sip security, voip security

In heading out the Communications Developer Conference/ITEXPO next week in L.A., the show organizers have already told me there is no free WiFi access at the LA Convention Center... but I can, of course, pay for the access through the local provider. (And probably deal with the same usual headaches of getting adequate signal strength.)

I am so incredibly sick of show WiFi, both in terms of paying for it and also just in quality, that yes, indeed, even though I am a cheap Yankee... er... "frugal", I think I need to suck it up and pay the $720/year to have wireless Internet access over the cell networks. This will also be hugely beneficial for all the wonderful times I spend hanging out in airports.

My choice seems to be either Sprint or Verizon. (AT&T and T-Mobile don't have great coverage in my area.) Both will cover whatever limited roaming I do in my local area... and both have coverage in the major cities I tend to travel to. I've seen both used on the Amtrak train down to New York. They both charge ~$60/month... they both charge $50-100 for your actual broadband access card. They both require a 2-year contract (or reference a 1-yr but then your hardware costs go up.) And they both seem to have 5GB monthly limits (on-network).

On the actual hardware, it seems that I can get either a USB dongle or an ExpressCard. The USB is interesting in the sense that I can plug it into virtually any computer and use it. But the ExpressCard version looks interesting because: 1) I don't use that slot currently for anything else (whereas I do plug things into the USB slots); and 2) it looks like a smaller external form factor, i.e. there's less sticking out of my laptop.

So my questions for you all, dear readers, are these:

• Have you seen any great reason to prefer Sprint or Verizon?
• Do either one work better with the Mac? (my laptop these days)
• Do either work better than the other inside of buildings like convention halls? (I'm imagining neither one works great.)
• Any suggestions of the USB dongle over the ExpressCard card?

Any advice or recommendations is definitely welcome... I'll probably be picking one of these up in the next couple of days. (Thanks in advance!)

Technorati Tags: wireless, connectivity, broadband, sprint, verizon

It was an enjoyable call (I was listening) that went for about 45 minutes. Jonathan spoke about how and why he started the company, about the new release of Prophecy 9, the acquisition of Micromethod, our recent financial results and much more. I think you all will find it a great introduction to what Voxeo is all about.

11 months later, I'm still extremely glad I made the choice to join the company...

Technorati Tags: squawkbox, voxeo, voice, voice applications, voip