A Session Initiation Protocol Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

This paper provides a survey on Session Initiation Protocol, presents the technique and design of this protocol, its applications and deployment concerns. This article also outlines some major concerns in deployment of SIP with some proposed solutions and scope of future research in this area.


Henning Schulzrinne and Mark Handley designed the SIP for the first time in 1996 however it was accepted as a part of IMS architecture for cellular networks, and as a 3GPP protocol in 2000 [3]. IETF defined the latest version of SIP as RFC 3261 in 2002 and has standardized SIP for inviting multicast conferences and internet Telephone calls [3].

Session Initiation Protocol is a peer to peer Application layer protocol for establishing, tearing down and terminating a real time communication session between two ore multiple participants in IP based networks. Though it establishes and maintains the connection but is not responsible for the actual media transport. SIP can be used for voice, video or text communication on any SIP enabled device like soft phones, instant messengers, IP phones, internet etc.

Design elements of SIP are quite similar to HTTP transaction model. In each transaction the client sends a request which invokes the server to respond. SIP uses the readable text based format and works with other different protocols like Real time Transport Protocol (RTP) and Session description Protocol (SDP) for a complete session. Basically SIP is designed to set up and tear down the video or voice calls but it can also modify the connection by changing ports or addresses, inviting new participants, and adding or deleting media. SIP is also used now in text communication applications like instant messengers and event notification managers etc.

Mobility has brought a revolution in the field of wireless communication. Enabling mobility in IP networks allows the portable light weight devices to roam around and communicate at the same time. The main goal of mobility support is to maintain the established connection between the mobile nodes (MN) and the network while MN is moving without any disruptions. An efficient solution must provide effective handover and location management, efficient routing, security, scalability, compatibility with IP, transparency and Quality of service.[1]. The internet host mobility is mainly approached from three angles; data link layer mobility, network layer mobility and higher layer mobility. IEEE 802.11b, Mobile IP, and MSOCKS are three example schemes of these three layers respectively [2]. IETF has standardized the IP mobility using mobile IP technique in which IP packets are tunneled from home agent to foreign agent. But mobile IP faces a lot of issues while supporting this mobility for example triangular routing, unique IP addresses and tunneling management etc.

For real time traffic in wireless communication networks, some very important factors are efficient quick handoff, low latency and bandwidth utilization. This creates the need for mobility awareness at higher layers which can decide to handle the mobility of traffic in particular situations. A lot of research has been done and new ideas have been proposed to provide a better solution using SIP to enable mobility in IP networks. In this paper these techniques and approaches are being discussed.

Section 2 of this paper explains SIP, its elements and transaction technique for communications. Section 3 deals with mobility support provided by SIP.

2 Session Initiation Protocol (SIP) Review

As mentioned earlier, SIP is an application layer protocol used to initiate, manage and end communication sessions in IP based networks. A session here can be two way phone call or multi parties' conference. Main functionalities provided via SIP can be classified as follows

· Determines user location by translating its network address from user's name.

· Determines the availability and willingness of requested participant.

· Determines the media and requires parameters for the session.

· Setting up the session by establishing desired parameters at each participant.

· Manages the session which can be termination, or modification of the session while in progress.

2.1 Design of Protocol

SIP was originally designed to support a superset of call processing functions like in public switched telephone networks (PSTN). The protocol is itself just responsible for signaling and call set up however the extended features which allows PSTN like operations are performed by its network elements described in next section. The implementation is quite different but to the end user the behavior of SIP technologies is very similar to that of PSTN.

2.2Network Elements of SIP

SIP employs a peer to peer transactions model using some network elements and specific messages. For public networks it is not appropriate to provide peer to peer direct communication so SIP also defines some network server elements. Each element or resource is identified by a uniform resource identifier (URI). Following are the main network elements in SIP defined in RFC 3261

2.2.1 User Agent

User agent in SIP is a logical end point in network which can send or receive a SIP message. A user agent can be client or server depending on its role in the session. A User Agent Client (UAC) sends the SIP requests and a User Agent Server (UAS) receives and responds to the requests. The role as a client or a server is only specific to a particular session and ends after the session is over.

An example of a user agent is a SIP phone which provides the traditional call functions of a telephone, such as dial, answer, reject, hold/resume, and call transfer [5]. SIP phones can be implemented as a hardware device or as a softphone.

2.2.2 Proxy server

A proxy server acts as a router by sending the request to other element closer to requested user. A proxy server can act as a client or server by making requests and responses on behalf of other clients. A proxy can interpret and if required modifies the request message before forwarding it.

2.2.3 Redirect server

A redirect server generates 3xx (Redirection) responses to its received requests, directing the client to contact an alternate set of URIs. By using this server proxy servers can send SIP invitations to external domains.

2.2.4 Registrar

