56 |
SIP: Understanding the Session Initiation Protocol |
3.5 SIP Servers
SIP servers are applications that accept SIP requests and respond to them. A SIP server should not be confused with a user agent server or the client-server nature of the protocol, which describe operation in terms of clients (originators of requests) and servers (originators of responses to requests). A SIP server is a different type of entity; the types of SIP servers discussed in this section are logical entities. Actual SIP server implementations may contain a number of server types, or may operate as a different type of server under different conditions. Because servers provide services and features to user agents, they must support both TCP and UDP for transport. Figure 3.2 shows the interaction of user agents, servers, and a location service. Note that the protocol used between a server and the location service or database is generally not SIP and is not discussed in this book.
3.5.1Proxy Servers
A SIP proxy server receives a SIP request from a user agent or another proxy and acts on behalf of the user agent in forwarding or responding to the request. Just as a router forwards IP packets at the IP layer, a SIP proxy forwards SIP messages at the application layer. A proxy is not a B2BUA since it is only allowed to modify requests and responses according to strict rules set out in RFC 3261. These rules preserve the end-to-end transparency of the SIP signaling while still allowing a proxy server to perform valuable services and functions for user agents.
Figure 3.2 SIP user agent, server, and location service interaction.
SIP Clients and Servers |
57 |
A proxy server typically has access to a database or a location service to aid it in processing the request (determining the next hop). The interface between the proxy and the location service is not defined by the SIP protocol. A proxy can use any number of types of databases to aid in processing a request. Databases could contain SIP registrations, presence information, or any other type of information about where a user is located. The example in Figure 2.2 introduced a proxy server as a facilitator of SIP message exchange, providing user location services to the caller.
A proxy does not need to understand a SIP request in order to forward it— any unknown request type is assumed to use the non-INVITE transaction model. A proxy should not change the order of header fields or in general modify or delete header fields.
A proxy server is different from a user agent or gateway in three key ways:
1.A proxy server does not issue requests; it only responds to requests from a user agent. (CANCEL and ACK requests are an exception to this rule.)
2.A proxy server has no media capabilities.
3.A proxy server does not parse message bodies; it relies exclusively on SIP header fields.
Figure 3.3 shows a common network topology known as the SIP Trapezoid. In this topology, a pair of user agents in different domains establishes a session using a pair of proxy servers, one in each domain. The trapezoid refers to the shape formed by the signaling and media messages. In this configuration, each user agent is configured with a default outbound proxy server, to which it sends all requests. This proxy server typically will authenticate the user agent and may pull up a profile of the user and apply outbound routing services. In an interdomain exchange, DNS SRV queries will be used to locate a proxy server in the other domain. This proxy, sometimes called an inbound proxy, may apply inbound routing services on behalf of the called party. This proxy also has access to the current registration information for the user, and can route the request to the called party. In general, future SIP requests will be sent directly between the two user agents, unless one or both proxies insert a Record-Route header field.
A proxy server can be either stateless or stateful. A stateless proxy server processes each SIP request or response based solely on the message contents. Once the message has been parsed, processed, and forwarded or responded to, no information (such as dialog information) about the message is stored. A stateless proxy never retransmits a message, and does not use any SIP timers. Note that the stateless loop detection using Via header fields described in RFC 2543 has been deprecated (removed) in RFC 3261 in favor of the use of a mandatory Max-Forwards header field in all requests.
58 |
SIP: Understanding the Session Initiation Protocol |
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 3.3 A SIP trapezoid.
A stateful proxy server keeps track of requests and responses received in the past, and uses that information in processing future requests and responses. For example, a stateful proxy server starts a timer when a request is forwarded. If no response to the request is received within the timer period, the proxy will retransmit the request, relieving the user agent of this task. Also, a stateful proxy can require user agent authentication, as described in Chapter 14.
The most common type of SIP proxy is a transaction stateful proxy. A transaction stateful proxy keeps state about a transaction but only for the duration of the pending request. For example, a transaction stateful proxy will keep state when it receives an INVITE request until it receives a 200 OK or a final failure response (e.g., 404 Not Found). After that, it would destroy the state information. This allows a proxy to perform useful search services but minimize the amount of state storage required.
One such example of a search service is a proxy server that receives an INVITE request, then forwards it to a number of locations at the same time, or forks the request. This forking proxy server keeps track of each of the outstanding requests and the response to each, as shown in Figure 3.4. This is useful if the location service or database lookup returns multiple possible locations for the called party that need to be tried.
In the example of Figure 3.4, the INVITE contains:
INVITE sip:support@chaos.info SIP/2.0
Via: SIP/2.0/UDP 45.2.32.1:5060 ;branch=z9hG4bK67865
Max-Forwards: 70
To: <sip:support@chaos.info>
|
|
|
|
|
|
SIP Clients and Servers |
59 |
||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 3.4 Forking proxy operation.
From: A. N. Sarkovskii <sip:sarkovskii@45.2.32.1>;tag=7643545 Call-ID: 0140092501
CSeq: 1 INVITE
Subject: Bifurcation Question Contact: <sip:sarkovskii@45.2.32.1> Content-Type: application/sdp Content-Length: ...
(SDP not shown)
The INVITE is received by the chaos.info proxy server, which forks to two user agents. Each user agent begins alerting, sending two provisional responses back to Sarkovskii. They are:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 45.2.32.1:5060;branch=z9hG4bK67865 To: <sip:support@chaos.info>;tag=343214112
From: A. N. Sarkovskii <sip:sarkovskii@45.2.32.1>;tag=7643545 Call-ID: 0140092501
CSeq: 1 INVITE
Contact: <sip:agent42@67.42.2.1> Content-Length: 0
and:
60 SIP: Understanding the Session Initiation Protocol
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 45.2.32.1:5060;branch=z9hG4bK67865 To: <sip:support@chaos.info>;tag=a5ff34d9ee201
From: A. N. Sarkovskii <sip:sarkovskii@45.2.32.1>;tag=7643545 Call-ID: 0140092501
CSeq: 1 INVITE
Contact: <sip:agent7@67.42.2.32> Content-Length: 0
The two responses are identical except for having different To tags and Contact URIs. Finally, one of the two UAs answers and sends a 200 OK response:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 45.2.32.1:5060;branch=z9hG4bK67865 To: <sip:support@chaos.info>;tag=343214112
From: A. N. Sarkovskii <sip:sarkovskii@45.2.32.1>;tag=7643545 Call-ID: 0140092501
CSeq: 1 INVITE
Contact: <sip:agent42@67.42.2.1> Content-Type: application/sdp Content-Length: ...
(SDP not shown)
The forking proxy server sends a CANCEL to the second UA to stop that phone alerting. If both UAs had answered, the forking proxy would have forwarded both 200 OK responses back to the caller who then would have had to choose which one, most likely by accepting one and sending a BYE to the other.
A stateful proxy usually sends a 100 Trying response when it receives an INVITE. A stateless proxy never sends a 100 Trying response. A 100 Trying response received by a proxy is never forwarded—it is a single hop only response. A proxy handling a TCP request must be stateful, since a user agent will assume reliable transport and rely on the proxy for retransmissions on any UDP hops in the signaling path.1
The only limit to the number of proxies that can forward a message is controlled by the Max-Forwards header field, which is decremented by each proxy that touches the request. If the Max-Forwards count goes to zero, the proxy discards the message and sends a 483 Too Many Hops response back to the originator.
The SIP session timer extension [9] limits the time period over which a stateful proxy must maintain state information without a refresh re-INVITE. In the initial INVITE request, a Session-Expires header field indicates a timer interval after which stateful proxies may discard state information about the session. User agents must tear down the call after the expiration of the timer. The caller can send re-INVITEs to refresh the timer, enabling a “keep alive” mechanism for
1. TCP usually provides end-to-end reliability for applications. In SIP, however, TCP only provides single-hop reliability. End-to-end reliability is only achieved by a chain of TCP hops or TCP hops interleaved with UDP hops and stateful proxies.