SIP Signaling
SIP is based on the request-response paradigm. The following sequence is a simple example of a call set-up procedure:
1. To initiate a session, the caller (or User Agent Client) sends a request with the SIP URL of the called party.
2. If the client knows the location of the other party it can send the request directly to their IP address; if not, the client can send it to a locally configured SIP network server.
3. The server will attempt to resolve the called user's location and send the request to them. There are many ways it can do this, such as searching the DNS or accessing databases. Alternatively, the server may be a redirect server that may return the called user location to the calling client for it to try directly. During the course of locating a user, one SIP network server can proxy or redirect the call to additional servers until it arrives at one that definitely knows the IP address where the called user can be found.
4. Once found, the request is sent to the user and then several options arise. In the simplest case, the user's telephony client receives the request, that is, the user's phone rings. If the user takes the call, the client responds to the invitation with the designated capabilities* of the client software and a connection is established. If the user declines the call, the session can be redirected to a voice mail server or to another user.
* "Designated capabilities" refers to the functions that the user wants to invoke. The client software might support videoconferencing, for example, but the user may only want to use audio conferencing. Regardless, the user can always add functions - such as videoconferencing, white-boarding, or a third user - by issuing another invite request to other users on the link.
SIP has two additional significant features. The first is a stateful SIP server's ability to split or "fork" an incoming call so that several extensions can be rung at once. The first extension to answer takes the call. This feature is handy if a user is working between two locations (a lab and an office, for example), or where someone is ringing both a boss and their secretary.
The second significant feature is SIP's unique ability to return different media types within a single session. For example, a customer could call a travel agent, view video clips of possible holiday destinations, complete an on-line booking form and order currency - all within the same communication session.
SIP Methods
The commands that SIP uses are called methods. SIP defines the following methods:
| SIP Method |
Description |
| INVITE |
Invites a user to a call |
| ACK |
Used to facilitate reliable message exchange for INVITEs |
| BYE |
Terminates a connection between users or declines a call |
| CANCEL |
Terminates a request, or search, for a user |
| OPTIONS |
Solicits information about a server's capabilities |
| REGISTER |
Registers a user's current location |
| INFO |
Used for mid-session signalling |
SIP responses
The following are SIP responses:
-
1xx Informational (e.g. 100 Trying, 180 Ringing)
-
2xx Successful (e.g. 200 OK, 202 Accepted)
-
3xx Redirection (e.g. 302 Moved Temporarily)
-
4xx Request Failure (e.g. 404 Not Found, 482 Loop Detected)
-
5xx Server Failure (e.g. 501 Not Implemented)
-
6xx Global Failure (e.g. 603 Decline)
They closely resemble HTTP responses
Diagram 1 below depicts a simple call set-up process.
| Download this for PC (203k) | Download this for MAC (242k) |
Notes: - All provisional (1xx) responses have been omitted for clarity. The route taken by the ACK, and any later in-call signalling can vary. As by the time the two user agents have exchanged INVITE and 200 OK messages they potentially know each others actual destinations it could be sent end-to-end. However, any of the proxies in the initial signalling path that wants to can insist on remaining in the signalling path for the rest of the call.
In this example, user 1, who resides in the domain here.com, wants to call user 2. User 1 knows user 2 because they usually reside within the same domain. User 1 therefore sends an INVITE for sip:user2@here.com to a local proxy server, shown in the diagram as SIP Stateful Proxy Server 1. The Proxy Server in turn sends the INVITE to a Redirect Server to try and identify the current location of sip:user2@here.com. The Redirect Server determines that user 2 does not presently reside within the domain here.com but can be found for today at there.com. The Redirect Server returns this information to Proxy Server 1 in a 302 Moved Temporarily response which lists the new address to try for user 2 as sip:user2@there.com.
As this represents a final response to the INVITE, the Proxy Server ACKs this response. Then Proxy Server 1 has a choice, it can either return the 302 response directly to user 1 for them to try or it can try the suggested location itself on user 1's behalf. In this example Proxy 1 attempts to locate sip:user2@there.com be modifying the original INVITE and sending it on. As Proxy1 doesn't know of another Proxy Server that controls the domain there.com it chooses to route the INVITE to a Stateless Proxy which should know where to route the INVITE next. This Stateless Proxy then routes the INVITE on to another Stateful Proxy, which does control the domain there.com. Of course in real life there may be many more hops than this. Stateful Proxy 2 then locates user 2 and completes the routing of the INVITE. User 2 then accepts the call by responding with a 200 OK message. This 200 OK response follows the same path that was taken by the INVITE back to user1. To complete the call set up user 1 must then confirm it received this response to its INVITE request by sending an ACK. Potentially it could send this ACK directly to user 2 but, in this example, both Stateful Proxy Servers indicated in the INVITE requests they routed on that they wanted to remain in the signaling path for the duration of the call. As a consequence, the ACK is routed through both of these proxies, as will any subsequent SIP messages related to this call, such as those for call tear down.
Inside a SIP message
The Request line and header field define the nature of the call in terms of services, addresses, and protocol features. The message body is independent of the SIP protocol and can contain anything.