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 ()  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 to set up a permanent connection SIP Proxies  High Proxy overhead  query SIP Registrars for routing information  Incoming calls addressed to sip:[email protected]  Endpoint connection must be set up, maintained and torn  now routed by the Proxy to the Contact: header URL down for the duration of the session sip:[email protected]

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  Required Headers From: E. Schroedinger ;tag=312345  To Call-ID: [email protected] CSeq: 1 INVITE  From Contact: sip:[email protected]  Via Content-Type: application/sdp  Call-ID Content-Length: 159  CSeq First line of a SIP message is Start Line which contains:  Max-Forwards  the method or Request type: INVITE ( session setup request).  Optional Headers:

 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 To: Heisenberg From: E. Schroedinger ;tag=312345 From: E. Schroedinger ;tag=312345 Call-ID: [email protected] Call-ID: [email protected] CSeq: 1 INVITE CSeq: 1 INVITE Contact: sip:[email protected] Contact: sip:[email protected] Content-Type: application/sdp Content-Type: application/sdp Content-Length: 159 Content-Length: 159

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 To: Heisenberg From: E. Schroedinger ;tag=312345 From: E. Schroedinger ;tag=312345 Call-ID: [email protected] Call-ID: [email protected] CSeq: 1 INVITE CSeq: 1 INVITE Contact: sip:[email protected] Contact: sip:[email protected] Content-Type: application/sdp Content-Type: application/sdp Content-Length: 159 Content-Length: 159

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 To: Heisenberg From: E. Schroedinger ;tag=312345 From: E. Schroedinger ;tag=312345 Call-ID: [email protected] Call-ID: [email protected] CSeq: 1 INVITE CSeq: 1 INVITE Contact: sip:[email protected] Contact: sip:[email protected] Content-Type: application/sdp Content-Type: application/sdp Content-Length: 159 Content-Length: 159 Contact header contains a SIP FQDN URI for direct Content-Type indicates the type of message body communication between User Agents attachment (others could be text/plain ,  If Proxies do not Record-Route , they can be bypassed application/cpl+xml , etc.)  If Record-Route is present in 200 OK, then a Route Content-Length indicates the octet (byte) count of header is present in all future requests in this dialog. the message body. Contact header is also present in 200 OK response Message body is separated from SIP header fields by a blank line (CRLF). 51 52

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 ; tag=24019385 c=IN IP4 100.101.102.103 From: E. Schroedinger ;tag=312345 t=0 0 Call-ID: [email protected] m=audio 49170 RTP/AVP 0 CSeq: 1 INVITE Contact: sip:[email protected] a=rtpmap:0 PCMU/8000 Content-Type: application/sdp Content-Length: 173  Version number (ignored by SIP) v=0  Origin (only version used by SIP - 28904529 ) o=Heisenberg 2452772446 2452772446 IN IP4 200.201.202.203  Subject (ignored by SIP) s=SIP Call c=IN IP4 200.201.202.203  Connection Data (IP Address for media - 100.101.102.103 ) t=0 0  Time (ignored by SIP) m=audio 56321 RTP/AVP 0 a=rtpmap:0 PCMU/8000  Media (type - audio , port - 49170 , RTP/AVP Profile - 0)  Attribute (profile - 0, codec - PCMU , sampling rate – 8000 Hz ) Via , To , From , Call-ID , & CSeq are all copied from request.  To now has a tag inserted by UAS Contact and Message Body contain UAS information.

