Technical writting about SIP

1. Session Initiation Protocol
Raheem Muftau, muftau@kth.se
Computer Networks-Royal Institute of Technology .
Abstract— Communication for decades now has outgrown the reachable and they include proxy, location, redirect and
traditional PSTN communication system and because, everything is registrar servers. Figure 1 shows the architecture of the SIP
over IP, there is need to understand how this has evolved, the network.
technology, and the mode of operation in general. This paper focuses
on the basic concepts of the Session Initiation Protocol which is a
signalling protocol, its data presentation formats and also how the
PSTN network had been made to suitably rout over the IP network
with the use of ENUM.
Keywords— SIP, SDP, UA,URI, SIMPLE, ENUM
I. INTRODUCTION
T he Session Initiation Protocol (SIP) is an application
layer protocol which is an ASCII-based designed and
developed by the IETF with good scalability, simple
implementation and flexibility in mind and all SIP
specifications had been defined in the RFC3261 [2]. The SIP
session negotiation is a request and response model between
Fig. 1 SIP Architecture
user agents which can act in a dual role but will take a role at
a point during a session. The functions of this servers is described thus:
SIP basically is a signalling protocol, so it mainly focuses on
making the communication possible by establishing the 1) Proxy Servers: This is the intermediate component that
session between user agents. For a complete communication acts on behalf of the user agents. The major role of the proxy
session, Real Time Protocol (RTP) and Session Description server is to ensure that session invitations are routed closer to
Protocol (SDP) are employed once the session is established. the called party. [1] Other functions of the proxy server
The RTP is used for the real- time multimedia data includes authorization, authentication, routing, network access
transmissions and SDP for the description of the data so it is control, reliable request transmissions and security.[6]
easily decoded by both agents. SIP had been designed to 2) Redirect Servers: It provides the client with the
provide a better functionality compared to the traditional information of the next hop where the session will be routed
PSTN because it is open to implement new serviced which over by sending a 3xx redirection response class message to
might be difficult to do in the PSTN. [1] the client based on the registrar’s database.
II. SIP ARCHITECTURE AND ITS ELEMENTS 3) Registrar: The registrar server accepts requests from
UACs for the registration of their current location. It is often
A. SIP Architecture placed together with the location server. [6]
SIP had been designed to function as a peer-to-peer protocol
4) Location: This server provides address resolution to the
that establishes sessions between peers [2]. The peers
proxies and the redirect servers using tools such as Finger
participating in these sessions are referred to as User Agents
protocol and RWhois. [6]
(UA). These User Agents functions as either a client or a
server at a time depending on the role it takes during the B. Call setup between two User Within a Proxy
session. When the user agent initiates requests and accepts SIP calls are established in several ways, within this section,
responses then it is referred to as the User Agent Client we examine the situation when the calling party and the called
(UAC) and on the other round when a user agent receives party both belong to the same domain (proxy server). This call
requests and sends responses, then is referred to the User is between two user agents, Raheem and Mustafa.kpa as it is
Agent Server (UAS). With this in mind, the architectural further shown from the capture of the call between them. In
network design of SIP can be classified as either a Client or a this case the caller is Raheem and the called is Mustafa.kpa.
Server. The clients are the endpoints which primarily are the To create a session, Raheem calls the URI (Uniform Recourse
user agents that could either be UAC or UAS. The servers are Identifier) of Mustafa.kpa which is similar to an e-mail format
those part of the network that ensures the user agents are because it has the username and the hostname part. Fort this

