Could SIP Really Save Skype?


skype_logoGlobal Index, a technology owned by Skype co-creators Niklas Zennstrom and Janus Friis via their company JoltID, is the fulcrum of leverage in their ongoing dispute with current Skype owner eBay and its potential purchasers. If you were either the buyer or seller in this labyrinthine transaction, you’d likely be tempted to declare, “Let’s just rip out Global Index and use something different.”

Such a move would undoubtedly take the wind out of JoltID’s sails as Skype tries to find a new home outside of eBay. Indeed, many VoIP pundits insist that Session Initiation Protocol (SIP) could be Skype’s savior. But while it’s true that technologies like SIP and its stepchild XMPP achieve a lot of the same goals as Global Index, such an argument ignores the fact that Skype is as successful as it is because it has exponentially better operating economics than the rest of the VoIP industry –- and Global Index is the singular reason why.

The Promise of SIP
In 2002, as Zennstrom and Friis were facing a bevy of lawsuits of indeterminate scope and the writing was on the wall as to the profitability prospects of a P2P file-sharing network, many in the then-fledgling VoIP industry were busily attempting to re-architect the telephone network in the Internet’s visage. A number of these services, including two from entrepreneur Jeff PulverVonage and Free World Dialup — used SIP at their core. They were consumer-focused services that, in their own way, attempted to mimic the architecture, business structure and design of the public switched telephone network using Internet Protocol technologies.

SIP is now hugely significant in shaping how many telecom networks are architected. But while many of us initially thought that SIP might herald an era of person-to-person multimedia communications free from the control of large companies, it hasn’t exactly worked out that way.

The Drawbacks of SIP
For telecom companies and their vendors, the draw of SIP was that it could be used to transpose the proprietary SS7 signaling network onto the Internet while allowing the calls themselves to transit IP networks –- both at a significant discount to the cost of switched telecom trunking. But even as a client-server phenomenon deployed on the public Internet, SIP is an incomplete solution. On its own it has no way of traversing firewalls or, more importantly, dealing with NAT traversal –- a critical oversight for a protocol created in the late 1990s for the IP address-starved modern Internet.

SIP user agents (such as that software on your computer or that phone on your desk) must also be manually configured to register themselves to a SIP proxy server if users are to be allowed to use them for differing networks. Furthermore, all traffic, addressing and routing decisions in a SIP network are typically handled at the network core or by equipment operated by the service provider. That includes the various workarounds such as STUN that enable folks behind firewalls or using private IP addresses to talk to each other, not to mention derivative (and much cooler) protocols and techniques such as XMPP and Jingle.

If adapting SIP to the vagaries of the modern Internet sounds expensive, it is. By 2006, Vonage had already burned through nearly half a billion dollars. More importantly, SIP architectures are a critically flawed design starting point for a true P2P network. SIP and XMPP networks are really client-server networks masquerading as P2P.

Forgetting about the exponentially more costly business of sending voice or video data across networks, 70 percent of traffic on XMPP instant messaging networks is the result presence updates. Some estimates are that as much as 60 percent of this information is itself redundant. Servicing the traffic on a network such as Skype’s, which consists of some 45 million daily users, would bury most startups in server and bandwidth expenses. Add to that the actual messages themselves, and having to handle the voice channel or video at the core, and it becomes clear that only the big boys get to play in distributed communications services.

Enter the Supernodes
Or do they? As it turns out, features like instant messaging, voice/video chat, and presence management are ideal applications for the technology that Skype’s founders had been playing with for years in the P2P world. The networks using their technology when Skype was founded in September 2002, Kazaa and Morpheus, handled massive volumes of data between peers with no real central core to speak of, but still significant domain control by FastTrack, the company created by Zennstrom and Friis to license technology using the same moniker. The key concept exploited by the services derivative of this technology is the distributed, auto-discovering, self-healing node-supernode model tied together by PKI encryption.

