May 20, 2005

Why SIP Isn’t Good Enough For Skype

Immediately after deploying Skype, its CEO defended their decision to use a proprietary system rather than use the SIP standard. He was widely quoted as having dismissed the SIP option to be inferior. This has sprung up in Skype Forum. Muppetmaster informs us that one of the Skype configurable parameters is labeled SipServers and an item under it is called DirectlyConnected. He goes on to suggest that this is evidence that Skype client runs SIP when it wants to interconnect to PSTN. A few days back DGLewis raised this same point. In that context I commented that there are operational benefits in Skype client following the same procedure independent of whether the call terminates at PSTN or not. This entry does not revisit that issue, but explores why Skype may not be satisfied with SIP and concludes that SIP can easily accommodate these requirements.

A communications protocol needs to identify the end-points involved in the session, specify the mode and format of the communication and finally identify any network resources it may want to use during the session. All protocols do these in one form or another. Q.931 of ISDN and H.323 are competent in this respect, contradicting the widely held belief. SIP does these as well. So what are missing from SIP (or for that matter H.323) that Skype would need. I can think of two things.

The first one is these protocols use UDP to transport the media packets, but many firewalls block UDP traffic. In these cases, unlike the standard protocols, Skype uses TCP in these cases. This is counter to the established security policies and hence it is not advisable that standard protocols be extended to use this scheme.

The second one involves NAT traversal. The standard scheme is to use Session Border Controllers and use UDP Hole Punching for optimization purposes. The two standard protocols use one set of port(s) to carry the signaling information and other port(s) to carry media. Because of this, the optimization scheme does not work if even one of the end-points is behind an asymmetric NAT. On the other hand, if the media port can receive limited signaling information then we can devise a method by which the optimization procedure will work as long as both the end points are not behind asymmetric NATs. Interestingly, according to Baset and Schulzrinne, Skype does not use this scheme.

So it is not clear what Skype achieves by using a non-standard signaling protocol.

Posted by aswath at May 20, 2005 09:37 AM
Related Posts Widget for Blogs by LinkWithin
If you do not have an OpenID, then please use www.enthinnai.com/unauopenid/anyblog.

 

Comments

Maybe there's a division here between "SIP the abstract protocol" and "SIP the API implementation reality". The problem Skype has is that everything is so dynamic and unstable in its environment; all the proxies can come and go, timeouts might take forever, nodes may partially fail. So perhaps to be able to set up a call and keep it up they've had to re-implement the same basic concepts, but also optimise it to take account of the rotten network environment. Cached data might be passed up and down chains of proxies and supernodes, multiple responses/options ("he could be here, here or here") included where standard SIP might only offer one, etc.

This is just a SWAG based on my Oracle experience and I have zero evidence.

Posted by: Martin Geddes at May 20, 2005 12:07 PM

What if the whole thing was deleberatly done for misleading the user?
How can you say to have an innovative technology and then using what all others used since long?

In principle Free World Dial up was there much before them and so VoIP.
I do not think they invented the hot water, they just used it in a most clever way and built a very good market product out of it.

How long it will last that has still to be seen as how much revenue it will produce.

Patrizia

Posted by: Patrizia at May 22, 2005 02:36 AM

Martin:

Pursuing your line of thought, data exchanges between proxies and supernodes could have been done outside of SIP (after all SIP is "immensely extendable"). Also, won't forking have handled the scenario you are alluding to in your comment? My puzzle is given that under normal conditions Skype provides directory service and assists in NAT traversal, why SIP is not sufficient. IF I want to replicate Skype, then I need to understand this.

Posted by: Aswath at May 22, 2005 07:34 AM

Patrizia:

They are probably misleading the industry players and not users, for users are getting the service they were promised. Even though FWD and other VoIP players have preceeded Skype, we must recognize that Skype is the first one to use wideband codec. All the others were busy imitating POTS (not just PSTN) both in the technical architecture and in their business models. I agree with the uncertain economic viability; but then it is true for all VoIP service providers.

Posted by: Aswath at May 22, 2005 07:39 AM



Copyright © 2003-2014 Moca Educational Products.