DAY 1 #AFTERNOON. SIP Fundamentals CENTRE FOR NETWORK RESEARCH. Department of Computer Engineering Prince of Songkla University

Transcription

1 DAY 1 #AFTERNOON SIP Fundamentals CENTRE FOR NETWORK RESEARCH Department of Computer Engineering Prince of Songkla University

2 2 Acknowledgements ศ นย เทคโนโลย อ เล กทรอน กส และ คอมพ วเตอร แห งชาต (NECTEC) สถาบ นว จ ยและพ ฒนาอ ตสาหกรรม โทรคมนาคม (TRIDI) คณะกรรมการก จการ โทรคมนาคมแห งชาต (NTC)

3 SIP Tutorial Introduction to SIP Original Slides by Alan Johnston and Henry Sinnreich, MCI

4 Contents SIP Overview SIP Components SIP in detail SIP Call Flow Scenarios SIP Security SIP Applications NAT & Firewall Original Slides by Alan Johnston and Henry Sinnreich, MCI 4

5 SIP Overview

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

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

8 Internet Multimedia Protocols RTSP 8

9 A Short History of SIP Internet Engineering Task Force (IETF) protocol Inventors: M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg Became Proposed Standard and RFC 2543 in March 1999 in MMUSIC WG. Separate SIP WG established in September 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

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

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

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

13 SIP Uniform Resource Indicators (URIs) Same form as addresses: Two URI schemes: is a SIP URI Most common form introduced in RFC 2543 sips:henry@siptest.mci.com is a Secure SIP URI New scheme introduced in RFC 3261 Requires TLS over TCP as transport for security Two types of SIP URIs: Address of Record (AOR) (identifies a user) sip:henry@mci.com (Needs DNS SRV records to locate SIP Servers for mci.com domain) Contact (identifies a device and is usually a Fully Qualified Domain Name, FQDN) sip:henry@ or sip:henry@cube43.lab.mci.com (Which needs no resolution for routing) 13

14 SIP Components

15 SIP Trapezoid DNS Server Location Server DNS Outbound Proxy Server SIP Inbound Proxy Server SIP SIP SIP Media (RTP) User Agent A User Agent B 15

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

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

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

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

20 SIP Registrar, 1 SIP server that can receive and process REGISTER requests A user has an account created which allows them to REGISTER contacts with a particular server The account specifies a SIP Address of Record (AOR) 20

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

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

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

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

25 SIP Redirect Server Receives a request and returns a redirection response (3xx) Contact header in response indicates where request should be retried Similar to database query All Server types are logical NOT Physical 25

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

27 SIP in detail

28 SIP Request Methods, 1 SIP used for Peer-to-Peer Communication though it uses a Client-Server model Requests are called methods Six methods are defined in base RFC 3261: INVITE ACK OPTIONS BYE CANCEL REGISTER 28

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

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

31 SIP Methods - INVITE, 2 An INVITE during an existing session (dialogue) is called a re-invite re-invites can be used to Place calls on or remove calls from hold Change session parameters and codecs The SIP UPDATE method is the proposed replacement for this technique 31

32 SIP Methods - ACK ACK completes the three way session setup handshake (INVITE, final response, ACK) Only used for INVITE If INVITE did not contain media information ACK must contain the media information 32

33 SIP Methods - OPTIONS OPTIONS requests the capabilities of another User Agent Response lists supported methods, extensions, codecs, etc. User Agent responds to OPTIONS the same as if an INVITE (e.g. if Busy, returns 486 Busy Here) Very basic presence information 33

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

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

36 SIP Request URI The Request-URI indicates the destination address of the request Proxies and other servers route requests based on Request-URI. The Request-URI is modified by proxies as the address is resolved. INVITE SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bk776asdhds Max-Forwards: 70 To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Request-URI 36

37 SIP From and To Tags Tags are pseudo-random numbers inserted in To or From headers to uniquely identify a call leg INVITE request From header contains a tag Any User Agent or Server generating a response adds a tag to the To header in the response To: sip:john@company.com;tag=

