Department of Computer Engineering

CmpE208- Network Architecture and Protocols

(Spring 2009, Tuesday Class)

SIP

Instructor
Prof. Dr. Rod Fatoohi
Abstract
In this project we propose to perform in-depth analysis of the SIP, Session Initiation Protocol which is an
application layer control protocol. Voice over IP is a very upcoming technology widely used in
performing PC-PC, PC to PSTN and PSTN to PC calls due to usage of low bandwidth and integration of
voice with data. Most of the VOIP applications use SIP, as its signaling protocol in performing the basic
operations in a call establishment which are creation, management and termination of sessions between
hosts in any IP based network. A detailed study of the SIP functionality and its structure is performed
followed by the experimental analysis of the SIP protocol which is done by using the two most widely
used VOIP applications, Yahoo Messenger and Media Talk Ring. Test connections are set up between two
hosts using the above mentioned applications and the data packets are captured using the Wireshark tool
where the various SIP methods and messages are presented. Some of the test scenarios such as call setup,
call forwarding on no answer, call placed with a request URI where the user does not exist, user located at
another location, called party is busy, called party terminates the call are performed by setting up calls
between PC-PC and PC-PSTN users. SIP works in conjunction with another protocol called SDP, the
Session Description Protocol which is used to share the session information between the two hosts. A
detailed study of the SDP is also performed with respect to the RFCs and a detailed analysis is done and
verified.

Introduction
SIP is a TCP/IP based Application Layer control protocol which initiates, manages and terminates
multimedia sessions. SIP runs on TCP, UDP and is designed to be independent of the underlying transport
layer. It is a text based Protocol similar to the Hypertext Transfer Protocol. Participants can be invited to
already existing sessions using SIP. It developed by the SIP working group within the Internet engineering
Task Force (IETF) multimedia data and control architecture. It is used in conjunction with Session
Description Protocol (SDP) which is an IETF protocol.

SIP Architecture
SIP consists of two basic components: the SIP clients and SIP servers. The SIP clients are also knows as
User-AgentTeam Members:
clients (UAC) is an end system component to initiate a call or send SIP requests. The SIP
server also known as User Agent Server (UAS) is a network device that answers the call or responds to
the requests. SIP is a client-server Protocol.
SIP network consists of four
Lalitha different servers
Garudadri Proxy
SJSU Id: server, redirect
006196034 server, user agent server, and registrar
<lalithagarudadri@gmail.com>
server.
User Agent:
Varun Kalyan Anantharaman SJSU Id: 005889377 < varunkalyan@gmail.com>
It is an endpoint entity. It starts and ends the session by exchanging requests and response. It is a client who is starting a session between server
and client. This client is always a sender in sip server while server is a receiver. This client can be phone, fax or anything. According to
requirements the role of server and client can be interchanged in the single session.

Registrar:

In SIP registrar has the same functionality as Gate Keeper has in H.323. This register is working as a database center in SIP Server.
It has all the information like IP address and port address of all connected users. It is also updating its data base according to the
connection changes between server and client. It is performing an authentication function.

Proxy Server:

Proxy Servers execute call signaling on the behalf of the parties they serve. It is also performing an authentication function. Proxy Server stay in
the path of call routing. It receives SIP requests and routes them to the other users or other Proxy Servers. Server do it based on the
routing data base and routing rules. Proxy Server can stay in the path of call.

Redirect Server:
Redirect Server determine the current location of the called party and gave its address to the calling party . Then calling party can do
direct contact of called party. It is basically used to point the location purpose. Redirect server is not staying in the path of call.

SIP Advantages

SIP Protocol Structure

The syntax of the SIP protocol is text based and looks similar to the HTTP. SIP messages are broadly
classified into two types SIP request messages which are sent by the client to the server, and SIP response
messages or status messages which are sent by the server in response to the client. Both the SIP requests
and SIP response messages have a similar syntax and consist of

 Start line: The start line consists of the request-line and status line. The request line specifies the
type of request and the status line gives the response for the request a success or a failure.
 Zero or more headers: This field gives additional information like the message originator, message
