Disruptive Telephony

By way of a Twitter post today, I learned that Dave Troy has unveiled "Talking Ruby", a new site promoting information about the integration of the Ruby language with telephony, collaboration and messaging.  I've always been intrigued by Ruby (and also Ruby on Rails, which has been one of the most visible uses of Ruby), but have yet to really have had a reason to plunge in and play with it.  Perhaps this will provide an excuse.  Dave indicates on his site the following reasons for using Ruby with telephony:

• Ruby’s DSL (Domain Specific Language) Capabilities are ideal for expressively encapsulating diverse telephony and collaboration technologies
• Inherits the momentum of Rails, so web integration is baked-in
• Cross-platform support (Linux, OS X, BSD, Windows ) unifies application development efforts
• Ruby integration libraries can be easily developed and shared
• DRb (Distributed Ruby) allows for persistent state storage and scaling across servers

I wish him all the best with the new site and do look forward to seeing what people come up with.  The site is a wiki, so if you're interested and Ruby-literate, you can easily jump in and participate (there's also a mailing list).

With my post earlier this month about the possibility of SIP botnets, I've had a number of people asking about more information and wondering about the possible impacts.  And while I will write more on botnets in general, as far as the potential impact of "botnets" in general, one need only look over at the current situation in Estonia:

• Washington Post: "Cyber Assaults on Estonia Typify a New Battle Tactic"
• CNN: "Estonia suspects Kremlin in Web attacks"
• BBC: "Estonia hit by 'Moscow cyber war'"

Now, perhaps Russia is behind the attack... perhaps not. There are obviously much larger political issues going on between the two states.  In the end it doesn't really matter on one level who exactly is behind it... the net of it is that Estonian entities are being attacked in a massive Distributed DoS (DDoS) brought about in part by botnets. For anyone doubting the potential threat, you need only to read through those news articles to understand what can happen.

In fact, I found it interesting that the UK's Centre for the Protection of National Infrastructure (CPNI) issued an advisory today about the DDoS attacks against Estonia, mostly to reassure people in the UK that no attacks were currently being seen against UK businesses.  It also included two links to previous papers written by NISCC (one of the predecessors to the CPNI) about:

• Distributed DoS Attacks
• Botnets - the threat to Critical National Infrastructure

Both make for interesting reading and give some suggestions for how to prepare.

So what does this have to do with telephony?  Well, for starters I'll admit to knowing nothing of Tallinn, Estonia, before Skype entered the picture.  Skype is, of course, headquarted in Tallinn and through things like their Life at Skype blog have provided a view of Skype as a company, but also of Tallinn and Estonia.   Since then I have also learned of other companies coming out of Estonia... certainly seems like an interesting hi-tech place these days.  Now I don't know what, if any, disruption Skype has been seeing from these attacks.  The distributed p2p nature of Skype would argue for there not being much of an impact (except, obviously, to those right in Estonia), but I don't know.

On a larger level, though, it's just a powerful reminder that the botnet threat is very real out there.  And the question is... could your IP telephony infrastructure withstand a botnet attack?  Is your larger IT infrastructure up to withstanding some degree of an attack?  Do you have multiple VoIP gateways?  Could you route around points on your infrastructure that were being attacked?  Do you (gasp) have TDM trunks that could work as backups? 

I don't know if anyone in Estonia has had their IP telephony disrupted by botnets, but odds are if the attacks are as bad as being reported, some companies probably did.  What will you do to ensure your company's IP communication isn't disrupted should botnets come calling?

P.S. For another view on the larger conflict between Estonia and Russia, here's an article (and comments) I found interesting in John Robb's "Global Guerillas" blog: "Russia vs. Estonia: 21st Century State vs State Conflict".

In a few short hours, I will be catching a plane heading out to Fort Huachuca, Arizona, to swim in an alphabet soup of very different acronyms and jargon than my normal work - the "OSD-Sponsored, JITC-Hosted DOD Telecommunications Services Information Conference".  As noted on the page:

The purpose of the conference is to provide an open forum where DOD and vendor representatives can discuss issues related to interoperability of systems providing DOD Telecommunications Switched Services.

The conference will present the current program and discuss ongoing developments to the interoperability certification and information assurance procedures and test documentation. Other topics for discussion include emerging technologies, standards and their integration into the systems providing DOD Telecommunications Services.

