Intro To SIP Draft Final

SIP Tutorial
Introduction to SIP
Original Slides by Alan Johnston and Henry Sinnreich, MCI (at VON03)
Contents
SIP Overview SIP in detail SIP Call Flow Scenarios SIP Security SIP Programming Some Related Works
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 50 40 30 20 10 0 1980 1985 1987 1990 1995 2000 2001
Technology evolution of PSTN
4
electromech analog digital
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) Voice, video, gaming, instant messaging, presence, call control, etc.
5
Applications include (but not limited to):
Security & Privacy

SIP Authentication

Challenge/Response based on shared secret - SIP Digest Mechanism also used by HTTP Used for client devices Used between servers SIP signaling can be encrypted
S/MIME (Secure/Multipurpose Internet Mail Extensions)
Encryption using private/public keys
Privacy and security
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
A Short History of SIP

Internet Engineering Task Force (IETF) protocol Inventors: M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg Became Proposed Standard and RFC 2543 in March 1999 in MMUSIC WG. Separate SIP WG established in September 1999. Now new SIPPING (applications) and SIMPLE (presence and instant messaging) WGs using SIP. RFC2543bis-09 I-D became RFC 3261 in June 2002

Added four new authors: G. Camarillo, A. Johnston, J. Peterson, and R. Sparks. Entire spec rewritten for clarity, but some new features Mostly backwards compatible with RFC 2543
SIP Requests and Responses

SIP Request types are called methods Methods in base spec: INVITE ACK OPTIONS CANCEL BYE REGISTER SIP Responses use a numerical code and a reason phrase Classes:
1xx 2xx 3xx 4xx 5xx 6xx Informational Final Redirection Client Error Server Error Global Failure
Example: 404 Not Found

9
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
10
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.
11
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 (Which needs no resolution for routing)
12
SIP Trapezoid
DNS Server Location Server
DNS
Outbound Proxy Server
SIP
Inbound Proxy Server
SIP SIP
SIP Media (RTP) User Agent A User Agent B
13
SIP Elements User Agents

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

DNS
Forward or proxy requests on behalf of User Agents Consult databases:

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

Location Server
Database of locations of SIP User Agents Queried by Proxies in routing Updated by User Agents by Registration
DNS
SIP
SIP SIP
SIP Media (RTP)
DNS Server
User Agent B
User Agent A
SRV (Service) Records used to locate Inbound Proxy Servers

16
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)
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)
18
SIP Registrar, 2
SIP Registrars store the location of SIP endpoints
Each SIP endpoint Registers

with a Registrar using its 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
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
21
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 Stateful
Dialogue (from INVITE to BYE)
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
23
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
24
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
26
SIP Request Methods, 2

REGISTER
Register contact with Registrar Creates, negotiates and tears down a call (dialogue) Creates an Instant Messaging session
INVITE/ACK/BYE/CANCEL/UPDATE
MESSAGE
SUBSCRIBE
Subscribe to a service (like message waiting indication)

Notify a change in service state (new Voicemail)
NOTIFY
27
SIP Methods - INVITE, 1

INVITE requests the establishment of a session Carried in Message Body (SDP)

Type of session IP Address Port Codec
28
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
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
30
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
31
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.
32
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
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. 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)
34
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
35
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
36
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
37
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
38
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
39
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
40
SIP Responses
SIP Requests generate Responses with codes borrowed from HTTP Classes:

1xx 2xx 3xx 4xx 5xx 6xx
Informational Final Redirection Client Error Server Error Global Failure
Response example 404 Not Found

41
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.
42
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
43
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
44
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

45
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)
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
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 Details

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 Details

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 Details

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
50
SIP Message Details

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 Details

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).
52
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)
53
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

54
Contact and Message Body contain UAS information.
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.
56
SIP Call Setup Attempt Scenario

Outbound Proxy Server 1. INVITE Contact: A SDP A
2. 100 Trying
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.
User Agent A
User Agent B (Not Signed In)
57

3. DNS Query: mci.com?
4. Response: 1.2.3.4
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
2. 100 Trying
User Agent A
58

