The presentation is a compiled assembly from the SIP RFC' s, and original works of Alan Johnston and Henry Sinnreich . It contains Sip Detailed , Call flows , Architecture descriptions , SIP services , sip security , sip programming.

1. SIPSIP
Original Slides by Alan Johnston and Henry Sinnreich, MCI (at VON’03)
ALTANAI BISHT
tara181989@gmail.com
http://altanaitelecom.wordpress.com

2. Contents
2
 SIP OverviewSIP Overview
 SIP in detailSIP in detail
 SIP Call Flow Scenarios
 SIP Security
 SIP Programming

3. SIP Overview
What SIP is, Multimedia Protocol Stack, Short History and
Related Protocols are included.

4. Why packet switching? Why SIP?
4
0
10
20
30
40
50
60
70
80
90
100
1980 1985 1987 1990 1995 2000 2001
electromech
analog
digital
Technology evolution of PSTN

5. Session Initiation Protocol OverviewSession Initiation Protocol Overview
5
 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.

6. Security & Privacy
6
 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

7. Internet Multimedia ProtocolsInternet Multimedia Protocols
7
RTSP

8. SIP Requests and ResponsesSIP Requests and Responses
8
SIP Responses use a
numerical code and a
“reason phrase”
1xx Informational
2xx Final
3xx Redirection
4xx Client Error
5xx Server Error
6xx Global Failure
SIP Request types are
called “methods”
INVITE
ACK
OPTIONS
CANCEL
BYE
REGISTER

9. Related Protocols: SDPRelated Protocols: SDP
9
 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”

10. Related Protocol: RTP
10
 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.

11. SIP Uniform Resource Indicators (URIs)SIP Uniform Resource Indicators (URIs)
11
 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 (Which
needs no resolution for routing)

12. SIP “Trapezoid”
12
Outbound
Proxy Server
User Agent B
Inbound
Proxy Server
User Agent
A
SIP
SIP
SIP
Media (RTP)
DNS Server
DNS
Location
Server
SIP

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

14. SIP Elements – Proxy Servers
14
Outbound
Proxy Server
Inbound
Proxy Server
Forward or “proxy”
requests on behalf of
User Agents
Consult databases:
 DNS
 Location Server
Types:
 Stateless
 Transaction Stateful
 Call Stateful
No media capabilities
 Ignore SDP.
Normally bypassed once
dialog established, but
can Record-Route to
stay in path.
SIP
SIP
SIP
DNS Server
DNS
Location
Server
User Agent BUser Agent
A
Media (RTP)
SIP

15. SIP Elements – Other Servers
15
Outbound
Proxy Server
Inbound
Proxy Server
Location Server
Database of locations of
SIP User Agents
Queried by Proxies in
routing
Updated by User Agents
by Registration
DNS Server
SRV (Service) Records
used to locate
Inbound Proxy
Servers
SIP
SIP
SIP
DNS Server
DNS
Location
Server
User Agent BUser Agent
A
Media (RTP)
SIP

16. SIP Client and Server
16
 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)

17. 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

18. SIP Registrar, 2
18
 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

19. Proxy Server
19
 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

20. 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

21. Stateless vs. Stateful Proxy
21
 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

22. 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

23. Locating SIP Servers
23
 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

24. SIP in detail
Now, we are going to study SIP in detail including SIP Request,
SIP Response and SIP Header

25. SIP Request Methods, 1
25
 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

26. SIP Request Methods, 2
26
 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)

27. SIP Methods - INVITE, 1
27
 INVITE requests the establishment of a session
 Carried in Message Body (SDP)
 Type of session
 IP Address
 Port
 Codec

28. SIP Methods - INVITE, 2
28
 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

29. 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

30. SIP Methods - OPTIONS
30
 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

31. SIP Methods – BYE and CANCEL
31
 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.

32. SIP Methods - REGISTER
32
 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

33. 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.
33

34. SIP From and To Tags
34
 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

35. SIP Method - INFO
35
 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

36. SIP Method - REFER
36
 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

37. SIP Method - PRACK
37
 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

38. SIP Methods – SUBSCRIBE and NOTIFY
38
 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

39. SIP Method - MESSAGE
39
 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

40. SIP Responses
40
 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”