38 SIP Method - INFO Used to transport mid-call signaling information Only one pending INFO at a time Typical use - PSTN signaling message carried as MIME attachment E.g. ISDN User-to-User information Defined in RFC

39 SIP Method - REFER Indicates that recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request Typical Use: Call Transfer features Allowed outside an established dialogue 39

40 SIP Method - PRACK Provisional Response ACKnowlegement Used to acknowledge receipt of provisional response 183 Session Progress Does not apply to 100 Trying responses Only provisional responses may be sent reliably and acknowledged with PRACK If no PRACK sent, response retransmitted Defined in RFC

41 SIP Methods SUBSCRIBE and NOTIFY SUBSCRIBE requests notification of when a particular event occurs Use Expires=0 to unsubscribe A NOTIFY message is sent to indicate the event status Sample Applications Presence Message waiting indication for voic Defined in RFC

42 SIP Method - MESSAGE Extension to SIP for Instant Messaging (IM) MESSAGE requests carry the content in the form of MIME body parts use the standard MIME headers to identify the content 42

43 SIP Responses SIP Requests generate Responses with codes borrowed from HTTP Classes: 1xx Informational 2xx Final 3xx Redirection 4xx Client Error 5xx Server Error 6xx Global Failure Response example 404 Not Found 43

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

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

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

47 SIP Message Details INVITE SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg From: E. Schroedinger Call-ID: CSeq: 1 INVITE Contact: sip:schroed5244@ Content-Type: application/sdp Content-Length: 159 First line of a SIP message is Start Line which contains: the method or Request type: INVITE (session setup request). the Request-URI which indicates who the request is for sip:wh@ 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 47

48 SIP Headers SIP Requests and Responses contain Headers (similar to headers) Required Headers To From Via Call-ID CSeq Max-Forwards Optional Headers: Subject, Date, Authentication (and many others) 48

49 SIP Message Details INVITE SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg From: E. Schroedinger Call-ID: CSeq: 1 INVITE Contact: sip:schroed5244@ Content-Type: application/sdp Content-Length: 159 Via headers show the path the request has taken The bottom Via header is inserted by the User Agent which initiated the request Additional Via headers are inserted by each proxy in the path The Via headers are used to route responses back the same way Required branch parameter contains a cookie (z9hg4bk) then a transaction-id. 49

50 SIP Message Details INVITE SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg From: E. Schroedinger Call-ID: CSeq: 1 INVITE Contact: sip:schroed5244@ Content-Type: application/sdp Content-Length: 159 Max-Forwards is a count decremented by each proxy that forwards the request. When count goes to zero, request is discarded and 483 Too Many Hops response is sent. Used for stateless loop detection. 50

51 SIP Message Details INVITE SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg From: E. Schroedinger Call-ID: CSeq: 1 INVITE Contact: sip:schroed5244@ Content-Type: application/sdp Content-Length: 159 Dialog (formerly called call leg) information is in headers: To tag, From tag, and Call-ID (Note: Not URIs) To and From URIs usually contain AOR URIs. All requests and responses in this call will use this same Dialog information. Call-ID is unique identifier usually composed of pseudo-random hostname or IP Address 51

52 SIP Message Details INVITE SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg From: E. Schroedinger Call-ID: CSeq: 1 INVITE Contact: sip:schroed5244@ Content-Type: application/sdp Content-Length: 159 CSeq Command Sequence Number Initialized at start of call (1 in this example) Incremented for each subsequent request Used to distinguish a retransmission from a new request Also contains the request type (method) - INVITE 52

53 SIP Message Details INVITE SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg From: E. Schroedinger Call-ID: CSeq: 1 INVITE Contact: sip:schroed5244@ Content-Type: application/sdp Content-Length: 159 Contact header contains a SIP FQDN URI for direct communication between User Agents If Proxies do not Record-Route, they can be bypassed If Record-Route is present in 200 OK, then a Route header is present in all future requests in this dialog. Contact header is also present in 200 OK response 53

