SIP

ALTANAI BISHT
tara181989@gmail.com
http://altanaitelecom.wordpress.com

Original Slides by Alan Johnston and Henry Sinnreich, MCI (at VON’03)
Contents
 SIP Overview
 SIP in detail
 SIP Call Flow Scenarios
 SIP Security
 SIP Programming

2
 SIP Overview

What SIP is, Multimedia Protocol Stack, Short History and

Related Protocols are included.
Why packet switching? Why SIP?

100
90
80
70
60 electromech
50 analog
40 digital
30
20
10
0
1980 1985 1987 1990 1995 2000 2001

Technology evolution of PSTN

4
Session Initiation Protocol Overview
 Application Layer Signaling Protocol
 Used to establish, modify, and terminate
multimedia sessions
 Part of Internet Multimedia Architecture
 Can use UDP, TCP, TLS, SCTP, etc.
 Based on HTTP (Web)
 Similar text-based structure
 Uses URIs (Uniform Resource Indicators)
 Applications include (but not limited to):
 Voice, video, gaming, instant messaging, presence, call
control, etc.

5
Security & Privacy
 SIP Authentication
 Challenge/Response based on shared secret - SIP Digest
 Mechanism also used by HTTP
 Used for client devices
 Encryption using private/public keys
 Used between servers
 Privacy and security
 SIP signaling can be encrypted
 S/MIME (Secure/Multipurpose Internet Mail Extensions)
 Defined in RFC 2633
 SIP can be transported over
 IPSec
 Defined in RFC 2401
 TLS (Transport Layer Security)
 Defined in RFC 2246

6
Internet Multimedia Protocols

RTSP

7
 SIP Requests and Responses
SIP Responses use a
SIP Request types are
numerical code and a
called “methods” “reason phrase”

INVITE 1xx Informational

ACK 2xx Final
OPTIONS 3xx Redirection
CANCEL 4xx Client Error
BYE 5xx Server Error
REGISTER 6xx Global Failure

8
Related Protocols: SDP
 SIP carries (encapsulates) SDP messages
 SDP specifies codecs and media termination points
 Only one of many possible MIME attachments carried by
SIP
 SDP – Session Description Protocol
 Used to describe media session.
 Carried as a message body in SIP messages.
 Is a text-based protocol
 Uses RTP/AVP Profiles for common media types
 Defined by RFC 2327
 E.g. RFC 3551 “RTP Profile for Audio and Video Conferences with
Minimal Control”

9
Related Protocol: RTP
 RTP – Real-time Transport Protocol
 Used to transport media packets over IP
 RTP adds a bit-oriented header containing:
 name of media source
 timestamp
 codec type
 sequence number
 Defined by H. Schulzrinne et al, RFC 1889.
 Profiles defined by RFC 1890.
 RTCP for exchange of participant and quality reports.

10
 SIP Uniform Resource Indicators (URIs)
 Same form as email addresses: user@domain
 Two URI schemes:
 sip:henry@siptest.mci.com is a SIP URI
Most common form introduced in RFC 2543
 sips:henry@siptest.mci.com is a Secure SIP URI
New scheme introduced in RFC 3261
Requires TLS over TCP as transport for security

 Two types of SIP URIs:

 Address of Record (AOR) (identifies a user)
sip:henry@mci.com (Needs DNS SRV records to locate SIP Servers
for mci.com domain)
 Contact (identifies a device and is usually a Fully Qualified Domain
Name, FQDN)
 sip:henry@127.24.45.4 or sip:henry@cube43.lab.mci.com

11
(Which needs no resolution for routing)
SIP “Trapezoid”
DNS Server Location
Server

DNS

SIP
Outbound Inbound
Proxy Server Proxy Server

SIP
SIP

SIP

Media (RTP)

User Agent A User Agent B

12
SIP Elements – User Agents
DNS Server Location
Capable of sending
Server and receiving SIP
requests.
DNS  UAC – User Agent Client
 UAS – User Agent Server
End Devices
SIP
Outbound Inbound  SIP phone
Proxy Server Proxy Server
 PC/laptop with
SIP Client
SIP
 PDA
SIP
 mobile phone
SIP PSTN Gateways
Media (RTP) are a type of User
Agent
User Agent A
User Agent B

13
SIP Elements – Proxy Servers
DNS Server Location
Server Forward or “proxy”
requests on behalf of
DNS User Agents
Consult databases:
SIP  DNS
Outbound Inbound
Proxy Server Proxy Server  Location Server
Types:
SIP  Stateless
 Transaction Stateful
SIP

 Call Stateful
SIP
No media capabilities
Media (RTP)
 Ignore SDP.
User Agent A User Agent B Normally bypassed once
dialog established, but
can Record-Route to
14 stay in path.
SIP Elements – Other Servers
DNS Server Location
Server
Location Server

