In the past two days, Andy Abramson has created a small storm by scooping a story of a possible(?) legal action taken by one Streamcast Networks against a collection of individuals and companies, including the founders of Skype. This story is sensational and might also be interesting; but as Andy himself suggests that this could very well be a transient one and could be settled out of court. At least for the present time, there is no suggestion that Skype will be affected very much.
On the other hand recently there have been talk of two studies that further explore the inner workings of Skype. Some of their observations are worth noting. The first one (Ref.1) is a study by Philippe Biondi and Fabrice Desclaux (I saw it in Brough Turner’s blog) and the second (Ref.2) is by Saikat Guha, Neil Daswani and Ravi Jain (I saw it in Skype Journal). The following are some of the interesting points I picked from these two references.
NAT Traversal: As I have been claiming, that Skype essentially uses STUN and TURN (actually I will say ICE to handle intra LAN and such connectivity scenarios) for NAT/FW traversal. Slide 45 of Ref.1 points out that clients determine their public IP address using a NACK message exchange - a customized procedure that otherwise could have used a standard procedure. Ref.2 (in Experiment 1) also claims this and extends that Skype uses TURN-like procedure if both the clients are behind NAT/FW. So can we now stop harping about the great NAT/FW traversal capability of Skype?
Supernode cloud: Ref.1 claims (slide 99) that they observed 20K supernodes. It is not clear when the study was conducted. In an early interview, Skype CEO claimed that a supernode will serve about 100 users. This suggests that the data must be dated. Ref.2 (Experiment 4) claims that they discovered 250K supernode “addresses” and were able to crawl 150K of them. The same analysis suggests that the pool of eligible supernodes is rather large. Because of this, each supernode is only lightly loaded – the median bandwidth consumption is less than 205 bps.
The second study found out that “a public host with a 10 Mbps connection to the Internet joined the supernode network within minutes.” They also observed that “there is very little churn in the supernode network.” These are important because the stability of supernodes is important for the stability of the network.
They also observed that only about 10% of the time supernodes are utilized for relaying voice and they note that this is smaller than they expected. It is not clear why they expected this to be higher. It is known that only 6 or 7 percent of home routers are “symmetrical” NATs and only they require media relying for the duration of the session. This means that 1-((1-.06)^2) = .12, which is about the observed value.
Security: Ref.1 makes an interesting claim (Slides 102 and 103) that there is a possibility that voice can be intercepted, encrypted or not. I am not sure I fully understand the scenario; but it looks like this is possible only if the attacker is able to convince the users to use a modified Skype client. With that kind of an assumption, isn’t everything vulnerable?
It seems that Alec Saunders received an email regarding the availability of PhoneGnome API. This is an interesting development that could potentially generate useful applications. Indeed, they encourage contributions to the library from third parties and Mark Petrovic has contributed a Java midlet for Java enabled cell phones. What follows is a summary of what is available based on a quick review of their website.
Currently seven API calls have been defined. Basically, these calls are XML-RPCs directed at a server, which will pass on the command request to the appropriate PhoneGnome device. Every call must identify the device by the PhoneGnome number and the caller needs to authorize by supplying the MD5 hash of the account’s PIN. After the execution of the command request, the server will reply with the result.
The calls that have been defined so far I presume are only an initial set of useful functions. I am hoping that they and the user community will add to this list.
The first one is called phonegnome.Dial that will prompt the PhoneGnome to originate a call to a designated number. In other places it is known as third party call setup. It is useful in scenarios like Address Book based dialing or click-to-call applications. In this context, it will be nice if the API allows for including some sort of identification string to indicate the specific location where the link was clicked. This will seriously disintermediate many of the click-to-call services. An associated call is phonegnome.setCdial. This call identifies the ITSP that should be used for subsequent calls, overriding the default ITSP. It will be nice if there is a way to include the pin code issued by that ITSP. This way, the user can dynamically select the ITSP. There is an associated enhancement: a call to handle two stage dialing.
Two directory related calls are phonegnome.addContact and phonegnome.getContact. The first one allows one to add a contact to the online phonebook and the second one retrieves all contacts that match a search string. Some of the enhancements I see here are the following: designate the specific route (PSTN or VoIP) to be used for the call, the ITSP to be used for the call and restricting the search to specific parameters.
The next useful call (phonegnome.Vmsg) allows a user to request the built-in answering machine to forward a new message to a designated email address, thereby creating “unified messaging” service.
phonegnome.cdrQuery allows the user to get a report on the list of calls that fit a set of descriptions. The last one (phonegnome.deliverSound) commands an audio file in wave format to be delivered to PhoneGnome. I am not sure the specific scenario where this can be used.
Alec quotes David as saying, “Basically, plugging PhoneGnome in "opens up" your landline, giving it an API, enabling various kinds of convergence applications…all kinds of things your landline provider, and even today’s VoIP providers are not giving us.” I agree with the general sentiment of this claim, I will take issue with the last portion, if only to suggest where enhancements can be made. I would like to bring to your attention the service offered by Verizon, iobi (my favorite). PhoneGnome can easily offer a similar such service if it reports the status of the calls to a registered client, either directly or via the “RPC2” server. This way, the user who is away from the PhoneGnome can monitor the call activity and even control the disposition of such calls from a remote location. The possibilities are endless and it is only beginning.
Some serious thoughts clothed in infantile (help me out here with a word that does not have negative connotation) rhythmic song, penned by Dr. Seuss Jeff.
Tom Keating has posted a forthcoming announcement from Cisco on their Unified Communications. In that long write up, two things are noteworthy. The first thing is that they are embracing SIP big time. The second thing is quote from Barry O'Sullivan vice president and general manager of Cisco's IP Communications Business Unit: "Our strategy is to put as much intelligence onto the network to allow applications whether our applications or others applications to take advantage of that intelligence. So call processing intelligence, presence intelligence, and rich-media applications.” What an irony! H.323 having been created by Bellheads places intelligence in the network (not true, of course). SIP, on the other hand is Netheads’ creation and consequently is happy to live in a stupid network. It looks like this is also not true. Oh well.
A few days back, AP had a story about easy availability of Caller ID spoofing service. As the article points out that this was feasible in PSTN itself (for example with CO trunks) and now it is more widely available with some VoIP services. The story also points out that there are many caller ID spoofing services. Obviously, many PSTN subscribers object to this capability and some are asking for legislation that will make it spoofing illegal.
There are legitimate uses of spoofing and the affected industries will object to such legislative attempts. For example, a call center that serves multiple customers should be able to put the caller ID information depending on the customer associated with the call. So my recommendation is the following set of actions on the service providers.
In my opinion that this is a good compromise for all the parties involved. A legitimate caller’s need for flexibility is maintained; the service providers need to implement a simple rule; the called user is given as much information as available.