recipient, retry-after header and subject header.
 Message body: Consists of SDP which provides format for describing the session information
between the session participants.

SIP Request Messages

The SIP request message consists of a request line which includes the following fields a method
token, a request URI and SIP version. Request URI is the address of the user to which request is sent,
SIP version specifies the version of SIP being used. The method token describes one of the six
different SIP methods that are defined in the RFC. The following captures which are obtained by
placing calls between two VoIP clients using Yahoo Messenger and MediaRing Talk are used to
explain the various SIP request messages that are defined in the RFC.

 INVITE: The SIP INVITE method is used to start a session or place a call. This method consists of
the following fields
• Request-line: Which shows the SIP method INVITE, request URI i.e., address of the
called party sip:kmgarudadri@68.142.233.158:5050 and SIP version transport=tcp sip/2.0
• Message Header: The message body consists of From, To, Call-ID, Cseq, User-Agent, Via,
Contact, Allow, Content type, and Content-length fields.
• Message Body: It consists of the SDP which provides format for describing the session
information like session name, session originator, media type etc between the session
participants.

Capture: Invite Method

 ACK: This method is sent by the calling party when a final response like called user is busy or call
cannot be complete is received in response to the INVITE method. This method contains the
following fields Request-line, Message header From, To, Call-ID, Cseq, User-Agent, Max-
Forwards, Via, Contact, Content-Length. It can be observed from the capture that the content
length is zero as the message body is absent.

Capture: ACK Method

 CANCEL: This method is used to terminate a session for which an INVITE method is sent but a
final response is not received. The Content-length field is zero as observed from the captures as
there is no message body.

Capture: CANCEL Method

 BYE: This method is used to terminate the session. It can be initiated by the calling or the called
party. The Content-Length filed is set to zero as there is no message body.

Capture: BYE Method

 OPTIONS: This method can be used to find the features like type of media supported by the called
party by enquiring the server.

 REGISTER: This method is used by the user agent client to let the register server know where it is
located so that it can be contacted. The UAC registers its address with the SIP server for this
purpose. It can be observed that To and the From fields are the same as the user is registering
himself. The Register messages for one user should use the same call ID. The content length is set
to 0 as there is no message body. The Expires field is set to 3600sec indicating the duration for
which the registration is valid.

Capture: Register Method

 Additional SIP methods
 SUBSCRIBE: This method is used by the client to subscribe to certain events. It can be observed
from the capture that the Event field in this case is set to ‘billing’.

Capture: SUBSCRIBE method

 NOTIFY: When the events occur the client is informed using the NOTIFY method for the events it
subscribed to. It can be observed from the capture that the Event field is set to ‘billing’ to the
corresponding SUBSCRIBE request.

Capture: NOTIFY Method

 INFO: This method is used to communicate the mid-session signaling information by carrying
the session-related control information. This method does not changes the state of SIP calls and
the state of sessions initiated by SIP. It is used to provide more information which can enhance
the applications using SIP.

Capture: INFO Method

SIP Response Messages

The SIP response message consists of a status line which is a start line. The status line comprises of SIP
version, a three digit number which indicates the result of the request called status code and reason phrase
that interprets the textual description of the result. The RFC defines the following SIP response messages.
These responses can be explained from the captures obtained by placing a call between two clients using
Yahoo Messenger PC-PC and one client using Yahoo Messenger and the other using PSTN mobile service
PC-PSTN.
 Provisional (1xx): Indicates that request sent by the client is received by the server and it is
processing the request. TRYING 100, RINGING 180, CALL IS BEING FORWARDED 181,
QUEUED 182, SESSION PROGRESS 183 are the 1xx responses defined in the RFC
• TRYING 100: The TRYING response is sent by the proxy server that serves the called party
in response to the INVITE method sent by the proxy server that serves the calling party. This
response is sent to the calling party to indicate that the INVITE method is received and the
proxy is working to route the INVITE message on its behalf. It can be observed that the
Content-Length field is zero.

Capture: 100 TRYING

• RINGING 180: This response is sent back to the calling party which indicates that the
INVITE method is received and the called party is alerted.