4. Response: 1.2.3.4 5. INVITE Contact: A SDP A 6. 100 Trying
2. 100 Trying
5. Outbound Proxy sends INVITE to Inbound Proxy Server. 6. Inbound Proxy sends 100 Trying response.
User Agent A
59

4. Response: 1.2.3.4
7. LS Query: B?
8. Response: Not Signed In
5. INVITE Contact: A SDP A 6. 100 Trying 2. 100 Trying
7. Inbound Proxy consults Location Server. 8. Location Server responds with Not Signed In.
User Agent A
60

4. Response: 7. LS Query: B? 1.2.3.4 5. INVITE Contact: A SDP A 6. 100 Trying
8. Response: Not Signed In Inbound Proxy Server
Outbound Proxy Server 1. INVITE Contact: A SDP A 2. 100 Trying
9. Inbound Proxy sends 480 Temporarily Unavailable response.

10. Outbound Proxy sends ACK response.
9. 480 Temporarily Unavailable 10. ACK
User Agent A
61

4. Response: 7. LS Query: B? 1.2.3.4 5. INVITE Contact: A SDP A 6. 100 Trying
8. Response: Not Signed In Inbound Proxy Server
Outbound Proxy Server 1. INVITE Contact: A SDP A 2. 100 Trying
9. 480 Temporarily Unavailable 10. ACK 11. 480 Temporarily Unavailable 12. ACK
11. Outbound Proxy forwards 480 response to A. 12. A sends ACK response.
User Agent A
62
SIP Presence Example

DNS Server Presence Server
3. SUBSCRIBE
2. SUBSCRIBE
1. A wants to be informed when B signs on, so sends a SUBSCRIBE
1. SUBSCRIBE
2. Outbound Proxy forwards to Inbound Proxy 3. Inbound Proxy forwards to Bs Presence Server
User Agent A
63

3. SUBSCRIBE
4. 200 OK
2. SUBSCRIBE 5. 200 OK
1. SUBSCRIBE
6. 200 OK
4. Presence Server authorizes subscription by sending a 200 OK. 5. & 6. 200 OK proxied back to A.
User Agent A
64

7. NOTIFY <Not Signed In>
12. 200 OK
Outbound Proxy Server 9. NOTIFY <Not Signed In>
8. NOTIFY <Not Signed In>

11. 200 OK
10. 200 OK
User Agent A
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 Bs Presence Server.
65
SIP Registration Example

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 Bs User Agent. 2. Database update is sent to the Location Server
User Agent A
User Agent B
66
SIP Registration Example

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

DNS Server Presence Server 13. NOTIFY <Signed In>
Outbound Proxy Server 15. NOTIFY <Signed In>
14. NOTIFY <Signed In>

17. 200 OK
16. 200 OK
User Agent A
13. Presence Server learns of Bs new status from 18. 200 OK the Location Server and sends a NOTIFY Inbound containing new status Proxy Server 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 User Agent B Presence Server.
68
SIP Instant Message Scenario

3. LS Query: B?
4. Response: sip:B@2.3.4.5
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.
Outbound Proxy Server 1. MESSAGE <Can you talk now?>
2. MESSAGE <Can you talk now?> 7. 200 OK 5. MESSAGE <Can you talk now?>
8. 200 OK
6. 200 OK
User Agent A
User Agent B
69
SIP Instant Message Scenario

Location Server
5. LS Query: A?
6. Response: 2. DNS Query: sip:A@4.5.3.2 globalipcom.com?
3.
1. B sends an Instant Message to A saying Sure. in a Response: 5.6.7.8 MESSAGE sent to As AOR URI.
DNS Server Outbound Proxy Server
Inbound Proxy Server 7. MESSAGE <Sure.>
4. MESSAGE <Sure.> 9. 200 OK 8. 200 OK 1. MESSAGE <Sure.>
10. 200 OK
User Agent A
User Agent B
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.
70

5. LS Query: B
6. Response: sip:B@2.3.4.5
3. INVITE Contact: A SDP A 4. 100 Trying
1. to 5. A retries INVITE to B which routes through two Proxy Servers.