2. scenario, the URI of Mustafa.kpa being called is Call-ID:
sip:mustafa.kpa@iptel.org and because both parties belong to 6F6DD13843954D2FA9D6B9403410482E0xc10a279
same proxy, the URI of Raheem (caller) is raheem@iptel.org. d
Musta.kpa is called from a softphone (SJphone) which sends CSeq: 3 BYE
an INVITE that a client raheem@iptel.org will like to Max-Forwards: 70
connect with it. The details of the call session is described User-Agent: SJphone/1.65.377a (SJ Labs)
below based on the capture with from a packet sniffer. Content-Length: 0
INVITE sip:mustafa.kpa@iptel.org SIP/2.0 The BYE method is the termination message between both
Via: SIP/2.0/UDP user agents. The messages in both cases are similar as with the
193.10.39.157;branch=z9hG4bKc10a279d00000 INVITE method. With critical investigation into the two
10a4cd1702b000042e700000091;rport initiation and termination process during the session, it could
From: "raheem" be observed that both user agents belongs to the same proxy
<sip:raheem@iptel.org>;tag=9c76c6cd6 server which is iptel.org as it could be seen from the URI of
To: <sip:mustafa.kpa@iptel.org> both user agents (raheem@iptel.org and
Contact: sip:raheem@193.10.39.157 Mustafa.kpa@iptel.org ).
Call-ID: To every method, there is an accompanied RESPONSE with a
6F6DD13843954D2FA9D6B9403410482E0xc10a279 code signifying the type of response to the request made.
d Below is what the RESPONSE looks like from the packet
CSeq: 1 INVITE sniffer during the session.
Max-Forwards: 70 SIP/2.0 100 trying -- your call is
User-Agent: SJphone/1.65.377a (SJ Labs) important to us
Content-Length: 368 Via: SIP/2.0/UDP
193.10.39.157;branch=z9hG4bKc10a279d00000
The above capture illustrates the INVITE method which is 10b4cd1702b0000542700000093;rport=5060
the request initiation process. The details of the INVITE is From: "raheem"
further described. <sip:raheem@iptel.org>;tag=9c76c6cd6
Via shows that the version 2 of SIP is being used together To: sip:mustafa.kpa@iptel.org
with UDP and 193.10.39.157 as the address where raheem Call-ID:
will receive all responses to its request. 6F6DD13843954D2FA9D6B9403410482E0xc10a27d
From shows the client making the request in this case CSeq: 2 INVITE
Raheem and its URI, raheem@iptel.org with an identifier Server: ser (3.1.0-pre1 (i386/linux))
called tag appended by the SJphone. Content-Length: 0
To shows the username and the URI of the UAS where all
SIP/2.0 180 Ringing
requests are directed which are Mustafa.kpa and
Via:SIP/2.0/UDP
sip:musta.kpa@iptel.org respectively.
193.10.39.157;branch=z9hG4bKc10a279d00000
Call-ID is the global unique identifier for the call generated
10b4cd1702b0000542700000093;rport=5060
by the combination of the random strings and Soft phone’s From:"raheem"
hostname or the IP address. <sip:raheem@iptel.org>;tag=9c76c6cd6
The CSeq shows an integer being incremented at every To:"MZ Mustafa"
request with a method name i.e INVITE. <sip:mustafa.kpa@iptel.org>;tag=30676bd07
Max-Forwards with a value of 70 shows that maximum Contact: sip:mustafa.kpa@193.10.39.158
hop the request could make to the server. This number Call-ID:
decreases as each hop is met. 6F6DD13843954D2FA9D6B9403410482E0xc10a27d
User-Agent shows the client and soft phone from which Record-Route:
the request had been made. [2] sip:213.192.59.75;ftag=9c76c6cd6;avp=veAD
BwBhY2NvdW50AwB5ZXMDBgBzdGltZXIEADE4MDADC
BYE sip:mustafa.kpa@193.10.39.158 SIP/2.0 QBkaWFsb2dfaWQWADViOTgtNGNjODdhNTItZDgxOG
Via: SIP/2.0/UDP E0NDg;lr=on
193.10.39.157;branch=z9hG4bKc10a279d00000 Server: SJphone/1.65.377a (SJ Labs)
10d4cd170340000365000000099;rport
From: "raheem" SIP/2.0 200 OK
<sip:raheem@iptel.org>;tag=9c76c6cd6 Via: SIP/2.0/UDP
To: 193.10.39.157;branch=z9hG4bKc10a279d00000
<sip:mustafa.kpa@iptel.org>;tag=30676bd05 10b4cd1702b0000542700000093;rport=5060
7 From: "raheem"
Contact: sip:raheem@193.10.39.157 <sip:raheem@iptel.org>;tag=9c76c6cd6