Capture: 180 RINGING

• CALL IS BEING FORWARDED 181: This status code is used by the server to indicate that
the call is forwarded to another destination example a voice mail server

Capture: 181 CALL IS BEING FORWARDED

• SESSION PROGRESS 183: The 183 Session Progress Message is a new extension of SIP
response which sends an indication from the calling user agent client to the called user agent
server that a One-way media path is opened from the called party to the calling party.

Capture: 183 SESSION PROGRESS

 Success (2xx): This response indicates that the server received, accepted and understood the
actions successfully. OK 200 is the 2xx response defined by the RFC
• OK 200 : This status code indicates that the request is successful
 Capture: OK 200
 Redirection (3xx): These responses indicate that further actions are needed to complete the
request.
 Request Failure (4xx): These responses indicate that there is a failure from a particular server.
The request by the client might contain a bad syntax or cannot be fulfilled at the server. The client
can modify the request and try again. UNAUTHORIZED 401, FORBIDDIEN 403, PROXY
AUTHORIZATION REQUIRED 407, TEMPORARILY UNAVAILABLE 480, REQUEST
TERMINATED 487, REQUEST PENDING 491 are few of the responses defined in the RFC
• UNAUTHORIZED 401: This response indicates that the request needs user authentication. It
is issued by User agent server and registrars.

Capture: UNAUTHORIZED 401

• FORBIDDEN 403: This response is sent by the server indicating that it understood the clients
request but is refusing to fulfill the request.

Capture: FORBIDDEN 403

• NOT FOUND 404:
This response is sent back to the user indicating that the server has information that the
user does not exit at the domain that is specified in the Request-URI

Capture: NOT FOUND 404

• PROXY Authentication Requires UNAUTHORIZED 407:This response indicates that the

client should first authenticate itself with the server.
 Capture: PROXY Authentication Requires UNAUTHORIZED 407
• TEMPORARILY UNAVAILABLE 480: This response indicates that the called party is
contacted successfully but is temporarily not available. For example the user could be
available in some other location unknown by the server, the user is not logged in, or the user
activated do not disturb feature.

Capture: Temporarily unavailable 480

• CALL LEG/TRANSACTION DOES NOT EXIST 481:This response indicates that a request
which does not match any existing transaction is received by User Agent Server.

Capture: Call Leg/ Transaction Does Not Exist 481

• ADDRESS INCOMPLETE 484: Indicates that a request is received by the server with an
incomplete Request-URI

Capture: Address Incomplete 484

• BUSY HERE 486: Indicates that the called party is busy

Capture: Busy Here 486

• REQUEST TERMINATED 487: This response is sent when the request is terminated by a
CANCEL or BYE request.

Capture: REQUEST TERMINATED 487

 • REQUEST PENDING 491: This response is sent by the User agent server to the client
indicating that the request was received by the UAS and has a pending request within the same
dialog..

Capture: REQUEST PENDING 491

 Server Error (5xx): These responses indicate that the server failed.
• BAD GATEWAY 502: This response indicates that the invalid response is received by
the server when it is trying to fulfill a request from a downstream server.

Capture: Bad Gateway 502

• SERVICE UNAVAILABLE 503: This response indicates that the server cannot respond
temporarily due to maintenance or overloading of the server

Capture: Service Unavailable 503

• SERVER TIME-OUT 504: A response is not received on time by the external server in
the attempt of processing the request.

Capture: Server Time-out 504

 Global Failure (6xx): These responses indicate that the server has information about the user but
the request cannot be fulfilled at any server.

SIP Scenarios
1. Simple Call flow

➢ Call Initiation
This scenario is used to show the basic function of exchange of SIP messages used to initiate a
session. To study the exchange of messages a call is setup between two clients using SIP Yahoo
Messenger VoIP application. A call is placed between the two clients using SIP identity i.e..,
 SIP URI which is Uniform Resource Identifier. The exchange of the SIP messages between the
two clients is shown in the figure below.

Capture: Showing the exchange of SIP messages for establishing a call

Timeline Capture: Showing the exchange of SIP messages for establishing a call

