Contents
SIP Overview SIP Tutorial SIP in detail Introduction to SIP SIP Call Flow Scenarios SIP Security SIP Programming SIP Applications SIP Deployment
Original Slides by Alan Johnston and Henry Sinnreich, MCI (at VON’03)
2
Why packet switching? Why SIP?
SIP Overview
What SIP is, Multimedia Protocol Stack, Short History and Related Protocols are included.
Technology evolution of PSTN
4
Session Initiation Protocol Overview Security & Privacy
Application Layer Signaling Protocol SIP Authentication Challenge/Response based on shared secret - SIP Digest Used to establish, modify, and terminate Mechanism also used by HTTP multimedia sessions Used for client devices Part of Internet Multimedia Architecture Encryption using private/public keys Can use UDP, TCP, TLS, SCTP, etc. Used between servers Privacy and security Based on HTTP (Web) SIP signaling can be encrypted Similar text-based structure S/MIME (Secure/Multipurpose Internet Mail Extensions) Defined in RFC 2633 Uses URIs (Uniform Resource Indicators) SIP can be transported over Applications include (but not limited to): IPSec Defined in RFC 2401 Voice, video, gaming, instant messaging, presence, call control, etc. TLS (Transport Layer Security) Defined in RFC 2246
5 6 Internet Multimedia Protocols 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 RTSP 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
7 8
SIP Requests and Responses Related Protocols: SDP
SIP Request types are SIP Responses use a SIP carries (encapsulates) SDP messages called “methods” numerical code and a SDP specifies codecs and media termination “reason phrase” Methods in base spec: points Classes: Only one of many possible MIME attachments carried by SIP INVITE 1xx Informational SDP – Session Description Protocol ACK 2xx Final Used to describe media session. OPTIONS 3xx Redirection Carried as a message body in SIP messages. CANCEL 4xx Client Error Is a text-based protocol BYE 5xx Server Error Uses RTP/AVP Profiles for common media types REGISTER 6xx Global Failure Defined by RFC 2327 Example: 404 Not Found E.g. RFC 3551 “RTP Profile for Audio and Video Conferences with Minimal Control” 9 10
Related Protocol: RTP SIP Uniform Resource Indicators (URIs) RTP – Real-time Transport Protocol Same form as email addresses: user@domain Used to transport media packets over IP Two URI schemes: sip:[email protected] is a SIP URI RTP adds a bit-oriented header containing: Most common form introduced in RFC 2543 name of media source sips:[email protected] is a Secure SIP URI timestamp New scheme introduced in RFC 3261 codec type Requires TLS over TCP as transport for security sequence number Two types of SIP URIs: Defined by H. Schulzrinne et al, RFC 1889. Address of Record (AOR) (identifies a user) sip:[email protected] (Needs DNS SRV records to locate SIP Servers Profiles defined by RFC 1890. for mci.com domain) RTCP for exchange of participant and quality Contact (identifies a device and is usually a Fully Qualified Domain reports. Name, FQDN ) sip:[email protected] or sip:[email protected] (Which needs no resolution for routing) 11 12 SIP “Trapezoid” SIP Elements – User Agents
Capable of sending DNS Server Location DNS Server Location Server Server and receiving SIP requests. DNS DNS UAC – User Agent Client UAS – User Agent Server End Devices SIP SIP Outbound Inbound Outbound Inbound SIP phone Proxy Server Proxy Server Proxy Server Proxy Server PC/laptop with SIP Client SIP SIP PDA SIP SIP mobile phone
SIP SIP PSTN Gateways
Media (RTP) Media (RTP) are a type of User Agent User Agent A User Agent A User Agent B User Agent B
13 14
SIP Elements – Proxy Servers SIP Elements – Other Servers
DNS Server Location DNS Server Location Location Server Server Forward or “proxy” Server requests on behalf of DNS User Agents DNS Database of locations of Consult databases: SIP User Agents
SIP DNS SIP Queried by Proxies in Outbound Inbound Outbound Inbound Proxy Server Proxy Server Location Server Proxy Server Proxy Server routing Types: Updated by User Agents SIP Stateless SIP by Registration SIP Transaction Stateful SIP Call Stateful SIP SIP DNS Server No media capabilities Media (RTP) Media (RTP) Ignore SDP. User Agent A User Agent B Normally bypassed once User Agent A User Agent B SRV (Service) Records dialog established, but used to locate can Record-Route to Inbound Proxy stay in path. Servers 15 16
SIP Client and Server SIP Registrar, 1
SIP Elements are either SIP server that can receive and process REGISTER requests
User Agents (end devices that initiate and terminate A user has an account created which allows them to REGISTER media sessions) contacts with a particular server The account specifies a SIP “Address of Record (AOR)” 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 18 SIP Registrar, 2 Proxy Server
SIP Registrars store the location of SIP SIP Proxy servers route SIP messages endpoints Stateless Proxies use stateless protocols like UDP to Each SIP endpoint Registers talk to endpoints with a Registrar using it’s Address of Record and Contact address Low Proxy overhead Address of Record for John Smith in From: header Ephemeral connections, dropped as soon as message is From: John Smith
19 20
SIP Proxy Server Stateless vs. Stateful Proxy
SIP Server which acts on behalf of User Agents Stateless Proxy Receives a SIP request Forwards every request downstream and response upstream Keeps no state (does not have any notion of a transaction) Adds some headers Never performs message retransmissions Modifies some of the headers Stateless proxies scale very well Forwards request to next hop server or client 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 22
SIP Redirect Server Locating SIP Servers
Receives a request and returns a redirection response Manual provisioning (3xx) DHCP SIP Option 120 Contact header in response indicates where request RFC 3361 should be retried Multicast (deprecated) Similar to database query DNS SRV method All Server types are logical NOT Physical Get local domain name automatically from DHCP server Perform SRV record query through DNS on that domain for _sip._udp.
Send SIP REGISTER message to resolved server
phone is up and running without user intervention
23 24 SIP Request Methods, 1
SIP used for Peer-to-Peer Communication though it uses a Client-Server model SIP in detail Requests are called “methods” Six methods are defined in base RFC 3261: INVITE Now, we are going to study SIP in ACK detail including SIP Request, SIP OPTIONS BYE Response and SIP Header CANCEL REGISTER
26
SIP Request Methods, 2 SIP Methods - INVITE, 1 REGISTER INVITE requests the establishment of a Register contact with Registrar INVITE/ACK/BYE/CANCEL/UPDATE session Creates, negotiates and tears down a call (dialogue) Carried in Message Body (SDP) MESSAGE Type of session Creates an Instant Messaging session SUBSCRIBE IP Address
Subscribe to a service (like message waiting indication) Port
NOTIFY Codec Notify a change in service state (new Voicemail)
27 28
SIP Methods - INVITE, 2 SIP Methods - ACK
An INVITE during an existing session ACK completes the three way session setup (dialogue) is called a re-INVITE handshake (INVITE, final response, ACK) re-INVITEs can be used to Only used for INVITE Place calls on or remove calls from hold If INVITE did not contain media information Change session parameters and codecs ACK must contain the media information The SIP UPDATE method is the proposed replacement for this technique
29 30 SIP Methods - OPTIONS SIP Methods – BYE and CANCEL
OPTIONS requests the capabilities of another BYE terminates an established session User Agent User Agents stop sending media packets (RTP) Response lists supported methods, CANCEL terminates a pending session. extensions, codecs, etc. INVITE sent but no final response (non-1xx) yet User Agent responds to OPTIONS the same received. as if an INVITE (e.g. if Busy, returns 486 User Agents and Proxies stop processing INVITE Busy Here) Can be sent by a proxy or User Agent Useful for “forking proxy” Very basic presence information Parallel search using multiple registration Contacts. First successful wins, rest are cancelled.
31 32
SIP Methods - REGISTER SIP Request URI The Request-URI indicates the destination address of the Registration allows a User Agent to upload request current location and URLs to a Registrar Proxies and other servers route requests based on Registrar can upload into Location Service Request-URI. The Request-URI is modified by proxies as the address is Incoming requests can then be proxied or resolved. 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 34
SIP From and To Tags SIP Method - INFO
Tags are pseudo-random numbers inserted in Used to transport mid-call signaling To or From headers to uniquely identify a call information leg Only one pending INFO at a time INVITE request From header contains a tag Typical use - PSTN signaling message carried Any User Agent or Server generating a as MIME attachment response adds a tag to the To header in the E.g. ISDN User-to-User information response Defined in RFC 2976 To: sip:[email protected];tag=123456
35 36 SIP Method - REFER SIP Method - PRACK
Indicates that recipient (identified by the Provisional Response ACKnowlegement Request-URI) should contact a third party using Used to acknowledge receipt of provisional the contact information provided in the request response Typical Use: Call Transfer features 183 Session Progress Allowed outside an established dialogue 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 38
SIP Methods – SUBSCRIBE and NOTIFY SIP Method - MESSAGE SUBSCRIBE requests notification of when a Extension to SIP for Instant Messaging (IM) particular event occurs MESSAGE requests Use Expires=0 to unsubscribe carry the content in the form of MIME body parts A NOTIFY message is sent to indicate the event status use the standard MIME headers to identify the content Sample Applications
Presence
Message waiting indication for voicemail Defined in RFC 3265
39 40
SIP Responses SIP Responses: 1xx-3xx
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 42 SIP Responses: 4xx SIP Responses: 5xx-6xx
43 44
SIP Message Details SIP Headers
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 SIP Requests and Responses contain Headers (similar Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 to Email headers) Max-Forwards: 69 To: Heisenberg
the Request-URI which indicates who the request is for Subject, Date, Authentication (and many others) sip:[email protected] 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 46
SIP Message Details SIP Message Details
INVITE sip:[email protected] SIP/2.0 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 Max-Forwards: 69 To: Heisenberg
Via headers show the path the request has taken Max-Forwards is a count decremented by each proxy
The bottom Via header is inserted by the User Agent which initiated that forwards the request. the request When count goes to zero, request is discarded and 483 Additional Via headers are inserted by each proxy in the path Too Many Hops response is sent. The Via headers are used to route responses back the same way Used for stateless loop detection. Required branch parameter contains a “cookie” ( z9hG4bK ) then a transaction-ID. 47 48 SIP Message Details SIP Message Details
INVITE sip:[email protected] SIP/2.0 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 Max-Forwards: 69 To: Heisenberg
Dialog (formerly called call leg) information is in headers: CSeq Command Sequence Number To tag, From tag, and Call-ID (Note: Not URIs) Initialized at start of call ( 1 in this example) To From and URIs usually contain AOR URIs. Incremented for each subsequent request
All requests and responses in this call will use this same Dialog Used to distinguish a retransmission from a new request information. Also contains the request type (method) - INVITE Call-ID is unique identifier usually composed of
pseudo-random string “@” hostname or IP Address 49 50
SIP Message Details SIP Message Details
INVITE sip:[email protected] SIP/2.0 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 Max-Forwards: 69 To: Heisenberg
SDP Message Body Details SIP Response Details
SIP/2.0 200 OK v=0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 o=Tesla 289084526 28904529 IN IP4 lab.high-voltage.org Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 s=- To: Heisenberg
53 54 SIP Call Flow Scenarios
Call Attempt - Unsuccessful Presence Subscription Registration SIP Call Flow Scenarios Presence Notification Instant Message Exchange Call Setup – Successful As followings … 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 SIP Call Setup Attempt Scenario
DNS Server Location DNS Server Location Server Server
3. DNS Query: 4. Response: 1.2.3.4 mci.com? 1. A “dials” SIP AOR 3. Outbound Proxy does URI sip:[email protected] . DNS query to find
Outbound Inbound User Agent A sends Outbound Inbound proxy server for Proxy Server Proxy Server INVITE to outbound Proxy Server Proxy Server mci.com domain Proxy Server. 4. DNS responds with 1. INVITE 1. INVITE Contact: A 2. 100 Trying 2. Outbound Proxy Contact: A 2. 100 Trying IP address of SDP A SDP A sends 100 Trying mci.com Proxy response. Server
User Agent A User Agent B User Agent A User Agent B (Not Signed In) (Not Signed In)
57 58
SIP Call Setup Attempt Scenario SIP Call Setup Attempt Scenario
DNS Server Location DNS Server Location Server Server
3. DNS Query: mci.com? 4. Response: 3. DNS Query: mci.com? 4. Response: 1.2.3.4 1.2.3.4 7. LS Query: B? 8. Response: Not 5. Outbound Proxy Signed In 7. Inbound Proxy 5. INVITE sends INVITE to 5. INVITE Contact: A Inbound Proxy Contact: A consults Location Outbound SDP A Inbound Outbound SDP A Inbound Server. Proxy Server Proxy Server Server. Proxy Server Proxy Server 6. 100 Trying 6. 100 Trying 6. Inbound Proxy sends 8. Location Server 1. INVITE 1. INVITE responds with “Not Contact: A 2. 100 Trying 100 Trying Contact: A 2. 100 Trying SDP A response. SDP A Signed In.”
User Agent A User Agent B User Agent A User Agent B (Not Signed In) (Not Signed In)
59 60 SIP Call Setup Attempt Scenario SIP Call Setup Attempt Scenario
DNS Server Location DNS Server Location Server Server
3. DNS Query: 4. Response: 7. LS Query: B? 8. Response: 3. DNS Query: 4. Response: 7. LS Query: B? 8. Response: mci.com? 1.2.3.4 Not Signed mci.com? 1.2.3.4 Not Signed In 9. Inbound Proxy sends In 5. INVITE 5. INVITE Contact: A 480 Temporarily Contact: A 11. Outbound Proxy SDP A SDP A Outbound Inbound Unavailable Outbound Inbound forwards 480 response Proxy Server Proxy Server Proxy Server 6. 100 Trying response. Proxy Server 6. 100 Trying to A. 1. INVITE 9. 480 Temporarily Unavailable 1. INVITE 9. 480 Temporarily Unavailable 12. A sends ACK response. Contact: A 10. Outbound Proxy sends Contact: A SDP A 10. ACK ACK response. SDP A 10. ACK 2. 100 Trying 2. 100 Trying 11. 480 Temporarily Unavailable 12. ACK
User Agent A User Agent B User Agent A User Agent B (Not Signed In) (Not Signed In)
61 62
SIP Presence Example SIP Presence Example
DNS Server DNS Server Presence Presence Server Server
3. SUBSCRIBE 3. SUBSCRIBE 4. 200 OK 1. A wants to be informed when B signs on, so 4. Presence Server 2. SUBSCRIBE 2. SUBSCRIBE Outbound Inbound sends a SUBSCRIBE Outbound Inbound authorizes subscription Proxy Server Proxy Server Proxy Server Proxy Server 2. Outbound Proxy 5. 200 OK by sending a 200 OK . forwards to Inbound 5. & 6. 200 OK proxied back to A. 1. SUBSCRIBE Proxy 1. SUBSCRIBE 6. 200 OK 3. Inbound Proxy forwards to B’s Presence Server
User Agent A User Agent B User Agent A User Agent B (Not Signed In) (Not Signed In)
63 64
SIP Presence Example SIP Registration Example
DNS Server DNS Server Presence Location Server Server
7. NOTIFY 12. 200 OK 2. Update database:
User Agent A User Agent B proxied back to B’s User Agent A User Agent B (Not Signed In) Presence Server.
65 66 SIP Registration Example SIP Presence Example
DNS Server DNS Server Location Presence Server Server 13. Presence Server learns 13. NOTIFY 2. Update database:
67 68
SIP Instant Message Scenario SIP Instant Message Scenario
1. A sends an Instant 1. B sends an Instant DNS Server Location Location DNS Server Server Message to B saying Server Message to A saying “Can you talk now?” “Sure.” in a 6. Response: 2. DNS Query: 3. LS Query: B? 4. Response: in a MESSAGE 5. LS Query: A? 3. Response: 5.6.7.8 MESSAGE sent to A’s sip:[email protected] globalipcom.com? sip:[email protected] request. AOR URI. 2. MESSAGE 2., 3. & 4. MESSAGE
SIP Call Setup Attempt Scenario SIP Call Setup Scenario
DNS Server Location DNS Server Location Server Server 1. to 5. A retries 5. LS Query: B 6. Response: INVITE to B which sip:[email protected] routes through two 8. User Agent B alerts B 3. INVITE Proxy Servers. Contact: A 9. 180 Ringing and sends 180 Outbound SDP A Inbound 6. Location Server Outbound Inbound Ringing response. Proxy Server Proxy Server Proxy Server Proxy Server 4. 100 Trying responds with the 9. & 10. 180 Ringing FQDN SIP URI of B’s 1. INVITE is proxied back to A. Contact: A 2. 100 Trying 7. INVITE SIP Phone. 10. 180 Ringing SDP A Contact: A 8. 180 Ringing SDP A 7. Inbound Proxy Server forwards INVITE to B’s SIP Phone.
User Agent A User Agent B User Agent A User Agent B
71 72 SIP Call Setup Scenario SIP Call Setup Scenario
DNS Server Location DNS Server Location Server Server
11. B accepts call and 14. ACK is sent by A to 9. 180 Ringing User Agent B sends 9. 180 Ringing confirm setup call Outbound Inbound Outbound Inbound Proxy Server Proxy Server 200 OK response. Proxy Server Proxy Server bypassing proxies. 12. 200 OK 12. 200 OK Contact: B 12. & 13. 200 OK is Contact: B SDP B SDP B 10. 180 Ringing 13. 200 OK 11. 200 OK proxied back to A. 10. 180 Ringing 13. 200 OK 11. 200 OK Media session begins Contact: B 8. 180 Ringing Contact: B Contact: B 8. 180 Ringing Contact: B between A and B! SDP B SDP B SDP B SDP B
14. ACK
Media (RTP)
User Agent A User Agent B User Agent A User Agent B
73 74
SIP Call Hold (re-INVITE) SIP Call Transfer Scenario
DNS Server Location DNS Server Location Server Server 15. B places A on hold by sending a re- INVITE.
16. A accepts with a 18. B transfers A to C 200 OK. Outbound Inbound Outbound Inbound using REFER. Proxy Server Proxy Server 17. B sends ACK to A. Proxy Server Proxy Server 19. Transfer is accepted by A with 202 No media between A Accepted response. 15. INVITE SDP a=sendonly and B. 20. Notification of 18 REFER Refer-To: sip:[email protected] 16. 200 OK trying transfer is SDP A 19. 202 Accepted sent to B in NOTIFY . 20. NOTIFY <100 Trying> 17. ACK 21. B sends 200 OK User Agent A User Agent B User Agent A 21. 200 OK User Agent B response to NOTIFY
75 76
SIP Call Transfer Scenario SIP Call Transfer Scenario
DNS Server Location DNS Server Location Server Server 8. User Agent C alerts C 1. to 5. A sends new and sends 180 5. LS Query: C? 6. Response: INVITE to C which Ringing response. sip:[email protected] 3. INVITE routes through two 9. & 10. 180 Ringing Contact: A Proxy Servers. Ref-By: B 9. 180 Ringing is proxied back to A. Inbound Inbound Outbound SDP A 6. Location Server Outbound Proxy Server Proxy Server Proxy Server Proxy Server 11. C accepts call and 4. 100 Trying responds with the 12. 200 OK Contact: C 11. 200 OK sends 200 OK 7. INVITE FQDN SIP URI of C’s Contact: C 1. INVITE SDP C Contact: A 13. 200 OK SDP C Contact: A 2. 100 Trying SIP Phone. 10. 180 Ringing response. Ref-By: B Contact: C 8. 180 Ringing Ref-By: B SDP A SDP A 7. Inbound Proxy Server SDP C 12. & 13. 200 OK is 14. ACK User Agent C forwards INVITE to proxied back to A. User Agent C C’s SIP Phone. Media (RTP) 14. ACK is sent by A to confirm setup call. User Agent A User Agent B User Agent A User Agent B Media session between A and C begins. 77 78 SIP Call Transfer Scenario
DNS Server Location Server
20. Notification of successful transfer is sent to B in NOTIFY . SIP Security
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 23. 200 OK User Agent B
79
Authorization TLS and sips:
SIP uses standard HTTP Digest Authentication with minor revisions
Simple Challenge/Response scheme Implementation of TLS is mandatory for proxies, redirect REGISTER -> servers and registrars <- 407 Challenge + nonce The ;transport=tls URI parameter value is deprecated REGISTER + MD-5 hash (pw + nonce) -> <- 200 OK A sips: URI scheme (otherwise identical to the sip: scheme) Password is never sent in the clear, just the MD-5 hash generated indicates that all hops between the requestor and the resource with the password and nonce identified by the URI must be encrypted with TLS. Defeats Man-in-the-middle attacks since source address can’t be If the request is retargeted once the resource is reached, it spoofed or second REGISTER will never arrive must use secured transports. Required by many Internet Telephony Service Providers (ITSPs)
Service Provider supplies Username and password
SIP leverages Digest Authentication features to do this
81 82
S/MIME Attacks : denial of service
Provides end-to-end security of message body and/or headers. Denial of service Certificate identified by end user address Network
Public key can be transported in SIP Protocol (SIP INVITE)
Entire message can be protected by “tunneling” the message in Systems / Applications
an S/MIME body Phone
Availability
Header Fields Requires: power
Alternatives (Business Continuity/Disaster Recovery) ?
Header Fields E911 (laws and technical aspect)
Body GSM
Signature PSTN-to-GSM
83 84 Attacks : fraud Attacks: interception
Call-ID spoofing Interception “Who talks with who” (Network sniffing, Servers (SIP, CDR, etc) LAN User rights takeover Physical access to the LAN ARP attacks
Fake authentication server Unauthenticated devices (phones and servers)
Different layers (MAC address, user, physical port, etc) Where to intercept ?
Where is the user located ?
Networks crossed ?
85 86
Attacks : systems Defense Systems Signaling: SIP Mostly none is hardened by default Secure SIP vs SS7 (physical security) Worms, exploits, Trojan horses Transport: Secure RTP (with MiKEY) Attacks : phone Network: QoS [LLQ] (and rate-limit) Firewall: application level filtering (S)IP phone Phone: signed firmware Startup DHCP, TFTP, etc. Identification: TLS
Physical access Clients by the server Hidden configuration tabs Servers by the client TCP/IP stacks 3P: project, security processes and policies Firmware/configuration
Trojan horse/rootkit
87 88
SIP based Application Interfaces
These include :
JAIN SIP Low level and very complex API SIP Programming 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
90 HTTP Servlets SIP Servlet API
HTTP Java Servlets Widely Used in Web HTTP Servlets Java extension API for SIP servers Application Development War File Similar in spirit to HTTP servlet API Applications Consist of Sets of HTTP Servlets, Each of Which Processes a Server matches incoming messages against local rules in order to Single Web Request in the Application decide which servlet to pass message to
HTTP Servlets Return Web Pages to The API gives full control to servlets to handle SIP messages, e.g. Developer Display has full access to headers and body Deployer HTTP Servlets Can Create “Session Data” proxy or redirect requests
e.g., shopping cart, that spans multiple respond to or reject requests requests forward responses upstream “Container” Manages HTTP Servlet Web Server Lifecycles, Fault Tolerance, Session State initiate requests Servers may choose to provide constrained environment to HTTP Servlets Collected into a War File – Web Archive selected servlets (e.g. using sandbox security model)
91 92
Basic SIP Servlet Model Example: Routing Services
Location of SIP Server and servlet engine: Servlet proxies request to one or more destinations in same Java Virtual Machine - forwards response to caller different process, same host
different hosts: 1:1, 1:n, n:1, n:m 93 94
Example: Servlet as UAS 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 Servlets can reject (screen) calls Lifecycle model allows servlets to
Can accept and set up media streams maintain state, e.g. database connections
manage timers Access to wide range of APIs
95 96 An Example: RejectServlet Relationship to JAIN SIP import org.ietf.sip.*; JAIN SIP is a generic, low-level public class RejectServlet extends SipServletAdapter { interface for accessing SIP protected int statusCode, reasonPhrase; services
public void init(ServletConfig config) { Can be used in Servlet super.init(config); SIP Servlet API Servlet Clients try { statusCode = Integer.parseInt(getInitParameter("status-code")); Servers SIP Servlet reasonPhrase = getInitParameter("reason-phrase"); Gateways } catch (Exception _) { Container statusCode = SC_INTERNAL_SERVER_ERROR; Focuses purely on the protocol JAIN SIP } Complete access to SIP } capabilities public boolean doInvite(SipRequest req) { SIP Protocol SipResponse res = req.createResponse(); Supports transactions only res.setStatus(statusCode, reasonPhrase); res.send(); SIP Servlet Container is a return true; particular application of JAIN } SIP }
97 98
Relationship to JAIN SIP SIP CGI
Servlets focus on high Hide many parts of JAIN SIP Almost identical to HTTP CGI volume carrier grade servers Direct access to many Add significant, non-SIP headers is not provided Language independent ( Perl, Tcl, C, C++, ... )
protocol functions Write access to most Any binary may be executed as a separate program Lifecycle management everything is often Domain objects restricted Suitable for services that contains substantial web content Context and configuration Servlets should be defined to Deployment descriptors allow a SIP container to be Passes message parameters through environmental variables to Archive files built using JAIN SIP a separate program. Synchronization primitives SIP Objects in Servlet API More flexible but more risky Security defined with interfaces that Add significant SIP protocol match JAIN SIP signatures Feb. 1, 2001: RFC 3050 (Common Gateway Interface for SIP) functions Cannot directly expose JAIN Construction of requests SIP objects, though published and responses from domain objects
99 100
Applications in the Component Architecture
SIP Applications
• Announcements • IVR • Voice mail • Auto-attendant • Conferencing
102 The Application Server Component Architecture for SIP SIP Control Models Why Decompose Decoupling between components Scale: Linear increase of Separation of Business: Any resources with number of users. outsourcing and reseller models Sharing of Resources: Many-to- Rapid Development: All functions Centralized: 3 rd party call control many interaction allows each can be developed and procured server to be shared at any point in independently time. Better Interoperability: Minimal Expertise: Complex services information exchange required, require specialization of the basically the URIs only. development. Flexibility: Placement of functions Independent Upgrades: Easy can be optimized. deployment of new features. Peer-to-peer: REFER and Replace Reliability: Failed servers can be Drawbacks backed up by others across the net
Security becomes more complex …is the opposite of the central control, such as in the PBX or of the master-slave model of Architectural discipline is required softswitches using MGCP, MEGACO/H.248.
Ref:
3rd Party Call Control: Basic Example of 3pcc: Click-to-Dial Call Setup B A
Controller A B Call Teardown User PC User SIP Phone Controller Agent Workstation HTTP POST INVITE no SDP No media HTTP 200 OK 200 SDP A1 Media info Controller A B 1. User INVITE no media from A clicks to dial ACK (SDP held) RTP 2. Controller INVITEs A without 200 no media INVITE no SDP BYE from A SDP and holds SDP from A ACK 183 SDP B 200 OK INVITE no SDP Media info from B 3. Controller INVITEs user B without re-INVITE SDP B’ B info to A BYE from CTRL SDP and holds SDP from user B 200 w. SDP INVITE SDP U1’ 200 SDP A2 200 OK 4. Controller INVITEs agent A A2 info to B with SDP from user B and gets 200 SDP A ACK SDP A2’ new SDP from agent A ACK SDP A ACK 5. Controller ACKs to user B with ACK with SDP from new SDP from A RTP Ref: draft-ietf-sipping-3pcc-03.txt RTP 6. User B talks to agent A 105 Ref: draft-ietf-sipping-3pcc-03.txt 106
Mid-Call Announcement for a Pre-Paid Call Voice Portal Service
Prepaid User Controller Media Server Called Party
(0) RTP – call in progress (1) INVITE SDP c=0 CALLER CONTROLLER VoiceXML Service 1 INVITE (2) 200 answer 1 Timeout: “Disconnect” the (3) ACK called party 2 INVITE (4) INVITE no SDP 3 200 OK 1 - Controller first (5) 200 offer 2 connects caller to (6) INVITE offer 2 4 183 Calling party is IVR server 5 ACK connected to (7) 200 offer 2 media server to (8) ACK offer 2 MEDIA 2 - IVR input from add amount. (9) ACK Welcome! Please speak your ID caller is transmitted (10) RTP 6 HTTP GET to controller using Update the My ID is 12345 12345, is this correct? 7 HTTP 200 OK the HTTP side amount and (11) BYE Yes channel. New credit card. Disconnect the MEDIA instructions to the media server (12) 200 OK IVR are sent by the How can we help? 8 HTTP GET controller. (13) INVITE no SDP “Reconnect” the Would like to Add High Speed 9 HTTP 200 OK Internet access to my service (14) 200 offer 3 called party (15) INVITE offer 3’ MEDIA 3 - IVR is disconnected Thank you! We will transfer you to 10 BYE and the call setup (16) 200 answer 3’ new installations of High Speed proceeds based on (17) ACK answer 3’ Internet service to schedule an 11 200 OK caller input to the IVR (18) ACK appointment. One moment please… server (19) RTP – call continues 12 INVITE
Ref: draft-ietf-sipping-3pcc-03.txt 107 108 DTMF Enabled Hold Service (or other mid-call features using DTMF) SIP Control Models
CALLER Controller DTMF Collector CALLED 1 INVITE 1 - The controller calls 2 - SDP from DTMF 2 INVITE the DTMF collector rd collector in step 3 is sent first to get the SDP Centralized: 3 party call control 3pcc to caller in re-INVITE in 3 200 OK connection data. setup for step 11. A second media 4 ACK stream is established in DTMF step 14 from caller to 5 INVITE DTMF collector. 6 200 OK 7 200 OK 8 ACK 9 SIP ACK 10 RTP audio 11 INVITE SDP-DTMF payload, Peer-to-peer: REFER and Replace Media 12 200 OK RFC 2833, send only from user 13 ACK 14 RTP DTMF digits to 3 - DTMF digits collected 15 HTTP GET by the DTMF collector controller are sent to the controller for hold 16 HTTP OK via HTTP in the GET 17 INV request 4- Put callee on hold 18 200 OK
The REFER Method The SIP Replaces Header
REFER is a SIP extension that requests the recipient Message 1 to REFER to a resource provided in the request. REFER sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP agenta.atlanta.com;branch=z9hG4bK2293940223 Alice Alice To:
Operator to help desk transfer with Replaces header SIP Telephony Call Features - Primitives
Message 1: Operator -> Call Center Using the SIP Multiparty Call Control INVITE sip:[email protected] SIP/2.0 To:
Announcement from SIP device Proxy announcement in the network [email protected] [email protected] SIP phone with (1) INVITE “do not disturb” (2) 486 Busy a calls b that is busy PSTN SIP Proxy & Media (3) ACK GWY Controller Server UAC UAS INVITE (4) SUBSCRIBE: Event: dialog INVITE INVITE (5) 200 OK 100 Trying Callback state doc1 (6) NOTIFY doc1 a subscribes to b for 183 Session Progress 183 Session Progress* (7) 200 OK automatic callback
Use of URIs Examples of Naming: Announcement Server Naming Users SIP Request URI’s: Address of Record Contacts User preferences in Contacts: sip:[email protected]; \ ======• from who play=“http://prompts.carrier.net/audio/allcircuitsbusy.g.711;” sip:[email protected] sip:[email protected]:5060 • if sip:[email protected] • where \early=yes sip:[email protected] • when to route incoming calls sip:[email protected]; \ Naming Resources play=“file://fileserver.carrier.net/gemini/yourHoroscope.wav” Examples of URLs that invoke VoiceXML dialogs are: The service provider can choose specific URI naming rules or use mnemonic naming strings, but the application should accept any names sip:dialog.vxml.http%3a//dialogs.server.com/[email protected] as shown in RFC 3087.
Ref: draft-burger-sipping-netann-05.txt sip:[email protected] From where to fetch the script
117 118
Instant Message to Transfer a Call Example: Attended Call Transfer continued A B C User B User C (1) INVITE User A INVITE (hold) MESSAGE: sip:[email protected] User A User B User C 180 Ringing (2) 200 OK Via: SIP/2.0/UDP pc22.foo.com INVITE 200 OK User A calls User B. From: sip:[email protected] ACK (3) ACK User B puts User A on 180 Ringing REFER Refer-To: C To: sip:[email protected] hold then calls User C to 200 OK 202 Accepted (4) RTP MEDIA announce transfer, then Call-ID:[email protected] NOTIFY (5) MESSAGE places C on hold. ACK 200 OK CSeq: 99 MESSAGE User B transfers User A RTP (6) 200 OK to User C which INVITE Replaces: B Max-Forward: 70 INVITE (hold) (7) INVITE w. Replaces replaces the session 200 OK Content-Type: text/html between B and C. 200 OK Content-Length: … C then disconnects ACK (8) 200 OK ACK (no RTP) session with B. RTP A reports success of INVITE (9) ACK transfer to B, who NOTIFY
180 Ringing then disconnects with A. BYE (10) RTP MEDIA Hi Jack! Would you like to take this 200 OK call? 200 OK ACK (11) BYE Thanks, Bob 200 OK RTP <\body> BYE (12) 200 OK <\html> Ref:Alice Focus Bob Carol Caller is leaving a RTP RTP voice message 4 Called party Alice adds Bob into the conference 1 PSTN or does not answer REFER Refer-To: Conf-ID F1 mobile call 202 Accepted F2 3 Call is forked to phone SIP NOTIFY NOTIFY (Trying) F3 and to UM server 3 MSG Waiting 200 OK F4 VoIP Gateway SIP Server INVITE sip:Conf-ID F5 2 180 Ringing F5 200 OK Contact:Conf-ID; isfocus F7 3 6 ACK F8 e-mail notification UM Server RTP 5 Message NOTIFY (OK) F9 Message store takes Web retrieval and 200 OK F10 call after 10s retrieval by playback using RTSP NOTIFY F11 voice 200 OK F12 SUBSCRIBE sip:Conf-ID F13 200 OK F14 Legend: NOTIFY F15 Deposit voice mail Unified Message Store 200 OK F16 Retrieve voice mail via PSTN or e-mail/web Reference: draft-ietf-sipping-cc-conferencing-01 121 122
Communicate with anyone across the Internet IETF Approaches to NAT/Firewall Traversal Scenario Solutions ALG External B2BUAWM Hosted 'IP Centrex' Outsourced MIDCOM Outsourced STUN or TURN SIP ALG Cooperative Enterprise SIP Deployment Internal B2BUAWM Set DMZ host to phone IP address Residence/SOHO with NAT STUN in client NAT in DSL/Cable ISP STUN agent in home B2BUA SIP ALG Symmetric NAT in DSL/Cable ISP TURN (media routing) Uncooperative Enterprise STUN in client
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-00.txt
UPnP Approach to NAT/FW Traversal Legend Designed for Residence/SOHO ALG: Application level gateway Consistent with e2e control B2BUA: Back-to-back user agent B2BUAWM: Back-to-back user agent w. media STUN: Simple Traversal of UDP through NAT UPnP: Universal Plug and Play http://upnp.org/resources/whitepapers.asp TURN: Traversal Using Relay NAT 124
The B2BUA Dilemma and Challenges UPnP Network Example with SIP UAs …shows market penetration of ‘simple’ devices… Back-to-back user agents (B2BUA) perform useful functions, but Wireless, SIP enabled B2BUA contradict the e2e principle (IETF SIP/SIPPING mailing lists) and UPnP computers breaks the e2e security between users. All media streams need to pass the B2BUA: Precautions are required Keep-alive traffic load. UPnP GWY FW/NAT Compromises: Wi-Fi 10/100 4 port E-switch Maintain transparency Full end user control Provide CALEA
Note: *
snom UPnP SIP phones * PDA SIP phones are not yet UPnP enabled
125 126 Types of NATs Full Cone NAT
Type Description Solution Private Public
Constant mapping between private IP address and M Full Cone NAT STUN public IP address
Constant mapping, but an outgoing packet is needed to Restricted NAT STUN A,b open incoming path X,y P Different public IP address mapping is used based on Symmetric NAT TURN destination IP address Full Cone NAT S Keep-alive packets needed to maintain bindings TCP can be used if connection is reused rport parameter in
Restricted Cone NAT Port Restricted Cone NAT
Private Public Private Public M M,n X P,q P,q A,b A,b X X,y X P,r X,y X P,r
Restricted Restricted Cone S Cone S NAT NAT
Restricts at (A,b) only based on Public IP address, Restricts at (A,b) based on Public IP address and not Public port #. port number Therefore, if (X,y) sends to (P,q); (P,r) can send Therefore, if (X,y) sends to (P,q); (P,r) can’t send back to (A,b) back to (A,b)
129 130
Symmetric NAT SIP Signaling Issues
Public Private Public Private SIP Private M,n Proxy C,d SIP P,q Signaling A,b X SIP Phone P,r SIP Phone X,y X Firewall Firewall Restricted Cone S 1) SIP Proxy does not communicate back to NAT SIP client on NAT’ed channel Restricts at (A,b) based on Public IP address and port number 2) Pinhole in Firewall/NAT will timeout on Therefore, if (X,y) sends to (P,q); (P,r) can’t send inactivity. Typically less than 1 minute. back to (A,b) • If this occurs, client can’t receive incoming calls Creates a new instance (C,d) for each unique public IP address that it sends to
131 132 Media Traversal Issues Application Level Gateway Solution
Public Private Private SIP Firewall/NAT is SIP aware, and modifies messages Proxy appropriately
RTP/RTCP Media Application Level Gateways (ALG) have serious SIP Phone SIP Phone Limitations which include scalability and speed to Firewall/NAT Firewall/NAT deploy new applications 1) IP address & port sent in SIP INVITE/200 OK (SDP) is Requires an upgrade to the installed base of Firewall Private, and not globally routable. and NATs 2) Media must be initiated in Private -> Public direction 3) RTCP (port +1) fails through Firewall with NAPT function 4) Pinhole in Firewall/NAT timeout on inactivity. Typically less than 1 minute.
133 134
STUN Solution TURN Solution TURN Private Public Private O,p Public Server M,n STUN [A,b] STUN A,b [O,p] O,p Client Server TURN A,b S,t Client S,t M,n X,y X,y NAT NAT IETF RFC 3489 Protocol for determining public IP address allocated by NAT IETF draft “draft-rosenberg-midcom-turn-06” Does not work with ‘Symmetric’ NAT used by most corporations Protocol for allowing a client behind a NAT to receive incoming For non-symmetric NATs, does not require a NAT upgrade media over UDP Does not work if both clients are behind same NAT Solves worst case ‘Symmetric’ NAT case Not an end-to-end solution, ie all clients need STUN support Needs ‘big hardware’ to avoid adding latency SIP clients now coming out with STUN support Not an end-to-end solution, ie all clients need STUN/TURN support Adds complexity to SIP clients and proxies Few SIP clients support TURN today (complexity)
135 136
ICE Solution Session Border Controller Solution
SIP Proxy Interactive Connectivity Establishment (ICE) SIP IETF draft “draft-ietf-mmusic-ice-03” Signaling Allows peers to discover NAT types and client capabilities SIP Phone RTP/RTCP Media SIP Phone Firewall Firewall Will utilize existing protocols such as STUN and TURN SBC Adds significant complexity to a SIP client Signaling Solution SBC has ability to communicate to SIP client over NAT’ed address
Limited client support SBC sets client re-Register interval & handles SIP traffic (best refresh method) Works with all types of NATs Media Traversal Solution
Requires each peer to support a traversal method SBC allocation of IP address & port in public network; SBC modification of SDP on behalf of client;
SIP client codec synchronization primes the Firewall/NAT
SBC handling of RTCP channel mapping
137 138 Global SIP/IMS deployment needs IPv6 Multi-access IMS
Introduction of SIP-based peer-to-peer services is an important step after current client-server based services. S-CSCF IMS IP Multimedia Subsystem (IMS) is a service infrastructure based P-CSCF (IPv6) on the use of Session Initiation Protocol (SIP). 3GPP GGSN 3GPP Release 5 and 6 specifications access P-CSCF nw P-CSCF 3GPP2 specifications
In order to make peer-to-peer services work between different PDSN 3GPP2 operators' networks, IPv6 is needed - peer-to-peer services work access WLAN nw well only with public IP addresses. access nw Small scale IMS deployment / piloting can be started with IPv4. Common IP IPv6 is vital for wider scale, global IMS deployment. version (=IPv6) makes the multi- SIP access case much easier SIP Signaling for building up the session User IP data
139 140