On any of the other VoIP and IM networks such as Gizmo or iChat, each user is a node -– a logical endpoint in a cloud that connects to host computers operated by the service. But with Kazaa, Skype and even Joost, a small percentage of each service’s users unwittingly conspire to provide the network’s backbone in the form of supernodes. Which means that if you have some combination of a permissive firewall, really good port-forwarding on your router and a public IP address on your computer, you, too, can be a Skype supernode. When it comes to traversing firewalls, NAT, and handling distributed authentication and presence management, supernodes do all of the heavy lifting.

That is the reason Skype is able to service 45 million daily users on a fraction of the infrastructure that a SIP-based provider like Vonage needs to deploy. The workload that normally would be handled by equipment owned by the company is distributed among the users themselves.

The Power of Global Index

In order to make this seamless to users, Skype implements a Service Discovery Protocol. Such technologies have always worked well on Local Area Networks (Apple’s implementation is called Bonjour) but often get confused on the public Internet because there is usually no central registry — and because the broadcast packets they use tend to get snubbed by access routers.

When you load it up, it starts with a table of known supernodes and the central Skype server. Skype’s only centralized involvement is in verifying your identity via PKI authentication and providing an update (if necessary) of friendly nearby supernodes. From that point on, your associated supernodes handle every piece of data you share on the network. An added bonus is that supernodes can redesignate the location of the master Skype hosts on your computer whenever necessary.

Since the whole thing is encrypted, and the encryption keys of nodes and supernodes are all validated by Skype’s root key authority, everything on the network is trustworthy and virtually impossible to hack or otherwise corrupt. In other words, the Skype network is fully distributed, self-healing and largely decentralized, but still maintains all of the advantages of command and control desired by a service operator who actually wants to make money from integrating the service.

Thanks to Global Index, Skype operates at cost levels that are believed to be a fraction of those of even the most efficient SIP or XMPP-driven networks. It is this economic advantage that trumps the possibility of forklifting standards-based telephony technologies into the core of Skype’s network. If you truly wanted to replicate Skype’s ingenious — and very practical — design, you’d be better off looking at technologies like Napster, Bittorrent or GNUtella.

Ian Andrew Bell is creator of the team management service


Seeking VC

We introduce “Skype-disruptor” application with new and unmatched web browser centric Video and VoIP cross-platform technology, based on US Patent 7,089,319. The key distinguishing factor of our platform is that it’s instantly web browser centric, without anything to download or install. No plugins, no active x controls or Flash. Just instant communication gratification from any web enabled device. We can compete on “true P2P” signal strength, unmatched platform reach, innovative “Orbing” (P2P live and pre-recorded social networks video broadcasts) function, as well as lower operating cost base (higher margins). While Skype is negotiating its way out of a legal minefield, we are focused on capturing strategic market segments. We are actively seeking venture capital. Please visit for more detail.

Julian Cain

I posted yesterday that N/J and Skype were closing this deal and GigaOM deleted it. This is now in the NYT here:

Why did you delete my post? Why are you holding back information on purpose? Why are you not discussing the fact that Volpi’s career has ended permanently?

Listen everyone, Skype and N/J began talks last week with Skype to do a joint deal and take a portion with board membership. They are attempting to push this through this week and then it’s holiday for the legal teams next week.


My argument in this piece was largely an economic one, not as much a dissertation on the independent merits of the protocols in play. I do think that the issues around SIP remain relevant as they result in far less than satisfactory economics.

However, Skype is now a big company. It can afford to be infrastructure-heavy. It could NOT have been so when it was founded (and funded) in 2002, however, so Skype’s design was perfect for an aenemic startup. Note that for a number of years Skype had no billing system, no “SkypeOut”, and virtually no infrastructure. The design was elemental to their growth, but as Jeff pointed out they’re big kids now and could probably handle it.