53 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: B = [email protected] 7. Presence Server sends 1. B signs on to his SIP 8. NOTIFY NOTIFY containing Phone which sends a REGISTER message Outbound Inbound current presence status Outbound Outbound Proxy Server Proxy Server Proxy Server 11. 200 OK of B (Not Signed In). Proxy Server containing the FQDN 8. and 9. NOTIFY is URI of B’s User Agent. 9. NOTIFY 10. A acknowledges receipt Contact: [email protected] of notification with 200 OK . 11. & 12. 200 OK is

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: 18. 200 OK of B’s new status from B = [email protected] 3. OK 3. Location Server database update is the Location Server and 14. NOTIFY sends a NOTIFY confirmed. Outbound Outbound Outbound Inbound containing new status Proxy Server 4. Registration is confirmed Proxy Server Proxy Server Proxy Server 17. 200 OK of B (Signed In). with a 200 OK 14. & 15. NOTIFY is response. 15. NOTIFY 16. 200 OK proxied back to A. 1. REGISTER 4. 200 OK Contact: [email protected] Contact: [email protected] 16. A acknowledges receipt of notification with 200 OK . 17. & 18. 200 OK is proxied back to User Agent A User Agent B User Agent A User Agent B Presence Server.

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 Outbound Inbound request is proxied, Inbound Outbound queried. Proxy Server Proxy Server Proxy Server Location Server Proxy Server 4. Outbound Proxy 7. 200 OK queried. 9. 200 OK forwards MESSAGE to 1. MESSAGE 7. MESSAGE 8. 200 OK Inbound Server. 8. 200 OK talk now?> 5. & 6. Location Server is B. queried. 6. User Agent B responds 7. Inbound Proxy with 200 OK . forwards to A. 7. & 8. 200 OK is proxied User Agent A User Agent B User Agent A User Agent B 8. User Agent A responds back to A. with 200 OK . 9. & 10. 200 OK is proxied back to B. 69 70

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: 103 104

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 SDP w. address 0 19 SIP ACK 109 110

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: phone 1 phone 2 Bob From: ;tag=193402342 Park a@agentland b@agentland Call-ID: [email protected] RTP CSeq: 93809823 REFER 1. Alice talks to Bob Max-Forwards: 70 Refer-To: (whatever URI) from phone 1 REFER/202 Contact: sip:[email protected] Content-Length: 0 INVITE/200/ACK AB Message 2 2. Alice transfers Bob REFER SIP/2.0 202 Accepted to park RTP 1 Via: SIP/2.0/UDP agenta.atlanta.com;branch=z9hG4bK2293940223 To: ;tag=4992881234 202 From: ;tag=193402342 NOTIFY/200 2 Call-ID: [email protected] Accepted CSeq: 93809823 REFER 3. Phone 1 is notified Contact: sip:[email protected] and says BYE BYE/200 (whatever) Content-Length: 0 Message 3 INVITE w. Replaces NOTIFY NOTIFY sip:[email protected] SIP/2.0 3 Via: SIP/2.0/UDP agentb.atlanta.com;branch=z9hG4bK9922ef992-25 4. Alice retrieves the To: ;tag=193402342 parked call form 200 200 OK From: ;tag=4992881234 BYE/200 4 Call-ID: [email protected] phone 2 CSeq: 1993402 NOTIFY ACK Max-Forwards: 70 MUST: Body of type Event: refer Subscription-State: active;expires=(depends on Refer-To URI) RTP "message/sipfrag" Contact: sip:[email protected] Content-Type: message/sipfrag;version=2.0 Ref: Content-Length: 20 Ref: 111 112

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: From: ; tag=7743 Caller Operator Call Center Call-ID: [email protected] Call Hold Speakerphone paging CSeq: 1 INVITE Intercom INVITE/180/200/ACK Help Desk Contact: Accept-Language: en Call waiting Speed dial “Hello, I am having trouble Automatic callback Message 2: Help Desk -> Operator “OK, I will try it and transfer calling the help desk” SIP/2.0 182 You are 7th in Queue you if it works for me” To: ; tag=6472 Blind transfer Call return Find-me From: ; tag=7743 INVITE Call-ID: [email protected] Agent tries call center and CSeq: 1 INVITE *1 Attended transfer Inbound call screening Whispered call waiting completes transfer Contact: 182 You are caller #7 1 2 Voice message screening REFER/202 Reason phrase, “you are #, Message 3: Customer -> Call Center Consultative transfer Outbound call screening waiting time is…” INVITE sip:[email protected] INVITE with Replaces To: 3 From: ; tag=8983 Conference call Call forwarding Presence-enabled conferencing 182 You are caller #7 Call-ID: [email protected] 4 CSeq: 1 INVITE Contact: In-conference alerts New response code 687 Dialog Terminated Replaces: [email protected];to-tag=7743;from-tag=6472 Call park Message waiting 5 Accept-Language: en ACK Referred-By: Call pick-up Do not disturb Single line extension …time passes… Message 4: Call Center -> Customer 6 SIP/2.0 182 You are 7th in Queue Music on hold Distinctive ring Click-to-dial NOTIFY/200 To: Caller waits in queue From: ; tag=8983 and notifies agent when Call-ID: [email protected] BYE/200 CSeq: 1 INVITE Call monitoring Hotline Prepaid calling 200 OK from call center Contact: 200 OK Voice portal Message 5: Call Center -> Operator Barge-in Auto-answer ACK SIP/2.0 687 Dialog Terminated To: ; tag=6472 From: ; tag=7743 NOTIFY/200 Call-ID: [email protected] CSeq: 1 INVITE draft-ietf-sipping-cc-framework-02.txt Contact: Ref: draft-ietf-sip-replaces-02.txt 113 114 Early Media Applications Use of Presence for Telephony: Automatic Callback

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 183 Session Progress

confirmed b becomes available Play announcement (RTP) (8) NOTIFY doc2 486 Busy Here Callback state doc2 (9) 200 OK 486 Busy Here* (10) INVITE 486 Busy Here* terminated “I am not available right (12) ACK now, please try later…” (13) SUBSCRIBE Expires:0 * For SIP-ISUP mapping Ref: (14) 200 OK 115 Related: draft-sipping-dialog-package-01.txt 116

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: 200 OK 119 120 Example of Unified Messaging SIP Call Control in Conferencing

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 RTCP can be lost unless a=rtcp attribute to specify new port (and/or IP No restrictions on IP traffic arriving at A,b address)

 ICE is proposal to unify approaches and works in every case

 127 128

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