3. To: "MZ Mustafa"
<sip:mustafa.kpa@iptel.org>;tag=30676bd07
Contact: sip:mustafa.kpa@193.10.39.158
Call-ID:
6F6DD13843954D2FA9D6B9403410482E0xc10a27d
CSeq: 2 INVITE
Record-Route:
sip:213.192.59.75;ftag=9c76c6cd6;avp=veAD
BwBhY2NvdW50AwB5ZXMDBgBzdGltZXIEADE4MDADC
QBkaWFsb2dfaWQWADViOTgtNODdhNTItZDgxOGE0N
Dg;lr=0
It could be observed that record-route is being used during this
INVITE method; details will be discussed later in the paper.
SIP/2.0 200 OK
Via: SIP/2.0/UDP
193.10.39.157;branch=z9hG4bKc10a279d00000
10d4cd170340000365000000099;rport=5060
Fig. 1 SIP Signalling between two User agents within a Proxy Server
From: "raheem"
<sip:raheem@iptel.org>;tag=9c76c6cd6 C. Signalling between two user agents on different proxy
To: "MZ Mustafa" servers and the effect of record route on it.
<sip:mustafa.kpa@iptel.org>;tag=30676bd07
There are two ways to use the proxy during a session
Contact: sip:mustafa.kpa@193.10.39.158
establishment, it is either to have record route enabled or
Call-ID:
disable. By Record route we mean that the proxy includes a
6F6DD13843954D2FA9D6B9403410482E0xc10a27d
CSeq: 3 BYE record route header field in the SIP messages during requests
in other to ensure that all requests are sent through the same
path sequence in this case, the proxy. This feature is often
The flow response from the protocol analyzer as shown above
used for proxies that are providing mid-call features [2]. When
has some unique status codes which signify different meaning
no record route is used, then the messages needs no send
based on its operation at a particular time. The summary of the
further messages via the proxy once a communication session
codes is described below:
had been established. Figures 3 and 4 illustrate the effect of
• 1xx means provisional response e.g 100/180
the proxy servers during the session signaling. Figure 3 shows
(Ringing) continuous and constant message path from the user agents
• 2xx means positive final responses e.g 200 OK through the proxy servers, while the reverse is noticed in
• 3xx used for redirecting the calling party figure 4 as shown, once a communication session had been
• 4xx used for negative final responses established between the two user agents, then there is no need
for the messages to be communicated via the proxy.
• 5xx means there is a problem on the server’s side
• 6xx indicates the request cannot be fulfilled at any
server. [1]
It could be seen that the INVITE method has three responses
which includes 100 (trying), 180(Ringing) and 200 (OK). The
100 and 180 indicates the result of the processing is yet to be
known and immediately the server responds to the request, the
status changes to 200 OK which connotes the final response of
the request process. Figure 2 below shows a detailed session
request between the user agents within same proxy server.
Fig. 3 SIP Call Signalling between two User agents and different Proxy
Servers with record route enabled.