54 SIP Message Details INVITE SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg From: E. Schroedinger Call-ID: CSeq: 1 INVITE Contact: sip:schroed5244@ Content-Type: application/sdp Content-Length: 159 Content-Type indicates the type of message body attachment (others could be text/plain, application/cpl+xml, etc.) Content-Length indicates the octet (byte) count of the message body. Message body is separated from SIP header fields by a blank line (CRLF). 54

55 SDP Message Body Details v=0 o=tesla IN IP4 lab.high-voltage.org s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Version number (ignored by SIP) Origin (only version used by SIP ) Subject (ignored by SIP) Connection Data (IP Address for media ) Time (ignored by SIP) Media (type - audio, port , RTP/AVP Profile - 0) Attribute (profile - 0, codec - PCMU, sampling rate 8000 Hz) 55

56 SIP Response Details SIP/ OK Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hg4bk Via: SIP/2.0/UDP :5060;branch=z9hG4bK45a35h76 To: Heisenberg From: E. Schroedinger Call-ID: CSeq: 1 INVITE Contact: sip:wh@ Content-Type: application/sdp Content-Length: 173 v=0 o=heisenberg IN IP s=sip Call c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Via, To, From, Call-ID, & CSeq are all copied from request. To now has a tag inserted by UAS Contact and Message Body contain UAS information. 56

57 SIP Call Flow Scenarios As followings

58 Call Attempt - Unsuccessful Presence Subscription Registration Presence Notification Instant Message Exchange Call Setup Successful Call Hold Call Transfer SIP Call Flow Scenarios 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. 58

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

76 SIP Call Setup Scenario DNS Server Location Server Outbound Proxy Server Ringing Ringing OK Contact: B SDP B OK Contact: B Ringing SDP B 14. ACK Media (RTP) Inbound Proxy Server OK Contact: B SDP B 14. ACK is sent by A to confirm setup call bypassing proxies. Media session begins between A and B! User Agent A User Agent B 76

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

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

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

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

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

82 SIP Security

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

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

85 S/MIME Provides end-to-end security of message body and/or headers. Certificate identified by end user address Public key can be transported in SIP Entire message can be protected by tunneling the message in an S/MIME body Header Fields Header Fields Body Signature 85

86 Signaling: SIP Defense Secure SIP vs SS7 (physical security) Transport: Secure RTP Network: QoS [LLQ] (and rate-limit) Firewall: application level filtering Phone: signed firmware Identification: TLS Clients by the server Servers by the client 86

87 SIP Applications

88 Applications in the Component Architecture Announcements IVR Voice mail Auto-attendant Conferencing 9/22/2003 SIP Applications - a 88

89 The Application Server Component Architecture for SIP Why Decompose Scale: Linear increase of resources with number of users. Sharing of Resources: Many-tomany interaction allows each server to be shared at any point in time. Expertise: Complex services require specialization of the development. Independent Upgrades: Easy deployment of new features. Drawbacks Security becomes more complex Architectural discipline is required Decoupling between components Separation of Business: Any outsourcing and reseller models Rapid Development: All functions can be developed and procured independently Better Interoperability: Minimal information exchange required, basically the URIs only. Flexibility: Placement of functions can be optimized. Reliability: Failed servers can be backed up by others across the net is the opposite of the central control, such as in the PBX or of the master-slave model of softswitches using MGCP, MEGACO/H.248. Ref: <draft-rosenberg-sip-app-components-01.txt> 9/22/2003 SIP Applications - a 89

90 Call Setup 3 rd Party Call Control: Basic Controller A B INVITE no SDP 200 SDP A1 ACK (SDP held) No media Media info from A INVITE no SDP Call Teardown Controller A B RTP BYE from A re-invite SDP B 183 SDP B Media info from B B info to A 200 OK BYE from CTRL 200 SDP A2 A2 info to B 200 OK ACK SDP A2 ACK RTP Ref: draft-ietf-sipping-3pcc-03.txt 9/22/2003 SIP Applications - a 90

