The original Internet paradigm advocates a scenario where the network is dumb and the endpoints are intelligent. The network should only provide is end-to-end connectivity. Moreover, it should keep as little state information as possible in order to make it robust and scalable. The state information should be moved to the periphery of the network.

Accordingly, the SIP design incorporated the Internet principles, and so it was defined as an end-to-end protocol that reflected the end-to-end nature of the underlying IP network. Nevertheless, soon in our discussion about SIP, we discovered that some additional functions at the SIP level were needed in order to properly address the mobility of the users and the routing of terminating calls to them. That is how the registrar and SIP proxy functions were born, which are considered to be SIP network functions—that is, application-level functions that are generic enough to be needed in any SIP implementation, and that require the introduction of new infrastructure in addition to the endpoints’ hardware and software.

Starting from that point, we have seen throughout the book more and more functions incorporated into the architecture outside of the endpoints. These functions are not always needed. Depending on the deployment scenario, there may be more or fewer functions in the network. For instance, in Internet-wide deployments—that is, in interdomain and in heterogeneous environments—the network functions are kept to a minimum, and the trend is to do almost everything in an end-to-end fashion.

On the other hand, in controlled network deployments under the administration of a single entity (e.g., company, telecom operator, and so on), there can be a significant amount of additional network functions that allow us to deliver specific features. Private VoIP networks that intend to replicate (and enhance) existing services in the PSTN are an example of this.

The most basic functions in a SIP network, as we saw in Chapter 4, refer to the capability to route terminating calls to users who might be changing their location (i.e., their IP address). This is achieved through the introduction of three entities: the SIP registrar, the location service, and the SIP (inbound) proxy. The proxy functions are not limited to routing the terminating calls; they can also help in routing calls at origination. Thus, the SIP outbound proxy concept is born, which helps in routing the messages on behalf of the originating user.

In addition, SIP proxies may contain complex routing logic that takes a number of arbitrary input parameters into consideration, such as date, time of the day, presence information, and so forth.

We saw in Chapter 14 that in order to obtain an IP communications service, users need to subscribe to a service provider. Whenever the users want to take part in communications scenarios, they need to have previously registered with their home server, which authenticates them. Therefore, there is a need for an authentication function sitting in the network. Moreover, as we saw in Chapter 20, the authentication function can also incorporate additional functions for assertion of the user’s identity. The authentication of the users, together with the assertion of their identities, is one of the key network functions.

User authorization is again a network function that can be implemented in proxies. User authorization may relate to very different aspects. Particularly relevant to our discussion are the aspects regarding media and quality of service authorization that we saw in Chapter 21. These functions allow the service provider to control the media and the QoS requested by the users, and to assure that network resources are used according to what was authorized. These functions are particularly relevant in controlled network scenarios where both SIP network and IP access network fall under the same administrative domain.

Also, accounting is an important network function, especially in scenarios with a tighter relationship between users and service providers, because these will most likely want to charge for offering the service. This function typically requires that the network infrastructure is able to monitor the entire duration of the call. Therefore, this function needs to be implemented in call-stateful proxies or in Back-to-Back-User-Agents. These network nodes might generate call records that include the identity of the caller, the destination address, time of day, call duration, and other information. These call records, when processed, allow the service provider to create bills for the users. This approach is called offline charging. Another approach allows for online charging, as is typical for prepaid applications.^[2] In these cases, a Back-to-Back User Agent is required that has control over the call for the entire duration of the call, and that is able to query a charging server, obtain charging authorization from it, and release the call as soon as the credit is finished.

Security is a broad topic in which the network plays an important role. We already mentioned the authentication service. Network functions are also concerned with securing the connections over which messages are sent that are addressed to SIPs URIs.

Privacy is another interesting security service that may be provided by the network, both at the control plane and at the media plane, as we saw in Chapter 20.

Interworking with PSTN is yet another example of an issue that requires a network function to be resolved. IP communications service providers may offer an interconnect service with the PSTN. Some service providers offer calls just from the IP domain to the PSTN. Other service providers allow for calls in both directions. In any case, the service provider needs to come to an agreement with a telecom operator, and then deploy one or several gateways and connect them to the operator’s PSTN infrastructure. The gateways are, in this case, network elements that contain, among others, the necessary conversion functions between the protocols in the two domains.

When interconnecting two different service providers’ IP communication infrastructure, there is a need to provide additional functions that are implemented in the network and that involve the control plane and the media plane. These additional functions are typically offered by elements collectively known as Session Border Controllers (SBC). SBCs usually sit between two service provider networks in a peering environment, or between an access network and a backbone network to provide service to residential and/or enterprise customers. They provide a variety of functions to enable or enhance multimedia services. These functions include:

SBCs typically handle both signaling and media traffic, and they include a SIP B2BUA. The privacy service that we saw in Chapter 20 might, as a matter of fact, be implemented in SBCs.

A detailed description of the functions of SBCs is given in [draft-ietf-sipping-sbc-funcs].

As we saw in Chapter 5, there are different approaches to deliver value-added services (VAS) in SIP. One approach is the end-to-end approach, where services are sitting in the endpoints. In such an approach, no service logic (or very limited service logic) is sitting in the network. An example of that could be a chess game or a plain voice call.

In another approach, the application is sitting in the network. Take, for instance, an application that provides enhanced voice call control services such as those required in an enterprise environment (hunting group, boss/secretary, call queuing, do not disturb, etc.).^[3]

Network applications are provided in application servers that are typically implemented as SIP B2BUA. In order to provide these applications, Application Servers (AS) very often need to work alongside Media Servers. Both Application Servers and Media Servers are considered network infrastructure.

As a summary of the previous ideas, Figure 23.1 depicts a SIP network that incorporates most of the previous functions. This picture represents an IETF view. In the next chapter, we will see how this architecture may evolve, in order to cope with some telecom operator’s requirements to build a controlled multimedia network under their administration (IMS).

Figure 23.1. 

In this chapter, we have presented the basic functions in a SIP-based multimedia network. Even if the “SIP network” concept has not been explicitly tackled by the IETF, there are a lot of SIP extensions that allow building such a concept. Today, we can see many examples of IETF-like SIP networks deployed all around the world, either by service providers in the Internet or in enterprise environments.

In the next chapter, we will see an example of a particular SIP-based multimedia network specified by 3GPP: the IMS. Such a network is implemented by reusing the IETF concepts, though some extensions had to be developed in order to cope with new requirements.