Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Article: Could SIP Really Save Skype?
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  6 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Steve Song  
View profile  
 More options Nov 3, 8:00 am
From: Steve Song <steve.s...@shuttleworthfoundation.org>
Date: Tue, 03 Nov 2009 15:00:33 +0200
Local: Tues, Nov 3 2009 8:00 am
Subject: Article: Could SIP Really Save Skype?
Interesting article on Skype architecture and why straight-up SIP will
never match it.

Skype's supernode technology sounds a bit like what we are beginning to
discuss around traffic aggregation.

-Steve

-----------------------------
Could SIP Really Save Skype?

http://gigaom.com/2009/11/01/could-sip-really-save-skype/

Could SIP Really Save Skype?

By Ian Andrew Bell <http://gigaom.com/author/gigaguest>  | Sunday,
November 1, 2009

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
<http://gigaom.com/2009/04/14/will-joltid-turn-ebay-dream-of-skype-ipo...>

with current Skype owner eBay and its potential purchasers
<http://gigaom.com/2009/09/02/who-invested-how-much-to-buy-skype>. 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)
<http://en.wikipedia.org/wiki/Session_Initiation_Protocol> could be
Skype’s savior
<http://gigaom.com/2009/03/22/skype-now-means-business-friends-the-sip...>.

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
<http://gigaom.com/2009/10/29/voip-ringing-up-billions-in-sales> were
busily attempting to re-architect the telephone network in the
Internet’s visage. A number of these services, including two from
entrepreneur Jeff Pulver <http://jeffpulver.com/> — Vonage
<http://www.vonage.com/> and Free World Dialup
<http://www.siptosip.net/> — 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
<http://en.wikipedia.org/wiki/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
<http://gigaom.com/2008/11/02/who-killed-the-voip-revolution>.

*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 <http://en.wikipedia.org/wiki/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
<http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protoc...>

and Jingle <http://xmpp.org/extensions/xep-0176.html>.

If adapting SIP to the vagaries of the modern Internet sounds expensive,
it is. By 2006, Vonage had already burned through
<http://venturebeat.com/2006/06/05/roundup-option-scandal-spreads-vona...>

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
<http://mail.jabber.org/pipermail/standards/2006-May/011158.html> is the
result presence updates. Some estimates are that as much as 60 percent
of this information
<http://mail.jabber.org/pipermail/standards/2006-May/011182.html> 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
<http://wyliemac.blogspot.com/2007/03/how-skype-works.html> 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/ <http://www.ianbell.com/> is creator of the team
management service rosterbot.com <http://www.rosterbot.com/>

--
Steve Song
Telecommunications Fellow, Shuttleworth Foundation

email:   steve.s...@shuttleworthfoundation.org
work:    +27 21 970 1220
mobile:  +27 83 482 2088
skype:   steve_l_song
blog:    http://manypossibilities.net
twitter: stevesong


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Raphaël Jacquot  
View profile  
 More options Nov 3, 8:12 am
From: Raphaël Jacquot <sxp...@sxpert.org>
Date: Tue, 03 Nov 2009 14:12:54 +0100
Local: Tues, Nov 3 2009 8:12 am
Subject: Re: Article: Could SIP Really Save Skype?

On Tue, 2009-11-03 at 15:00 +0200, Steve Song wrote:
> Interesting article on Skype architecture and why straight-up SIP will
> never match it.

> Skype's supernode technology sounds a bit like what we are beginning to
> discuss around traffic aggregation.

> -Steve

the funny part is that the traffic aggregation stuff is already at work
in RFC5456... (which is also much more nat friendly than SIP)

    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Alexander Chemeris  
View profile  
 More options Nov 3, 8:18 am
From: Alexander Chemeris <alexander.cheme...@gmail.com>
Date: Tue, 3 Nov 2009 16:18:53 +0300
Local: Tues, Nov 3 2009 8:18 am
Subject: Re: Article: Could SIP Really Save Skype?
Hi Steve,

On Tue, Nov 3, 2009 at 16:00, Steve Song

<steve.s...@shuttleworthfoundation.org> wrote:
> Interesting article on Skype architecture and why straight-up SIP will
> never match it.

Article is very much superficial.. E.g. author seems to forget (or don't know)
that there are other distributed hash table implementations, many of which
are open and freely available. Also he misses the fact that there is an ongoing
effort to create P2P SIP. Just google for this term - p2psip and you'll suddenly
find even IETF working group on the topic.

Also, Skype's success was not *just* technology, but rather GUI and its
easiness to install. It just works.

> Skype's supernode technology sounds a bit like what we are beginning to
> discuss around traffic aggregation.

Well, that's an interesting analogue, yet I think physical mesh network has
different demands then logical. What Skype actually solved with super-nodes
is NAT issues, not traffic aggregation.

--
Regards,
Alexander Chemeris.


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Alexander Chemeris  
View profile  
 More options Nov 3, 8:23 am
From: Alexander Chemeris <alexander.cheme...@gmail.com>
Date: Tue, 3 Nov 2009 16:23:18 +0300
Local: Tues, Nov 3 2009 8:23 am
Subject: Re: Article: Could SIP Really Save Skype?
Hi  Raphaël,

2009/11/3 Raphaël Jacquot <sxp...@sxpert.org>:

> On Tue, 2009-11-03 at 15:00 +0200, Steve Song wrote:
>> Interesting article on Skype architecture and why straight-up SIP will
>> never match it.

>> Skype's supernode technology sounds a bit like what we are beginning to
>> discuss around traffic aggregation.

>> -Steve

> the funny part is that the traffic aggregation stuff is already at work
> in RFC5456... (which is also much more nat friendly than SIP)

Oh, so they finally got to standardize IAX2. Good news!

Yet, as we discussed earlier, IAX2 does not suite MP needs very well,
because it offers only end-to-end traffic aggregation, while MP needs
hop-to-hop aggregation. I think it can be used if we build a real p2p
network, in the sense of p2psip, but it seems for me, this will greatly
increase load on the network and MP's CPU. And after all, that's not
what we want, because you'll face problems with billing, etc then.
IP-level hop-to-hop aggregation looks much more promising.

--
Regards,
Alexander Chemeris.


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Raphaël Jacquot  
View profile  
 More options Nov 3, 8:29 am
From: Raphaël Jacquot <sxp...@sxpert.org>
Date: Tue, 03 Nov 2009 14:29:21 +0100
Local: Tues, Nov 3 2009 8:29 am
Subject: Re: Article: Could SIP Really Save Skype?

you could probably add an iax2 daemon to split / aggregate on each
node...

    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Antoine van Gelder  
View profile  
 More options Nov 3, 9:42 am
From: Antoine van Gelder <anto...@7degrees.co.za>
Date: Tue, 3 Nov 2009 16:42:18 +0200
Local: Tues, Nov 3 2009 9:42 am
Subject: Re: Article: Could SIP Really Save Skype?

On 03 Nov 2009, at 15:18 , Alexander Chemeris wrote:

> ... there are other distributed hash table implementations, many of  
> which
> are open and freely available.

I've still got OpenWRT packages for:

   http://www1.cs.columbia.edu/~salman/peer/

...if anyone has free time to play!

:-)

  - antoine

--
http://7degrees.co.za
"Libré software for human education."


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google