A redirect server responds to an INVITE request with a 3xx reply (or rejects the call with a client error or server error):
• The 300 MULTIPLE CHOICES reply can be used when the SIP URL of the request can be contacted at several alternative addresses. The choices are listed as Contact fields. This can be used as a simple form of load balancing or, more interestingly, to let a caller know all the available means or media that can be used to communicate with the destination user. For instance, the returned Contact field could be:
Contact: sip:John [email protected],sip:John [email protected]
• The 301 MOVED PERMANENTLY reply indicates that the SIP URL of the request can no longer be contacted at this location. The client should try to contact the new location given by the Contact header field of the reply. This change is permanent and can be memorized by the client. The Contact header can also indicate several possible destinations.
• The 302 MOVED TEMPORARILY reply redirects the client to a new location, as above, but for a limited duration, as indicated by the Expires field.
• The 305 USE PROXY indicates that the specified location should be reached via the indicated proxy.
• The 380 ALTERNATIVE SERVICE is really for future use; it is not fully defined in the current SIP RFC. This reply is more complex, and may seem a bit redundant is light of the previous replies: in addition to providing a new destination in the Contact field, the reply can also contain a session description in the message body that represents the sending capacities of the new destination. The caller is expected to send an INVITE request to this new destination, and offer in its SDP session description the appropriate capabilities (which can be a copy of the SDP parameters of the 380 reply, except for receiving RTP ports).
Other replies (e.g., 303) were defined in early SIP drafts, but have become obsolete. A redirect server can be used in conjunction with a registrar to redirect calls to the current location(s) of the caller. It can also act as a basic form of call distribution system, as shown in Figure 3.25.
SIP redirect
User agent A User agent B
INVITE [email protected] INVITE [email protected] 302 moved Contact: [email protected] ACK
Here the proxy determines (through a database lookup or
any other means) that the request to ‘support’ must be
routed to John
Same dialog identifier, Call-ID as initial INVITE, and new
CSeq value
200 OK ACK
Figure 3.25 SIP redirect server distributes calls, in a very basic contact center.
Redirect servers can be useful tools to improve the scalability of complex call manage- ment systems. Inserted as a front end, it can distribute calls among a pool of secondary servers, achieving load balancing. This is permitted by the maddr parameter of the Con- tact field:
<sip:[email protected]:9999;maddr= sophisticatedACD3.callcenter.com> By returning this, the redirect server indicates that the caller should send an INVITE with the same destination URI ([email protected]), but send it to the third ACD server of the pool (ACD3.callcenter.com). The maddr parameter instructs the caller to bypass the normal procedure to find the appropriate SIP server from the domain part of the URL, and to use the domain name provided instead.
One of the most interesting uses of the redirect server in conjunction with a registrar is for the deployment of large-scale residential networks. A network serving hundreds of thousands of SIP endpoints cannot be realistically realized with a single server. The reason is that if N endpoints are sending a registration message every S seconds, the number of messages per second that would need to be processed by the central server would be on average N /S, and much worse when the network starts or restarts. With N= 300,000 and
S= 60, the central server should process over 5,000 registration messages per second.
Obviously, in this case it is necessary to use a number of separate registrar servers (e.g., one server per block of 6,000 users). The call control function can still be centralized because there are a lot less calls than registration messages (if each user makes 1 call every 5 hours, this is 300,000/(5∗3, 600) = 16 calls per second). But, in order to terminate incoming calls to the right user agent, the central call control function will need to query
the registrars, which can be done using an INVITE/REDIRECT transaction. This type of strategy is currently used with success in residential networks with over 200,000 users.
Redirect server functionality is very similar to the role played by the H.323 gatekeeper when using the direct call model.
3.4.2
The proxy function
3.4.2.1 Definition
A proxy server acts as a server on one side (receiving requests) and as a client on the other side (possibly sending requests).
Strictly speaking, a proxy should be mostly transparent to user agent messages, simply passing messages and changing them in very limited ways. A proxy can forward a request without any change to its final destination, it can decide to validate requests, authenticate users, fork requests, resolve addresses, and cancel pending calls, etc.
Depending on the level of control the proxy has over the SIP messages it processes it can be a stateless proxy, a stateful proxy, or even a back-to-back user agent:
• A stateless proxy simply chooses the next hop destination for an incoming SIP message using To header information; it keeps no state for the call or even the transaction (it will not handle retransmissions, but simply pass them on transparently). For instance, a stateless proxy will not carry out any local processing for a CANCEL request other than forward it, and will not even acknowledge locally any response, but simply pass it transparently to the original sender of the request. This behavior is made possible because SIP allows a proxy to store some state in the messages (e.g., in the Via header). This state is copied in the response, and therefore the stateless proxy server does not need to keep in memory any call parameter to be able to forward a response, it simply finds the information it needs in the response itself (e.g., the next hop is at the bottom of the pile of Via headers, after discarding the Via header corresponding to the proxy itself). Stateless proxies have often been presented as a technology breakthrough that would make SIP networks considerably more scalable than any other network. The reality is that a stateless proxy can serve only very limited purposes (e.g., it cannot do billing), and therefore can be used only in simple infrastructure call flows, such as performing load balancing or basic message routing in core networks. Even in this role it cannot do very much, as even a simple load-balancing function usually needs to keep in memory the number of calls it has sent to each destination and discard any destination that appears to fail frequently.
• Stateful proxies are much more useful, as they can keep any state relative to the call and all transactions involved in the call. Stateful proxies also manage locally some aspects of the transactions (e.g., they will handle retransmissions locally and acknowledge the final responses, except 200 OK and CANCEL requests). Stateful proxies can serve most call control purposes required in a SIP network, such as choosing an egress route for a phone call among multiple gateways by offering the call in sequence to multiple gateways and analysing the responses to eventually try another gateway if the current
attempt fails due to congestion or any other reason. Since a stateful proxy memorizes when a call has begun, it can generate call detail records about the duration of the call when the call ends.
• Some applications need so much control on the call that they cannot be implemented within the restrictions set on proxies.16 For instance the requirement to transparently forward any 200 OK response received from a destination may not be compatible with applications which need to filter the responses for security or any other purpose. Many of the most sophisticated applications, such as business telephony applications, contact centers, need the complete range of possibilities of a user agent. Therefore they act as a full user agent receiving a call and re-initiate a call as a user agent. Strictly speaking, such servers are no longer proxies, but should be called back-to-back user agents.
The names feature server or application server that emerged in marketing presentations are now widely used by the industry, but they have no precise meaning. A feature server is any server that implements an application! It could be a stateful proxy, a back-to-back user agent, or even an interactive voice response server that can receive, generate, and bridge calls. The closest to a feature or application server in traditional telephony terms would be a service node.
There is frequent confusion leading to the idea that a SIP application server can be used to replace the old intelligent network model. In fact, the intelligent network model refers to the ability of a Service Control Point (SCP) to use an abstract protocol-independent model of a call to remote-control a Service Switching Function (SSF), which is the only one that is part of the telephony network and implements telephony protocol stacks. The function implemented by an SSF with SIP stacks and the SCP together can be described as an application server. But, a simple, monolithic SIP-only application server does not replace an IN architecture, which has been designed precisely to facilitate the programming of protocol-independent application.
In Figure 3.26, the proxy is at least a stateful proxy because it locally sends a 100 reply and generates ACKs (transaction awareness). Note that a stateful proxy is not allowed to send ACKs locally to 200 OK responses (Figure 3.27). This message and its reliability must be handled end to end, ensuring that the call is established and media can start flowing only when the end-to-end handshake is complete. Only a back-to-back user agent can send an ACK locally to a 200 OK response (and it must understand the consequences). Most useful functions (e.g., the ability to drop a call from the proxy) go beyond the strict definition of a ‘proxy’: most commercial server implementations are back-to-back user agents, according to SIP terminology. In section 3.4.2.2 we do not restrict ourselves to the strict ‘proxy’ terminology and describe the various functions of a server that has control over SIP signaling during the call (i.e., these that encompass the proxy and back-to-back user agent features).
16These theoretical restrictions do not serve any useful purpose; in fact, they imply a very poor
SIP proxy
User agent A User agent B
INVITE [email protected] INVITE [email protected] 3xx 3xx ACK ACK
Here the proxy determines (through a database lookup or any other means) that the request to ‘support’ must be
routed to John. 100 is sent to stop INVITE
retransmission
100
ACK is sent locally (transaction awareness of a stateful proxy)
Figure 3.26 Simple call through a stateful proxy.
SIP proxy
User agent A User agent B
INVITE [email protected] INVITE [email protected] 200 OK 200 OK ACK ACK
Here the proxy determines (through a database lookup or any other means) that the request to ‘support’ must be
routed to John. 100 is sent to stop INVITE
retransmission
100