Another aspect that was difficult to wedge into the article is the License Agreement between JoltID and eBay/Skype. I have negotiated a few of these in my time. This is probably perpetual, but given the court actions to date I would think it’s a safe bet that eBay is prohibited from reverse-engineering or modifying JoltID code.

That being the case, assuming you switched to SIP or even some other form of home-grown technology you are talking about forklifting OUT the JoltID code and SkyLib, which Global Index is a part of, and forklifting IN whatever you’re going to replace it with. This means no backward-compatibility and this means a global “upgrade day” where Skype forces its whole userbase to migrate or drop away from the network. The user churn they could expect on such an event is epic.

Nope, a negotiated solution is a FAR more likely outcome here than Skype buying Gizmo5 — a rumour that I suspect is more founded in the aspirations of Michael Robertson than any material discussions going on between Gizmo and eBay. If that was truly happening, then neither party would be anxious to divulge the conversation until it was done.


Isn’t the question really “Can Skype put together a cost-effective service offering using existing protocols, without relying on Global Index?”

Who cares if SIP alone traverses NATs when you have STUN, ICE and TURN? More relevant is whether you can implement a solution using these protocols as well. If most of the IM network traffic is presence updates, and we have a bunch of IM companies still standing, it seems reasonable to believe that Skype can build a more centralized infrastructure to monitor status, aid connections and manage account info, then leave communication content traffic to end nodes.

Regarding the vagueness of the SIP protocol, and the costs of provisioning CPE when there are so many different implementations, there seems plenty of room for efficient improvement here. First, with Skype’s size they lead (or partner) to standardize configurations (including voice codecs). Second, there seems to be room for remote/auto provisioning of hardware (and GoToMeeting-based configuration doesn’t count).

As an end-user, all I care about is being able to make clear connections (voice, presence, video) reliably and cost-effectively, and from my choice of devices. This seems well within Skype’s abilities, Global Index or no.


The only thing that can realistic save Skype is a combination of SIP backbones and Jingle for Clients.

Super Nodes? We do it open now and we do it better:


Leaving the JoltID/legal issue to one side for the moment….

One of the mooted reasons for Skype ‘moving to SIP’ is to reduce the
costs of engineering the client software by just buying in the best of breed
SIP client for a given platform.

Based on our experience with the SILK codec, Skype would need to keep control on
the client software to be able to keep advancing the user experience.

Integrating SILK well into existing client software isn’t trivial and would be
much harder in an environment with multiple different clients from independent
software vendors.

So as Sten said “We would need a _very_ good reason” (to move to SIP) and it looks to me
as if reducing engineering costs aren’t that reason.

Dan York

@Ian, Interesting piece – and great comments to read as well. I wrote a post on the same general topic a few weeks back “Could Skype realistically replace its P2P algorithm with P2PSIP?” – – after there was discussion on a few sites about “P2PSIP”. My point was really that we have to separate discussion of the SIP *protocol* from the SIP *infrastructure*.

At the end of the day, SIP is a signaling protocol for establishing communication sessions and, as you note, can be used for creating *any* type of session, not just voice. Whether or not Skype were to switch to using SIP as their signaling protocol instead of their own protocol is not really the point – as you mention it’s more an issue of what Skype would do with its *infrastructure*.

So the question is really – could Skype move from the P2P algorithm and protocol it uses today to either:
1. another P2P protocol (such as that being discussed in the P2PSIP world); or
2. the more traditional client/server model used in SIP infrastructures today.

On the latter point #2, @Jeff may certainly be write that Skype/eBay could certainly create a “traditional” system that could scale – and perhaps that is one option for them. But both @ian and @duane are correct that there *are* other P2P options out there.

And sadly (as a promoter of open standards) @Michael is right that there are still way too many issues with SIP “interoperability” and challenges with NAT traversal, etc. Yes, there are solutions out there – but all too often people do have to resort to SBCs or other devices to “normalize” the SIP between devices so that they can interconnect. Some of the efforts within the SIP Forum, like the great SIPit test events, and IETF Working Groups like BLISS may over time help with the SIP interop issues, but they do sadly still cause pain today.