The SIP URI is similar to an Email address which consists of a username and host name or
Username and Phone. It can be observed from the capture that SIP URI in this scenario is
sip:garudadrikrishnamurthy@68.142.233.115:443 where 68.142.233.115:443 is the domain of the
called party SIP service provider.

• INVITE MESSAGE: SIP is a request/response transaction model. The transaction is initiated

when the calling party sends an INVITE request to the called party using the called parties SIP
URI. The INVITE request contains a number of fields. The fields are described below.

Capture: Invite message

The first line shows the Request line which contains the INVITE method. Following the
Request line is the Message header indicating a list of header fields which are
 ○ Via: TheVia field contains the sip version being used, the address at which the calling
party wishes to receive the response for the request 192.168.1.107:55154. It also contains
a branch parameter indentifying a transaction.
○ Contact: This field contains the SIP URI that indicates a direct route to contact the calling
party. Contact header is used to let others know where to send future requests.
○ To: This field provides the address of the called party i.e., the called users name
garudadrikrishnamurthy and SIP URI sip:garudadrikrishnamurthy@68.142.233.115:443
○ From: This field provides the address of the calling party i.e.., the calling users name
glalitha21 and SIP URI sip:glalitha21@68.142.233.115:443 who initiated the session
followed by a tag field 207b1657 which is generated by the calling party for identification
and is a pseudorandom value.
○ Call-ID: A unique ID set by the calling party which uniquely identifies an invitation to a
session.
○ Cseq: This field specifies the method being used and has a unique integer number the Cseq
integer value will be incremented for same Call-ID initiating a new request method.
○ User-Agent: This field indicates the type of application being used.
○ Content type: This field indicates the media type of message body. Most of the VoIP
applications have this field as SDP.
○ Content-length: This field indicates the length of the message body in octets

It can be observed from the To and From field that the proxy server for both the calling
and called party is the same.

• TYRING message: When the INVITE message is received by the proxy server
(68.142.233.155) it acts on behalf of the called party and sends a TYRING(100) response back
to the calling party.

Capture: Trying message

This response indicates that the INVITE message has been received and the proxy server
is working to route that message to the destination. It can be observed from the INVITE
capture that From, To, Call-ID, Cseq, Branch field in the Via filed is the same as the
INVITE message to help the calling party to correlate the response to the INVITE
message sent.

• RINGING message: When the INVITE message is received by the called party the called
party is alerted to the incoming call and if the called party decides to receive the call a 180
ringing response is sent back to the calling party.
 Capture: Ringing Message

• OK message: When the called party receives the call 200 OK response is sent by the called
party indicating that the call is answered. This response contains a message body with the SDP
media description which indicates the type of session the called party is ready to establish with
the calling party.

Capture: OK message
• ACK message: An Ack message is sent by the calling party to the called party to confirm the
reception of the final response.

Capture: Ack Message

Session Description Protocol

It can be observed that there is a two-phase exchange of the SDP messages between the two parties’ one
from the calling to the called party and another from the called to the calling party providing the
negotiation capabilities between the two end parties. SDP information is carried in the SIP message body.
The session information between two participants is described using the Session Description Protocol.
The parameters relating to the media stream is described using session-level parameters and media-level
parameters. The session-level parameters include the following information protocol version(v), name of
the session(s), originator session ID(o), time of the session(t) i.e. how long the session should be active.
The media-level parameters include the following information like media description which comprises of
the media type, port number, transport protocol, media format (m), media information(i), connection
information(c), bandwidth information(b), attributes(a). These fields can be observed in the following
SDP capture.
The syntax of all the fields are described below
• Origin (o): Consists of 6 subfields username, session ID, version, network type (IN), address
type (IP4) and address of session originator.
• Connection Data (c): Consists of three subfields network type (IN), address type (IP4),
connection address of the session originator.
• Media Information (m): Consists of four subfields media type (audio), port (45825), transport
(RTP/AVP), formats lists all various type of media format that a user can support.
• Attributes (a): Can be specified at the session level or media level or both. Attributes
are of two forms property attributes and value attributes. Property attributes specifies
that a session has a specific characteristic like sendonly or recvonly. Value attributes
like orient specify that a session has a particular characteristic of a particular value. Format of
attribute is a: rtpmap: <payload type> <encoding name/ clock rate>
Example a: rtpmap: 103 ISAC/16000

