Session Initiation Protocol
Session Initiation Protocol or SIP is the IETF standard for voice or multimedia session
establishment over the Internet. It was proposed as a standard (RFC 2543) in Feb. 1999. Its
original author was Henning Schulzrinne. SIP is an application level protocol used for call
setup management and teardown. SIP is used in association with its other IETF sister
protocols like the SAP, SDP and MGCP (MEGACO) to provide a broader range of VoIP
services. The SIP architecture is similar to HTTP (client-server protocol) architecture. It
comprises requests that are sent from the SIP user client to the SIP Server. The Server
processes the request and responds to the client. A request message, together with the
associated response messages makes a SIP transaction.
SIP makes minimal assumptions about the underlying transport protocol and itself provides
reliability and does not depend on the underlying protocol’s characteristics. SIP depends on
Session Description Protocol (SDP) for negotiation of session parameters such as codec
identification and media. It supports user mobility through proxy servers and redirecting
requests to the user’s currently registered location. The SIP specifications are provided in
RFC2543 of IETF.
Some major SIP features are as follows:
Feature Description
Call Setup Session Establishment with agreed call parameters between the two
endpoints.
Renegotiate call
parameters
Renegotiate session parameters while the call is in progress.
User Location Determination of the end system to be used for communication, given the
user’s email style address.
User Availability Determination of the willingness of the called party to engage in a
conversation.
User Capabilities Determination and negotiation of the media and call parameters to be used in
the session.
Call Handling Transfer and termination of the call.
Network Convergence and VoIP Debashish Mitra 14 of 36
The SIP architecture specifies two components as given below.
User Agents : A SIP User Agent is an end system (end point) acting on behalf of the user. It consists of two
parts:
User Agent Client (UAC): This is the user client portion, which is used to initiate a
SIP request to the SIP servers or the UAS.
User Agent Server (UAS): This is the user server portion that listens and responds
to SIP requests
Note: User = UAC+UAS
SIP Servers
The SIP architecture describes the following types of network servers to help in the SIP call
setup and services.
Registration Server: This server receives registration requests from SIP users and updates
their current location with itself.
Proxy Server: This server receives SIP requests and forwards them to the next-hop server,
which has more information of the called party.
Redirect Server: This server on receipt of the SIP request, determines the next-hop server
and returns the address of the next-hop server to the client instead of forwarding the request
to the next-hop server itself (as in the case of SIP proxy).
SIP Messages
SIP defines the following major messages between the client and server.
INVITE Request to invite a user (called party) to a call
ACK Acknowledgment to start reliable exchange of invitation messages
BYE To terminate (or transfer) the call between the two endpoints
OPTIONS Request to get information about the capabilities of a call
REGISTER To register information of current location with a SIP registration server
CANCEL Request to terminate search of a user or “ringing”
INFO Mid-call information (e.g. ISUP, DTMF)
PRACK Provisional Acknowledgement
COMET Pre-condition met
SUBSCRIBE Request to subscribe to an event
NOTIFY Notify subscribers
Network Convergence and VoIP Debashish Mitra 15 of 36
Typical SIP Call setup
Although SIP is relatively new, it has already been implemented by several companies. The
implementations encompass SIP proxy and redirect servers; User agents on MS Windows,
Linux, etc.; Ethernet Phones; Softswitches; firewalls, SIP-H.323 translators and unified
messaging systems.
Some of the current ongoing implementations are being done by companies such as
dynamicsoft, Hughes Software Systems, Cisco, Ericsson, Hewlett Packard, Lucent, Nokia,
Nortel, Siemens, Telogy, Iwatsu Electric and Vovida. Universities such as
implementations. The SIP stack can also be found as Open Source software. Companies such
as Vovida or dynamicsoft have SIP stacks in the Open Source arena.
Comparison between H.323 and SIP
SIP is a relatively new protocol as compared to H.323 and hence, has been able to avoid all
the problems associated with H.323. Because H.323 had been initially designed, keeping ATM
and ISDN in mind, it was not suited to control voice traffic over IP networks. The earlier
version of H.323 is inherently complex with large overheads and is thus inefficient for IP
networks, where bandwidth is a premium commodity.
On the other hand, as SIP has been designed keeping the Internet in mind, it has been able
to better address and circumvent the complexity and extensibility issues. SIP is “HTTP-ish”,
i.e. it reuses most of the HTTP header fields, encoding rules, error codes and authentication
mechanisms. SIP uses only 37 header fields as compared to hundreds of elements in the
H.323 header. This “HTTP-ish” characteristic of SIP enables it to be lightweight and also
gives it the potential of becoming a more popular protocol, such as HTTP, over the Internet.
H.323 uses a binary representation for its messages. This is based on ASN.1 syntax. The SIP
however, is a text-based protocol such as HTTP. SIP is more scalable, whereas H.323 has
limited scalability, as it was initially designed for use within a single LAN. The newer versions
of H.323 have, however, managed to address this issue.
complex multi-domain searches in H.323 are limited and not very scalable. This is done in a
limited manner in H.323 by maintaining message states. However, in SIP this is done
efficiently by checking the path history stored in the message header and thus it can be done
in a stateless manner.