We are the team of inventors behind US Patent 7,089,319 issued in 2006 titled “Method and system for instantaneous on-demand delivery of multimedia content over a communication network with aid of content capturing component, delivery-on-demand client and dynamically mapped resource locator server”.
We introduce “Skype-killer” application, with new innovative “Internet broadcasting” functionality, as well as unmatched web browser centric cross-platform, cross-device reach. We will be able to compete on VoIP signal quality, innovative “Orbing” (P2P live and pre-recorded video broadcasts by individuals), as well as lower cost base. Skype is facing multiple litigations and is about to either be shut down permanently, or enter very expensive settlement arrangements. Plus, Skype is not in control or ownership of Global Index technology, the node forming augmentation of delivery system which they push to each user computer.
We are actively pursuing venture capital. Please visit for more detail.


Nice article and nice comments. I’m a SIP developer for several years, and I will not defend it. SIP alone can’t replace Skype, because it’s responsibilities are very limited. A large framework should be built on top of it to provide all the neseccary functionality. With Skype, some static infrastructure is nesessary to bootstrap connection to Skype network, this infrastructure is not too heavy, because lots of information is distributed in DHT, like addresses, availability, chat history. SIP itself doesn’t provide any facility like DHT, it should be built on top of SIP. NAT is a big problem, many proposals were made to fix SIP. The main problem is that SIP is extensible, some unknown headers may contain IP addresses and there are no common rules how to replace those addresses. Also, sometimes it will be necessary to relay media stream. All these problems could be solved separatelly, but only combined together into single product they will provide a user experience comparable to Skype. A part of this technology will be SIP, but this technology is very far from SIP. SIP is open and extensible, with products from many vendors able to interconnect with each over. But downside is a lack of capabilities.

Christer Fahlgren

Skype is a clever end-to-end solution for VoIP and communications services.

Having worked with SIP for 5 years (and in Telco Software for 12 years) I think that while there may be some basic interoperability for simple VoIP use cases in RFC 3261 (basic SIP) there are umpteen other RFCs and drafts required for a complete solution where interoperability is a nightmare. Not mentioning that the 271 pages of RFC 3261 leaves much room for interpretation and partial support.

While Skype as a service could theoretically be implemented using SIP, it would be a proprietary solution for all intents and purposes. The benefits of using SIP for Skype would be limited IMHO as it doesn’t really address firewall traversal (well, ok, in umpteen overlapping drafts and RFCs…), secure network connections and peer-to-peer discovery.

One of the biggest points of Skype is the peer-to-peer discovery and routing which basically is a research item for SIP. More info here:

Interesting link: Analysis of Skype protocol (from 2004):

Michael Marrs

I also worked in the voip industry for 5 years. My company actually developed or integrated a Vonage like clone. Yes we were sold on VoIP and SIP. You know what?, the users didn’t care if we used SIP or PIS. They just wanted to make phone calls, and we failed because we spent too much energy supporting their firewall and NAT problems. We spent even more money and time doing interop between our ATA (phone adapters) and our SIP core, why? because everyone implemented the SIP RFC to the best of their understanding. SIP is not a standard its a RFC. So then we had to buy Session Border Controllers to manipulate the SIP headers in order to normalize the SIP protocol. So after 3 years we shut down our VoIP service and we disbanded.

Today I work for a large Canadian telco, and SIP and VoIP is just used to replace the SS7 network, and I’m not sure with all the operational issues around it if it saves the company any money. It does save capital relative to legacy equipment, but I don’t think it saves any operating costs.

Jeff Bonforte

Actually agree with Ian on the basics of SIP issues and the promise vs. actuals of ICE/TURN (always disappointing in my opinion). But we figured it out. My point was that the Skype team is incredibly clever and where some have found some success (yhoo/gizmo), they would do better. I am not a SIP defender as much as I am saying P2P has it’s drawbacks and the cost savings is overrated for the big guys, like Skype.