41. SIP Responses: 1xx-3xx
SIP Response Code Brief Description
100 Trying Request received and action is being taken
180 Ringing UA received INVITE and is alerting user
181 Call Is Being Forwarded Used by proxy to indicate call is being forwarded
182 Queued Called party unavailable, call queued
183 Session Progress Used in early media and QoS setup
200 OK Request successful
300 Multiple Choices Address resolved to several choices
301 Moved Permanently User can no longer be found at Req-URI address
302 Moved Temporarily Temporarily cannot find user at Req-URI address
305 Use Proxy Resource MUST be accessed through proxy.
380 Alternative Service Call not successful. Alternatives possible.
41

42. SIP Responses: 4xx
SIP Response Code Brief Description
400 Bad Request Request not understood due to malformed syntax
401 Unauthorized Request requires user authentication
402 Payment Required Reserved for future use
403 Forbidden UAS understood request and refuses to fulfill it
404 Not Found UAS finds that user doesn't exist in the domain
405 Method Not Allowed Method is understood but not allowed
406 Not Acceptable Response content not allowed by Accept header
407 Proxy Authentication Required Client must first authenticate itself with proxy
408 Request Timeout UAS could not produce response in time
410 Gone UAS resource unavailable; no forwarding addr.
413 Request Entity Too Large Request contains body longer than UAS accepts
414 Request-URI Too Long Req-URI longer than server is willing to interpret
415 Unsupported Media Type Format of the body not supported by UAS
416 Unsupported URI Scheme Scheme of URI unknown to server
420 Bad Extension UAS not understand protocol extension
421 Extension Required UAS needs particular extension process request
423 Registration Too Brief Contact header field expiration time too small
480 Temporarily Unavailable UAS contacted successfully but user unavailable
481 Call/Transaction Does Not Exist UAS Rx request not matching any existing dialog
482 Loop Detected UAS has detected a loop
483 Too Many Hops UAS received request containing Max-Forwards=0
484 Address Incomplete UAS Rx request with incomplete Request-URI
485 Ambiguous The Request-URI was ambiguous
486 Busy Here UAS contacted successfully but user busy
487 Request Terminated Request terminated by a BYE or CANCEL request
488 Not Acceptable Here Same as 606 but only applies to addressed entity
491 Request Pending UAS Rx req. & have pending req. for same dialog
493 Undecipherable UAS Rx request with encrypted MIME body & not have decryption key
42

43. SIP Responses: 5xx-6xx
SIP Reponse Code Brief Description
500 Server Internal Error UAS unexpected condition & cannot fulfill request
501 Not Implemented UAS not support functionality to fulfill the request
502 Bad Gateway UAS Rx invalid response from a downstream server
503 Service Unavailable UAS can't process due to overload or maintenance
504 Server Time-out UAS not Rx response from external server
505 Version Not Supported UAS not support SIP version in request
513 Message Too Large Message length exceeded UAS capabilities
600 Busy Everywhere End systems contacted, user busy at all of them
603 Decline End systems contacted, user explicitly decline
604 Does Not Exist Anywhere UAS has information Req-URI user not exist
606 Not Acceptable Some aspects of Session Desc. not acceptable
43

44. SIP Message DetailsSIP Message Details
INVITE sip:wh@200.201.202.203 SIP/2.0INVITE 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
44
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

45. SIP Headers
45
 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)

46. SIP Message DetailsSIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76Via: 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
46
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.

47. SIP Message DetailsSIP 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: 69Max-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
47
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.

48. SIP Message DetailsSIP 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>To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159
48
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

49. SIP Message DetailsSIP Message Details
49
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
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 INVITECSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159

50. SIP Message DetailsSIP 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.103Contact: sip:schroed5244@100.101.102.103
Content-Type: application/sdp
Content-Length: 159
50
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

51. SIP Message DetailsSIP Message Details
51
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).
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/sdpContent-Type: application/sdp
Content-Length: 159Content-Length: 159

52. SDP Message Body DetailsSDP Message Body Details
52
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)

53. SIP Response DetailsSIP Response Details
53
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.
SIP/2.0 200 OKSIP/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=24019385tag=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.203Contact: sip:wh@200.201.202.203
Content-Type: application/sdp
Content-Length: 173
v=0v=0
o=Heisenberg 2452772446 2452772446 IN IP4 200.201.202.203o=Heisenberg 2452772446 2452772446 IN IP4 200.201.202.203
s=SIP Calls=SIP Call
c=IN IP4 200.201.202.203c=IN IP4 200.201.202.203
t=0 0t=0 0
m=audio 56321 RTP/AVP 0m=audio 56321 RTP/AVP 0
a=rtpmap:0 PCMU/8000a=rtpmap:0 PCMU/8000