91 Example of 3pcc: Click-to-Dial B A User PC User SIP Phone Controller Agent Workstation HTTP POST 1. User clicks to dial HTTP 200 OK INVITE no media 2. Controller INVITEs A without 200 no media SDP and holds SDP from A ACK 3. Controller INVITEs user B without INVITE no SDP SDP and holds SDP from user B 200 w. SDP 4. Controller INVITEs agent A INVITE SDP U1 with SDP from user B and gets new SDP from agent A 5. Controller ACKs to user B with with SDP from new SDP from A 6. User B talks to agent A ACK SDP A RTP 200 SDP A ACK 9/22/2003 Ref: draft-ietf-sipping-3pcc-03.txt SIP Applications - a 91

92 Mid-Call Announcement for a Pre-Paid Call Prepaid User Controller Media Server Called Party (0) RTP call in progress (4) INVITE no SDP (1) INVITE SDP c=0 (3) ACK (2) 200 answer 1 Timeout: Disconnect the called party Calling party is connected to media server to add amount. (5) 200 offer 2 (8) ACK offer 2 (6) INVITE offer 2 (7) 200 offer 2 (9) ACK Update the amount and credit card. (10) RTP Disconnect the media server (11) BYE (12) 200 OK (15) INVITE offer 3 (13) INVITE no SDP (14) 200 offer 3 Reconnect the called party (16) 200 answer 3 (18) ACK (17) ACK answer 3 (19) RTP call continues Ref: 9/22/2003 draft-ietf-sipping-3pcc-03.txt SIP Applications - a 92

93 DTMF Enabled Hold Service (or other mid-call features using DTMF) CALLER Controller DTMF Collector CALLED 3pcc setup for DTMF 1 INVITE 2 - SDP from DTMF collector in step 3 is sent to caller in re-invite in step 11. A second media stream is established in step 14 from caller to DTMF collector. 2 INVITE OK 4 ACK 1 - The controller calls the DTMF collector first to get the SDP connection data. 5 INVITE OK OK 8 ACK 9 SIP ACK 10 RTP audio Media from user to controller for hold 11 INVITE OK 13 ACK 4- Put callee on hold <draft-rosenberg-sip-app-components-01.txt> SDP-DTMF payload, RFC 2833, send only 14 RTP DTMF digits 15 HTTP GET 16 HTTP OK 17 INV OK 19 SIP ACK 3 - DTMF digits collected by the DTMF collector are sent to the controller via HTTP in the GET request SDP w. address 0 9/22/2003 SIP Applications - a 93

94 Early Media Applications Announcement from SIP device Proxy announcement in the network SIP phone with do not disturb UAC INVITE UAS PSTN GWY INVITE 100 Trying SIP Proxy & Controller INVITE Media Server 183 Session Progress 183 Session Progress* RTP 486 Busy Here 183 Session Progress Play announcement (RTP) 486 Busy Here* 486 Busy Here* I am not available right now, please try later Ref: <draft-burger-sipping-netann-05.txt> <draft-burger-sipping-msuri-01.txt> * For SIP-ISUP mapping 9/22/2003 SIP Applications - a 94

95 NAT and Firewall Traversal

96 Communicate with anyone across the Internet IETF Approaches to NAT/Firewall Traversal Scenario Hosted 'IP Centrex' Cooperative Enterprise Residence/SOHO with NAT NAT in DSL/Cable ISP Symmetric NAT in DSL/Cable ISP Uncooperative Enterprise Solutions ALG External B2BUAWM Outsourced MIDCOM Outsourced STUN or TURN SIP ALG Internal B2BUAWM Set DMZ host to phone IP address STUN in client STUN agent in home B2BUA SIP ALG TURN (media routing) STUN in client UPnP Approach to NAT/FW Traversal Designed for Residence/SOHO Consistent with e2e control Legend ALG: Application level gateway 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 TURN: Traversal Using Relay NAT 96

97 Types of NATs Type Description Solution Full Cone NAT Constant mapping between private IP address and public IP address STUN Restricted NAT Constant mapping, but an outgoing packet is needed to open incoming path STUN Symmetric NAT Different public IP address mapping is used based on destination IP address TURN Keep-alive packets needed to maintain bindings TCP can be used if connection is reused rport parameter in <draft-ietf-sip-symmetric-response-01> RTCP can be lost unless a=rtcp attribute to specify new port (and/or IP address) <draft-ietf-mmusic-sdp4nat-05> ICE is proposal to unify approaches and works in every case <draft-rosenberg-sipping-ice-01> 97