I like Ian. He knows much more about the technical issues than I do. I have lots of practical experience, and have probably supervised as many minutes as anyone in the world that is not Skype. My point is that at 10x scale, Yahoo’s voice business would work better not worse in terms of costs. Yhoo/goog/msft aren’t scared of servers or bandwidth. EBay/Skype are of similar size and shouldn’t fear these routes either.

Duane Storey

And when I say address, I mean IP/PORT pair — that’s the binding NATs make, and why UDP ports are generally random. The Firewall/NAT will understand that 24.x.x.x:5000 will route internally to and 24.x.x.x:5001 will route internally to — that’s why STUN is important — it tells you the binding that the NAT is using to route traffic to you. As long as you advertise that to your peer, you’ll be able to receive traffic at that public address. NATs generally keep pinholes open for 30s or longer.

Duane Storey

Hey Ian,

I think you need to reread STUN and ICE. That’s how NATs work — when you poke a pinhole in the firewall, the firewall understands (based on the IP/port combination) how to route the traffic back to the client. STUN and ICE solve almost all the problems associated with SIP and media traversal. If you’re a user of a corporate network on a computer with a private address (192.168.x.x or 10.x.x.x), you’re still publicly routeable, you’re just behind a NAT (network address translator). Almost nothing in SIP is TCP these days — it’s all UDp.

So when you place a call from inside a Cisco firewall, your SDP (if you’re using ICE) will generally contain at least two addresses. The first is your private address, 10.x.x.x, the second is your public address (which almost every computer has, even though it’s NAT’ed), for example, 24.x.x.x. If you’re making a call on the local NAT, the remote party will use your private address (since it’s routeable). But if not, your public address is routeable behind the NAT. Because you contacted a STUN server to get that address, the Firewall is keeping that port open *just for you*, directing all traffic to you that’s addressed to your IP/PORT pair (that’s what NATs do). So as long as you set up a SIP call within 30 seconds, the traffic will be able to go peer to peer (i.e., directly from your friend to you).

Don’t forget that I worked in VOIP for 5 years, wrote a lot of VOIP software (including pieces of the Yahoo! voice engine) — I fully understand how VOIP works. I’m telling you first hand, you very rarely need to relay traffic via a TCP proxy. Except in the case of a symmetric NAT to a symmetric NAT (i..e a Cisco Pix Firewall), you’ll be sending traffic directly over UDP from client to client, mainly because NATS/Firewalls will do sane things, i.e. keep ports open for at least 30 seconds, making the addresses your advertise in SIP/SDP routeable to your peers.


70% is usually the number of calls that are potentially able to direct connect without relaying.
Although you might need public relays sometimes. XMPP Jingle does that gracefully and without tricks in routing level, proxies etc…
And also in a proper way, not like the SIP workarounds for P2P


@Duane Interestingly, you keep declaring that you disagree and then making statements in agreement with the thesis of the article and my comments. So by all means, disagree away!

About how Skype works, read here to understand how the login process and data model work for Skype.

I don’t understand how you think that if TCP signaling packets need to be relayed, that an RTSP stream from behind your router can arrive to my router via UDP and magically tell it which of the computers on my network was expecting it…

SIP media streaming is peer-to-peer only when both clients are directly routable to each other (ie. public, or on the same subnet). The documents you are likely reading are SIP primers and are factually correct until you factor in how the internet actually works today — a rabbit’s warren of firewalls, private IP addresses, etc.

Duane Storey

I don’t agree at all Ian. Skype also requires publicly addressable supernodes as well as its boot strapping process when you login, so it’s no worse than SIP. You *have to have* a public rendezvous in many NAT cases, or it simply won’t work.

In almost all cases, media traffic for SIP calls goes peer to peer — it doesn’t use a rendezvous at all other than for the signaling.


@duane You’re missing the point.