I attended last year as well and it's definitely an interesting experience.  The US DoD is really doing some intriguing things with how they make use of VoIP / IP Telephony.  Obviously security is rather important.  They are also driving IPv6 adoption into their infrastructure and so, with the June 2008 mandate only a year away, it will be quite interesting to hear where they are with regard to IPv6 adoption.  Obviously, their huge size and buying power is of strong interest, so the number of vendors will no doubt be high.  Also, and I would think "obviously", I won't exactly be writing about things that I hear or learn there.

If any of you reading this happen to be out there at the conference, do drop me a note as I'm always interested in meeting readers or listeners.

I do have to hand it to the Skype marketing folks... it's certainly a cute move on their part to offer Skype users in the US and Canada a full day of free calls to landlines and cell phones around the world.   With Mother's Day being one of the highest days of phone usage, it's a natural day to pick for a gimmick. 

There are limits, though, and the terms and conditions were interesting to read.  I'm not sure how to read #9 where users are limited to 200 minutes per call:

Skype asks that you enjoy this offer fairly and sensibly, for your personal and non-commercial purposes. Calls are limited to 200 minutes per computer during the offer period. If you make excessive, systematic or intentional misuse of the offer, Skype reserves the right to terminate your access to your account immediately.

So is that 200 minutes, total?  Or is that per call?  i.e., if you've been talking to someone for over 3 hours on the same call you have to hang up and initiate a new call?  Either way, it's a good amount of time to spend on the "phone".

I also enjoyed this part:

Skype reminds users of the nature and limitations of the Internet and is not responsible for any hardware or software problems, any technical malfunctions of any communications network, online system or computer hardware or software that may affect access to the offer. Skype is also not responsible for any fraudulent, incomplete, garbled, or delayed computer transmissions or inaccurate transcription of information, whether caused by Skype, its users or by any of the equipment or programming associated with or utilized in this offer by any technical or human error which may occur in the processing of the offer which may damage a user's system or limit a participant's ability to participate in the offer.

So if you can't understand your mom (or whomever else you call), it's not Skype's responsibility!  :-)

Ah, well... kudos to them for coming up with a cute marketing gimmick.  If it get's some more people to try out consumer VoIP, all the better for us all.

I will call my Mom on Mother's Day, but odds are that I'll just be using the regular old landline.  We'll see.  It's tempting to call other people in other parts of the world that day, but: a) it's a Sunday and for most folks I know overseas it's a weekend and they like to spend that time with their family; and b) *I* will be spending that day with my family.

P.S. Also quite interesting to see that Intel is a co-sponsor of this marketing campaign.

Last week Skype came out with a Developer Program newsletter that provided a bit more insight into the Call Transfer capability now available in the recently released Mac version 2.6. In the full version of the article, Skype technical project manager Morné van Dalen answers some questions about what the Call Transfer API is all about.  It's interesting to see the discussion here of Group transfer, specifically in this list:

• Skype to Skype (P2P)
• Skype to SkypeOut (P2P to SipOut)
• SkypeIn to Skype (SipIn to P2P)
• SkypeIn to SkypeOut (SipIn to SipOut)
• Skype to Group
• SkypeIn to Group

It's quite curious, though, that transfer to SkypeIn and SkypeOut will only be available to Skype Pro customers, which of course is not available in North America!  Seems a rather puzzling disconnect.

Anyway, it will continue to be interesting to watch these capabilities evolve...

Yesterday after the close of the market, my employer, Mitel, announced an agreement to acquire Inter-Tel.   There's not much I can say beyond what's in the news release... but I can say that I am quite excited by the news!

I posted Blue Box Podcast #56 tonight and with it Jonathan and I are beginning a series of mini-tutorials on subjects related to VoIP security.  In this show, we talked about voice encryption. In the next show (already recorded) we will talk about signaling encryption.  The idea is to cover some basic ground so that people not familiar with the area can have a basic understanding.

Just glad to get that one up - tomorrow I'm going to work on #57 to see if I can get it online for Wednesday.  We're trying hard to get back on a weekly schedule.  (#56 was intended to go up last week.)

Here's something for a Friday afternoon... yes, indeed, out at Emerging Telephony 2007 back in February, someone (David Troy) did indeed have Asterisk running on a Roomba.  And yes, it was "Press one to start sucking. Press two to stop sucking."

Pictures are now available on Flickr.

More precisely, Asterisk is running on a hacked Linksys WRT54G access point (which is Linux-based) and the controller is using a Nokia WiFi/GSM phone to connect to the Asterisk install.  You could also control the direction of the Roomba using the other keys on the phone keypad.

Why would anyone do this?  Well... why not?

As I mentioned in a recent post, the beautiful thing about VoIP is that it now enables people to "play" with telephony... and do wacky things like hook it up to a Roomba!  :-)