DNS
Database of locations of
SIP User Agents
SIP Queried by Proxies in
Outbound Inbound
Proxy Server Proxy Server routing
Updated by User Agents
SIP by Registration
SIP

SIP DNS Server

Media (RTP)

User Agent A User Agent B SRV (Service) Records

used to locate
Inbound Proxy
15
Servers
SIP Client and Server

 SIP Elements are either

 User Agents (end devices that initiate and terminate media
sessions)
 Servers (that assist in session setup)
 Proxies
 Registrars
 Redirect servers
 A User Agent acts as a
 Client when it initiates a request (UAC)
 Server when it responds to a request (UAS)

16
SIP Registrar, 1

 SIP server that can receive and process REGISTER requests

 A user has an account created which allows them to REGISTER contacts
with a particular server
 The account specifies a SIP “Address of Record (AOR)”

17
SIP Registrar, 2
 SIP Registrars store the location of SIP endpoints
 Each SIP endpoint Registers
 with a Registrar using it’s Address of Record and Contact address
 Address of Record for John Smith in From: header
From: John Smith <sip:jsmith@zultys.com
 Contact: header tells Registrar where to send messages
Contact: John Smith <sip:jsmith@192.168.1.100>
 SIP Proxies
 query SIP Registrars for routing information
 Incoming calls addressed to sip:jsmith@zultys.com
 now routed by the Proxy to the Contact: header URL
sip:jsmith@192.168.1.100

18
Proxy Server
 SIP Proxy servers route SIP messages
 Stateless Proxies use stateless protocols like UDP to talk
to endpoints
 Low Proxy overhead
 Ephemeral connections, dropped as soon as message is forwarded
 Stateful Proxies use TCP or other stateful protocols to set
up a permanent connection
 High Proxy overhead
 Endpoint connection must be set up, maintained and torn down for
the duration of the session

19
SIP Proxy Server
 SIP Server which acts on behalf of User Agents
 Receives a SIP request
 Adds some headers
 Modifies some of the headers
 Forwards request to next hop server or client

20
Stateless vs. Stateful Proxy
 Stateless Proxy
 Forwards every request downstream and response upstream
 Keeps no state (does not have any notion of a transaction)
 Never performs message retransmissions
 Stateless proxies scale very well
 can be very fast
 good for network cores
 Stateful Proxy
 Maintains state information for the duration of either the:
 Transaction (request)
 Transaction Stateful
 Dialogue (from INVITE to BYE)
 Dialogue Stateful
 Performs message retransmission

21
SIP Redirect Server

 Receives a request and returns a redirection response (3xx)

 Contact header in response indicates where request should
be retried
 Similar to database query
 All Server types are logical NOT Physical

22
Locating SIP Servers
 Manual provisioning
 DHCP SIP Option 120
 RFC 3361
 Multicast (deprecated)
 DNS SRV method
 Get local domain name automatically from DHCP server
 Perform SRV record query through DNS on that domain for
_sip._udp.<domain name>
 Send SIP REGISTER message to resolved server
 phone is up and running without user intervention

23
 SIP in detail

Now, we are going to study SIP in detail including SIP Request,

SIP Response and SIP Header
SIP Request Methods, 1

 SIP used for Peer-to-Peer Communication though it

uses a Client-Server model
 Requests are called “methods”
 Six methods are defined in base RFC 3261:
 INVITE
 ACK
 OPTIONS
 BYE
 CANCEL
 REGISTER

25
SIP Request Methods, 2
 REGISTER
 Register contact with Registrar
 INVITE/ACK/BYE/CANCEL/UPDATE
 Creates, negotiates and tears down a call (dialogue)
 MESSAGE
 Creates an Instant Messaging session
 SUBSCRIBE
 Subscribe to a service (like message waiting indication)
 NOTIFY
 Notify a change in service state (new Voicemail)

26
SIP Methods - INVITE, 1

 INVITE requests the establishment of a session

 Carried in Message Body (SDP)
 Type of session
 IP Address
 Port
 Codec

27
SIP Methods - INVITE, 2

 An INVITE during an existing session (dialogue) is

called a re-INVITE
 re-INVITEs can be used to
 Place calls on or remove calls from hold
 Change session parameters and codecs
 The SIP UPDATE method is the proposed
replacement for this technique

28
SIP Methods - ACK

 ACK completes the three way session setup

handshake (INVITE, final response, ACK)
 Only used for INVITE
 If INVITE did not contain media information
 ACK must contain the media information

29
SIP Methods - OPTIONS

 OPTIONS requests the capabilities of another

User Agent
 Response lists supported methods, extensions,
codecs, etc.
 User Agent responds to OPTIONS the same as if
an INVITE (e.g. if Busy, returns 486 Busy Here)
 Very basic presence information

30
SIP Methods – BYE and CANCEL

 BYE terminates an established session

 User Agents stop sending media packets (RTP)
 CANCEL terminates a pending session.
 INVITE sent but no final response (non-1xx) yet
