We’ve already touched on how signalling in the PSTN has evolved from its analog origins advanced. Now let’s analyze the architectural principles behind the telephone network and how they differ from those used to design the Internet. This comparison will go a long way toward explaining why SIP is a true revolution, and not an evolution of existing signalling systems.
Two main architectural differences exist between the PSTN and the Internet:
■ Intelligence in the PSTN is concentrated in the network rather than the terminals.
■ Access to the network and the services provided are tightly related.
Intelligence Inside the Network SS7 makes a clear distinction between terminals and the network. It operates in the network—trunk sig-nalling—while other protocols like DSS-1 bridge the network and its ter-minals. SS7 proposes an architecture that enables the use of very simple terminals with limited responsibilities. On the Internet, the opposite holds true. Intelligence is pushed to end-user equipment, and the network is kept as simple as possible. We will see in a later chapter that this enables still faster and more flexible implementations of new services.
Following out the logic of the Internet paradigm, a signalling protocol should support intelligent end systems instead of building a network that makes decisions on the user’s behalf. As we have seen, protocols in the PSTN do not meet this criterion. Some systems using SS7 such as GSM resemble master/slave architectures, where a node in the network—the Mobile Switching Center (MSC)—sends commands to the GSM terminal, which obeys unconditionally. This architecture leads to a network that makes assumptions about what the user wants, instead of letting the user dictate what he wants. When end-to-end services are implemented in such a network, unintended effects sometimes occur.
Consider, for instance, a call between two GSM terminals (see Fig-ure 1-19). GSM terminals use GSM codecs for encoding the voice. The MSC that handles the caller’s terminal decides, on behalf of the terminal, that transcoding from the GSM codec to PCM—the codec used in the fixed PSTN—is needed. When the call reaches the MSC handling the callee’s ter-minal, it performs the opposite transcoding, from PCM to GSM, before at last sending the voice to the terminal. Unhappily transcoding notably reduces the voice quality, and when it is performed twice, as in this sce-nario, its effect is amplified.
This example shows clearly that end-to-end services are better imple-mented using end-to-end protocols, which would enable both terminals to negotiate the codec to be used, avoiding the situation we’ve just examined.
Reliability Because the PSTN concentrates system intelligence in some net-work nodes, a failure in one of the nodes means disruption of service for the user. Consequently, network nodes must be highly reliable. Techniques such as processor redundancy ensure that a certain network node does not just
GSM PCM GSM
GSM
GSM
MSC MSC
Figure 1-19 A call between GSM mobiles.
fail. However, implementing nodes that (almost) never fail results in a sig-nificant increase in equipment costs.
We will see that on the Internet, since the intelligence is pushed to the terminals, failure in a network node such as a router is usually not critical.
Other nodes can take over its task. Here reliability is obtained by imple-menting end-to-end services in which a network failure won’t lead to a loss of state information essential for the service. As long as the end systems do not crash, the service can still be provided.
Access Tightly Tied to Service Provision We have seen how PSTN signalling has evolved throughout the years, and why its evolution has been closely related to that of the user plane. When new multiplexing techniques or transmission mechanisms are created for the user plane, signalling pro-tocols have to evolve to exploit the new mechanisms. Traditionally, new sig-nalling protocols were developed in order to carry new information about the user plane.
Signalling protocols specify the types of user plane that can be used in conjunction with them in detail. For instance, international ISUP defines three types of user plane: 64-kbps unrestricted, speech, and 3.1-kHz audio.
This is because, in the PSTN, access to the network and service provi-sion is coordinated. Therefore, if a user accesses the PSTN, the services he or she is able to access will be those provided by the protocol used for access. If DSS-1 is used, for instance, the caller will be provided with a voice channel. He or she cannot then access the PSTN and request another kind of service.
In the next chapter, we’ll see that on the Internet environment, access and service provision are completely separated. A user can (and often does) connect to the Internet through a particular Internet Service Provider(ISP) and get e-mail services through an Internet portal. Access provider and ser-vice provider in this situation are different.
As one might expect, the Internet promotes a different approach to design signalling protocols from the PSTN. We will see that SIP does not restrict the number of types of sessions that can be established. A caller can use SIP to establish a VoIP session, but he can also use SIP in order to establish, say, a gaming session. SIP could even be leveraged to establish a traditional telephone call. Thus, Internet protocols are implemented in a much more modular way than PSTN protocols.
Conclusions
We have seen that the PSTN implements the intelligence of the system in the network rather than in the terminals. In addition, signalling related to call establishment is tightly tied to management of the user plane. This overloads protocols and makes them less general for use in another type of network.
Taking the previous statements into consideration, we infer that the par-adigm behind SS7 does not suit IP networks, which are designed for maxi-mum flexibility. SS7 is an excellent performer in circuit-switched networks but cannot take advantage of the very flexibility that IP networks provide.
Therefore, signalling protocols to be used in IP environments need to be designed keeping the IP paradigm in mind. It will be seen that SIP suits it very well.