3 ms·

That's one possible explanation, and I think there's a healthy amount of skepticism required when analyzing moves like this, but it's not the only explanation.

That's one possible explanation, and I think there's a healthy amount of skepticism required when analyzing moves like this, but it's not the only explanation. Keep in mind that a large part of Microsoft's business is in the enterprise, and voice is a huge application product for enterprise customers. Exchange has always had some form of voice integration. I haven't used it in years (since back when H.323 was big), so I don't know the current state of affairs, but it is just as plausible that Microsoft is moving to a more traditional client-server structure in a bid to win the mindshare of enerprise purchasers. I'm particularly attached to this explanation because of my insight in to the telecom industry. Telcos don't want to sell dumb pipes to customers, because dumb pipes are a commodity. Selling a TDM PRI with 23 voice channels is something anyone can do. Carriers are pushing customers away from these products in to SIP offerings that can integrate with customer applications because these products have high exit costs. I can swap out PRIs three times a year without much trouble. Changing application integration is far more expensive. This creates room for higher margins. Here's the thing: with Skype, Microsoft can enter this space. I don't know exactly how Skype does it, but they manage to deliver a great VoIP product without any infrastructure considerations (network design, QoS, backhaul constraints). I've used SIP carriers who deliver a router with preconfigured QoS that can't call quality as good as Skype. I'm not suggesting there's magic here or anything, but Skype's product is damned good. If Microsoft were to integrate Skype in to Exchange, that would give them a customer endpoint that could take advantage of a network designed for voice. Exchange could keep intra-office calls local (like a PBX) and segregated on their on VLAN, while aggregating outside voice traffic on separate network interfaces, much like traditional TDM and SIP based PBX systems. This would check all the right boxes for enterprise voice managers. I'm also willing to bet this would push Skype voice quality over the threshold from end-user novelty to enterprise infrastructure. There are far too many positive business reasons from a straight forward product standpoint to jump straight to the "this lets them mine customer data" viewpoint.

wetsocket 15y ago
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.
- bradleyland 15y ago
  I think you might have missed my point. The P2P portion isn't the amazing part for me, it's that Skype call quality is so good without any of the traditional network engineering requirements I'm used to. 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.

wetsocket 15y ago

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.

bradleyland 15y ago
I think you might have missed my point. The P2P portion isn't the amazing part for me, it's that Skype call quality is so good without any of the traditional network engineering requirements I'm used to. 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.