So a few points, in no particular order:

Lee mentioned (as have others before) that P2PSIP is “copy-cat Skype”. This always bothers me, not because we came first (we certainly didn’t) but because it wasn’t my vision for P2PSIP (although others certainly had that view) . When I came up with P2PSIP and brought it to the IETF, I wanted to do things SIP couldn’t do at all. SIP can theoretically build a system that looks like Skype. To me, the interesting areas for P2PSIP were distributed softswitches/corporate IM (config-free small office, etc.), rapid response (quickly set up a communications system after a natural disaster), ad-hoc clusters for IM/app sharing (think Google wave away from the Internet), and vendors adding voice to apps without becoming an ISP. You could do a Skype-like service with P2PSIP (sort of: see below) but that wasn’t really the idea that got me started creating P2PSIP.

To me, Skype’s success was solving the NAT issue and getting the user experience right. P2P was a means to an end/efficiency multiplier, but not the reason for the success. Skype just worked. SIP’s major flaw is embedded IP addresses. Skype avoids this, uses media relays (P2P, but could have been centralized) and “falls back” (in the worst case) to tunneling over port 80. Users love this. Administrators and protocol purists hate it as it breaks traffic characterization, shaping, etc. Skype’s closed garden (one protocol stack) also ensured things just worked. Closed gardens and HTTP tunnels are at odds with the SIP goal of vendor/carrier interoperability. The two achieve different goals. (Today, many folks believe ICE with ISP-provided relays has addressed the SIP NAT problem. It looks promising, but until we have a Skype-sized Internet deployment, some say the jury is out. Time will tell.)

You could theoretically deliver a Skype-like experience with either a SIP or P2PSIP solution. Pure P2PSIP is very decentralized (every node is a peer and central servers are only used for obtaining a certificate), so you would need a hybrid approach if you want to maintain customer control. You could also use regular SIP with ICE, and many, many servers if you could solve the scalability problems. The best approach might be conventional SIP between the endpoints and a cloud of servers, with the servers sharing information using P2P. This ends up looking much like a SIP version of Skype’s super-peer model, executed in the cloud.

All this still begs the question of what happens to the Skype ecosystem of hardware, etc. If you go SIP, what do you break in the process? As Dan York and Shidan Gouran point out, Skype has many options, lots of great engineers, and lots of cash, but nobody outside of Skype knows what they will do.

As an aside to Lee’s comment on P2PSIP as a standard (it is fair to say adoption in product has been very slow, I’m sorry to say): The standard is moving, just at the (glacial) pace of standards, which can be frustrating for idea guys like Lee or I. In the early days, P2PSIP had lots of ideas, chatter, and excited non-standards folks, so work moved quickly. Today, with an accepted draft in progress and a more mainstream standards audience, iterations have slowed. That said, things are moving, there is strong interest, and a lot of hard work by the editors and participants.

My biggest worry is the protocol becoming too cumbersome. We are building a very flexible, universal DHT protocol with mandatory ICE and TLS/DTLS security. This is great for some scenarios, but overkill for others (ad-hoc, for example), and I worry the bulk may make it unsuitable for some of the scenarios I first imagined. I think many of these may migrate to the cloud. DHTs will be used, but as a means to distribute data among servers, not all the way to the edge as I first anticipated. Things change. Progress is good. I’m very excited to see how DHT principals in the cloud might solve many of the problems posed of a pure P2P approach. (eComm talk for SF, Lee?)

David

In any P2P network pointer distribution, the biggest problem (in my view) is one of trust, not scale. Being able to rely upon the distributed pointer caches becomes critically important. It may not be easily done, or it may not be possible at all without “owning” the binaries that are running the caches. Skype solves this problem by both owning the binaries that run the caches at the edge, as well as completely owning the systems/binaries that operate at the top of the tree. This may be sub-optimal for legal, business, or privacy reasons, but it solves the issue of distributed trust.

And yes, the issue of “directory” and the companion issue of “discovery” are the two hardest pieces to solve in any kind of distributed, decentralized service.

@Julie – You are always welcome to ask questions! But no, this has no relation to Skype 3.8 versus 4.x. This is all speculation about what Skype could potentially do in the future with some future version.

I want to compare Skype vs 3.8 to 4x … and have a ways to go. Would this explain any of the changes?

I’ve been thinking about this stuff for a while, and it seems to me that there are advantages in centralising some parts of Skype – storage of IM messages for example. At the moment, no European company can use Skype IM for anything that includes any customer data as you can’t be sure that it will not be exported from the EU. EU data protection rules say that you have to have the customer’s permission before exporting it.

Other parts work best de-centralized – like registry – No amount of trickery is going to let you create a single SIP registrar that copes with 19M (and counting) dynamic registrations. Skype would have to distribute this pretty widely (as they do now with super-nodes)

What is really lacking is a protocol to discover where users are and allow them to connect. Digium has made a stab at this with their Dundi prortocol, but I don’t know of one in the SIP camp.

You could use some sort of dynamic DNS, a la .TEL , but that probably wouldn’t propagate fast enough.

There are other possible ways, my favourite being to use IPv6 tunnelled over IPv4.

As for the voice bit – that’s pretty easy – heck we already have a lightweight Java based web phone at phonefromhere.com, if we can do it I’m pretty sure Skype can.