Capture: Session Description Message send from calling party to called party
 Capture: Session Description Message send from called party to calling party
➢ Call termination:

The capture below shows the exchange of SIP messages when a party wishes to terminate a call.

Capture: Showing exchange of SIP messages to terminate the call

Timeline capture: Showing exchange of SIP messages to terminate the call

• BYE message: One of the parties generates a BYE message when it is decided to terminate the
call. In this scenario the calling party generates a BYE message.
 Capture: BYE message

• OK message: The called party sends a 200 OK message to confirm receipt of the BYE
message which terminates the session.

Capture: OK message

2. Call hold
In this scenario a call is placed is placed to one client using Yahoo Messenger and the call is
placed on hold and another call is made to second client. The second call is terminated and the
first call is resumed back. Finally the first call is terminated. The Exchange of SIP packets is
shown in the capture below.
3. Call Forwarding on No Answer: - 181 response
This capture is obtained when a call is placed between two Yahoo Messenger SIP clients and the called
party does not receive the call. The call is being forwarded to an automatic voice message system.
 Capture: Showing the exchange of SIP messages

Capture: Call Is Being Forwarded 181

The timeline graph below shows the exchange of SIP messages for the call set up. The call establishment
process is the same as explained in the first scenario. When a ringing 180 message is sent from the called
to the calling party it is up to the called party to answer the call or ignore the call. When the called party
does not receive the call a 181 message is sent from the called to the calling party.

Capture: Showing the exchange of SIP messages when the called party does not
receive the call (181 call is being forwarded message).
4. Call placed to an Invalid number

The following capture is obtained when a call is placed to an invalid number a Call Forbidden 403
response is sent back to the calling party indicating that it’s an invalid number.

Capture: Forbidden 403 Invalid number

The capture below is obtained by placing a call from Yahoo Messenger which does not have a phone
out service. When the user tires to place the call a Forbidden 403 message is also sent by the server
indicating that Subscription is required.

Capture: Forbidden 403 Subscription Required

5. Call placed with a Request-URI where the user does not exist.

The following capture is obtained by placing a call using MediaRing talk to a number which does not
match with any of the domains that the recipient of the request handles. A Not Found 404 response is
sent back to the calling party indicating that the user does not exist at the domain specified in the
Request URI.

Capture: Not Found 404

 Capture: Showing the exchange of SIP messages when user does not exist at the domain specified
in the Request URI (404 Not Found).

6. User is located at another location - Temporarily Unavailable 480:

This response is obtained when a call was placed by using the Yahoo Messenger phone out service. A
phone number was registered twice using two different names. The response is forwarded by the
server to the calling party indicating that the Called party is contacted successfully but the called
party is currently unavailable as the user is available at another location.

Capture: Temporarily Unavailable 480

Capture: Showing the exchange of SIP messages when the called party is available at another
location (480 Temporarily Unavailable).

7. Call Placed with Request – URI that does not match transaction

When a call is placed from Yahoo Messenger with an ID that does not have the phone out service with a
number that doesnot match any transaction or match any existing numbers the server sends back Call
Leg/Transaction does not exist to the calling party. The response can be observed from the capture below.
 Capture: Call Leg/ Transaction Does not Exist

Capture: Showing the exchange of SIP messages when the number does not match any transaction
(481 Call Leg/ Transaction Does not Exist).

8. Address Incomplete: Call placed with Request-URI incomplete:

The capture below is obtained by placing a call from Yahoo Messenger by using the phone
out service to a number with incomplete information like dialing few digits the server sends
back an Address Incomplete 484 response indicating that the server received a request with a
Request-URI which is incomplete. Additional information needs to be provided to complete
the call.

Capture: Address Incomplete 484

 Capture: Showing the exchange of SIP messages Call placed with incomplete URI (484 Address
Incomplete)

