First off, I’m not trying to bash SIP, merely explore some of its possible shortcomings.
After having had a very interesting conversation with someone in the VoIP security/resiliency field, I got to thinking more about this.
SIP by its very nature might not be well suited to enhance communications because it isn’t a very stateful protocol. There’s the initial setup, and unless some feature needs to be performed on a call, the RTP stream is about the only thing out there. Because of it’s very transactional nature, this makes it difficult to truly manage, compared to something like SS7.
A more stateful/windowed approach to a protocol might be more practical, something similar to the constant communication Cisco has with its phones when using SCCP (Skinny). This would allow better tracking and capabilities through firewalls, proxies, SBC’s and the like. This better approach may also allow better security simply because the call would be truly “active” (RTP bearer stream and an active control channel). This could facilitate alternate routing such as what SS7 does with its separate paths for call control and bearer traffic. For me it is almost ironic, because I used to frequently bash SS7 as inferior for having split paths. I can admit I was seriously misguided.
Don’t get me wrong, I think SIP is a great thing. It promotes open-source applications, a great developer community, and (at least for now) some decent vendor interoperability. SIP has brought us things like Vonage and Skype which have facilitated communication far beyond what some people twenty years ago might never have thought possible.
I simply think we need to take a closer look at what we want from our networks going forward.
We need security.
We need reliability (gobs more).
We need functionality.
We need to be able to monitor it all, no matter where it is.
Is this too much to ask?
Mark this point….
I think this article was interest for you….