6. Location Server responds with the FQDN SIP URI of Bs SIP Phone. 7. Inbound Proxy Server forwards INVITE to Bs SIP Phone.
1. INVITE Contact: A SDP A
2. 100 Trying
7. INVITE Contact: A SDP A
User Agent A
User Agent B
71
SIP Call Setup Scenario

9. 180 Ringing
10. 180 Ringing 8. 180 Ringing
8. User Agent B alerts B and sends 180 Ringing response. 9. & 10. 180 Ringing is proxied back to A.
User Agent A
User Agent B
72

9. 180 Ringing 12. 200 OK Contact: B SDP B 13. 200 OK Contact: B 8. 180 Ringing SDP B
10. 180 Ringing
11. 200 OK Contact: B SDP B
11. B accepts call and User Agent B sends 200 OK response. 12. & 13. 200 OK is proxied back to A.
User Agent A
User Agent B
73

9. 180 Ringing 12. 200 OK Contact: B SDP B 13. 200 OK Contact: B 8. 180 Ringing SDP B 14. ACK Media (RTP)
14. ACK is sent by A to confirm setup call bypassing proxies. Media session begins between A and B!
10. 180 Ringing
11. 200 OK Contact: B SDP B
User Agent A
User Agent B
74
SIP Call Hold (re-INVITE)

15. B places A on hold by sending a reINVITE. 16. A accepts with a 200 OK. 17. B sends ACK to A. No media between A and B.
15. INVITE SDP a=sendonly 16. 200 OK SDP A User Agent A 17. ACK
User Agent B
75
SIP Call Transfer Scenario

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

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

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

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 User Agent A 23. 200 OK
User Agent B
79
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 cant 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:

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
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
IPhreakers

IP knowledge Known weaknesses Evolution 2600Hz -> voicemail/intl GWs -> IP telephony Internal or external threat ? Targets: home user, enterprise, government, etc ?
Protocol implementations
PROTOS
The human element
84
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
85
Attacks : fraud
Call-ID spoofing
User rights takeover
Fake authentication server
Effects

Access to voicemail Value added numbers Social engineering Replay

86
Attacks: interception
Interception
Who talks with who (Network sniffing, Servers (SIP, CDR, etc) Physical access to the LAN ARP attacks Unauthenticated devices (phones and servers) Different layers (MAC address, user, physical port, etc) Where is the user located ? Networks crossed ?
LAN

Where to intercept ?

Lawful Intercept

CALEA ETSI standard Architecture and risks

87
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

88
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
89
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
91
HTTP Servlets
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
HTTP Servlets
War File
Developer Deployer
e.g., shopping cart, that spans multiple requests Web Server
Container Manages HTTP Servlet Lifecycles, Fault Tolerance, Session State HTTP Servlets Collected into a War File Web Archive
92
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)
93
Basic SIP Servlet Model

servlet servlet
Servlet Engine requests SIP Server responses responses requests
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

RTP
servlet
UAC Server SIP SIP
UAS
Servlet proxies request to one or more destinations - forwards response to caller
95
Example: Servlet as UAS

RTP UAC Server SIP
servlet
Servlets can reject (screen) calls Can accept and set up media streams
96
Benefits of Servlet Model

Powerful:
Full access to SIP signaling No need to fork new process for each request The same servlet can handle many requests simultaneously
Performance:

Safety: type checked; no pointers; exception handling Convenience:

high level abstractions. Tight integration with server: logging, security, location database maintain state, e.g. database connections manage timers
Lifecycle model allows servlets to

Access to wide range of APIs

97
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; } }
98
Relationship to JAIN SIP

Servlet
SIP Servlet API
Can be used in
Clients
Servers
Gateways

Focuses purely on the protocol Complete access to SIP capabilities Supports transactions only
JAIN SIP
SIP Servlet Container SIP Protocol
SIP Servlet Container is a particular application of JAIN SIP

99
Servlet
JAIN SIP is a generic, low-level interface for accessing SIP services
Relationship to JAIN SIP

