Disruptive Telephony

NOTE: I have a few updates to the post that I am putting at the bottom of the text.

---

Would you like Skype users to be able to call your business' phone system? Would you like to connect your phone system to Skype's network and make use of their cheap calling rates? If you have an IP-PBX or other call server that supports the Session Initiation Protocol (SIP), you may now have those options.

For a company that only a bit over a year ago was saying that customers weren't asking for interconnection, today Skype has done something rather dramatic and lowered their walls a bit more with the announcement of the beta program of "Skype For SIP". With this announcement from the "Skype For Business" group, companies with SIP-enabled phone systems will be able to receive calls from Skype users - and make calls using Skype's network at Skype rates. The news release (and blog post announcement) highlights these four aspects:

• Receive and manage inbound calls from Skype users worldwide on SIP-enabled PBX systems; connecting the company Web site to the PBX system via click-to-call
• Place calls with Skype to landlines and mobile phones worldwide from any connected SIP-enabled PBX; reducing costs with Skype’s low-cost global rates
• Purchase Skype’s online numbers, to receive calls to the corporate PBX from landlines or mobile phones
• Manage Skype calls using their existing hardware and system applications such as call routing, conferencing, phone menus and voicemail; no additional downloads or training are required

Let's take those one at a time - and then take a look at some details and what's missing.

