Talk has become so cheap that we don’t want to talk about cheap talk any more. Well, that was the idea of SIP, to truly move beyond voice, beyond network boundaries of the past and free us from the shackles of that dull, boring Voice. But that does not seem to be the case in the operator networks of today, at least for now. Every SIP conversation that I have had with operators, every real SIP deployment that I have come across in an operator network, I hear voices!!!
Voice-centric SBC’s that are grumbling because they cannot lift the heavy load of voices… unhappy softswitches confined to the voice core, MSC Servers trying to pick between BICC and SIP to carry voice signaling, confused IMS trying to figure out its raison d’être beyond voice…
The reason for SIP was never to replace something that is working fine, but it got trapped somewhere along the way to become voice focused. This is to be expected. Despite the continuing decline in the potential of voice revenue, it is still the cash king for the service provider. Operators (maybe with a few exceptions) will continue to invest in new technology such as SIP in their voice networks for a few more years.
But that is not my concern. In my view, what seems to be not right is that we are building these SIP networks with an architecture that is too voice-centric. The burden of voice may be too heavy to lift when it comes time to go beyond voice.
A few examples:
Deploying border devices that break the end-to-end transparency of a session (read Jiri Kuthan’s blog posting – “Back-to-Back User Agents (B2BUA) Considered Harmful for Service Providers“).
Network implementations that combine the media functions with Session Controllers in a single box. Many of the scalability issues we are seeing with SBC deployments are due to this fact.
Network implementations that combine the SIP UA functions (MSC Servers and Softswitches) and SIP Proxy/Routing functions (SIP Signaling Routers). These two functions not only scale differently, but also have different dependencies from a network evolution perspective. SIP UA have some media dependency (for example an MSC Server deals only with Voice and SMS) where as SIP Routing functions are independent of media and access.
SIP is just a protocol, but its power comes from some underlying architectural principles that are more important than the bits and bytes of a protocol. Our near term goal may be to solve a Voice problem. But this should not dictate the future network architecture that will be the foundation for multi-media communication services. A few key principles to look for in a SIP network design:
- Avoid breaking end-to-end transparency at the service layer
- Decompose independent functional blocks that scale differently and have differentevolution profiles
- Reuse functional components (Horizontal model of IMS versus Silo model) for multiple media and service compositions
Have you come across problems in the network that resulted primarily because some core architecture principles were compromised? What were those core architecture principles? How could that have been avoided? I would like to hear from your experience.