Servlets focus on high volume carrier grade servers Add significant, non-SIP protocol functions
Hide many parts of JAIN SIP
Direct access to many headers is not provided Write access to most everything is often restricted
Lifecycle management Domain objects Context and configuration Deployment descriptors Archive files Synchronization primitives Security
Servlets should be defined to allow a SIP container to be built using JAIN SIP
Add significant SIP protocol functions
SIP Objects in Servlet API defined with interfaces that match JAIN SIP signatures Cannot directly expose JAIN SIP objects, though
Construction of requests and responses from domain objects
100
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
101
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
102
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>
103
Some Related Works

Parlay IMS IPv6
Why Parlay is Important to Galaxy

Open standard Range of services Many levels of sophistication and complexity
Secure framework for discovery of and access to services by third party applications
Registration of non-Parlay service APIs
Independent of specific network and software environment
105
Why Unified Communications?

Calls
Private Job Fixed Fax
Messages
Job
Private
Mobile
E-mail SMS
VoIP V-mail
MPEG
IM
106
Architecture I: Parlay as a Unifying Technology
Application Parlay
INAP
ISUP
MAP
SIP
107
Architecture II: SIP as a Unifying Technology
Application Servlet/CGI/CPL Script SIP Gateway to Other Networks
IP network
108
Key Questions
Which of these two models is correct, or are there opportunities for both approaches to co-exist?
How well can a generic network API sit on top of SIP? For example, would it severely limit a developer, and what advantages would it offer? Which aspects of network functionality will actually be useful in practice to developers?
109
Parlay within Galaxy
3rd Party Applications CORBA Appium Unified Comms Application
BT C++ Apps
BT VB Apps
DCOM
PSTN Platform
Parlay Gateway
SIP Proxy
VOIP gateway
SIP clients
110
Feasibility: A proof of concept prototype ...

Game server
Parlay
Game events XML over JXTA
MRFC
MRFP
SIP
RTP
Player 1
Player 2
Player 3
111
Some Challenges for Parlay

Which technologies should Parlay support?
How can interoperability testing be encouraged? How can Parlay get feedback from developers? Sizeable specifications with complex interfaces and data types give long learning curve for developers? Although specifications are maturing, still few Parlay products commercially available. Why?
How does Parlay keep pace with new protocols?
112
Parlay on a SIP Network ?

Parlay adds security to SIP Parlay provides many features not available in SIP APIs Parlay provides a network independent model BUT... SIP APIs can make some simpler solutions for some applications envisaged by Parlay group Parlay could support SIP better SO... SIP will have a significant impact on the future of Parlay SIP and Parlay can already work well together and are a powerful combination
113
Global SIP/IMS deployment needs IPv6

Introduction of SIP-based peer-to-peer services is an important step after current client-server based services. IP Multimedia Subsystem (IMS) is a service infrastructure based on the use of Session Initiation Protocol (SIP).

3GPP Release 5 and 6 specifications 3GPP2 specifications
In order to make peer-to-peer services work between different operators' networks, IPv6 is needed - peer-to-peer services work well only with public IP addresses.

Small scale IMS deployment / piloting can be started with IPv4. IPv6 is vital for wider scale, global IMS deployment.
114
Example of peer-to-peer IP connectivity

UMS CSCF
Thomas challenges you to a game of checkers!
Peter: 00:00:00 Accept Decline Thomas: 00:00:00
SIP Thomas
IPv6 Game data

IP Connection
Peter
Peter accepted the challenge! Invite player
Chat
Push to Stream Quit
115

UMS CSCF
> Peter: I am going to win this time! >Thomas: Yeah right, in your dreams!
Peter: 00:00:00 Thomas: 00:00:00
SIP
Thomas
IPv6 Game data

Chat
Peter: 00:00:00 Thomas: 00:00:00 > Peter: I am going to win this time! >Thomas: Yeah right, in your dreams!
IP Connection
Peter
Invite player
Chat
Push to Stream Quit
116

UMS CSCF
Peter chooses to add a streaming component to share what he is seeing
SIP
Thomas
IPv6 Game data

Streami ng video
Streaming video from Peter: Peter: 00:00:00
IP Connection
Peter
Invite player
Thomas: 00:00:00 > Peter: hey, look what just passed by!
Chat
Push to Stream Quit
117
Future mobile services = serverless media

