SIP- all that it’s cracked up to be?
by Vik Malhi
|
Vik Malhi
 Bio:
Vik Malhi CCIE #13890, CCSI #31584, Senior Technical Instructor - IPexpert, Inc. Vik has also contributred the following articles to the CCIEFLYER:
|
I last wrote an article for the Flyer at the tail end of 2008 and a lot has happened since then. The economy has picked up, the markets are looking good and house prices are nearing their 2006 peak. Life is very rosy in this newly found buoyant market.
Ok, Ok- calm down. I’ve had my head firmly implanted in some sand for two months working on preparing the new edition of the CCIE Voice training materials and feel like I’ve been stuck in a dark room left all alone with my Unified Communications Manager (a.k.a Callmanager) and a few routers and phones.
If you have any involvement with IP Telephony in the past few years you will have most probably jumped onto the SIP (Session Initiation Protocol) bandwagon at some stage. Having been isolated in the world of Skinny (Cisco’s proprietary protocol that IP Phones use) for the past 4 years it was with great anticipation that I began the task of integrating SIP endpoints with the existing Cisco IPT infrastructure which is primarily based on Skinny, on the line side, and H323 and MGCP, both of which are predominant on the trunking side.
In short- what an anti-climax! Whilst SIP is most definitely the flavor of the month on Asterisk (the leading open-source IP-PBX) the conclusion I have drawn from 2009 thus far is that SIP phones and Cisco are not quite ready for each other especially as it’s sister protocols are that much more mature and elegant. Yes SIP has advantages as a protocol in the carrier and service provider world not to mention the whole Presence thing being built using SIP. However the previous statement certainly holds true on the line side- getting a phone to register to CallManager Express (CME) using SIP is an ordeal that I hope you are all spared from. Using Skinny is very much the preferred option in my eyes if nothing else for the ease of provisioning and administration.
SIP trunking is becoming the more prevalent method for ITSP’s to provide their customers with PSTN connectivity as opposed to the traditional approach of provisioning traditional ISDN circuits at the customer premises. Once all the teething problems are over, this seems to be where the future of public access lies. Companies such as Verizon have been offering their customers SIP trunks for quite some time and I know they have had numerous problems with providing feature parity next to the ISDN circuits. Why is SIP trunking the topic du jour for so many?
Well it all comes down to cost cutting- theoretically the time and cost to provision public voice access over a data circuit is much lower thereby allowing customers to benefit from reduced ongoing charges as well as enhanced services which eventually are supposed to lead to increased productivity. All you need is an IP-PBX (such as CallManager), a Border Element (Cisco Unified Border Element a.k.a CUBE which just so happens to be built into IOS) that acts as a termination point or proxy for the voice traffic that flows between the Enterprise and ITSP and finally sufficient bandwidth to meet your data and voice requirements. It’s that simple.
SIP becomes even more interesting when we start to talk about cutting out the ITSP altogether. Why pay per minute call charges when you’ve already paid for the bandwidth- aren’t they charging twice? This off course is a simplistic view of life since somebody has to pay for the capital expenditure this new technology requires. However, it is only a matter of time before SIP peering really explodes into life- this allows resolution of telephone numbers that are assigned to remote SIP endpoints without the need for an ITSP to route the call through a public network and in effect exempts callers from legacy per minute billing! The whole telephone number to ip address mapping (known as ENUM) uses an existing resolution technology that is fairly widely used- DNS. Isn’t it surprising that somebody has the great idea to use existing protocols and infrastructure rather than the usual reinventing of the wheel!
SIP has some way to go to overcome interoperability issues and its ability to provide traditional telephony services- H323, the ITU competitor of SIP, is a more mature protocol that has the methods for providing the telephony services more rigorously defined. However going forward SIP (an IETF defined protocol) seems to have the upper hand on H323 given the ease with which developers are able to build new services such as Presence and Instant Messenger applications which are largely based on SIP.
Return to the top of 'SIP- all that it’s cracked up to be? '.
Send Feedback