SIP for Skype

Let's put it straight. Skype was the simplest telephony service ever. Period. And that's perfectly ok.

Frankly, building a Skype-like service is damn easy. Hopefully, now since it is gone and not anymore a potential easy-to-buy target, it will wake up some people in decision positions from the major telephony operators.

It's just lately Skype added video group chat, but what was the rest?

• audio conversations directly between two people
• instant messaging between two people
  
• audio group chat (audio conferencing)
• multi-user chant (group chat)
• desktop sharing
  
• contacts list (buddy list) with presence states (offline, online with sub-statuses like away, do not disturb, a.s.o.)
• secure communication - encryption for all cases above
  
• interconnect to other networks (PSTN and SIP)

In the core network were just the group of authentication servers with the storage for accounts data (user profiles) and the gateways to break out to PSTN and SIP. There was nothing else done in the Skype core network, everything was done in the client side, offering peer to peer communication model. To localize and make possible to have the conversation with the called person, some instances of the client applications were acting as supernodes, guiding the signaling and media streams.


That's all folks!

Now, let's look at the SIP side. It was designed to be able to establish peer to peer real time communication (RTC) sessions over IP networks. Here is the classic SIP trapezoid:



The difference to Skype implementation is in essence that the core network servers do location services along with authentication and storing the user profiles. But the rest is practically identical as concept. Simple and straight.

What it takes to build a service such as Skype with SIP?

Here is the same bullet list saying if it is possible and how, exemplifying with open source applications (therefore very cost effective to design the service and deploy the components):

• audio conversations directly between two people - yes, the very basic concept in SIP. Client applications, lot of them, e.g.,: Jitsi, Ekiga, Linphone, ... Server applications: Kamailio, Asterisk, FreeSwitch, SEMS
  
• instant messaging between two people - yes, the end to end model using SIP MESSAGE request, widely supported. Client applications: Jitsi, Ekiga, Linphone. Server applications: Kamailio, Asterisk, FreeSwitch
• audio group chat (audio conferencing) - yes, most client applications can do 3-way conferencing (small conference of 3 people), then Jitsi can do multi-user conferencing. In addition, instances of applications such as Asterisk, SEMS or FreeSwitch can be used as dedicated conference bridges, where anyone with a SIP capable phone can dial in and join group conversations.
  
• multi-user chat (group chat) - yes, server side with Kamailio in a not standardized way, just reusing the SIP MESSAGE to carry the chat content and imc module to control the members of the chat room. Client applications can be also the host of multi-chat room.
  
• desktop sharing - yes, use Jitsi as client and Kamailio as server
• contacts list (buddy list) with presence states (offline, online with sub-statuses like away, do not disturb, a.s.o.) - yes, client application: Jitsi. Skype model is SIP end-to-end presence model which is very simple from server side application point of view. The SIP end-to-end presence is implemented in many other SIP client applications. Server side: Kamailio. Contact list can be managed locally or via XCAP. Jitsi is a very good client application for both. When XCAP is used, in server side you can use Kamailio with embedded XCAP server.
  
• secure communication - encryption for all cases above - yes, via TLS for SIP and SRTP for media stream. Using Jitsi and Kamailio can be an example of doing such communication. Servers can run on different ports that will help going through firewalls and the TLS will ensure nobody can detect it is SIP.
  
• interconnect to other networks (PSTN and SIP) - yes, numerous SIP-to-PSTN gateways or termination providers
  

Actually, looking at the points above, SIP as it was at its early stage of specifications (call setup, instant messaging and presence) is far more closer to Skype communication model than the latest IETF/ITU published specs in regard to SIP.

Where is the problem in IP telephony? Why no big telecom which had the infrastructure and the financial resources could do any revolutionary step in IP networks? Because they don't think simple and don't look at what is important for the most of the users nowadays. All that matters so far for operators (based on my 10 years in the area) are the roaming/inter-connect fees and the set of 500 old PBX features, which are not used more than 2 percent anyhow in a daily basis, and 95% were never used probably.

The change for a proper evolution would be very simple technically, practically is the hardest: because that's about the change of mentality and concepts.

First, stop pushing new SIP specifications with very complex architecture! They don't help neither implementers nor operators. Roll back to the basics of the SIP, it is really a good protocol for RTC. Forget about compressing signaling, bandwidth issues, gran'ma love to 10 digits dialpad, battery life, a.s.o., they are the false problems for you right now (btw, gran'ma loves to see gran'kids on the screen). Get out simple to use services, bring on board new customers with that. Start listening to young and enthusiastic minds, they know what they like to make their life easier, they have the future ahead. Just as that: build the services for your kids.

If you keep talking only with the classic telephony vendors, then the chances to evolve and develop new ways of communication through your companies are close to zero. It could be the Skype protocol "the one" for the future of telephony, it could be XMPP, or SIP can stay in for that, but that is the least relevant aspect.

The winner will be the proper model, not the technology behind it. Definitely the classic telephony is not that!