received.
 User Agents and Proxies stop processing INVITE
 Can be sent by a proxy or User Agent
 Useful for “forking proxy”
 Parallel search using multiple registration Contacts.
 First successful wins, rest are cancelled.

31
SIP Methods - REGISTER

 Registration allows a User Agent to upload

current location and URLs to a Registrar
 Registrar can upload into Location Service
 Incoming requests can then be proxied or
redirected to that location
 Built in SIP support of mobility
 UAs do not need static IP addresses
 Obtain IP address via DHCP, REGISTER indicating new IP
Address as contact

32
SIP Request URI
 The Request-URI indicates the destination address of the
request
 Proxies and other servers route requests based on Request-
URI.
 The Request-URI is modified by proxies as the address is
resolved. Request-URI

INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

(Alice's SDP not shown)

33
SIP From and To Tags

 Tags are pseudo-random numbers inserted in To

or From headers to uniquely identify a call leg
 INVITE request From header contains a tag
 Any User Agent or Server generating a response
adds a tag to the To header in the response
 To: sip:john@company.com;tag=123456

34
SIP Method - INFO

 Used to transport mid-call signaling information

 Only one pending INFO at a time
 Typical use - PSTN signaling message carried as
MIME attachment
 E.g. ISDN User-to-User information
 Defined in RFC 2976

35
SIP Method - REFER

 Indicates that recipient (identified by the Request-

URI) should contact a third party using the contact
information provided in the request
 Typical Use: Call Transfer features
 Allowed outside an established dialogue

36
SIP Method - PRACK

 Provisional Response ACKnowlegement

 Used to acknowledge receipt of provisional
response
 183 Session Progress
 Does not apply to 100 Trying responses
 Only provisional responses 101-199 may be sent reliably
and acknowledged with PRACK
 If no PRACK sent, response retransmitted
 Defined in RFC 3262

37
SIP Methods – SUBSCRIBE and NOTIFY

 SUBSCRIBE requests notification of when a

particular event occurs
 Use Expires=0 to unsubscribe
 A NOTIFY message is sent to indicate the event
status
 Sample Applications
 Presence
 Message waiting indication for voicemail
 Defined in RFC 3265

38
SIP Method - MESSAGE

 Extension to SIP for Instant Messaging (IM)

 MESSAGE requests
 carry the content in the form of MIME body parts
 use the standard MIME headers to identify the content

39
SIP Responses

 SIP Requests generate Responses with codes

borrowed from HTTP
 Classes:
 1xx Informational
 2xx Final
 3xx Redirection
 4xx Client Error
 5xx Server Error
 6xx Global Failure
 Response example “404 Not Found”

40
 SIP Responses: 1xx-3xx
SIP Response Code
100 Trying
180 Ringing
181 Call Is Being Forwarded
182 Queued
183 Session Progress
200 OK
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service
Brief Description
Request received and action is being taken
UA received INVITE and is alerting user
Used by proxy to indicate call is being forwarded
Called party unavailable, call queued
Used in early media and QoS setup
Request successful
Address resolved to several choices
User can no longer be found at Req-URI address
Temporarily cannot find user at Req-URI address
Resource MUST be accessed through proxy.
Call not successful. Alternatives possible.
41
SIP Responses: 4xx
SIP Response Code
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
410 Gone
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Unsupported URI Scheme
420 Bad Extension
421 Extension Required
423 Registration Too Brief
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
482 Loop Detected
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
491 Request Pending
493 Undecipherable
Brief Description
Request not understood due to malformed syntax
Request requires user authentication
Reserved for future use
UAS understood request and refuses to fulfill it
UAS finds that user doesn't exist in the domain
Method is understood but not allowed
Response content not allowed by Accept header
Client must first authenticate itself with proxy
UAS could not produce response in time
UAS resource unavailable; no forwarding addr.
Request contains body longer than UAS accepts
Req-URI longer than server is willing to interpret
Format of the body not supported by UAS
Scheme of URI unknown to server
UAS not understand protocol extension
UAS needs particular extension process request
Contact header field expiration time too small
UAS contacted successfully but user unavailable
UAS Rx request not matching any existing dialog
UAS has detected a loop
UAS received request containing Max-Forwards=0
UAS Rx request with incomplete Request-URI
The Request-URI was ambiguous
UAS contacted successfully but user busy
Request terminated by a BYE or CANCEL request
Same as 606 but only applies to addressed entity
UAS Rx req. & have pending req. for same dialog
UAS Rx request with encrypted MIME body & not have decryption key
42
 SIP Responses: 5xx-6xx
SIP Reponse Code
500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable
Brief Description
UAS unexpected condition & cannot fulfill request
UAS not support functionality to fulfill the request
UAS Rx invalid response from a downstream server
UAS can't process due to overload or maintenance
UAS not Rx response from external server
UAS not support SIP version in request
Message length exceeded UAS capabilities
End systems contacted, user busy at all of them
End systems contacted, user explicitly decline
UAS has information Req-URI user not exist
Some aspects of Session Desc. not acceptable
43
SIP Message Details
INVITE sip:wh@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159

First line of a SIP message is Start Line which contains:

 the method or Request type: INVITE (session setup request).
 the Request-URI which indicates who the request is for
sip:wh@200.201.202.203
 Note: Request-URI can be either an AOR or Contact (FQDN)
 This Request-URI is a FQDN, but the initial Request-URI was an AOR
(same as To URI)
 the SIP version number SIP/2.0
44
SIP Headers

 SIP Requests and Responses contain Headers (similar to

Email headers)
 Required Headers
 To
 From
 Via
 Call-ID
 CSeq
 Max-Forwards
 Optional Headers:
 Subject, Date, Authentication (and many others)

45
SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159

Via headers show the path the request has taken

 The bottom Via header is inserted by the User Agent which initiated
the request
 Additional Via headers are inserted by each proxy in the path
The Via headers are used to route responses back the same way
Required branch parameter contains a “cookie” (z9hG4bK) then a
transaction-ID.
46
SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159

Max-Forwards is a count decremented by each proxy

that forwards the request.
When count goes to zero, request is discarded and 483
Too Many Hops response is sent.
Used for stateless loop detection.

47
SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159

Dialog (formerly called call leg) information is in headers:

 To tag, From tag, and Call-ID (Note: Not URIs)
To and From URIs usually contain AOR URIs.
All requests and responses in this call will use this same Dialog
information.
Call-ID is unique identifier usually composed of
 pseudo-random string “@” hostname or IP Address
48
SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159

CSeq Command Sequence Number

 Initialized at start of call (1 in this example)
 Incremented for each subsequent request
 Used to distinguish a retransmission from a new request
Also contains the request type (method) - INVITE

49
SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159

Contact header contains a SIP FQDN URI for direct

communication between User Agents
 If Proxies do not Record-Route, they can be bypassed
 If Record-Route is present in 200 OK, then a Route
header is present in all future requests in this dialog.
Contact header is also present in 200 OK response

50
SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159

Content-Type indicates the type of message body

attachment (others could be text/plain,
application/cpl+xml, etc.)
Content-Length indicates the octet (byte) count of
the message body.
Message body is separated from SIP header fields by a
blank line (CRLF).
51
SDP Message Body Details
v=0
o=Tesla 289084526 28904529 IN IP4 lab.high-voltage.org
s=-
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

 Version number (ignored by SIP)

 Origin (only version used by SIP - 28904529)
 Subject (ignored by SIP)
 Connection Data (IP Address for media - 100.101.102.103)
 Time (ignored by SIP)
 Media (type - audio, port - 49170, RTP/AVP Profile - 0)
 Attribute (profile - 0, codec - PCMU, sampling rate – 8000 Hz)

52
SIP Response Details
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
To: Heisenberg <sip:w.heisenberg@munich.de>;tag=24019385
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:wh@200.201.202.203
Content-Type: application/sdp
Content-Length: 173

v=0
o=Heisenberg 2452772446 2452772446 IN IP4 200.201.202.203
s=SIP Call
c=IN IP4 200.201.202.203
t=0 0
m=audio 56321 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Via, To, From, Call-ID, & CSeq are all copied from request.
 To now has a tag inserted by UAS
Contact and Message Body contain UAS information.
53
SIP Call Flow Scenarios

As followings …
 SIP Call Flow Scenarios
 Call Attempt - Unsuccessful
 Presence Subscription
 Registration
 Presence Notification
 Instant Message Exchange
 Call Setup – Successful
 Call Hold
 Call Transfer

Call Flows and full message details:

 “SIP Basic Call Flow Examples” I-D by A. Johnston et al.
 “SIP Service Examples” I-D by A. Johnston et al.

55
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

1. A “dials” SIP AOR

URI sip:B@mci.com.
Outbound Inbound User Agent A sends
Proxy Server
Proxy Server INVITE to outbound
Proxy Server.
1. INVITE
Contact: A
SDP A
2. 100 Trying 2. Outbound Proxy
sends 100 Trying
response.

User Agent A User Agent B

(Not Signed In)

56
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: 4. Response: 1.2.3.4

3. Outbound Proxy does
mci.com?

DNS query to find

Outbound Inbound proxy server for
Proxy Server Proxy Server
mci.com domain

1. INVITE
4. DNS responds with
Contact: A 2. 100 Trying IP address of
SDP A
mci.com Proxy
Server

User Agent A User Agent B

(Not Signed In)

57
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: mci.com? 4. Response:

1.2.3.4
5. Outbound Proxy
5. INVITE sends INVITE to
Outbound
Contact: A
SDP A Inbound Inbound Proxy
Proxy Server Proxy Server
Server.
6. 100 Trying
6. Inbound Proxy sends
1. INVITE
Contact: A 2. 100 Trying 100 Trying
SDP A
response.

User Agent A User Agent B

(Not Signed In)

58
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: mci.com? 4. Response:

1.2.3.4 7. LS Query: B? 8. Response: Not
Signed In
7. Inbound Proxy
5. INVITE
Contact: A consults Location
SDP A Inbound
Outbound
Proxy Server Proxy Server Server.
6. 100 Trying 8. Location Server
1. INVITE
Contact: A
responds with “Not
2. 100 Trying
SDP A Signed In.”

User Agent A User Agent B

(Not Signed In)

59
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: 4. Response: 7. LS Query: B? 8. Response:

mci.com? 1.2.3.4 Not Signed
In 9. Inbound Proxy sends
5. INVITE
Contact: A
480 Temporarily
Outbound
SDP A Inbound Unavailable
Proxy Server
Proxy Server 6. 100 Trying response.
1. INVITE
Contact: A
9. 480 Temporarily Unavailable 10. Outbound Proxy sends
SDP A 10. ACK ACK response.
2. 100 Trying

User Agent A User Agent B

(Not Signed In)

60
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: 4. Response: 7. LS Query: B? 8. Response:

mci.com? 1.2.3.4 Not Signed
In
5. INVITE
Contact: A 11. Outbound Proxy
Outbound
SDP A Inbound forwards 480 response
Proxy Server
Proxy Server 6. 100 Trying to A.
1. INVITE 9. 480 Temporarily Unavailable 12. A sends ACK response.
Contact: A
SDP A 10. ACK
2. 100 Trying
11. 480 Temporarily Unavailable
12. ACK

User Agent A User Agent B

(Not Signed In)

61
 SIP Presence Example
DNS Server
Presence
Server

3. SUBSCRIBE
1. A wants to be informed
when B signs on, so
Outbound
2. SUBSCRIBE Inbound sends a SUBSCRIBE
Proxy Server Proxy Server
2. Outbound Proxy
forwards to Inbound
1. SUBSCRIBE
Proxy
3. Inbound Proxy forwards
to B’s Presence Server

User Agent A User Agent B

(Not Signed In)

62
 SIP Presence Example
DNS Server
Presence
Server

3. SUBSCRIBE 4. 200 OK

4. Presence Server
Outbound
2. SUBSCRIBE Inbound authorizes subscription
Proxy Server
Proxy Server 5. 200 OK by sending a 200 OK.
5. & 6. 200 OK proxied
1. SUBSCRIBE 6. 200 OK
back to A.

User Agent A User Agent B

(Not Signed In)

63
 SIP Presence Example
DNS Server
Presence
Server

7. NOTIFY 12. 200 OK

<Not Signed In>
7. Presence Server sends
8. NOTIFY NOTIFY containing
<Not Signed In>
Outbound Inbound current presence status
Proxy Server Proxy Server
11. 200 OK of B (Not Signed In).
8. and 9. NOTIFY is
9. NOTIFY
<Not
10. 200 OK
proxied back to A.
Signed
In> 10. A acknowledges receipt
of notification with
200 OK.
11. & 12. 200 OK is
User Agent A User Agent B
proxied back to B’s
(Not Signed In) Presence Server.

64
SIP Registration Example
DNS Server
Location
Server

2. Update database:
B = B@2.3.4.5
1. B signs on to his SIP
Phone which sends a
Outbound Outbound REGISTER message
Proxy Server
Proxy Server containing the FQDN
URI of B’s User Agent.
2. Database update is sent
1. REGISTER
Contact: B@2.3.4.5 to the Location Server

User Agent A User Agent B

65
SIP Registration Example
DNS Server
Location
Server

2. Update database:
B = B@2.3.4.5 3. OK
3. Location Server
database update is
confirmed.
Outbound Outbound
Proxy Server Proxy Server 4. Registration is confirmed
with a 200 OK
response.
1. REGISTER 4. 200 OK
Contact: B@2.3.4.5 Contact: B@2.3.4.5

User Agent A User Agent B

66
 SIP Presence Example
DNS Server
Presence
Server

13. Presence Server learns

13. NOTIFY
<Signed In> 18. 200 OK of B’s new status from
the Location Server and
14. NOTIFY sends a NOTIFY
Outbound
<Signed In> Inbound containing new status
Proxy Server
Proxy Server 17. 200 OK of B (Signed In).
14. & 15. NOTIFY is
15. NOTIFY
<Signed In> 16. 200 OK proxied back to A.
16. A acknowledges receipt
of notification with 200
OK.
17. & 18. 200 OK is
User Agent A User Agent B
proxied back to
Presence Server.

67
 SIP Instant Message Scenario
DNS Server
1. A sends an Instant
Location
Server Message to B saying
“Can you talk now?”
3. LS Query: B? 4. Response: in a MESSAGE
sip:B@2.3.4.5
request.
2. MESSAGE
<Can you
2., 3. & 4. MESSAGE
Outbound
talk now?> Inbound request is proxied,
Proxy Server
Proxy Server Location Server
7. 200 OK
queried.
1. MESSAGE
<Can you 5. MESSAGE 5. Inbound Proxy
talk now?> 8. 200 OK <Can you 6. 200 OK forwards MESSAGE to
talk now?>
B.
6. User Agent B responds
with 200 OK.
7. & 8. 200 OK is proxied
User Agent A User Agent B
back to A.

68
 SIP Instant Message Scenario
Location
1. B sends an Instant
DNS Server
Server Message to A saying
“Sure.” in a
5. LS Query: A? 6. Response: 2. DNS Query:
sip:A@4.5.3.2 globalipcom.com?
3. Response: 5.6.7.8 MESSAGE sent to A’s
AOR URI.
4. MESSAGE
2. & 3. DNS Server is
Inbound
<Sure.> Outbound queried.
Proxy Server Proxy Server
4. Outbound Proxy
9. 200 OK
forwards MESSAGE to
7. MESSAGE
<Sure.> 8. 200 OK Inbound Server.
1. MESSAGE
<Sure.>
10. 200 OK 5. & 6. Location Server is
queried.
7. Inbound Proxy
forwards to A.
User Agent A User Agent B
8. User Agent A responds
with 200 OK.
9. & 10. 200 OK is proxied
back to B.
69
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

1. to 5. A retries
5. LS Query: B 6. Response:
sip:B@2.3.4.5
INVITE to B which
routes through two
3. INVITE
Contact: A Proxy Servers.
SDP A Inbound
Outbound
Proxy Server 6. Location Server
Proxy Server
4. 100 Trying
responds with the
1. INVITE
FQDN SIP URI of B’s
Contact: A 2. 100 Trying 7. INVITE SIP Phone.
SDP A
Contact: A
SDP A 7. Inbound Proxy Server
forwards INVITE to
B’s SIP Phone.

User Agent A User Agent B

70
 SIP Call Setup Scenario
DNS Server Location
Server

8. User Agent B alerts B

9. 180 Ringing
and sends 180
Inbound
Outbound
Proxy Server Ringing response.
Proxy Server
9. & 10. 180 Ringing
is proxied back to A.
10. 180 Ringing
8. 180 Ringing

User Agent A User Agent B

71
 SIP Call Setup Scenario
DNS Server Location
Server

11. B accepts call and

9. 180 Ringing
Inbound User Agent B sends
Outbound
Proxy Server Proxy Server 200 OK response.
12. 200 OK
Contact: B 12. & 13. 200 OK is
SDP B
10. 180 Ringing 13. 200 OK 11. 200 OK proxied back to A.
Contact: B 8. 180 Ringing Contact: B
SDP B SDP B

User Agent A User Agent B

72
 SIP Call Setup Scenario
DNS Server Location
Server

14. ACK is sent by A to

9. 180 Ringing confirm setup call
Outbound Inbound
Proxy Server Proxy Server bypassing proxies.
12. 200 OK
Contact: B
SDP B
10. 180 Ringing 13. 200 OK 11. 200 OK
Media session begins
Contact: B
SDP B
8. 180 Ringing Contact: B
SDP B
between A and B!
14. ACK

Media (RTP)

User Agent A User Agent B

73
SIP Call Hold (re-INVITE)
DNS Server Location
Server
15. B places A on hold
by sending a re-
INVITE.
16. A accepts with a
Outbound Inbound 200 OK.
Proxy Server
Proxy Server
17. B sends ACK to A.

No media between A
15. INVITE
SDP a=sendonly and B.
16. 200 OK
SDP A

17. ACK
User Agent A User Agent B

74
SIP Call Transfer Scenario
DNS Server Location
Server

18. B transfers A to C
Outbound Inbound
Proxy Server
using REFER.
Proxy Server
19. Transfer is accepted
by A with 202
Accepted response.
20. Notification of
18 REFER Refer-To: sip:C@mci.com
trying transfer is
19. 202 Accepted
sent to B in NOTIFY.
20. NOTIFY <100 Trying>
User Agent A
21. B sends 200 OK
21. 200 OK User Agent B
response to NOTIFY

75
 SIP Call Transfer Scenario
DNS Server Location
Server

1. to 5. A sends new
5. LS Query: C? 6. Response: INVITE to C which
sip:C@6.7.8.9
3. INVITE routes through two
Contact: A
Ref-By: B Proxy Servers.
SDP A Inbound
Outbound
Proxy Server Proxy Server 6. Location Server
4. 100 Trying responds with the
1. INVITE
7. INVITE FQDN SIP URI of C’s
Contact: A
Contact: A 2. 100 Trying Ref-By: B SIP Phone.
Ref-By: B SDP A
SDP A 7. Inbound Proxy Server
User Agent C forwards INVITE to
C’s SIP Phone.

User Agent A User Agent B

76
 SIP Call Transfer Scenario
DNS Server Location
Server
8. User Agent C alerts C
and sends 180
Ringing response.
9. & 10. 180 Ringing
9. 180 Ringing
Inbound
is proxied back to A.
Outbound
Proxy Server Proxy Server
11. C accepts call and
12. 200 OK
Contact: C 11. 200 OK sends 200 OK
SDP C Contact: C
10. 180 Ringing
13. 200 OK SDP C response.
Contact: C 8. 180 Ringing
SDP C 12. & 13. 200 OK is
14. ACK
proxied back to A.
User Agent C
Media (RTP) 14. ACK is sent by A to
confirm setup call.
User Agent A
User Agent B
Media session between
A and C begins.
77
SIP Call Transfer Scenario
DNS Server Location
Server

20. Notification of
successful transfer is
sent to B in NOTIFY.
Outbound Inbound 21. B sends 200 OK
Proxy Server
Proxy Server
response to NOTIFY
22. B hangs up by
sending a BYE.
23. 200 OK response to
20. NOTIFY <200 OK> BYE is sent.
21. 200 OK
22. BYE
User Agent A User Agent B
23. 200 OK

78
SIP Security
Authorization
 SIP uses standard HTTP Digest Authentication with minor revisions
 Simple Challenge/Response scheme
REGISTER ->
<- 407 Challenge + nonce
REGISTER + MD-5 hash (pw + nonce) ->
<- 200 OK
 Password is never sent in the clear, just the MD-5 hash generated with
the password and nonce
 Defeats Man-in-the-middle attacks since source address can’t be spoofed
or second REGISTER will never arrive
 Required by many Internet Telephony Service Providers
(ITSPs)
 Service Provider supplies Username and password
 SIP leverages Digest Authentication features to do this

80
TLS and sips:
 Implementation of TLS is mandatory for proxies, redirect servers and
registrars
 The ;transport=tls URI parameter value is deprecated
 A sips: URI scheme (otherwise identical to the sip: scheme) indicates
that all hops between the requestor and the resource identified by the
URI must be encrypted with TLS.
 If the request is retargeted once the resource is reached, it must use
secured transports.

81
S/MIME
 Provides end-to-end security of message body and/or headers.
 Certificate identified by end user address
 Public key can be transported in SIP
 Entire message can be protected by “tunneling” the message in an
S/MIME body

Header Fields

Header Fields

Body

Signature

82
Attacks
 IPhreakers
 IP knowledge
 Known weaknesses
 Evolution 2600Hz -> voicemail/int’l GWs -> IP telephony
 Internal or external threat ?
 Targets: home user, enterprise, government, etc ?

 Protocol implementations
 PROTOS

 The human element

83
Attacks : denial of service
 Denial of service
 Network
 Protocol (SIP INVITE)
 Systems / Applications
 Phone

 Availability (BC/DR)
 Requires: power
 Alternatives (Business Continuity/Disaster Recovery) ?
 E911 (laws and technical aspect)
 GSM
 PSTN-to-GSM

84
Attacks : fraud
 Call-ID spoofing

 User rights takeover

 Fake authentication server

 Effects
 Access to voicemail
 Value added numbers
 Social engineering
 Replay

85
Attacks: interception
 Interception
 “Who talks with who” (Network sniffing, Servers (SIP, CDR, etc)
 LAN
 Physical access to the LAN
 ARP attacks
 Unauthenticated devices (phones and servers)
 Different layers (MAC address, user, physical port, etc)
 Where to intercept ?
 Where is the user located ?
 Networks crossed ?
 Lawful Intercept
 CALEA
 ETSI standard
 Architecture and risks

86
Attacks : systems
 Systems
 Mostly none is hardened by default
 Worms, exploits, Trojan horses

Attacks : phone
(S)IP phone
 Startup
 DHCP, TFTP, etc.
 Physical access
 Hidden configuration tabs
 TCP/IP stacks
 Firmware/configuration
 Trojan horse/rootkit
87
Defense
 Signaling: SIP
 Secure SIP vs SS7 (physical security)
 Transport: Secure RTP (with MiKEY)
 Network: QoS [LLQ] (and rate-limit)
 Firewall: application level filtering
 Phone: signed firmware
 Identification: TLS
 Clients by the server
 Servers by the client
 3P: project, security processes and policies

88
SIP Programming
SIP based Application Interfaces
 These include :
 JAIN SIP
 Low level and very complex API
 CNRSIP API is one of available reference implementations.
 SIP Servlets
 proposed within JAIN
 SIP API for J2ME
 intermediate level API (minimal SIP knowledge required)
 SIP CGI
 CPL ( Call Processing Language)
 XML based

90
HTTP Servlets
 HTTP Java Servlets Widely Used in Web
HTTP Servlets
Application Development War File

 Applications Consist of Sets of HTTP Servlets,

Each of Which Processes a Single Web Request in
the Application

 HTTP Servlets Return Web Pages to Display

Developer
 HTTP Servlets Can Create “Session Data”
 e.g., shopping cart, that spans multiple requests Deployer

 “Container” Manages HTTP Servlet Lifecycles,

Fault Tolerance, Session State

 HTTP Servlets Collected into a War File – Web

Web Server
Archive

91
SIP Servlet API
 Java extension API for SIP servers
 Similar in spirit to HTTP servlet API
 Server matches incoming messages against local rules in order to decide
which servlet to pass message to
 The API gives full control to servlets to handle SIP messages, e.g.
 has full access to headers and body
 proxy or redirect requests
 respond to or reject requests
 forward responses upstream
 initiate requests
 Servers may choose to provide constrained environment to selected
servlets (e.g. using sandbox security model)

92
Basic SIP Servlet Model
servlet servlet

Servlet Engine
requests requests
SIP Server
responses responses

Location of SIP Server and servlet

engine:
 in same Java Virtual Machine
 different process, same host
 different hosts: 1:1, 1:n, n:1, n:m
93
Example: Routing Services

RTP

servlet
UAC UAS

Server
SIP SIP

 Servlet proxies request to one or more destinations

 - forwards response to caller

94
Example: Servlet as UAS

RTP
servlet
UAC
Server
SIP

Servlets can reject (screen) calls

Can accept and set up media streams

95
Benefits of Servlet Model
 Powerful:
 Full access to SIP signaling
 Performance:
 No need to fork new process for each request
 The same servlet can handle many requests simultaneously
 Safety: type checked; no pointers; exception handling
 Convenience:
 high level abstractions.
 Tight integration with server: logging, security, location database
 Lifecycle model allows servlets to
 maintain state, e.g. database connections
 manage timers
 Access to wide range of APIs

96
 An Example: RejectServlet
import org.ietf.sip.*;

public class RejectServlet extends SipServletAdapter {

protected int statusCode, reasonPhrase;

public void init(ServletConfig config) {

super.init(config);
try {
statusCode = Integer.parseInt(getInitParameter("status-code"));
reasonPhrase = getInitParameter("reason-phrase");
} catch (Exception _) {
statusCode = SC_INTERNAL_SERVER_ERROR;
}
}
public boolean doInvite(SipRequest req) {
SipResponse res = req.createResponse();
res.setStatus(statusCode, reasonPhrase);
res.send();
return true;
}
}

97
Relationship to JAIN SIP
 JAIN SIP is a generic, low-level
interface for accessing SIP services

Servlet
Servlet
 Can be used in
 Clients
 Servers SIP Servlet API
 Gateways
 Focuses purely on the protocol SIP Servlet
 Complete access to SIP capabilities Container
JAIN SIP
 Supports transactions only
 SIP Servlet Container is a particular
application of JAIN SIP SIP Protocol

98
Relationship to JAIN SIP
 Servlets focus on high volume carrier
grade servers
 Add significant, non-SIP protocol
functions
 Lifecycle management
 Domain objects
 Context and configuration
 Deployment descriptors
 Archive files
 Synchronization primitives
 Security
 Add significant SIP protocol functions
 Construction of requests and
responses from domain objects
99
 Hide many parts of JAIN SIP
 Direct access to many headers is not
provided
 Write access to most everything is
often restricted
 Servlets should be defined to allow a
SIP container to be built using JAIN
SIP
 SIP Objects in Servlet API defined with
interfaces that match JAIN SIP
signatures
 Cannot directly expose JAIN SIP
objects, though
SIP CGI
 Almost identical to HTTP CGI
 Language independent ( Perl, Tcl, C, C++, ... )
 Any binary may be executed as a separate program

 Suitable for services that contains substantial web content

 Passes message parameters through environmental variables to a

separate program.
 More flexible but more risky

 Feb. 1, 2001: RFC 3050 (Common Gateway Interface for SIP) published

100
Call Processing Language (CPL)
 Designed by the IETF to support sophisticated telephony services
 May be used by both SIP or H.323.
 XML based scripting language for describing controlling call services
 Simple Syntax
 Extendible
 Easily edited by GUI tools
 Scripts runs on network SIP signaling server to create end user
services
 Lightweight CPL interpreter is need to parser & validate scripts

101
CPL Example
 A simple script that blocks anonymous callers

<?xml version="1.0" ?>

<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN"
"cpl.dtd">
<cpl>
<incoming>
<address-switch field="origin" subfield="user">
<address is="anonymous">
<reject status="reject"
reason="I don't accept anonymous calls" />
</address>
</address-switch>
</incoming>
</cpl>

102