4. Each client is composed of a Presence source which provides
information to the presence server which makes the
information available to the watchers. The watchers are the
clients that requests the Presence of the other user in the
communication.
IV. JABBER(XMPP)
Extensible Messaging and Presence Protocol (XMPP) is an
extensible Message and Prescence protocol which is an open
technology for instant messaging, presence multiparty chat,
voice and video calls and generalised routing of XML data.
[4]. It uses TCP rather than UDP and denoted by a jabber
identifier in the form user@name.com.
Table ii below highlights the key difference between SIMPLE
Fig. 4 SIP Call Signalling between two User agents and different Proxy
Servers without record route enabled
and XMPP
TABLE II
D. Session Description Protocol, SDP SIMPLE VERSES XMPP
This protocol is meant for the description and encoding of
SIMPLE XMPP
session participants which is later used for the session
Uses Proxy servers No proxy required
negotiation so that all participants are able to take part in the
Uses SIP, so supports Purely XML
session [1]. By this all participants in the session will have
signalling
same encoding schemes to understand and decode all requests
and responses. SDP is capable of describing multimedia Consumes network Small because it is purely
sessions which includes the type of media to be used, resources because it text based
transport layer protocol and possible codec for the adds SIP headers
transmission. Likely result of the SDP is described below as
obtained from the packet sniffer. V. ENUM
(a): rtpmap:3 GSM/8000
(t): 0 0 This is a standard developed by the IETF and administers by
(a): rtpmap:8 PCMA/8000 the ITU that shows the scalability of the Session Initiation
(c): IN IP4 193.10.39.157 Protocol. ENUM meaning Electronic Numbering is the
SDP has some basic syntax which are often appended to the mapping of telephone numbers to domain names using a DNS
SDP capture of SIP, some of this is shown in table 1. based architecture. This is achieved through mapping which
makes it easier to translate the common PSTN numbers to an
TABLE I internet based address in the form of x.x.x.x....e164.arpa [9].
SDP SYNTAX
How this is done is shown in the table iii below.
Syntax Attributes TABLE III
a Attribute of the session PSTN TO IP BASED ADDRESS
b Bandwidth
C Connection information Rule Application
o Session owner Turn the PSTN and the 234565764
country code backward
v Protocol version
e.g +467565432
m Media name
Add points between each 2.3.4.5.6.7.6.4
t Active time
number disregarding the +
An application of this could be seen in a real time streaming
Add .e164.arpa at the end 2.3.4.5.6.7.6.4.e164.arpa
media managed by Real Time Streaming Protocol (RTSP).
The URI address 2.3.4.5.6.7.4.e164.arpa can then be used by
RTSP manages media sessions between endpoints using the
an internet client which will make it possible to use VoIP
SDP as its presentation description format.
protocols for its communication. With this, the when a user
III. SIP INSTANT MESSAGING AND PRESENCE (SIMPLE) dials a PSTN number, the SIP server does an ENUM lookup
as described in table II then the ENUM server detects the SIP
SIMPLE as the name implies, is a SIP for Instant Messaging
address which is then sent to the SIP server. [8].
and Presence, it is an open standard which aids its
interoperability with other protocols compared to other VI. CONCLUSION
proprietary protocols. It becomes important to know how the
This paper has elaborated the Session description protocol
presence service is implemented in the SIMPLE since the SIP
from a practical view because it is primarily based on a
had been extended to support the presence of users.
laboratory experience being monitored from a network

5. analyser. The methods (INVITE , BYE ) with their responses Request-Line: BYE
and the message codes were keenly observed. The effect of sip:mustafa.kpa@193.10.39.158 SIP/2.0
proxy servers in relation to other supporting servers like the Status-Line: SIP/2.0 200 OK
registrar, location and redirecting servers were observed and As it could be seen, the request lines are mainly the plain text
they have proven to be capable of making SIP a protocol of the messages and no code attached to them.
much better than the traditional PSTN.
F. What’s the call ID?
VII. APPENDIX
Call-ID contains a globally unique identifier for this call,
A. IP Address of the User Agent being used during the generated by the combination of a random string and the SJ
Laboratory exercise. phone host name or IP address.
193.10.39.157 Call-ID:
E07F8C8746D64E13B593B53FCDE26BD70xc10a279
B. Where in the packet does it say which kind SIP message it
is?
G. Can you get information about the user agent and/or
All messages are on the request line of the SIP Application proxy? And is so, what?
Layer.
Request-Line: INVITE Yes, as it could be seen from the network analyzer, it is
sip:mustafa.kpa@iptel.org SIP/2.0 possible to get information about the user agents and the
Request-Line: ACK proxy servers. From the trace, it is possible to get the SIP
sip:mustafa.kpa@iptel.org SIP/2.0 URI, user part, host part and IP addresses of user agents .
C. Can you in the SIP message see if you are the sender or Moreso, the IP address and DNS of the proxy is seen.
receiver? SIP from address: sip:raheem@iptel.org
Yes it is possible because it is contained in the message SIP from address User Part: raheem
header which shows the “from and to”. SIP from address Host Part: iptel.org
Message Header SIP to address: sip:mustafa.kpa@iptel.org
Via: SIP/2.0/UDP SIP to address User Part: Mustafa.kpa
From: "raheem" SIP to address Host Part: iptel.org
<sip:raheem@iptel.org>;tag=9c76c6cd6
Source: 193.10.39.157 (193.10.39.157)
To: sip:mustafa.kpa@iptel.org
Destination: 213.192.59.75 (213.192.59.75)
D. What’s the difference between the URI in the contact-line H. In which packet does it say what codec is going to be
compared to the SIP address in the to/from-line? used?
The contact shows the current IP location of the caller while The Message body of an INVITE with the session description
the to/from shows the proxy server connection of the caller as contains the SDP which clearly shows the codec being used
seen from the capture. during the call session.
Contact: sip:raheem@193.10.39.157 Media Attribute (a): rtpmap:3 GSM/8000
From: "raheem" <sip:raheem@iptel.org>;tag=9c76c6cd6 Media Attribute (a): rtpmap:101
To: sip:mustafa.kpa@iptel.org telephone-event/8000
Media Attribute (a): fmtp:101 0-16
E. What’s the status code for the different messages? Media Attribute (a): setup:active
The status code is contained in the status line of each SIP Media Attribute (a): sendrecv
message generated based on requests and corresponding The above message could easily be seen from the 200 OK
responses. This is illustrated below: with session description
Request-Line: INVITE I. Find the sizes of the ”200-packets”. Why does it vary?
sip:mustafa.kpa@iptel.org SIP/2.0 The sizes varied because the first 200 OK contains the session
Status-Line: SIP/2.0 407 Proxy description protocol which will also add its own headers. The
Authentication Required difference is shown below:
Status-Line: SIP/2.0 100 trying -- your Frame Length: 950 bytes
call is important tous Protocols in frame: eth:ip:udp:sip:sdp
Status-Line: SIP/2.0 180 Ringing Frame Length: 628 bytes
Status-Line: SIP/2.0 200 OK Protocols in frame: eth:ip:udp:sip
Request-Line: ACK
sip:mustafa.kpa@193.10.39.158 SIP/2.0

