SIP standardization has come a long way. Basic SIP calls “always” work right? OK let’s be honest. Oftentimes, interoperability still poses a challenge. Such ISDN features such as COLP (Connected Line Identification Presentation), AOC (Advice of Charge), and so on can be especially troublesome.
This post is part II in a series about ALL-IP service deployment. Part I covered the topics Quality of Service (QoS) and Security in ALL-IP telephony solutions.
>>Read it here…
Regarding the SIP “standard” there are in fact today over 80 RFCs and over 30 drafts in progress.
For many SIP features there are several ways to implement them and there remains – as with all standards – room for interpretation and bugs.
Some interest groups have started to define “meta-standards” which recommend which RFCs should be implemented and how. Nevertheless SIP has a long way to go before it becomes plug-and-play.
SIP normalization is the SBC feature which helps to resolve this problem. It basically translates between different SIP dialects. While big core SBCs are able to handle thousand of sessions and effectively protect the core infrastructure, they are less apt at dealing with the protocol differences of dozens or hundreds of IP Phones or IP-PBX systems installed at the customer premises.
So once again, an eSBC (enterprise session border controller) is the best way to close that gap.
Upcoming posts in this series will cover such topics as SIP survivability and legacy phone support. So stay tuned, or even better…
>>For a comprehensive treatment of how eSBC technology can address the challenges associated with ALL-IP implementation, get the Patton White Paper:
Who Needs an Enterprise Session Border Controller?
What do you think?
- Have you had any trouble getting your SIP based phone system to work together with a SIP trunking provider or ITSP?
- How important are the specialzed ISDN features to your business phone system? Do they work?
Add your thoughts in the comments below…