In the real world SIP *requires* a publicly addressable rendezvous… moreover, it requires that rendezvous to be owned and operated by the SIP network provider. This is exactly the point of the article.

In Skype’s case it has distributed a good portion of this load onto its individual users. And in a distributed peer-to-peer network running machines you never had to pay for you can be as inefficient as you like. The incremental cost to the network core is zero. And in the case where Skype DOES own the SuperNode, they don’t have to buy gear from some third-party vendor — they lust lease a pizza box running the Linux version of Skype in a CoLo somewhere.

SIP explicitly addresses how data gets from point A to point B, typically as informed by a Proxy. It advanced the state-of-the-art over H.323 very little, except that it doesn’t care about what the payload is, the headers are easy to read, and — this is the real bonus — media doesn’t need to travel with the headers as a cohesive unit.

You could use SIP for file transfer, internet radio, or whatever you like between peers — as long as both peers have public IPs and are unencumbered by firewalls. In the practical world you need a middle-man and this is why there are so many vendors offering media proxies which implement STUN etc.

Duane Storey

@Ian – that’s not really true. SIP has nothing to do with media, it’s just for establishing a session between two peers. As it typically relies on a publicly addressable rendezvous, it’s successful nearly 100% of the time at doing that.

What you really mean to say is that the body of SIP messages, which can be anything (but is typically a SDP blob), fails to properly address how to get media from point A to point B. And like I pointed out, most people do it successfully using STUN, ICE and some form of relay. The computational resources are no worse than what Skype would have I imagine. In fact, if they’re doing a DHT type network, then each peer would have to talk to various peers before establishing a connection (which would make it less efficient).

I spent a week at Google two years ago coding a peer to peer SIP library that used distributed hash tables. I’m not sure where the code ended up, but ideally you could use that to effectively replace the Skype backbone. I’m not arguing it’s better, but it would have been comparable technology with some of the same shortcomings as the Skype network.


Short answer, Patrick: No.

Long answer… anything’s possible.

SIP is so open-ended that when we talk about SIP networks today we’re really just talking about proprietary deployments which utilize SIP as an addressing/locator schema and media wrapper.

SIP only knows how to establish a point-to-point connection between two public IP addresses. So while SIP is indeterminate insofar as media type, it is wholly responsible for determining how media gets from A to B. This is where it falls down.

Technologies like STUN, TURN, ICE et al (from Paradial or any other vendor) are merely hacks which solve the NAT issue while allowing networks to still use SIP. They do this by connecting two connections and bridging them. I have a little knowledge in this area — I helped architect precisely the same thing for H.323 while at Cisco.

And yes, while Gizmo Project and YahOo both implemented SIP (as does iChat) none of these is doing anywhere near the 8-9 billion minutes of peer-to-peer calls per month that Skype is. And if they did, the computational resources required to bridge them would be formidable.

I too believe that Skype has significant investment in hosting their own supernodes but have yet to see anything that convinces me there’s a better way to scale that is addressed by another SIP-derived alternative.


Sure the SIP Proxies replace the Skye Supernodes. NAT seems to be the problem and is likely solvable. The cost for a network of Proxies is manageable. It sounds like a fun project.


Thanks for the article. The technical backgroud on the way Skype works is fascinating.

Pushpendra Mohta

On this narrow point:

“Forgetting about the exponentially more costly business of sending voice or video data across networks, 70 percent of traffic on XMPP instant messaging networks is the result presence updates. Some estimates are that as much as 60 percent of this information is itself redundant. Servicing the traffic on a network such as Skype’s, which consists of some 45 million daily users, would bury most startups in server and bandwidth expenses.”

AOL/AIM, MSN Messenger, and possibly Yahoo have existing networks of this scope that handle large amounts of presence updates. There may be a business combination possible where this infrastructure with sunk costs can be used for signaling/call setup and presence, and P2P can be used for actual media ( audio/video). As noted before – media does not always have to be sent in a client-server model so the bandwidth equation does not materially change vs. Skype.