6. J. Fill in the SIP traffic between the users agents and the
proxy, show the direction as well.
L. Which ports are used by RTP and SIP packets?
RTP
Source ports 49242
Dest Port 49224
SIP 5060
M. How large are the packets?
87 bytes (RTP)
SIP is from 450 to 1120
N. How much of the packet contain voice data?
Payload The payload is 33 bytes.
REFERENCES
Fig. 5 Call Signalling between Two UA and one Server
[1] M. brandl, D.Daskopoulos, and J.Janak, “IP telephony
K. What’s the difference in signalling between starting a call cookbook,” Terena Report March, 2004.
and “un holding” a call? [2] Rosenberg J., Schulzrinne H., et al., “SIP: Session
Several differences were observed during this scenarios, Initiation Protocol”. RFC 3261. (Standards Track). June
some of which are illustrated in the table below. The 2002
major difference when compared together was based on [3] SIP for Instant Messaging and Presence Leveraging
the previous information which the proxy server has Extensions (SIMPLE) IETF Working Group.
obtained during the first call. Those information which www.ietf.org
has been known earlier need not be requested again from [4] Interworking between the Session Initiation Protocol
the user agent during the un hold period of the call. (SIP) and the Extensible Messaging and Presence
Protocol (XMPP) www.xmpp.org
Example of this is information is the proxy server being used [5] “What is ENUM”, www.enum.org
during the call connection. [6] Kevin Wallace, Cisco CVoice 3rd Edition
INVITE starting a call INVITE un-holding a call [7] Overview of SIP, Cisco IOS SIP configuration Guide.
1071 bytes 1119 bytes www.cisco.com.
username@domain Username@IP from the [8] ENUM: e164 Number Translation. www.voipuser.org.
from the Request Request Line [9] SIP Laboratory Manual, Computer Networks Royal
Line sip:mustafa.kpa@193.1 Institute of Technology, Sweden.
sip:mustafa.kpa@ip 0.39.158 SIP/2.0
tel.org
No Route Field Route Field included
Required (i.e iptel proxy
server)
Proxy No Proxy needed
Authentication because the location
required because and DNS had already
it is the first been resolved and
call setup and found in the database
negotiation
No session expires Session Expired field
Field included when call is
terminated.