54. SIP Call Flow Scenarios
As followings …

55. SIP Call Flow Scenarios
55
 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.

56. SIP Call Setup Attempt Scenario
56
Outbound
Proxy Server
Inbound
Proxy Server
1. INVITE
Contact: A
SDP A
DNS Server Location
Server
1. A “dials” SIP AOR
URI sip:B@mci.com.
User Agent A sends
INVITE to outbound
Proxy Server.
2. Outbound Proxy
sends 100 Trying
response.
2. 100 Trying
User Agent B
(Not Signed In)
User Agent
A

57. SIP Call Setup Attempt Scenario
57
Outbound
Proxy Server
Inbound
Proxy Server
1. INVITE
Contact: A
SDP A
DNS Server Location
Server
3. Outbound Proxy
does DNS query to
find proxy server for
mci.com domain
4. DNS responds with
IP address of
mci.com Proxy
Server
3. DNS Query:
mci.com?
2. 100 Trying
4. Response: 1.2.3.4
User Agent B
(Not Signed In)
User Agent
A

58. SIP Call Setup Attempt Scenario
58
Outbound
Proxy Server
Inbound
Proxy Server
DNS Server Location
Server
5. Outbound Proxy
sends INVITE to
Inbound Proxy
Server.
6. Inbound Proxy sends
100 Trying
response.
3. DNS Query: mci.com?
2. 100 Trying
4. Response:
1.2.3.4
6. 100 Trying
User Agent B
(Not Signed In)
User Agent
A
1. INVITE
Contact: A
SDP A
5. INVITE
Contact: A
SDP A

59. SIP Call Setup Attempt Scenario
59
Outbound
Proxy Server
Inbound
Proxy Server
DNS Server Location
Server
7. Inbound Proxy
consults Location
Server.
8. Location Server
responds with “Not
Signed In.”
3. DNS Query: mci.com?
2. 100 Trying
4. Response:
1.2.3.4
6. 100 Trying
7. LS Query: B? 8. Response: Not
Signed In
User Agent B
(Not Signed In)
User Agent
A
1. INVITE
Contact: A
SDP A
5. INVITE
Contact: A
SDP A

60. SIP Call Setup Attempt Scenario
60
Outbound
Proxy Server
Inbound
Proxy Server
DNS Server Location
Server
9. Inbound Proxy sends
480 Temporarily
Unavailable
response.
10. Outbound Proxy sends
ACK response.
3. DNS Query:
mci.com?
2. 100 Trying
4. Response:
1.2.3.4
6. 100 Trying
7. LS Query: B? 8. Response:
Not Signed
In
9. 480 Temporarily Unavailable
10. ACK
User Agent B
(Not Signed In)
User Agent
A
1. INVITE
Contact: A
SDP A
5. INVITE
Contact: A
SDP A

61. SIP Call Setup Attempt Scenario
61
Outbound
Proxy Server
Inbound
Proxy Server
DNS Server Location
Server
11. Outbound Proxy
forwards 480 response
to A.
12. A sends ACK response.
3. DNS Query:
mci.com?
2. 100 Trying
4. Response:
1.2.3.4
6. 100 Trying
7. LS Query: B? 8. Response:
Not Signed
In
9. 480 Temporarily Unavailable
11. 480 Temporarily Unavailable
10. ACK
12. ACK
User Agent B
(Not Signed In)
User Agent
A
1. INVITE
Contact: A
SDP A
5. INVITE
Contact: A
SDP A

62. SIP Presence Example
62
Outbound
Proxy Server
Inbound
Proxy Server
1. SUBSCRIBE
DNS Server
Presence
Server
1. A wants to be informed
when B signs on, so
sends a SUBSCRIBE
2. Outbound Proxy
forwards to Inbound
Proxy
3. Inbound Proxy forwards
to B’s Presence Server
2. SUBSCRIBE
3. SUBSCRIBE
User Agent B
(Not Signed In)
User Agent
A

63. SIP Presence Example
63
Outbound
Proxy Server
Inbound
Proxy Server
1. SUBSCRIBE
DNS Server
Presence
Server
4. Presence Server
authorizes subscription
by sending a 200 OK.
5. & 6. 200 OK proxied
back to A.
6. 200 OK
2. SUBSCRIBE
5. 200 OK
3. SUBSCRIBE 4. 200 OK
User Agent B
(Not Signed In)
User Agent
A

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

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

