SIP Clients and Servers

request for an unknown dialog responds with a 481 Dialog/Transaction Does Not Exist. Responses from an unknown dialog are also silently discarded. These silent discards are necessary for security. Otherwise, a malicious user agent could gain information about other SIP user agents by spamming fake requests or responses.

A minimal implementation must to be able to interpret any unknown response based on the class (first digit of the number) of the response, but it is not required to understand every response code defined. That is, if an undefined 498 Wrong Phase of the Moon response is received, it must be treated as a 400 Client

Error.

A user agent responds to an unsupported request with a 501 Not Implemented response. For example, a UA receiving a method that it does not support would return a 501 response. A SIP UA must support UDP and TCP transport if it sends messages greater than 1,000 octets in size.

A SIP user agent contains both a client application and a server application. The two parts are a user agent client (UAC) and user agent server (UAS). The UAC initiates requests while the UAS generates responses. During a session, a user agent will usually operate as both a UAC and a UAS.

A SIP user agent must also support Session Description Protocol (SDP) for media description. Other types of media description protocols can be used in bodies, but SDP support is mandatory. Details of SDP are in Section 13.1.

A UA must understand any extensions listed in a Require header field in a request. Unknown header fields may be ignored by a UA. A UA should advertise its capabilities and features in any request it sends. This allows other UAs to learn them without having to make an explicit capabilities query. For example, the methods that a UA supports should be listed in an Allow header field. SIP extensions should be listed in a Supported header field. Message body types that are supported should be listed in an Accept header field.

UAs typically register with a proxy server in their domain.

3.2 Presence Agents

A presence agent (PA) [2] is a SIP UA that is capable of receiving subscription requests and generating state notifications as defined by the SIP Events specification [3]. An example of a presence agent can be found in Section 3.4. A presence agent supports the presence event package [2], responds to SUBSCRIBE requests, and sends NOTIFY requests. A presence agent also sometimes publishes event state to an event state compositor (ESC) using PUBLISH requests, as described in Section 4.1.9.

A presence agent can collect presence information from a number of devices. Presence information can come from a SIP device registering, a SIP device publishing presence information [4], or many other non-SIP sources.

A presence server is also a presence UA that can supply presence information about a number of users, and can also act as a proxy, forwarding SUBSCRIBE requests to another presence agents.

A presence agent first authenticates a subscription request. If the authentication passes, it establishes a dialog and sends the notifications over that dialog. The subscription can be refreshed by receiving new SUBSCRIBE requests.

Chapter 8 has a complete description of presence agents.

3.3 Back-to-Back User Agents

A back-to-back user agent (B2BUA) is a type of SIP UA that receives a SIP request, then reformulates the request and sends it out as a new request. As such, some B2BUAs act like a proxy but do not follow proxy routing rules. For example, a B2BUA device can be used to implement an anonymizer service in which two SIP UAs can communicate without either party learning the other party’s URI, IP address, or other information. To achieve this, an anonymizer B2BUA would reformulate an incoming request with an entirely new From, Via, Contact, Call-ID, and SDP media information, also removing any other SIP header fields that might contain information about the calling party. The response returned would also change the Contact and SDP media information from the called party. The modified SDP would point to the B2BUA itself, which would forward RTP media packets from the called party to the calling party and vice versa. In this way, neither end point learns any identifying information about the other party during the session establishment. (Of course, the calling party needs to know the called party’s URI in order for the call to take place.)

Sometimes B2BUAs are employed to implement other SIP services. However, they break the end-to-end nature of an Internet protocol such as SIP. Also, a B2BUA is a call-stateful single point of failure in a network, which means their use will reduce the reliability of SIP sessions over the Internet. The relayed media suffers from increased latency and increased probability of packet loss, which can reduce the quality of the media session. Geographic distribution of B2BUAs can reduce these effects, but the problem of selecting the best B2BUA for a particular session is a very difficult one since the source and destination IP addresses of the media are not known until the session is actually established (with a 200 OK).

B2BUAs can be a part of many devices. For example, many private branch exchange (PBX) enterprise telephone systems incorporate B2BUA logic. Conference bridges and mixers also use B2BUA logic. Another type of B2BUA present in some SIP networks is application layer gateways (ALG). Some firewalls have

ALG functionality built in, which allows a firewall to permit SIP and media traffic while still maintaining a high level of security. Another common type of B2BUA is known as a Session Border Controller (SBC). Some common functions of a SBC are listed in Table 3.1 which is from [5]. Note that many of these functions break the end-to-end security properties of SIP and SIP security.

3.4 SIP Gateways

A SIP gateway is an application that interfaces a SIP network to a network utilizing another signaling protocol. In terms of the SIP protocol, a gateway is just a special type of user agent, where the user agent acts on behalf of another protocol rather than a human. A gateway terminates the signaling path and can also terminate the media path, although this is not always the case. For example, a SIP to H.323 gateway terminates the SIP signaling path and converts the signaling to H.323, but the SIP user agent and H.323 terminal can exchange RTP media information directly with each other without going through the gateway. An example of this is described in Section 11.4.

A SIP to Public Switched Telephone Network (PSTN) gateway terminates both the signaling and media paths. SIP can be translated into, or interwork with, common PSTN protocols such as Integrated Services Digital Network (ISDN), ISDN User Part (ISUP), and other circuit associated signaling (CAS) protocols, which are briefly described in Section 11.1. A PSTN gateway also converts the RTP media stream in the IP network into a standard telephony trunk or line. The conversion of signaling and media paths allows calling to and from the PSTN using SIP. Examples of these gateways are described in Section 16.2. Figure 3.1 shows a SIP network connected via gateways with the PSTN and an H.323 network. The SIP/H.323 interworking function is described in [6].

In Figure 3.1, the SIP network, PSTN network, and H.323 networks are shown as clouds, which obscure the underlying details. Connecting to the SIP

Figure 3.1 A SIP network with gateways.

cloud are SIP IP telephones, SIP-enabled PCs, and corporate SIP gateways with attached telephones. The clouds are connected by gateways. H.323 terminals and H.323-enabled PCs are attached to the H.323 network. The PSTN cloud connects to ordinary analog black telephones (so-called because of the original color of their shell), digital ISDN telephones, and corporate private branch exchanges (PBXs). PBXs connect to the PSTN using shared trunks and provide line interfaces for either analog or digital telephones.

Gateways are sometimes decomposed into a media gateway (MG) and a media gateway controller (MGC). An MGC is sometimes called a call agent because it manages call control protocols (signaling), while the MG manages the media connection. This decomposition is transparent to SIP; the protocols used to decompose a gateway are described in Section 11.3.

Another difference between a user agent and a gateway is the number of users supported. While a user agent typically supports a single user (although perhaps with multiple lines), a gateway can support hundreds or thousands of users. A PSTN gateway could support a large corporate customer, or an entire geographic area. As a result, a gateway does not REGISTER every user it supports in the same way that a user agent might. Instead, a non-SIP protocol can be used to inform proxies about gateways and assist in routing. One protocol that has been proposed for this is the Telephony Routing over IP (TRIP) protocol [7], which allows an interdomain routing table of gateways to be developed. Another protocol called Telephony Gateway Registration Protocol (TGREP) [8] has also been developed to allow a gateway to register with a proxy server within a domain.