Enjoy the weekend!  Perhaps next week I'll actually get some time to upload the rest of the pictures I took out at ETel. (Hey, it was only 6 weeks ago... )

In the usual (and ongoing) flurry of IETF announcements, there was one notice that caught my attention.  It announces that an Internet Draft document about "dialstrings" has been approved to become a standards-track RFC.  So what, you say?  Well here's a bit more info:

This document provides a way of incorporating a dial string into the SIP or SIPS URI scheme. A dial string is a cousin of a telephone number, but rather than taking the form of a fully-qualified E.164 or national-specific telephone number, it is a description of a literal set of dialed digits that would be delivered over a POTS line. As such, it may include pauses, omit prefixes like area codes, and its applicability is necessarily restricted to a particular context (an enterprise, a LATA, etc). Support for dialstrings was formerly a feature of the tel: URI scheme specification (back in RFC2806); since that functionality did not make it into the revision (RFC3966), it is provided here specifically for the SIP and SIPS case.

Think of it as extra digits you have to type when making a call... or extra keys you have to press to start a service.  The challenge is that SIP proxies and other services need to know that it is a string of numbers that should be handled in a special manner, rather than just thought of as part of a SIP address or something like that.  I mention it here only because it's one of those really low-level things that you can do on the PSTN but until now haven't had a (standard) way to do in SIP. It's also one that ultimately anyone implementing SIP will need to implement.  No RFC number yet, but that will come soon.  Note the nice security warning:

Dialstrings exposed to the Internet may reveal information about internal network details or service invocations that could allow attackers to use the PSTN or the Internet to attack such internal systems. Dialstrings normally SHOULD NOT be sent beyond the domain of the UAC. If they are sent across the Internet, they SHOULD be protected against eavesdropping with TLS per the procedures in [RFC3261].

Yep... as we've been saying over at VOIPSA and Blue Box, you definitely need to think about encrypting SIP if you are sending it across the Internet.  If not, bad things will happen eventually.

As I travel around giving presentations about the technologies that are disrupting telephony, one of the themes I discuss is that one of the most severe disruptions brought about by VoIP is that people now have the ability to "play" with telephony in ways that were never possible before.  Pre-VoIP, you needed special (and typically costly) equipment.  Yes, there have been any range of CTI cards that let you play to a degree, but buying the real equipment was just not possible for most folks who might want to "hack" in the original meaning of the word.  Enter VoIP.  Now all you need is an old PC and some open source software and... ta da... you're playing with telephony. 

What I also see out there is that this ability to hack on telephony is happening at the same time that hacking on networks or operating systems seems to be getting less exciting and interesting.  Oh, don't get me wrong, there's still amazing things happening out there... but for people who want to "play" with technology, those areas aren't as exciting or novel as they once were.  So many of those early adopters have moved on to hack on other things... primarily, it seems to me, on "Web 2.0" apps/services/mashups... or telephony.  (And you'll note the already happening collision of both.) 

Because I like giving presentations with very minimalist slides (unless forced to bulletize), I often summarize this latter point as:

The cool kids now hack telephony.

Whether you agree or disagree with my point, I don't think anyone can deny the continued growth in the number and capability of open source telephony projects.  By way of voiploser's blog (also worth checking out), I learned of VoIP Now's list of 74 Open Source VoIP Apps and Resources.  It's a great list, which really serves to illustrate the amount of open source activity happening with regard to telephony.   Some of the projects on there have been around for quite a long time, while there were certainly some there that were quite new (and I'd not heard of them).

My only quibbles with the article would be these:

• There appears to be no way to leave comments, which is too bad, because you would undoubtedly get all sorts of other developers coming out of the woodwork and leaving comments saying "Hey, what about my project?"
• No matter how you structure a list, people will always say it's wrong.  So naturally, I question why you would start with "H.323 Clients" given that all the major work these days is on SIP.
• Given my past interaction with FreeSWITCH (read the comment left by the lead developer), I somehow doubt that they would want to only be classified under "H.323 Clients".  In fact, the inclusion there really makes absolutely no sense to me given that FreeSWITCH is decidedly not a client, but rather more a telephony platform.  It should probably have gone down near the PBXs or in a separate "platforms" category.  Ditto with YATE.  Part of me wonders if the author just wanted to list FreeSWITCH as #1...
• Under "SIP Test Tools", they list some of the more prominent ones, but the VOIPSA "VoIP Security Tools" list has far more, most all of which are also open source and are used to "test" your VoIP system.

Quibbles aside, the list is definitely a good one, and kudos to VoIP Now for putting it together.