[muppetmaster]

Report Here

Originally Posted by Columbia U

7. CONCLUSION

Skype is the first VoIP client based on peer-to-peer technology.
We think that three factors are responsible for its increasing
popularity. First, it provides better voice quality than MSN and
Yahoo IM clients; second, it can work almost seamlessly behind
NATs and firewalls; and third, it is extremely easy to install and
use. We believe that Skype client uses its version of STUN [1]
protocol to determine the type of NAT or firewall it is behind. The
NAT and firewall traversal techniques of Skype are similar to
many existing applications such as network games. It is by the
random selection of sender and listener ports, the use of TCP as
voice streaming protocol, and the peer-to-peer nature of the Skype
network, that not only a SC traverses NATs and firewalls but it
does so withhout any explicit NAT or firewall traversal server.
Skype uses TCP for signaling. It uses wide band codecs and has
probably licensed them from GlobalIPSound [10]. Skype
communication is encrypted.

The underlying search technique that Skype uses for user search is
still not clear. Our guess is that it uses a combination of hashing
and periodic controlled flooding to gain information about the
online Skype users.

Skype has a central login server which stores the login name and
password of each user. Since Skype packets are encrypted, it is
not possible to say with certainty what other information is stored
on the login server. However, during our experiments we did not
observe any subsequent exchange of information with the login
server after a user logged onto the Skype network.

[oasis-k]

Thanks for this one.

Skype - amazingly - is about the only softphone I haven't put under real close scrutiny. I bypassed it because it was proprietary and I always feel that is a mistake in the VoIP arena, but after reading this conclusion (I will get to the full article later) I'm downloading it as it write. Skype uses TCP for voice streaming! Wow! How is the re-sending of dropped packets going to help a conversation?! Must be some fascinating stuff in those encrypted packets!

I notice that Skype's catchphrase is that it "just works". Maybe they did the right thing by taking their own route afterall. I do remember a colleague, using Skype, called me from the US on my mobile in the UK and during a 60 minute conversation the voice quality was absolutely perfect.

[mberlant]

One reason that Skype can use TCP for conversations is that they are not having to pay for the horsepower to maintain the TCP connections. Skype is built upon the same distributed P2P architecture that powers Kazaa. This is because it was developed by the same two guys. Most of the switching fabric is contributed unknowingly by each and every Skype user who is logged in. Everybody pays for their own Skype service by hosting the transmission and relay of other people's calls. By distributing this load across such a wide field it is not as necessary to conserve resources.

[oasis-k]

One reason that Skype can use TCP for conversations is that they are not having to pay for the horsepower to maintain the TCP connections.

The issue of UDP vs. TCP in the context of this article is not resources but time. i.e. what it the point of resending packets of voice that didn't make it the first time! Anyway, the point is moot since I now discover - and I really hesitate to contradict the boffins at Columbia, but... seeing is believing. This statement

the use of TCP as voice streaming protocol

is not true. Skype uses UDP for voice streaming and TCP for signaling just like SIP skinny and everyone else.

I just called a UK mobile from my UK-based skype/adsl-internet connected PC. The voice was streamed in UDP (but not RTP/RTCP) between my internal NAT IP to 212.72.49.130 (the mobile or PSTN gateway).

I'm not clear about your references to

the switching fabric

and

Everybody pays for their own Skype service by hosting the transmission and relay of other people's calls

The fact is this voice stream went from my IP address to the remote gateway routed by the internet routers like any other IP packet - how can it get switched across a whole bunch of PCs in different network segments - the internet routers no nothing about this. They just work with the destination address and their routing table and route it accordingly.

I am aware (anecdotally) of the distributed nature of Skype architecture, but the media isn't streamed that way, so I suppose this relates to supervisory or address signaling. It's hard to tell from my very limited test.

Actually, I'm impressed with the economy of the skype call. It used no DNS! And here's the kicker - the very first packet went to 212.72.49.141 (same subnet as the voice was finally streamed!) Yipes! Lucky guess eh? Just 3 exchanges to setup the call and 2 to tear it down. I think the money part was taken care of by 66.189.245.73 (setup & close) and 80.160.91.28 (call end).

That's it - about 5 IP addresses sorted the whole thing, and the voice quality was toll quality. (I've now sniffed most softphones and this is at the top - MyWebCalls is at the bottom! It's terrible)

Plus, I really like the fact that skype voice is encrypted. After performance, integration and security are the keys to success in voip, I believe.

Since skype has performance and security sorted, the ultimate success of their proprietary approach might hinge on how well they can integrate with hardware and software.

[mberlant]

Thank you for the clarification. In my haste to type I didn't distinguish that I was referring to VoIP's TCP (the control channel) and not IP's TCP.

One of the reasons your call went directly to where it needed to, with few hops, is because your Skype client maintains its status not with "Skype Central", but with the nearest supernode to you, whose owner probably doesn't know how much resource he is contributing to keep Skype running smoothly.

I also use encryption over FWD regularly. I find that there is no discernable reduction in quality using encryption and I have set up my SPA to request encription on every call. If I didn't have these two factors I wouldn't use encryption because I don't believe that the exposure is significant enough, at least not yet.

And, yes, it would be nice if Skype were able to run on a real ATA, if they offered DID numbers, and if they offered peering. I still can't afford to donate my bandwidth and my computer's horsepower to supporting Skype's operation, just as I couldn't afford it with Kazaa.

[oasis-k]

I was referring to VoIP's TCP (the control channel) and not IP's TCP.

Sorry I don't follow this reference. There's only one TCP. What is VoIP TCP vs. IP TCP? I assume the reference is to the function it's used for. TCP is used for call control as you say, but not for voice streaming as indicated in the Columbia report.

Skype client maintains its status

By status do you mean the states of online/offline/call in progress - that type of thing? Or are you saying that this skype supernode has some address lookup/call admission or authorisation functions?

One of the reasons your call went directly to where it needed to, with few hops,

I didn't mean to imply this. My meaning was FEW STAGES. This is quite different. The number of hops between the IP addresses is of course resolved by Internet routers, in this case the voice stream went through 14 hops via MCI and leve13.net routers, and was finally directed to the (presumably but not necessarily) PSTN/Mobile gateway by ams-l3-in.skype.net [212.72.45.206] i.e. a router in skypes network. Of course, we can only speculate what happens at that point. But this voice stream to that point did not involve anyone elses computer.

More interesting were the TCP calls, I assume this is the part you say skype uses other users's resources. As I mentioned, these TCP calls were few (which is good) but with plenty of hops, in fact about 30 or more. The first 14 or so went through telia.net and broadwing.net routers and then they started on plain old IP addresses with no dns host names and I lost the trace for about 15 or more of those It could be that these are skype nodes you refer to.

I will do some more work on this - along with the other softphones I play with - but I think you may overestimate the extent of the resources skype is claiming on these contributors. We will see!