Site Map
SIP sessions, sometimes referred to informally as "calls" and more formally referred to as dialogs, are created via invitations from one User Agent (User Agent Client or UAC) to another (User Agent Server or UAS). This invitation transaction is basically a three-way handshake between the UAC and UAS that consists of the initial INVITE message sent by the UAC to the UAS, one or more provisional responses sent by the UAS to the UAC, a final response sent by the UAS to the UAC, and an acknowledgment sent by the UAC to the UAS. Contained within these SIP messages is a description of each UA's media capabilities using the Session Description Protocol (SDP). Based on these session descriptions, a common set of parameters can be negotiated during call setup, which can then be used to send media from one UA to the other whether it be audio, video, text, etc. Below is an example call flow of a peer-to-peer call between UA1 and UA2.
In this example, UA1 includes a description of its media capabilities in the SDP of the initial INVITE message. UA2 includes a description of its media capabilities in the SDP of its 200 OK response to the INVITE.
This is not a typical example, however, in that most sessions traverse a larger infrastructure made up of proxy servers. A more typical example involves a model known as the "SIP trapezoid" and involves SIP proxy servers that act on behalf of each UA. A diagram of the trapezoid is below.
An example of this more typical example is below. In this example, Proxy 1 acts on behalf of UA1 while Proxy 2 acts on behalf of UA2.
In the above example, UA1 does not know the location of UA2, so it sends its INVITE to the proxy that is responsible for UA1's domain, Proxy 1. Proxy 1 discovers the location of Proxy 2, perhaps via a DNS lookup, and forwards the request. Proxy 2 is able to ascertain the location of UA2 by using a location service. Prior to this call, UA2 would have had to register its location in order to specify an address or addresses where UA2 can be reached (Link here to SIP Registrations). Once UA1 receives the 200 OK from Proxy 1, it now knows the location of UA2 from the contact header field in the SIP message. Because of this knowledge, UA1 can now send the ACK directly to UA2. Any further messages between the two UAs within this call can also be sent direct, thus bypassing the proxy servers. SIP also defines mechanisms by which intermediate proxy servers can ensure that they remain in the signaling path (Link here to SIP Message Routing).
In the second example, before Proxy 1 can forward the invite it needs to know the IP address of Proxy 2. One way this can be done is for Proxy 1 to use the methods described in RFC 3263 to locate the server (Link here to Locating SIP Servers).
Both examples above involve the use of provisional SIP responses (100 Trying and 180 Ringing) to let UA1 know that UA2 has received its INVITE request and is processing it. One potential problem that arises is that when using an unreliable transport such as UDP, there is no was for UA1 to know that UA2 has received these messages. To solve this, SIP defines a method called PRACK in RFC 3262 for acknowledging provisional responses (Link here to SIP PRACK).
SIP provides a number of advanced call control mechanisms, which allow a User Agent to perform a number of tasks. Some examples of these controls are call transferring (Link here to SIP Call Transferring) and call forwarding (Link here to SIP Call Forwarding).
SIP also provides a keepalive mechanism for established sessions. This allows for both UAs and proxy servers to determine whether a particular session is still active. This method is called a SIP Session Timer and is defined by RFC 4028 (Link here to SIP Session Timers).