| Setting up the connections is not the "magic". That is not a hard problem. It's been solved years ago. First, P2P networks to not have to be enormous. Drop your assumptions. They can be small, and separated. (Think VLAN.) A P2P network can be set up so that any peer can volunteer to be a supernode. (Skype doesn't let you choose.) There must be at least one supernode to get a connection started but it does not have to be a company. It can be you, so long as you have a reachable IP. And the supernode does not have to forward traffic. She can just function to set up the connections. And she can do so agnostic to the traffic. She only keeps a table mapping MAC's and private, arbitrary IP's. The supernode can disappear after the connection established; it won't break established connections. If two nodes are behind the sane NAT, then the supernode can forward to traffic to get around this impediment. Setting up connections is not the "magic". There's no need for MS to be a (or should we say, "the") supernode. The "magic" in Skype is the way they handle the compression, encoding and decoding. That is where one needs to focus. Setting up P2P connections (for small, segregated P2P networks), reliably, and without snooping, is relatively easy. You or someone else in your contacts needs pulicly reachable IP. All the code you need to connect, which is not much- quite boring for the complexity lovers, has already been written. |
I work out of Florida, but most of my partners are in Ohio. Our phones in the Ohio office are delivered by a SIP carrier. The SIP carrier provides a router that establishes separate VLANs (on the local network) for the phones and computers. The phone traffic is prioritized so it goes out over the WAN link first. Granted, once it hits the internet all bets are off, but at least the voice packets are hitting the wire first. That should make our telephones the best performing VoIP option in the Ohio office.
That's not reality though. Everyone in the Ohio office prefers Skype because the call quality is better and the connection is more consistent/resilient.
I can read a SIP trace, and I understand a little bit about CODEC design. I can somewhat reliably identify the difference between a G.711 call and a G.729 call just by listening. In other words, I'm not a complete layman, but I'm not a voice engineer. What amazes me about Skype is that their voice stack performs so well without any special considerations at the network layer.
In an ideal world, a voice engineer wants not only a separate VLAN for voice traffic on the LAN, but prioritization all the way to the PSTN termination point. This usually means you need to get your transport link from the same carrier who provides your voice service. For example, if you buy SIP service from Level 3, Level 3 can also sell you a transport link, on which they can prioritize your voice traffic all the way back to the place where they connect to the PSTN. This assures the best possible transport quality.
Skype has none of this, but still manages to deliver great call quality. That is amazing to me, and it's a game changer. It decouples your voice and data provider.
The key reason to move away from P2P isn't technical, but business related. Enterprise decision makers demand more control over their network. By controlling the super-nodes, Microsoft opens the door for a whole different kind of customer:
Integrate Skype in to Exchange
With Skype integrated in to Exchange, desktop devices (Skype phones) could be segregated on to their own VLAN. The Exchange/Skype service (running on a server) can be bound to a network interface on this separate VLAN. This satisfies common enterprise network design requirements where voice is prioritized on the LAN. This would also provide an internal endpoint for Skype clients to connect to and pass through a set of business rules and/or integrate with internal applications. This is a typical use case for Exchange. Exchange would also handle call routing. Think of Exchange as the PBX, keeping intra-office calls on the LAN, and routing outside calls over a configured link.
Moving Skype Super-Nodes to Dedicated Infrastructure
The best reason to integrate Skype with Exchange is to replace the traditional SIP carrier. When a user picks up a Skype phone on their desk and dials by directory, the call hits Exchange. Exchange can examine the call and make some interesting decisions:
Directory lookup matches a local Skype username: call is routed entirely over the LAN.
Directory lookup matches a Skype user, but user is not local: call is routed over the outbound interface and through the traditional Skype infrastructure (now run by MS instead of P2P).
Directory lookup only contains a traditional telephone number: call is routed over the outbound interface and through the traditional Skype infrastructure (now run by MS instead of P2P), which terminates to the PSTN.
With Microsoft running the super-node, they have better control over the performance of the Skype back end.
The benefit of the ability to bypass the PSTN can't be understated. Many carriers offer what is called "free on-net calling". If your call is placed to another user on the same carrier, it is free, regardless of their geographical location. Skype could do the same. If you're calling another Skype user, the call is free. If you need to punch out to the PSTN, you get normal Skype rates.
The chances of an enterprise buyer considering this type of service over P2P is remote at best. There might not be any technical reason P2P couldn't satisfy the requirement, but it's bad joo-joo from a purchaser's perspective. They want assurances, and MS owned/run super-nodes make a lot of sense.