There are portions of Skype that are not fully decentralized either – I am sure Authentication and Billing are “centralized”.

Duane Storey

The concept of Skype as a distributed network is a bit overhyped in my opinion. To prove that, you simply have to block around 4 or 5 IP addresses from your computer and watch skype fall over. The bootstrap process requires some known server/IPs in the internet, as well as a host of Skype-run supernodes for the traffic. I saw a talk on this at a SIP BOF during the IET.

As another reader pointed out, SIP isn’t about media, it’s simply used to establish a session between two peers. While traversing NATs is a challenging problem, it’s not really difficult these days. STUN and ICE are both fairly mature (although the later was still in a draft stage a while ago). With those two technologies you can solve every NAT problem other than symmetric NAT to symmetric NAT, at which point you’ll need a tunnelling solution such as TURN. Unfortunately, TURN is still immature, so many companies have down proprietary tunnelling implementations, including CounterPath (X-Tunnels) and Yahoo! (who proxy traffic over their own web servers on port 80 in that scenario).

I spent five years in the VOIP industry, and got out last January. My own take on it is there was (and is) a clear lack of vision. Telcos wanted to use SIP to replace the very architecture they already had, and nobody wanted to entertain ideas about what else you could do with this technology. Plus, the lack of QoS on the public internet basically guarantees that VOIP will almost always be sub-par to traditional telephony. You could argue that wideband codecs make up for that, but since you have to use a headset and not a traditional phone for that, it’s basically only reserved for Internet early adopters and geeks in front of their computers.

Carl Ford

Ian, What no mention of Paradial? It was Paradial and GIPS that made Skype initially.

I doubt that the IPR is much more than something of a tweak on what Paradial gave Skype initially.

I also want to remind you that its hard to take this issue seriously on the IPR side. The issues between managements are something to take serious, but the issue is nothing SIP can fix unfortunately.


Sten Tamkivi – Skype’s chief evangelist was asked about moving to SIP at eComm in Amsterdam last week.
He said “We would need a very good reason” and then explained the benefits of SIP (and Skype for Asterisk) as interconnects at the edges of the Skype cloud -not in the core.

The technology in P2P that is relevant is Distributed Hash Tables, not the actual file transfer protocols themselves.

I did some musing aloud about how you could solve these problems a couple of months back over on my babyis60 blog.

Jeff Bonforte


“Forgetting about the exponentially more costly business of sending voice or video data across networks, 70 percent of traffic on XMPP instant messaging networks is the result presence updates. Some estimates are that as much as 60 percent of this information is itself redundant. Servicing the traffic on a network such as Skype’s, which consists of some 45 million daily users, would bury most startups in server and bandwidth expenses. Add to that the actual messages themselves, and having to handle the voice channel or video at the core, and it becomes clear that only the big boys get to play in distributed communications services.”

(a) SIP doesn’t require you to carry the voice via your bandwidth, just the signaling. There are some number of calls that would need the media to be sent via the company bandwidth. This paragraph exaggerates this costs.

(b) The cost isn’t as high as you suggest. Skype could afford to have SIP infrastructure. I know this having worked, as you know, for a two VoIP companies that did use SIP (Gizmo and Yahoo!), and did shoulder more of the costs for calls and video that Skype does…and it was profitable. Considering we didn’t have the same scale as Skype with Gizmo, we were still profitable. At Yahoo! we had probably similar scale as Skype as a whole and were very profitable on voice calls (free and premium combined).

It is clear you have a deep technical understanding of the issues. But Skype could work fine with a SIP infrastructure. P2P is helpful in deferring some of the costs, but it is certainly not necessary to make the business work or even thrive. Skype has a bunch of great technology and smart engineers. Those smart people can make Skype work via a standard protocol with some of their magic, given the state of things today (less true when they started back in 2003/4).

Comments are closed.