9. Call Party is Busy

The following capture is obtained when a call is placed to a client which is currently not willing to
accept the call or cannot accept any additional call as it is on a call a Busy Here 486 response is sent
back by the server to the client indicating that the called party is busy.

Capture: Busy Here 486

Capture: Showing the exchange of SIP messages when the called party busy (486 Busy
Here).

10. Called party terminates the call

When a call is placed between two clients the called party can receive the call or reject the
call. The following capture is obtained when a call is placed between two Yahoo Messenger
clients and the called party rejects the call. A status code 487 request terminated message is
sent by the server to the calling party indicating that the called party rejected the call.

Capture: Request Terminated 487

 Capture: Showing the exchange of SIP messages when the called party terminates the call (487
Request Terminated).

11. 502 Bad Gateway

The following capture is obtained by placing a call using MediaRing Talk when the server
receives an invalid response from a downstream server in the process of fulfilling the request
by the calling party a Bad Gateway 502 response is sent back to the calling party.

Capture: Bad Gateway 502

Capture: Showing the exchange of SIP messages when server receives invalid response
from downstream server (502 Bad Gateway).

12. Service Unavailable

When a call is placed to a mobile from a VoIP application like SKYPE or Yahoo Messenger a default
number is displayed for that call. The following capture is obtained when a call is placed from Media
Ring talk to that default number. When such a call is placed by the calling party the server responded
with a 503 service unavailable message indicating that the server is temporarily unable to process the
request due to maintenance or temporary overloading of the server.
 Capture: Service Unavailable 503

Capture: Showing the exchange of SIP messages when the server is Temporarily Unavailable (503
Service Unavailable).

13. Server Time-out:

When the server does not receive a timely response when it tries to process the request from an
external server a Server Time-out 504 response is sent back to the calling party as shown in the
capture below.

Capture: Server Time-Out 504

Capture: Showing the exchange of SIP messages when the Server does not receive a timely response
(504 Server Time-Out).

14. SIP 183 Session Progress Message - PSTN Internetworking

The 183 Session Progress Message is a new extension of SIP response which sends an indication
from the calling user agent client to the called user agent server that a One-way media path is opened
from the called party to the calling party. In-band call progress information such as tones and
announcements are provided to the calling client using this process. In traditional telephone network
this requirement is handled with SS7 using the Address Complete Message (ACM).

PSTN internetworking concept is described using a test scenario when a call is placed from Yahoo
message (SIP client) to a mobile phone (PSTN Network). The SIP network should be able to
communicate with the PSTN when a call is established between a SIP-based network and PSTN
using the signaling protocol used by the PSTN which is the SS7 protocol. For internetworking
between the SIP and the PSTN there is a Gateway entity in the network to provide the conversion
from circuit-switched media to packet-switched media.

When a call is placed from Phone out service provided by the Yahoo messenger to Mobile phone
connected to the PSTN switch the exchange of SIP messages takes place as shown in the captures
below. It can be observed that the SIP URL has the form of a telephone number which can be viewed
in the To field in the INVITE message. The INVITE message sent by the calling party to establish a
session is mapped to the IAM message of the calling party. The PSTN switch sends an ACM message
in response to the IAM which is mapped to the 183 (session – progress) response. The in-band
information which is contained in the SDP of the 183 response message is returned from the called
switch to the SIP caller. This enables a one way path from the Called to the Calling party. An ANM is
returned back which is mapped to the 200 (Ok) responses when the call is answered. An updated
Session description is sent in this response. An ACK message is sent from the calling to the called
party. Two way voice sessions is established. Any party can terminate the session by sending a Bye
message.

Capture: Showing the exchange of SIP messages.

 Capture: Timeline graph showing the exchange of SIP messages

Capture: Invite message showing the SIP URL has the form of telephone number in the To field

Capture: 183 Session Progress Message

At the end of the session a Notify message is sent back to the caller. The SDP in this message
contains the billing information: the cost if the call, the remaining balance etc which is shown in the
capture below.
Capture: Notify message showing the billing information at the end of the session