UMS CSCF
Peter: 00:00:00 Thomas: 00:00:00
SIP
IPv6 Game data

Chat
Thomas
IP Connection
Peter
No NATs in between, public IP addresses are needed

The SIP/IMS user plane is peer-to-peer in nature - SIP/IMS sessions between mobiles in different Private IPv4 address spaces become highly complicated. This is why public IP addresses are required. The only future proof solution is provided by IPv6.
Example services: gaming, chat, streaming, Voice/video over IP, etc.
118
Standardized technology enablers for new mobile services are here today
IPv6
MMS Color displays
SIP
XHTML and TCP/IP Multimode
Imaging and camera integration
GPRS EDGE WCDMA

CDMA2000 Bluetooth WLAN
Video Multimedia Streaming Symbian Java DRM
Positioning MIDI Presence
119
Technology and Application Trends

2G radio interface (GSM / EDGE) IPv4 Client-server connectivity SMS text messaging, WAP browsing, MMS multimedia messaging 2G and 3G radio interfaces (WCDMA / CDMA2000) IPv4/IPv6 dual stack Peer-to-peer connectivity Richer, IP-based Applications
HTTP/TCP/IP browsing Presence Instant Messaging Multimedia streaming Gaming Voice and video telephony Sharing Etc.
120
Multi-access IMS
S-CSCF P-CSCF
IMS
(IPv6)
P-CSCF
3GPP access nw
GGSN P-CSCF PDSN
WLAN access nw
Common IP version (=IPv6) makes the multiaccess case much easier
3GPP2 access nw
SIP
SIP Signaling for building up the session User IP data
121
References
Anders Kristensen, Hewlett-Packard Laboratories, Bristol, U.K Nicolas FISCHBACH, Senior Manager, IP Engineering/Security - COLT Telecom Jonathan Rosenberg, Dynamicsoft Ed Luff, Newport Networks Patrick Ferriter, ZULTYS
122

Intro To SIP Draft Final

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intro To SIP Draft Final

Uploaded by

Copyright:

Available Formats

SIP Tutorial

Why packet switching? Why SIP?

electromech analog digital

Session Initiation Protocol Overview

Applications include (but not limited to):

Security & Privacy

Encryption using private/public keys

Privacy and security

Defined in RFC 2633

SIP can be transported over

Defined in RFC 2401

TLS (Transport Layer Security)

Defined in RFC 2246

Internet Multimedia Protocols

A Short History of SIP

SIP Requests and Responses

Example: 404 Not Found

Related Protocols: SDP

with Minimal Control

of media source timestamp codec type sequence number

by H. Schulzrinne et al, RFC 1889. Profiles defined by RFC 1890.

SIP Uniform Resource Indicators (URIs)

sip:henry@siptest.mci.com is a SIP URI

Two types of SIP URIs:

Address of Record (AOR) (identifies a user)

Outbound Proxy Server

Inbound Proxy Server

SIP Media (RTP) User Agent A User Agent B

SIP Elements User Agents

Capable of sending and receiving SIP requests.

UAC User Agent Client UAS User Agent Server

Outbound Proxy Server

SIP phone PC/laptop with SIP Client PDA mobile phone

SIP Media (RTP) User Agent A User Agent B

PSTN Gateways are a type of User Agent

SIP Elements Proxy Servers

Forward or proxy requests on behalf of User Agents Consult databases:

Outbound Proxy Server

Inbound Proxy Server

SIP Media (RTP)

Stateless Transaction Stateful Call Stateful

SIP Elements Other Servers

Outbound Proxy Server

Inbound Proxy Server

SIP Media (RTP)

SRV (Service) Records used to locate Inbound Proxy Servers

SIP Client and Server

A User Agent acts as a

Each SIP endpoint Registers

Stateless Proxies use stateless protocols like UDP to talk to endpoints

down for the duration of the session

SIP Proxy Server

Receives a SIP request Adds some headers

Modifies some of the headers

Stateless vs. Stateful Proxy

good for network cores

Maintains state information for the duration of either the:

Dialogue (from INVITE to BYE)

Performs message retransmission

SIP Redirect Server

Locating SIP Servers

Multicast (deprecated) DNS SRV method