One of the largest difficulties people with a strong telecom background have when first encountering SIP is understanding that SIP is not just “another telecom protocol.” From the advent of automatic switching in the early 1900s, telephones have operated in a rather predictable way: the phone communicated hookstate and dialed digits to a central office, and the central office told the phone when to ring. All of the intelligence lived in the network, so that’s where the services lived.

This changed slightly with the introduction of mobile phones, which needed to know a bit more about what was going on with the call. But the protocols used by mobile phones were designed to closely mimic the way early-20th-century phones worked – all the way down to having a “hook flash” message.

So, as long as you’re younger than 100 years old, anything you ever learned about telecom protocols generally had a direct conceptual translation into the protocols that came after it. Electromechanical exchanges gave way to channel-associated MF switching, which eventually evolved into digital switches; but the basic flow of information remained unchanged. Services always had to live in the network, because that was the only place smart enough to do anything useful.

SIP changed all that.

SIP’s model for service interaction was not the telephones of the 1920s; it was that of the Internet. On the Internet, applications run in the clients, so that’s where the intelligence is. The network’s job is to route traffic efficiently and otherwise stay out of the way. For example, if you look at the various ways that three-way calling can be implemented, you’ll notice that the key players are the SIP terminals, not the network.

This is a radical shift, and it means that everything you know about telecom protocols no longer applies. It means that questions like “how do you interwork SIP with CAMEL?” don’t just lack answers, but actually make no sense at all. You’re asking how the network can provide services in a protocol that relegates services to the client. It’s the functional equivalent to asking, “how do you implement call waiting in a old-fashioned PSTN phone with no support from the end office?”

That’s not to say people don’t try to find answers to these questions. Many a SIP network architecture has been designed to emulate, as closely as possible, the PSTN. Most of the time, these networks require proprietary extensions to SIP and ridiculous contortions to fit SIP’s round peg into the PSTN’s square hole. The end result is a network that cannot live up to SIP’s promise of advanced services and interoperability, while having a tortured time of even providing the same basic services the PSTN can already provide.

What this means is that, when thinking about how to provide services in a SIP network, you must step back and ask “what is the problem we’re trying to solve, and how do we solve it with the tools that SIP provides,” instead of staying focused on how to directly translate the existing protocols into SIP procedures. Otherwise, you’ll end up asking nonsense questions and proposing ridiculous solutions.