Registrar is another server in SIP which registers the received location information on request. The client sends register request to registrar so that one or more IP addresses can be stored in location service domain against its URI. There servers mostly co located with proxy servers and also facilitates network's scalability and mobility.

2.2.5 Session border controller

A SBC is a middle box between user agents and servers, usually deployed in Voice over IP (VOIP) networks to exert some additional controls over signaling

2.2.6 Gateway

Gateway can be used to interface SIP with other networks using different technologies

2.3 Messages

SIP has two types of messages, requests and responses. Each message has two parts the first part being the request or response code and the later one is URI for relevant element.

IETF has defined following SIP request messages in RFC 3261 and RFC 3262





To register the current IP address and the URLs of a UA to receive calls


To request for establishing media session between UAs


To confirm the reliable exchange of messages


To terminate a pending request


To end a media session between UAs


To query the information about caller capabilities without setting up a call


To improve the reliability by adding acknowledgment to provisional responses

Following are the types of response messages standardized in RFC 3261


Message type


Provisional (1xx)

Tells that request has been received and is being processed

Success (2xx)

Tells that the request was received, interpreted and accepted

Redirection (3xx)

Tells that more actions are needed to complete the request

Client Error (4xx)

Tells that there are syntax error in request or the server is unable to complete the request

Server Error (5xx)

Tells about server failure on a valid request

Global Failure (6xx)

Tells that request cannot be fulfilled by any server

2.4 Transaction

SIP uses transaction method for initiating a media session between users, here is one simple example to explain the transaction of SIP messages involved in one media session between two users

figure 2.4.1

In figure 2.4.1 user agent 1 sends a request INVITE to SIP proxy server A. the proxy server receives and interprets the message then look at the domain to find the next destination of request and forward the request to next proxy server B which is closer to desired destination user 2. Proxy server then also sends a provisional message 100 to sender 1 telling that its request has been received and in progress. Proxy server B receives the INVITE message from proxy server A and undergo the same procedure to forward the request and sending back the TRYING message . User Agent 2 receives the INVITE message from proxy server B. and send back another provisional message 180 RINGING on successful interpretation of message to proxy server B. this RINGING message is forwarded to proxy server A and from here to User Agent 1. When User agent 2 accepts the call, it sends a successful message 200 OK back to User Agent 1 through proxy server B and proxy server A. after receiving this message User Agent 1 sends an ACK message directly to User agent 2 and this starts a media session between both users using other protocols like RTP. Whenever any user wants to end the session, it sends BYE message to the other user. BYE message is received by other user and it sends back acknowledgment in the form of 200 OK which ends the session.

2.5Applications of SIP

SIP devices are becoming very popular in market since last few years. SIP can be used for softphones as well has other IP phones for VOIP communication as well. Video conferencing, and video surveillance are also common applications using SIP. Some SIP enabled devices like Gateways and SIP trunks are increasingly replacing ISDN telephone lines.

2.6 Deployment Concerns

Like other protocols SIP also has some deployment problems.

2.6.1 Packet Loss

In channel associated signaling or communication where data and voice are travelling over same channel, voice or signalling packet may be dropped causing interruptions in voice communication. This problem can be solved using common channel signaling and even spliting voice and data traffic on different channels. some companies has also deployed multiple VLANs or traffic shaping to eliminate this problem.

2.6.2 Security Concerns

SIP channels also have security concerns like HTTP and mail servers. Proper security mechanisms are needed to avoid any attacks via SIP channels. IP networks face considerable risk of attacks and are never completely safe from external or internal attacks. So when SIP is deployed for IP networks it is compulsary to make sure that network posses sufficient physical security and trustworthy equipment is installed.

External attacks are more likely when the call traffic is involving some third party network which is not taking part in session and can be reduced by avoiding such situations.

Internal attacks are more difficult to handle as they usually involve trust breech by a SIP call participant with the network and are usually untraceable.Some major security problems and their proposed solutions are as following;

One major concern is Eavesdropping which causes loss of privacy in SIP. Encryption is one useful solution for such a problem. SIP can transmit encrypted data using TLs or IP security. By doing so any risk of Message Tempering is also eliminated.

Spoofing is possible when adresses are not authorized, Address authentication among all the call participants is necessary to avoid any unauthorized access.

Software bugs or Viruses can attack the device resulting in denial of service to actual user and unauthorized service access to the attacker. Remedy for this problem is to install proper antivirus applications and apply software patches.

The attacker can limit the access to network by flooding SIP proxy servers. one possible solution is to configure the devices to avoid such situations. Research is needed to provide quick and convineant remedies for such attacks.

Sometimes genuine request for reprocessing the messages is denied by the servers due to their Replay. By using sequence numbers and encryption this issue can be resolved.

2.6.3 Mobility