[NOTE: For the ease of writing this post I am going to refer to the SIP system as an "IP-PBX", but it could be a "call server", "call manager", "application server" or anything else than can send and receive SIP signaling. It could be open source or commercial - that doesn't really matter.]

---

INBOUND CALLS FROM SKYPE USERS

In a pre-announcement briefing, Chris Moore, a senior product manager at Skype, indicated that when the "Skype For SIP" service is fully released, the current "Business Control Panel" will be revamped a bit and will have an area where you can sign up for the service, identify your IP-PBX and associate one or more Skype names with your IP-PBX.

Calls from Skype users to those Skype names would then be routed across the SIP connection to your IP-PBX, where the IP-PBX would deal with those incoming connections exactly as it would any other incoming SIP connection. Call routing will be handled in the IP-PBX. Perhaps the incoming call will go to an auto-attendant, IVR, call-center software or other application. Perhaps it will be routed to a person. From the IP-PBX point-of-view, it's just another incoming call.

From a Skype users point-of-view, they are simply calling another Skype ID. It's a free call that seems just like any other Skype call.

You will, Moore stated, be able to associated multiple Skype IDs with your single SIP connection. Now I'm not sure what kind of call info you get across the SIP connection, but if you do get to see the Skype name the person is calling you could do some interesting call routing based on the Skype ID called. For instance, if someone made a Skype call to "companyname-help" it could be routed one way and calls to the Skype ID "companyname-sales" could go another way.

In any event, this aspect of the service makes it so that any Skype user can call your IP-PBX.

SIP TRUNKING, SKYPE-STYLE

The second aspect of the "Skype For SIP" service is that you can use Skype's global network for connections out to the PSTN... what we have been generically calling "SIP trunking" for some time now. As part of the Business Control Panel registration you will apparently indicate which Skype ID is to be charged for outbound calling (what we used to call "SkypeOut") and then any outbound calls via SIP will be charged to that account.

Effectively, Skype just opened up cheap international calling to businesses everywhere using Skype's cheap rates.

The already crowded "SIP trunking" market just got another big player. Configure your IP-PBX to send calls out across Skype's network to the PSTN... and start calling. Right now the plan as I understand it is that you would pay the regular SkypeOut rates, without the subscription plans that are available to individuals. Skype's Moore did say that they may evaluate some form of plans during the beta period. As we see all these various details, we'll have to see what impact this will have on the existing players.

ESTABLISHING PHONE NUMBERS AROUND THE WORLD

The third aspect of the announcement is that you can establish phone numbers around the world that will route to your IP-PBX via the Skype For SIP connection. Since, as I mentioned above, you are associating one or more Skype accounts with the SIP connection to your IP-PBX, you can also associate the "Online Numbers" (what we used to call "SkypeIn" numbers) of those Skype accounts with your IP-PBX.

So if you want a phone number in one of the 20 countries where Skype currently supports Online Numbers, you just buy the number for one of the Skype accounts connected to your IP-PBX.

For $60 per year per online number.

Not a bad deal if you want phone numbers in other area codes or other countries that will ring your business' phone system. Again depending upon what kind of caller ID and called ID info you receive, some interesting call routing might be possible.

(This assumes, of course, that Skype keeps the current pricing for Online Numbers and doesn't charge any additional costs.)

USE EXISTING HARDWARE

Skype's point here is really just that there's no additional software... it's just an inbound SIP connection to your IP-PBX that you deal with in the same way that you deal with all other inbound SIP connections.

---

COMMENTS/CONCERNS

Based on the conversations I had with folks from Skype about this new service, I do have a couple of comments and concerns:

SECURITY

Yes, okay, you would expect this of me. Obviously we'll have to wait to see the implementation, but it sounds like Skype has thought this through a good bit. They'll support the standard SIP digest authentication, but more interestingly they will support restricting connections based on IP addresses. If your IP-PBX - or more likely the SIP-aware firewall or SBC or edge proxy - has a fixed address you will apparently be able to enter this in and use that to limit inbound SIP connections. Skype also indicated that when they service moves out of beta into full production they intend to support TLS-encrypted SIP as well.

Similarly, on the media side the beta will support regular RTP but Skype is looking to support SRTP in the full production release.

CODECS

In a somewhat bizarre move (to me), Skype is initially releasing this in the beta program with only support for the G.729 codec. For those who don't follow audio codecs (used to encode the audio of your voice to send across the network), the G.729 codec compresses audio and results in lower bandwidth usage. It also, unfortunately, requires the payment of royalties which typically then require the purchase of additional licenses from the IP-PBX vendor. (This is true even in the case of Asterisk, where you can purchase G.729 licenses from Digium.)

Given that the very people likely to want to use Skype's services for low-cost calling are also the same people who are probably not going to pay for G.729 licenses, it seems that there is a bit of a disconnect here.

The good news is that the folks at Skype say that they are going through the testing to make the much more widely used (and royalty-free) G.711 codec available and expect to have that ready within the first couple of weeks of the beta program.

On the wideband side, Skype folks indicated that at the point in time where there are SIP endpoints that support the SILK codec, which Skype recently said they will make available in binary form for free, those SIP endpoints should be able to make and receive calls to/from Skype users with wideband audio.

(I'll just note that Skype's rationale when I asked them about why G.729 vs G.711 was that they currently use G.729 with all their many SIP termination providers and so using that codec just seemed to make sense to them. For someone with the high volume of calls that they have who are looking to send as many as possible over limited bandwidth, that probably does make sense. However, in this era of more and more available bandwidth, I've seen many people, especially on the SMB side, less concerned about conserving bandwidth and just using G.711.)

SIPconnect

I was pleased to hear Skype's Moore mention that they are looking at specifications like the SIP Forum's SIPconnect initiative as a way to help with interoperability from premise IP-PBX's out to Skype's service. Having been peripherally involved with SIPconnect, this is exactly the kind of situation that it's trying to address (interop between a premise SIP system and a SIP Service Provider). It would be great if Skype would formally get behind that initiative. (I can see certain SIP Forum people typing email as soon as they read this... ;-)

OUTBOUND *TO* SKYPE USERS

It's interesting to note what this release does NOT have - the ability to call from your IP-PBX out to a Skype user. You can call out to PSTN numbers via the SkypeOut connection... but you can't call a Skype ID. This isn't surprising, on one level, because this is a MUCH harder problem to solve. Basically every SKYPE ID would need a SIP address (a "SIP URI" in SIP-speak) that the IP-PBX could use to connect.

Several of us (myself included) have been asking for that kind of interconnection for years - and perhaps at some point we'll see that. Meanwhile, this "Skype For SIP" release gets us closer.

---

SOME CLOSING WORDS...

Over the years, I have written a good deal about Skype on this blog - and I have certainly been critical of Skype's closed network in the past (such as here and here). I don't like "walled gardens" in general and Skype has definitely had high walls.

That's certainly changing. I've definitely been pleased to see what they started last fall with "Skype For Asterisk" (which I wrote about here, here and here).

And now... "Skype For SIP".

If Skype implements this well, I think there is great potential. Suddenly, the millions and millions of Skype users are able to call your phone system... just via Skype. Forget dealing with long-distance or international calls. Just have someone use Skype to call your Skype ID.... ta da, it winds up on your corporate phone system via SIP. Similarly there is now the ability to easily project your presence geographically with phone numbers in different regions or countries - all through Skype's easy UI. Let alone the SIP trunking via Skype's network.

Granted, you can get the phone numbers and trunking through existing SIP service providers today. Skype just makes this a bit easier because they have the existing programs, user interfaces, etc.

Skype For SIP isn't perfect - it still doesn't get me the outbound calling to Skype users that I want - but it's definitely a step in the right direction as we continue building the interconnect between all these IP communications systems. (See my rant here and my Park Bench Manifesto presentation out at eComm)

Kudos to the folks at Skype for taking this step. For lowering their walls a bit more and letting others connect in. I definitely will look forward to seeing what evolves out of this.

Meanwhile, of course, I'll be heading over to skypeforsip.com and signing up for the beta program. :-)

---

UPDATE #1: (a few minutes after posting) Two items:

• GigaOm has a post up that I'm sure will attract some good comments
• The skypeforsip.com website is apparently not live yet (oops!) but will be soon. The skypeforsip.com is now live and accepting applications for the beta program

UPDATE #2: (6 hours later)

• Moshe Maeir disputes my characterization of G.729 and says most of his customers use it.
  
  
• Phil Wolff over at Skype Journal came out with his contrarian piece: Skype For SIP: Big Money, Skypeless, Brand Destroyer that argues that Skype For SIP is a negative thing for Skype. I disagree with a number of Phil's points (and would note that some of his info relates to the SFS *beta* versus the full announced release (such as the 1 Skype ID only limitation), but it's definitely worth a read.
  
  
• Phil does make the point, reinforced in the SFS beta application, that during the beta you can only have one Skype ID associated with your Skype connection. Per the beta application, it also needs to be a "temporary" one, i.e. you may not be able to continue using that after the end of the beta period. Chris Moore at Skype indicates that this has to do with different Terms of Service and EULAs for business users right now versus regular Skype users and they are looking to rationalize all of that before the full product launch.

UPDATE #3:

• Jason Goecke has a view that the release of Skype For SIP greatly reduces the value of Skype For Asterisk.

UPDATE #4:

• Rich Tehrani thinks that Skype should just call a spade a spade and refer to SFS as "SIP trunking", which is what we in the industry would certainly call the PSTN connectivity side of what Skype is offering. I think, though, that as much as we use that term, it is not widely used outside of our own industry. So as Skype seems to promote itself to the larger business audience, it makes sense to speak of it more openly as "placing calls", etc.
  
  
• Irv Shapiro over at IfByPhone weighs in on "Why Skype for Asterisk is more important than Skype for SIP". Irv believes because SFA lets out make outbound calls TO Skype users it is ultimately more important than SFS. I agree with Irv that SFA definitely has advantage and value because of this.

---

If you found this post interesting or useful, please consider either subscribing to the RSS feed or following me on Twitter or identi.ca.

---

Technorati Tags: skype, sip, standards, voice, voip

The 74th meeting of the Internet Engineering Task Force (IETF) starts Monday morning out in San Francisco. As usual there is a packed agenda with a lot of great discussions going on. This one is particularly interesting for those of us involved in the "Real-time Applications and Infrastructure (RAI)" area - which is all the various working groups related to SIP and other real-time communications protocols - as there are some proposals moving forward to rather fundamentally restructure the ways in which SIP-related work moves through the IETF. I expect there will be many involved conversations going on out there next week.

As much as I would like to be there, I won't be physically out at IETF 74. It's not my new role at Voxeo keeping me away, but rather this... oh... wee minor little detail that my wife is now five weeks from giving birth to our second child! :-) At this stage of things I'm severely limiting my travel - and flights across the country are definitely out.

Instead I'll be participating remotely, listening to the audio streams and joining in the Jabber chat rooms. Probably writing about some of it over on the "Speaking of Standards" blog I write in from time to time. The great thing with IETF meetings is that you can participate remotely (albeit obviously not to the same level of effectiveness as being in the room).

Lots of good stuff going on...

---

If you found this post interesting or useful, please consider either subscribing to the RSS feed or following me on Twitter or identi.ca.

---

Technorati Tags: ietf, standards, sip

This week out at the Emerging Communications Conference in San Francisco, I gave a 10-minute talk called "The Park Bench Manifesto: Why We Want To Kill Off The PSTN". In the talk, I mentioned that the text would be available here soon... And it will be.

In the meantime though, I have put up both the video and the 54-slide deck over on <a href="http://blogs.Voxeo.com/ett/">blogs.voxeo.com/ett/</a>

More soon..... (need to fly home...)

If you have a new SIP service or application, how can you find other services to which you can directly connect via SIP? That's the idea behind the new "SIP to SIP" directory launched by the folks at FWD and now available at www.siptosip.net. From the main page:

Why SIP to SIP VoIP?

SIPtoSIP lists applications and content that require SIP (Session Initiation Protocol) enabled devices on both ends of the connection. Realizing the promise of VoIP requires expanding real-time communication options beyond the functions already available with traditional telephones or cell phones. The ability of SIP based VoIP to support HDVoice, video, and click-to-connect requires SIP devices on both ends of the connection. Send suggestions for corrections and additional listings to Daniel Berninger at dan at danielberninger.com.

The directory is very obviously new and only has a few entries on the various pages:

• Devices
• Applications
• Content

As is noted, Daniel Berninger is looking for people to email him suggestions.

I do applaud the FWD folks for looking at another way to promote the further building of SIP interconnections and so I wish them well with this directory. I'd note, though, that the VoIP-Info.org wiki does already contain a great amount of this information. For instance, the site has a very lengthy page on VoIP phones. Now, granted, the phones listed there are for "IP" in general and not just SIP. Some use H.323, IAX or other protocols. There is perhaps a role for someone to curate a list like this into just SIP-specific information, but whether that needs to be a separate site or perhaps another page within a wiki like the VoIP-Info.org one is a question to consider.

Regardless, the FWD folks have now made this siptosip.net site available and it will be interesting to see how it evolves.

---

If you found this post interesting or useful, please consider either subscribing to the RSS feed or following me on Twitter or identi.ca.

---

Technorati Tags: fwd, sip, siptosip, directories, voip

There is a fundamental problem with the "VoIP is dead" debate continuing to rage across the VoIP/communications part of the blogosphere (see Alec Saunders part 1 and part 2, Jon Arnold, Andy Abramson, Ken Camp, Jeff Pulver part 1 and part 2, Om Malik, Shidan Gouran, Ted Wallingford, Dameon Welch-Abernathy (PhoneBoy), Rich Tehrani and a zillion others...)

Aswath Rao and Luca Filigheddu came closest to the mark in their posts. The fundamental problem with this entire debate is simply this:

Define "VoIP"?

As I discussed in an Emerging Tech Talk video podcast I put up this morning, there are a range of definitions you could give to "VoIP", including, but not limited to, the following:

1. The underlying infrastructure, a.k.a. the "plumbing" - the mechanisms, protocols, etc. that are used for the transport of voice/video/etc. over IP. Things like SIP, H.323, RTP, various codecs, etc.
   
   
2. Consumer "PSTN line replacement" services - Offerings like those of Vonage and so many others where the basic idea is that you can get cheaper telephone charges by going over the Internet and getting rid of your local landline. Also called "pure play" VoIP by some or "VoIP arbitrage" by others.
   
   
3. Computer-to-computer/softphone offerings, often coming from the IM space - Skype sets the bar here, but there's a host of other players as well, including Gizmo, GoogleTalk, FWD, and many others. Some of these came from existing Instant Messaging services that simply added voice.
   
   
4. Enterprise IP-PBX/"Unified Communications" solutions - Communications systems used by enterprises, large and small - what has traditionally been called the "PBX" but that term is increasingly meaningless given the range of options now being provided.
   
   
5. The *entire* vision of rich communication over IP - The whole picture... everything over IP... voice, video, IM, presence, file/data sharing... the whole rich communication experience.

Each and every one of these is referred to as "VoIP" by some segment of our industry. (And there's even more... I did have someone once reply to me that "VoIP" was the pre-paid calling cards that you can buy in convenience stores, etc. (And in truth, they usually do get their cheap rates by using VoIP for transport somewhere in there.))

The point is that we need to be a bit more precise in what we call "VoIP" before we can argue about whether it is alive or not.

From my point-of-view, the life and death of these different definitions of "VoIP" varies:

1. The underlying infrastructure - Doing extremely well... in fact, so well, that it's fading into the background and just being part of our underlying network infrastructure, both in the fixed and mobile environments. (Which also argues that some of the VoIP-infrastructure-specific products/services are no longer quite as necessary.)
   
   
2. Consumer "PSTN line replacement" services - Great for cable companies; not so good for pure-plays - Looked at Vonage's stock price lately? They and so many of the other companies whose only real selling point was "get cheaper phone calls with us" are certainly struggling or dying. Why? The cable companies, for one, are cleaning up in this space with their "triple-play" bundling of voice with Internet access and television. The pure-play companies may be cheaper on voice but the cable packages may be far more compelling. Add in the "unlimited calling" mobile phone plans we have here in North America, plus the softphone players like Skype plus some of the emerging cloud/hosted offerings... and all-in-all it's not a pretty picture for Vonage and friends. (And this is really the VoIP "industry" to which Alec was referring.)
   
   
3. Computer-to-computer/softphone offerings - Very alive - Skype is flirting with 15 million simultaneous online users and also reporting decent income, Gizmo is rolling out a Flash-based softphone to remove the need for a client, TringMe is providing widgets to various folks... and a whole range of others are growing. (While some players are shrinking here, too, of course.)
   
   
4. Enterprise IP-PBX/"Unified Communications" solutions - Very alive - Basically every vendor supplying communications systems to enterprises are now doing so over IP. No one is selling traditional TDM PBXs anymore. Players in this space include the traditional telephony players like Nortel, Avaya, Siemens, Mitel, Alcatel-Lucent, along with newer entrants like the dominant Cisco, ShoreTel, Digium/Asterisk and then even newer entrants like Microsoft OCS and IBM Sametime.
   
   
5. The *entire* vision of rich communication over IP - VERY alive! - In fact, I'd say that the next few years will be one of the most fascinating years in this space. We're at this amazing intersection of insane amounts of local bandwidth and computing power, increasingly ubiquitous powerful mobile devices, and incredible power out "in the cloud". All around us we are building the massive IP communications interconnect. It's happening. At a glacial pace in some areas and at a crazy pace in others. We're layering on applications and services. We're making them available through simple APIs and mashups. We're all collectively doing some pretty amazing things out there. It's a great time to be in this space!

So how do you define VoIP?

If you think of "VoIP" as my #2, the "cheap telephony consumer services", then sure, if you don't consider the cable companies then than sector isn't doing too well. If you define VoIP as one of the other definitions here, well, then in my view it is very much alive.

What do you think? How do you define "VoIP"?

P.S. If you'd like to join a number of us to discuss this topic, Sheryl Breuker and Ken Camp are hosting a conference call tonight at 9pm US Eastern / 6pm US Pacific. Join us... it should be fun. :-)

Technorati Tags: communications, telcom, telecom, telecommunications, telephony, unified communications, voice, voice applications, voip

Earlier this month out at ITEXPO in Los Angeles, I participated in the Ingate SIP Trunking seminars as I have been doing for the last year or so. My talk was "SIP Trunking and Security in an Enterprise Network". The slides are available for viewing or download from my SlideShare account and I'll also embed them here in this post.

I did record the presentation in both audio and video and hope to be making that available as a Blue Box podcast some time soon. I'll then sync the slides to the audio. Meanwhile... enjoy the slides!

Technorati Tags: voip, voip security, sip, sip security, voice, security, dan york, itexpo, commdev, voipsa

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)

(Taken from the voip-info page on sip.conf)

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

As per usual, Tom Keating gets us more details on the "Skype For Asterisk" beta program I just wrote about... in his update post, Tom explains how it will work:

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

Does today's announcement of a beta version of "Skype for Asterisk" signal a way to tear down some of Skype's walls? And does this move Skype along toward better SIP interoperability?

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

Do you care any more about zillion different IM services? Do you care about the IM protocol wars that have plagued the usage of IM for the last years?

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

All of those in one client with one directory of users and one window for chats (each on their own tab - and yes, I could have chats in separate windows but I generally choose not to do so).

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