66. SIP Registration Example
66
Outbound
Proxy Server
Outbound
Proxy Server
DNS Server
Location
Server
2. Update database:
B = B@2.3.4.5 3. OK
1. REGISTER
Contact: B@2.3.4.5
4. 200 OK
Contact: B@2.3.4.5
3. Location Server
database update is
confirmed.
4. Registration is confirmed
with a 200 OK
response.
User Agent BUser Agent
A

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

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

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

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

71. SIP Call Setup Scenario
71
Outbound
Proxy Server
Inbound
Proxy Server
10. 180 Ringing
DNS Server Location
Server
8. User Agent B alerts
B and sends 180
Ringing response.
9. & 10. 180 Ringing
is proxied back to A.
9. 180 Ringing
8. 180 Ringing
User Agent BUser Agent
A

72. SIP Call Setup Scenario
72
Outbound
Proxy Server
Inbound
Proxy Server
10. 180 Ringing
DNS Server Location
Server
11. B accepts call and
User Agent B sends
200 OK response.
12. & 13. 200 OK is
proxied back to A.
9. 180 Ringing
8. 180 Ringing
User Agent BUser Agent
A
11. 200 OK
Contact: B
SDP B
12. 200 OK
Contact: B
SDP B
13. 200 OK
Contact: B
SDP B

73. SIP Call Setup Scenario
73
Outbound
Proxy Server
Inbound
Proxy Server
10. 180 Ringing
DNS Server Location
Server
14. ACK is sent by A to
confirm setup call
bypassing proxies.
Media session begins
between A and B!
9. 180 Ringing
8. 180 Ringing
14. ACK
Media (RTP)
User Agent BUser Agent
A
11. 200 OK
Contact: B
SDP B
12. 200 OK
Contact: B
SDP B
13. 200 OK
Contact: B
SDP B

74. SIP Call Hold (re-INVITE)
74
Outbound
Proxy Server
Inbound
Proxy Server
DNS Server Location
Server
15. B places A on hold
by sending a re-
INVITE.
16. A accepts with a
200 OK.
17. B sends ACK to A.
No media between A
and B.15. INVITE
SDP a=sendonly
17. ACK
User Agent BUser Agent
A
16. 200 OK
SDP A

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

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

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

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

79. SIP Security

80. Authorization
80
 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

81. TLS and sips:
81
 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.

82. S/MIME
82
 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

83. Attacks
83
 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

84. Attacks : denial of service
84
 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

85. Attacks : fraud
85
 Call-ID spoofing
 User rights takeover
 Fake authentication server
 Effects
 Access to voicemail
 Value added numbers
 Social engineering
 Replay

86. Attacks: interception
86
 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

87. Attacks : systems
87
 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

88. Defense
88
 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

89. SIP Programming

90. SIP based Application Interfaces
90
 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

91. HTTP Servlets
91
 HTTP Java Servlets Widely Used in Web
Application Development
 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
 HTTP Servlets Can Create “Session Data”
 e.g., shopping cart, that spans multiple requests
 “Container” Manages HTTP Servlet Lifecycles,
Fault Tolerance, Session State
 HTTP Servlets Collected into a War File – Web
Archive
HTTP
Servlets
Web Server
Developer
Deployer
War File

92. SIP Servlet API
92
 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)

93. Basic SIP Servlet Model
93
S e rvle t E n g in e
S IP S e rve r
re q u e s t s
re s p o n s e s
re q u e s t s
re s p o n s e s
s e r v le ts e r v le t
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

94. Example: Routing Services
94
 Servlet proxies request to one or more destinations
 - forwards response to caller
S e rve r
s e r v le t
U A C U A S
S IP S IP
R T P

95. Example: Servlet as UAS
95
S e rve r
s e r v le t
U A C
S IP
R T P
Servlets can reject (screen) calls
Can accept and set up media streams

96. Benefits of Servlet Model
96
 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

97. An Example: RejectServlet
97
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;
}
}

98. Relationship to JAIN SIP
98
 JAIN SIP is a generic, low-level
interface for accessing SIP services
 Can be used in
 Clients
 Servers
 Gateways
 Focuses purely on the protocol
 Complete access to SIP capabilities
 Supports transactions only
 SIP Servlet Container is a particular
application of JAIN SIP SIP Protocol
SIP Servlet
Container
Servlet
JAIN SIP
SIP Servlet API
Servlet

99. Relationship to JAIN SIP
99
 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
 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

100. SIP CGI
100
 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

101. Call Processing Language (CPL)
101
 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

102. CPL Example
102
 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>