If you and your company are involved in Voice over IP and Unified Communications then there's no doubt you'll have heard about SIP (the Session Initiation Protocol). You may be (even a little bit) excited about all the things it promises to achieve by enabling multivendor products and services to work together. However, sometimes it's good and even necessary to just stop and look closely at what's actually happening with SIP, who's using it and what lies ahead for this most disruptive of protocols!
So let's start by asking,
What is SIP?
Well, SIP is boring!
Ok, to me it's not boring. However to people who simply want to make phone calls and use IM or their Unified Communications client to 'reduce human latency' (yes, that's a real UC benefit) it's not really something they care about. Who wants to talk about signalling protocols, new SIP methods and the work of the IETF working groups? Not your customers that's for sure - all they want to know is will it work, how much and will it save them money?
Who's using it and Why?
In reality a lot of people are using SIP without really knowing about it as it is replacing a number of existing proprietary protocols in IP handsets, PBXs and of course is starting to displace digital trunks. Yes, I know that it doesn't provide all the features that a 'proprietary' protocol does. SIP can help in cutting PSTN access costs, integrate voice, presence, messaging, and video services for a great Unified Communications solution. Include the possibility of tying all of these services to business process applications; surely that beats the need for some obsolete phone feature that is pointless supporting anymore.
So, how is it developing?
It's the responsibility of the Internet Engineering Task Force (IETF) and its working groups to see that the protocol is developed in a structured manner, making it easy for companies to implement SIP in their products. This, as we all know, has not been plain sailing, hence the need for Interop testing to make sure things work together. Of course Interop testing is something that should continue to be done. It is interesting though that at an IETF conference (in 2008), one of the lead architects of SIP (Jonathon Rosenberg of Cisco Systems) suggested that instead of forging ahead developing SIP using the original concept of it being a pure Peer 2 Peer (P2P) protocol, the many SIP 'working groups' should take into account that SIP is rarely deployed this way and should maybe focus on making SIP work better when there are things like NATs, Firewalls and Session Border Controllers in it's path. This is an 'enlightened' suggestion and shows that 'Real World' experiences can effect the ongoing development of the protocol.
To build on this great work being done, the Basic Level of Interoperability for SIP Services (BLISS) working group has the charter of documenting variations of SIP implementations including interoperability issues in order to help companies develop products to work better in a heterogeneous environment.
Providers of the Service
It's hard to ignore that there are so many providers now offering SIP trunking services, a great thing for customer choice and flexibility. Continue Reading...