SIP provides personal mobility by allowing network to locate the user independent of its location and device. To support IP mobility somehow same technique is used as in mobile IP. If the mobile host is already using mobile IP for mobility then its not compulsary for SIP to keep the location information but in other cases SIP enabled devices should support mobility efficiently.

Location handeling in SIP: On SIP networks it is assumed that tha mobile node MN belongs to a home network having server which recieved the registration from that mobile host. But the MNs dont need static IP addresses and whenever a corrosponding node CN sends an INVITE message to the mobile host the redirect server forward the message to desired host using its current registration status.

Handoff Handeling on SIP: when a mobile host changes its location during a session, it sends a new INVITE message to CN using same call identifier from call setup. It sends the new IP address to the CN to tell where it can recieve further messages.

The main problem for SIP to allow mobility is that it can not support TCP connections. one proposed solution is to use SIP mobility for real time communication over UDP and, Mobile IP for TCP connections. This can be achieved by allowing mobile host to decide when to use care of address and when home address. that is for RTP streams host can use care of address and use home address in case of establishing TCP connections[ELin Wedlund]. This also eliminates the tunneling problem from conventional mobile IP. However dealing mobility on application layer can introduce additional delays and a policy table has to be maintained for decision making . This scheme could deal with compatibility issue but is not more effective to support fast mobility.

Because of the longer distanace between CN and MH and network congestion, the RE-INVITE message from the MH can be delayed causing packet loss and disruptions as without REINVITE the CH will keep sending packets to previous address of MH. For such situations there is a need of better approach to deal fast handoff. Ashutush Dutta et all presented some application layer approaches that can work well in this case [Fast-handoff Schemes for Application Layer

Mobility Management by Ashutosh Dutta, Sunil Madhani, Wai Chen, Telcordia Technologies Inc., 444 Hoes Lane, Piscataway, NJ 08854].

Server assisted approachs

1- One of these application layer approachs, addresses the situation by combining both SIP and RTP translator techniques. The visited registrar recieves the registration updates from the MN that has just moved, and sends a request to RTP translator to bind the previous IP address of MN and forward the new packets to new address. Then if the RTP translator does not recievs any futher media packets, it releases the old IP address and removes the previous entry from forwading table. This method is useful to deal with packet loss due to handoff but needs some aging mechanism at translator to release old IP addresses for reuse efficiently. This method also needs memory to keep table entries based on addresses and UDP ports.

2- One another method can be use of an Outbound Proxy. SIP requests traverse the outbound proxy in the visted network. By using information in RE-INVITE messages i.e. the MH media address from SDP, the outbound proxy can configure the RTP translator in a simpler manner. However some extra memory is required to keep the INVITE information at outbound proxy for unbounded time.

Mobile Host assisted approaches

Back to Back User Agent involves two user agents in the visted network. one of these will recieve the RE-INVITE request from MH and sets the parameter in SDP, the next UA will re issue the request to desired CH. Each visiting MH is required to address a B2BUA which in turn sends the RE-INVUTE request to the CH and forwards the packets using translator table. B2BUA not only set up the session between MH and CH but also establishes a call between itself and CH so that when the MH moves to a new subnet, it sends RE-INVITE and INVITE messages to CH. untill next new packets are recieved from the CH, B2BUA and the MH have a transient session for some time in which transient packets are exchanged between them. This technique requires assistance from MH to address the B2BUA as otherwise due to encryption the UAs wont be able to interpret the messages.

By using scoped multicast and handoff prediction from MH one another mechanism can be implemented. In this case the MH predicts before a possible handoff and informs the visted registrar or B2BUA about its temporary multicast address as its media address. after arriving in a new subnet and acquiring a new media address the MH informs the registrar or B2BUA again abt the new unicast address while still listening to the multicast address. the multicast agent may co locate with first hop router or co exist with the proxy servers in the network. This technique is possible for smart MH which is capable of predicting handoff and acquiring multicast address in timely manner.

3 Future Work

4 Conclusions


[1] Shelley Zhuang, Kevin Lai, Ion Stoica, Randy Katz, Scott shenker, "Host Mobility Using an Internet Indirection Infrastructure" in proceedings of MOBICOM 2003.

[2] M Atiquzzaman and Abu S Reaz, "Survey and Classification of Transport Layer Mobility Management Schemes," 16th Annual IEEE International Symposium on Personal Indoor and Mobile Radio Communications, September 11-14,2005

[3] H. Schulzrinne and J. Rosenberg, "The session initiation protocol: Providing advanced telephony services across the internet," Bell Labs Technical Journal, Vol 3, pp. 144-160, December 1998

[5] Porter, Thomas; Andy Zmolek, Jan Kanclirz, Antonio Rosela (2006). Practical VoIP Security. Syngress. pp. 76-77