98 Full Cone NAT Private Public M X,y A,b P Full Cone NAT S No restrictions on IP traffic arriving at A,b 98

99 Restricted Cone NAT Private X,y A,b Public X X M P,q P,r Restricted Cone NAT S Restricts at (A,b) only based on Public IP address, not Public port #. Therefore, if (X,y) sends to (P,q); (P,r) can send back to (A,b) 99

100 Port Restricted Cone NAT Private Public M,n X,y A,b X X P,q P,r Restricted Cone NAT S Restricts at (A,b) based on Public IP address and port number Therefore, if (X,y) sends to (P,q); (P,r) can t send back to (A,b) 100

101 Symmetric NAT Private X,y Public C,d A,b X X M,n P,q P,r Restricted Cone NAT Restricts at (A,b) based on Public IP address and port number Therefore, if (X,y) sends to (P,q); (P,r) can t send back to (A,b) Creates a new instance (C,d) for each unique public IP address that it sends to S 101

102 Summary of Firewall/NAT Functions Private Public X,y A,b S,t Firewall/NAT IP must be initiated in Private Public direction; Pinholes have an inactivity timeout, typically 60 seconds (bidirectional activity is common) Only (S,t) can send back on (A,b) A new external NAT address (A,b) is created for each external address (S,t) that (X,y) sends to 102

103 SIP Signaling Issues Private Public SIP Proxy Private SIP Signaling SIP Phone Firewall Firewall SIP Phone 1) SIP Proxy does not communicate back to SIP client on NAT ed channel 2) Pinhole in Firewall/NAT will timeout on inactivity. Typically less than 1 minute. If this occurs, client can t receive incoming calls 103

104 Media Traversal Issues Private Public SIP Proxy Private SIP Phone RTP/RTCP Media SIP Phone Firewall/NAT Firewall/NAT 1) IP address & port sent in SIP INVITE/200 OK (SDP) is Private, and not globally routable. 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. 104

105 Application Level Gateway Solution Firewall/NAT is SIP aware, and modifies messages appropriately Application Level Gateways (ALG) have serious Limitations which include scalability and speed to deploy new applications Requires an upgrade to the installed base of Firewall and NATs 105

106 IETF MIDCOM Solution Middlebox SIP, H.323, MGCP Signaling Functions Signaling RTP Media Functions Media MIDCOM architecture solves ALG limitations Still requires an upgrade to the installed base of Firewalls and NATs 106

107 STUN Client X,y IETF RFC 3489 STUN Solution Private NAT A,b Public [A,b] Protocol for determining public IP address allocated by NAT Does not work with Symmetric NAT used by most corporations For non-symmetric NATs, does not require a NAT upgrade Does not work if both clients are behind same NAT Not an end-to-end solution, ie all clients need STUN support SIP clients now coming out with STUN support Adds complexity to SIP clients and proxies S,t STUN Server 107

108 TURN Solution Private TURN Client O,p X,y M,n A,b Public [O,p] S,t TURN Server O,p M,n NAT IETF draft draft-rosenberg-midcom-turn-06 Protocol for allowing a client behind a NAT to receive incoming media over UDP Solves worst case Symmetric NAT case Needs big hardware to avoid adding latency Not an end-to-end solution, ie all clients need STUN/TURN support Few SIP clients support TURN today (complexity) 108

109 ICE Solution Interactive Connectivity Establishment (ICE) IETF draft draft-ietf-mmusic-ice-03 Allows peers to discover NAT types and client capabilities Will utilize existing protocols such as STUN and TURN Adds significant complexity to a SIP client Limited client support Works with all types of NATs Requires each peer to support a traversal method 109

110 Session Border Controller Solution SIP Proxy SIP Signaling SIP Phone Firewall RTP/RTCP Media SBC Firewall SIP Phone Signaling Solution SBC has ability to communicate to SIP client over NAT ed address SBC sets client re-register interval & handles SIP traffic (best refresh method) Media Traversal Solution 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 110