Recently in The SIP Protocol Category

SIP, a reality check

July 13, 2009 4:41 AM | 0 Comments

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. Also in view of the current economic climate it is a good way to offer customers a more economic alternative to traditional digital lines.  This is good news if things work well but if not then customers will get frustrated and complain about being sold a technology that's not mature enough.  Well, how can you ensure things run smoothly?  A good start point is checking if PBXs and other SIP systems as well as SIP Trunks are 'SIP Connect' compliant.  This is a great recommendation from the SIP Forum that attempts to make connectivity issues a thing of the past, so go to their website and read all about it.

Get tooled up

So as SIP is the 'plumbing' that makes things work and you call a plumber when your boiler breaks, doesn't it make sense to call a SIP expert to fix your SIP/Communication problems?  Why not go one step further and get a SIP expert involved in the early stages such as planning and network design. This way they can advise on the right combination of products to use to meet your needs plus give you critical advice on what to do when adding new SIP services to your network. This ensures that you don't break your existing infrastructure. 

So much more to say

As I said earlier, it is often necessary to stop and look at what is really happening with SIP and by doing this you'll put yourself in a great position to understand what vendors are doing with their products and maybe see if everyone is working toward the ultimate goal of true interoperability or if everything is interoperable as long as it's from one manufacturer.  We'll see.

So you are looking for a winner of the Instant Messaging protocol debate are you?  Well, keep looking and maybe it will become clear over the coming years because XMPP has just gained another supporter, Yahoo. See this article on CNET.  We think this is good for interoperability between other XMPP based services as no translation services would be needed - so Google Talk (also based on XMPP) should 'in theory' interoprate with whatever Yahoo! do.  So far so good.

But what about SIP/SIMPLE?  Well the IMPP working group came up with a Spec/Set of rules/whatever you want to call it (the CPP actually) that defines how IM protocols should map to each other so that 'islands' of IM systems don't have to stay as islands and SIP/SIMPLE / XMPP systems can interoperate - just see what Jabber are up to to clarify this.

So is SIP/SIMPLE doomed because Yahoo and Google may end up on each others buddy list?  Well no, due to the fact that every Telecoms manufacturer I can think of (Mitel, Siemens, Nortel, Panasonic, Avaya etc. etc.) all use this protocol in their Unified Comms/Messaging products and are unlikely to switch.

So for now, no winners just two big players who should play nicely together (Hopefully).

Hitch Hikers guide to SIP

August 5, 2008 4:48 AM | 0 Comments

Ok, this is an old (2006) but great doc that you should have a look at if you want to get to grips will all the relevant RFCs related to SIP.  Written by Jonathan Rosenburg and posted here  ... Download it and have a read, it will save you a lot of time by stopping you reading RFCs that are no longer relevant or have been replaced.  Though keep an eye out for new drafts on the IETF website as things are always changing.

Find Me Elsewhere

Recent Activity

Today

  • Graham Francis tweeted, "+sip Get onto Voicecon TV, lots of great keynotes / interviews if you are into Telecoms.... http://ow.ly/ABRm"
  • Graham Francis tweeted, "A buddy of mine has some Google Wave invites left, if interested - let me know and I'll forward to him"
  • Graham Francis tweeted, "@charlesnw Makes you think about it, though they've done the deal now so they can take their time - panic over :)"

Wednesday

  • Graham Francis tweeted, "+sip Great standard support from snom - nice one! TR-069 http://ow.ly/xfAP"

Tuesday

  • Graham Francis tweeted, "+sip .. Report stating the obvious... Of course SIP trunking deployments are going to rise... http://ow.ly/xfAi"

Today

  • Graham Francis tweeted, "+sip Great news for HD voice, Voxbone and Skype... http://ow.ly/xfzi"

Friday

More...

Subscribe to Blog

Recent Entry Images

Blogroll

Around TMCnet Blogs

Latest Whitepapers

TMCnet Videos