SIP Sessions

What are SIP Sessions?

SIP Sessions are used with VoIP and Voice and Video over IP (VVoIP or V2oIP) to establish a call session between users. The core SIP specification provides a way to set up and manage sessions between two user agents.

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.

SIP Peer-to-Peer Call Session

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.

Call Session Using SIP Proxy Servers

In most SIP Sessions, a SIP connection traverses 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. 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 Session Signaling Path

SIP also defines mechanisms by which intermediate proxy servers can ensure that they remain in the signaling path. 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 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.

SIP provides a number of advanced call control mechanisms, which allow a User Agent to perform a number of tasks including call transferring and call forwarding. SIP also provides a keepalive mechanism for established sessions which allows for both UAs and proxy servers to determine whether a particular session is still active. The Session Timer is defined by RFC 4028.

SIP Sessions Timers

SIP provides a mechanism by which both user agents and proxies can determine whether a given SIP session is still active. This mechanism is referred to as a Session Timer and is described in RFC 4028 “Session Timers in SIP”. This specification defines a keepalive mechanism for SIP sessions.

In a SIP session that utilizes a session timer, UAs send periodic re-INVITE or UPDATE requests to refresh the session. The interval at which these session refreshers are sent and which UA is responsible for sending them is regotiated in the initial INVITE transaction that sets up the session. If a session refresher request is not received before the negotiated interval expires, both the UAS and UAC should send a BYE and any proxies in between can remove any state maintained for the session.

SIP Sessions Software

VOCAL’s embedded libraries include a complete range of ETSI / ITU / IEEE compliant algorithms, in addition to many other standard and proprietary algorithms. Our SIP source code is optimized for execution on ANSI C and leading DSP architectures from TI, ADI, AMD, Intel, ARM, MIPS, and other vendors. The SIP software libraries are modular and can be executed as a single task under a variety of operating systems or standalone with its own microkernel.

More Information

VOCAL Technologies has been in business for over 30 years and is an engineering design house that can provide a custom solution that meets your unique communication requirements.

Please contact us to discuss your communication application requirements.

Complete Communications Engineering