Session Initiation Protocol

By,

Vivek Nemarugommula
Background
 Overview Of Operation
 Structure Of The Protocol
 Definitions
 SIP Messages
 Dialogs
Overview
 SIP is an application-layer control protocol that can establish,
modify, and terminate multimedia sessions (conferences) such
as Internet telephony calls.
 SIP = ‘Session Initiation Protocol’ Proposed IETF Standard RFC
3261.
 Peer-to-peer application layer protocol where
endpoints (User Agents) initiate, modify and terminate sessions.
 SIP uses existing IETF protocols to provide media
negotiation (SDP), media transport (RTP), name
resolution and mobility (DHCP, DNS), and application encoding
(MIME)
SIP: Basic Idea
 Users are known by SIP URIs.
 Text-based encoding based on a
HTTP-like request/ response
transaction model.
 Simple extensions by introducing
new ‘Methods’ and ‘Headers`
 No relation between (SIP) signaling
path and data stream path.
 Telephony services across the
internet.
Sessions

 Simple: Two-way telephone call

 Collaborative multi-media conference
 Voice enriched e-commerce
 Instant Messaging with buddy list
SIP Entities In The Network
 SIP Functional Entities
User Agent (UA)
1. Intelligent endpoint entity capable of managing its own sessions
2. Paradigm: Intelligence to the edge!
3. Initiates and terminates SIP requests; Always call stateful
4. Is an application, containing both UA client (UAC) and UA server (UAS)
Registrar
1. Register current physical address of user agent
2. Provide location information based on the registrations
3. Essential for reachability
Proxy Server
1. Intermediate SIP node (“SIP router”)
2. Routes SIP requests towards their target
3. Accesses location and routing information to do its job
4. SIP Proxies can be: stateless, transaction stateful or call stateful
5. Additional jobs: e.g. access control, NAT / Firewall control
Redirect Server
1. Find location information and return it to user agent
2. No forwarding of requests, usually “search intensive”
SIP messages
 SIP is a Client-Server protocol similar to HTTP. Most SIP
components can act as client and as server.
 A SIP transaction is composed of a request of a client to
a server and its response.
 Message parts are:

Start Line: conveys message type & protocol version

Headers: to convey message attributes and to modify

message meaning

Body: to describe the session to be initiated or to transport

opaque textual or binary data. Body types: SDP, MIME, others)
SIP Basic Request Methods
SIP Responses
SIP Session Establishment
and Call Termination
Sip Signalling
 To initiate a session, the caller (or User Agent Client) sends a
request with the SIP URL of the called party.
 If the client knows the location of the other party it can send
the request directly to their IP address; if not, the client can
send it to a locally configured SIP network server.
 The server will attempt to resolve the called user's location and
send the request to them.
 There are many ways it can do this, such as searching the DNS
or accessing databases. Alternatively, the server may be a
redirect server that may return the called user location to the
calling client for it to try directly.
Sip Signalling
 During the course of locating a user, one SIP network
server can proxy or redirect the call to additional
servers until it arrives at one that definitely knows the
IP address where the called user can be found.
 Once found, the request is sent to the user and then
several options arise. In the simplest case, the user's
telephony client receives the request, that is, the
user's phone rings. If the user takes the call, the client
responds to the invitation with the designated
capabilities* of the client software and a connection is
established. If the user declines the call, the session
can be redirected to a voice mail server or to another
user
SIP Call Flow with direct
invitation
SIP Call Flow with Proxy
Server
SIP Call Flow with
Redirect Server
Example
Request/Response
Benchmarks-SIPstone
 SIPstone is a benchmark for SIP (Session Initiation Protocol [1])
proxy and redirect Servers (SIPServer). The benchmark
attempts to measure the request handling capacity of a SIP
server or a cluster of SIP servers.
 SIP-based Internet telephony systems need to be appropriately
dimensioned, as the call and registration rate can reach several
thousand requests a second.
 The benchmark currently is limited to evaluating the sustainable
rate of what we believe to be a representative workload,
consisting of registrations, successful forwarding and
unsuccessful call attempts.
SIPstone
 SIPstone describes a workload for SIP requests in proxies using
a set of tests that exercise various components of typical SIP
servers.
 Architecture:
The “server under test” (SUT) is a SIP proxy, redirect or
registrar server whose performance is to be estimated. The
benchmark consists of a set of SIPstone load generators that
create the SIP request load, a call handler that simulates a user
agent server and a central benchmark manager (“coordinator”)
that coordinates the execution of the benchmark, and the SUT.
Description Of Tests
 The benchmark currently consists of five tests. Each test is
performed using both UDP and TCP, with results reported
separately for each transport protocol
The individual tests are:

 Registration: Registrations are sent by the load generator,

using digest authentication. For simplicity, account name and
user secret are typically chosen to be the same. The message
flow is shown in Fig. 1. The transaction delay is measured from
sending the first REGISTER request to receiving the final 200
response, including the 401 “Unauthorized” message.
Registration
Types Of Tests
 Redirect: The load generator sends an
INVITE request to the SUT acting as a
redirect server. The transaction delay
is measured from sending the INVITE

request to receiving the 3xx response.

Types Of Tests
 Proxy 480: The load generator sends an INVITE request to the
SUT acting as a redirect server. The call destinations are known
to the server, but have not registered, so that the server
returns a 480 (Temporarily unavailable) response. The request
is not
authenticated.
 Proxy 200: The load generator alternates between INVITE and
BYE transactions to the SUT acting as a non-forking proxy
server. The BYE transaction is sent immediately after the
INVITE transaction completes.

The TRT is measured only for the INVITE request.

Proxy 200 test
Definition of terms
 Measurement Interval (MI): Themeasurement interval is defined
as the steady state period during the execution of the benchmark from
which the reported performance metric is derived. During the
measurement interval, the UACs generate SIP requests.
 Transaction Response Time (TRT): The transaction response time is
defined as the time elapsed from the first byte sent by a UAC to initiate
a transaction until the last byte received by the UAC that ends the
transaction.
 Registrations per second (RPS): is defined as the average number
of successful registrations per second during the measurement interval.
 Calls per second (CPS): Calls per second is defined as the average
number of calls per second completed with a 2xx or 4xx response during
a measurement interval.
 Transaction failure probability (TFP): The transaction failure
probability is the fraction of transactions that fail, i.e, where the server
does not return a provisional or final response within the time limit
Measurement Methology
 To determine the RPS and CPS values, the request rate is increased
until the TFP increases to 5%, evaluated across a measurement
interval of 15 minutes. The highest sustained throughput is reported as
the benchmark number.
 For more detailed benchmarks, the TRT as a function of the transaction
rate should be plotted, with at least four measurements recommended.
 The average TRT of a measurement interval is computed by averaging
over the successful (timely) responses
Metrics And Parameters
 Description of the clustering configuration, including the
number of hosts and the load balancing mechanism used (e.g.,
DNS SRV or stateless proxy);
 The number of connections requested by the clients and
accepted by the SUT per second. The intent is to count only the
number of new connections made successfully by the clients in
generating the load for the benchmark.
 CPU and memory utilization of server at various loads;
 A curve plotting the TRT as a function of request arrival rates,
with at least four plot points and one value at approximately
10% of the capacity;
 CPS and RPS.
Metrics
 We also define an initial composite benchmark called SIPstone-A that
weighs the ten processing rate metrics as follows:
Summary Of Requirements
 Below, R is the request handling rate.
SIP Security
 Security Framework
 Classic Threat Models
 Solutions
 Security Framework
Authentication is means of identifying another entity. There are many ways to authenticate
another entity, but the typical computer based methods involve user
ID/password or digitally signing a set of bytes using a keyed hash

Confidentiality Cryptographic confidentiality means that only the intended recipients will be
able to determine the contents of the confidential area

Integrity A message integrity check is means of insuring that a message in transit

was not altered

Authorization Once identification of a correspondent is achieved, a decision must be made

as to whether that identity should be granted access for the requested
services. This is the act of authorization. This is often done using access
control lists (ACL).

Privacy They want to make sure others do not know what they are doing or
transmitting. Some people prefer anonymity. In a higher education
environment, faculty and student reserve the right to privacy.

Non-repudiation Reverse protection

Administration Billing and accounting, maintenance of Call Data Records (CDRS)

Audit-trail Do not shred documents – Enron!

 Classic Threat Models
 Registration Hijacking – A registrar assesses the
identity of a UA. The From header of a SIP request
can be arbitrarily modified and hence open to
malicious registration.
 Impersonating a server – A UA contacts a Proxy
server to deliver requests. The server could be
impersonated by an attacker. Mobility in SIP further
complicates this.
 Tampering with message bodies
 More threats
 Tearing down sessions – insert a BYE
 Denial of Service attacks - Denial of service
attacks focus on rendering a particular network
element unavailable, usually by directing an excessive
amount of network traffic at its interfaces. In much
architecture SIP proxy servers face the public Internet
in order to accept requests from worldwide IP
endpoints. SIP creates a number of potential
opportunities for distributed denial of service attacks
that must be recognized and addressed by the
implementers and operators of SIP systems
Solutions For Securing SIP
 HTTP Basic Authentication
 HTTP basic authentication [Fr99] requires the transmission
of a username and a matching password embedded in the
header of a HTTP request.
 Included in a SIP request this user information could be
used by a SIP proxy server or destination user agent to
authenticate a SIP client or the previous SIP hop in a
proxy chain.
 Because the cleartext password can be easily sniffed and
therefore poses a serious security risk, the use of HTTP
basic authentication has been deprecated by SIPv2.
Pretty Good Privacy (PGP)
 Pretty Good Privacy [El96] could be
potentially used to authenticate and
optionally encrypt MIME payloads
contained in SIP messages but version
2 of SIP has deprecated the use of PGP
in favour of S/MIME.
S/MIME
• Existing solution, existing code
• Treat SIP message like email
attachment:
• Content-Type: message/sip ???
• Requires client certs?
• What if ssh-style security is sufficient
(same host as last time, but can’t prevent
MiM for first attempt)
Shared secret
 Avoid SIP-PGP mistakes:
 canonical form
 header ordering
 special headers
IP Security (IPsec)
 IPsec is a general purpose mechanism that can be used to protect the
SIP messages right on the network level. Due to the requirement that
each proxy server on the path must have read/write access to the SIP
header, IPsec ESP (Encapsulating Security Payload) or AH
(Authentication Header) in transport mode [KA98] must be applied on
a hop-by-hop basis

 The Internet Key Exchange (IKE) protocol [HC98] which is used to set
up IPsec security associations supports both Pre-Shared Key (PSK) and
Public Key (PKI) based authentication. Because the IP addresses of the
SIP user agents will be mostly dynamic and taking into account that
IKE Main Mode in that case does not work with pre-shared secrets and
that IKE Aggressive Mode is fraught with security problems (man-in-
the-middle attacks, off-line dictionary attacks on the PSK, etc.), public
key based authentication will be the preferred method.
Conclusions
 Session Initiation Protocol (SIP) has become a strong, catalytic force
shaping today's telecom industry.
 Using SIP, telephony becomes another web application and integrates
easily into other Internet services.
 SIP was designed to specifically reuse as many existing protocols and
protocol design concepts.
 SIP was also designed so that it would be easy to bind SIP functions to
existing protocols and applications, such as e-mail and Web browsers
 SIP is independent of the packet layer and only requires an unreliable
datagram service, as it provides its own reliability mechanism
 SIP security is very important based on its growth.
References
 http://www.ietf.org/rfc/rfc3261.txt
 http://www.sipcenter.com/sip.nsf/html/What+Is+SIP
+Introduction\
 http://www.sipstone.org/files/sipstone_0402.pdf
 http://en.wikipedia.org/wiki/
Session_Initiation_Protocol
 http://www.cs.columbia.edu/sip/
 http://bscwpub-itec.uni-klu.ac.at/pub/bscw.cgi/
d73544/13-Multimedia-SIP.pdf
 http://www.tmf.org/hospitalqi/sip/benchmark/
Benchmark%20Processes%20to%20Improve
%20SIP.pdf