Your SlideShare is downloading. ×
Sip Detailed , Call flows , Architecture descriptions , SIP services , sip security , sip programming
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sip Detailed , Call flows , Architecture descriptions , SIP services , sip security , sip programming

1,053
views

Published on

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

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

Published in: Mobile

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,053
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
137
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • SIP is a key component of the Internet Multimedia Architecture. Other protocols including SDP, RTP, DNS, etc are needed to implement a complete service.
    SIP was designed based on one of the most scalable and deployed Internet protocols Hyper Text Transport Protocol (HTTP) the underlying protocol of the World Wide Web (WWW).
    SIP is about much more than just voice – supports all media.
  • The Internet protocol stack has four layers: application, transport, Internet, and physical/link layer. SIP resides at the application layer and can use a variety of transport layer protocols such as UDP and TCP. Any physical layer can be used including Ethernet, dialup, 802.11 wireless, etc.
  • SIP is a client/server protocol that uses a request/response structure. Requests are called “methods”. Responses have a numerical code and a reason phrase – many are borrowed from HTTP including the common “404 Not Found” response. (Not all HTTP response codes are valid in SIP – only those defined in RFC 3261.)
  • Closely related protocols to SIP include Session Description Protocol (SDP) and Real-time Transport Protocol (RTP). SDP is a text-encoded media description language carried as a message body in a SIP request or response. RTP is used to transport media and identify codec. RTP is always sent end-to-end and bypasses SIP signaling chain.
  • One of the most powerful features of SIP is its use of Uniform Resource Indicators (URIs), also sometimes called Uniform Resource Locators (URLs). SIP can use a variety of URI schemes, but most commonly uses sip, sips, and tel (for telephone numbers). SIP URIs can be either an Address of Record (AOR) or a Contact depending on whether it references a user or a device.
  • The “Trapezoid” is a common SIP inter-domain architecture in which endpoints utilize SIP proxies to communicate. The SIP signaling flows between all the elements, but the media flows only along the bottom of the trapezoid.
  • User Agents (UAs) are the endpoints in a SIP network – they originate and terminate SIP requests and responses. They can be implemented as SIP phones, PC/laptop clients, PDAs, cell phones, or even as a PSTN gateway.
  • SIP proxy servers are the intermediary servers that help UAs establish sessions using SIP. They typically consult databases and perform SIP routing (proxying) on behalf of UAs. They are catagorized based on they type of state information they keep – a stateless proxy keeps no state, a transaction stateful proxy only keeps state on pending transactions, while a call stateful proxy keeps state for the entire duration of a SIP session.
  • Location Servers and DNS servers are two examples of databases often queried by SIP proxies (although DNS is often also queried by UAs). Location Servers are SIP registration databases, built by registrar servers. SIP can utilize DNS queries to resolve URIs using A (Address), SRV (Service), or NAPTR (Naming Authority Pointer Records) resource records.
  • This shows an example SIP message without the SDP message body.
    As SIP is a very polite protocol, a request to establish a session is called an INVITE.
    Since SIP is text-encoded, this is exactly how a captured packet would look “on the wire”.
    The structure of a request is a start line then a list of SIP header fields. The actual order of SIP header fields does not matter (except for the relative ordering of multiple header fields of the same name).
    The start line contains the method type (INVITE), the intended recipient of the request (sip:wh@200.201.202.203) and the SIP version number (2.0) separated by spaces.
  • The next two lines begin the list of SIP header fields which have the general structure Header-Name: value. While method names are conventionally all upper case, SIP header fields are a mixture of upper and lower case and end in a colon.
    The Via header field can appear multiple times in a SIP request or response, and contains a list of the SIP servers which have generated or processed the message. In this example, the bottom Via header field identifies the originating UA while the top Via header field identifies a proxy that has forwarded this request.
    The set of Via header fields are like a “stack” – the set is built as the request is forwarded, then the values are used to route responses back through the same set of proxies, at which time each Via header field is removed from the response as it is routed.
  • The Max-Forwards header field is used to prevent SIP message loops.
    In RFC 2543, loop detection was performed by doing Via header field searches, but this has been deprecated in RFC 3261 in which the Max-Forwards header field is mandatory in all requests.
  • The To, From, and Call-ID header fields contain the dialog identifiers for this SIP session, called a dialog (formerly called a call leg in RFC 2543).
    The dialog identifier consists of the To tag, From tag, and Call-ID which are compared as strings. Endpoints can have multiple separate SIP sessions established between them – each would have a unique dialog identifier.
  • The Command Sequence number, CSeq, header field contains a integer and the method name for the request. Each subsequent request contains an incremented CSeq count while a retransmission of a request would reuse the CSeq count.
  • The Contact header field contains a URI at which the SIP device is directly reachable during the dialog. It usually contains a Fully Qualified Domain Name (FQDN).
    SIP proxies can ensure that they remain in the signaling path for future requests during the dialog by using the Record-Route mechanism. Otherwise, SIP messaging goes directly between endpoints using the Contact URI.
  • The final two header fields Content-Type and Content-Length contain information about the message body (shown on the next slide).
    The message body is separated from the set of SIP header fields by a blank line.
  • This is the SDP message body not shown in the previous example. SDP uses a terse syntax in which a strict order of lines is enforced.
    SIP utilizes on a subset of the SDP information which includes the IP address (100.101.102.103) and port number (49170) at which the UA is listening for media, the media type (audio), Audio Video Profile (AVP) number (0), codec type (PCM -law), and sampling rate (8000 Hz).
  • This is an example response generated in response to the request example. Many of the header fields are directly copied from the request. The changed/new header fields and parameters are shown in bold.
    The start line is replaced with the response code (200) and reason phrase (OK) indicating that the request to establish a session is successful.
    A tag has been added in the To header field, which then becomes part of the dialog identifier.
    The answering UA includes its own Contact URI and media information in the SDP message body.
    This response would be routed back through the proxy.munich.de proxy server back to the caller using the Via header field URI set.
  • The next section will introduce more SIP behavior using some common call flow scenarios.
    The scenarios will utilize the SIP trapezoid to show how the work in an inter-domain environment.
    The full details of most of these examples can be found in two IETF Internet-Draft documents “SIP Basic Call Flow Examples” and “SIP Service Examples”.
  • In this SIP call setup attempt scenario, A wishes to call B and “dials” the AOR URI of B. User Agent A generates an INVITE and sends it to its default outbound proxy.
    This proxy address can be manually configured or looked up using DNS.
    The proxy server immediately returns a 100 Trying provisional response to indicate that it has received the INVITE but that the request is still pending.
  • The proxy server performs a DNS query and utilizes SRV records to locate the SIP proxy server for the destination domain.
  • The proxy server the forwards (proxies) the INVITE to that proxy server for the destination domain which also immediately responds with a 100 Trying.
    The 100 Trying response is not forwarded by the proxy server back to User Agent A – multiple 100 Trying responses do not convey an new information. As a result, the 100 Trying response is defined to only be a “hop-by-hop” response that is never proxied.
  • The inbound proxy server consults a location server for B’s current registration information. B is not currently signed in, so the location server returns this information.
  • The proxy server uses this information to generate a 480 Temporarily Unavailable response.
    This response receives an immediate ACK (Acknowledgement request) from the other proxy server.
    This INVITE/failure-response/ACK exchange completes the SIP transaction between the proxy servers.
  • The proxy then forwards the 480 back to User Agent A and receives an ACK, completing the transaction between them. The ACK is not forwarded by the proxy as it has already sent an ACK in the previous exchange.
  • A wishes to receive a notification when B signs in and is available for communication.
    User Agent A sends a SUBSCRIBE request requesting to be notified when B is available. The previous DNS query has been cached, so no new DNS query is needed for the request to be forwarded to the proxy in B’s domain. The inbound proxy then forwards the request to B’s presence server.
  • The presence server authenticates the subscription and confirms it by sending a 200 OK response which is forwarded back to User Agent A.
    No ACK is sent, as ACK is only used to confirm receipt of final responses to INVITE requests – only INVITE transactions use the 3 way handshake.
    The SUSBSCIBE/200 OK exchange completes the transaction.
  • The presence server immediately sends a NOTIFY containing the current state of B, that is, not signed in. User Agent A responds with a 200 OK which is proxied back to the presence server.
    This NOTIFY/200 OK exchange completes this transaction.
  • Time passes, then B signs in by send a REGISTER request to through his proxy which forwards it to the registrar server for B’s domain.
    The REGISTER contains B’s AOR and a Contact URI which identifies the device that B is currently using.
  • The location server updates its database with the information and returns a 200 OK to confirm. The Contact URI is also returned in the 200 OK along with an expiration time. To ensure continuous service, B will need to refresh the registration (by sending another REGISTER request) within the time interval.
    The REGISTER/200 OK exchange completes the transaction.
  • The presence server is informed of the change in B’s availability and sends a NOTIFY to User Agent A containing this new information. The 200 OK response of User Agent A is proxies back to the presence server.
  • Knowing that B is now available, A types in an Instant Message (IM) to B. User Agent A generates a MESSAGE request containing the typed text in a message body. The location server query by the inbound proxy server now returns B’s Contact URI and the MESSAGE is routed to B.
    User Agent B confirms receipt with a 200 OK. (Note that any typed response by B would not be returned in the 200 OK – it will be sent using a separate MESSAGE request sent from B to A as shown in the next slide.)
  • B types a reply to A. User Agent B generates a MESSAGE request and sends it to its local proxy. The proxy consults DNS to locate the proxy server for the globalipcom.com domain of A. The MESSAGE request is then forwarded to this proxy server which then forwards it to User Agent A. A 200 OK reply is sent which is proxied back to User Agent B.
  • A again attempts to establish a session with B by sending an INVITE. This time, the INVITE is forwarded to User Agent B by the inbound proxy server.
  • User Agent A being alerting user B and sends a 180 Ringing provisional response which is proxied back to User Agent A. User Agent A informs A that alerting is taking place, possibly by generating local ringtone.
  • A accepts the call, so User Agent A sends a 200 OK success response which is proxied back to A.
    Since the media is sent directly between A and B, it is possible that B’s “Hello” may reach A before the 200 OK. To avoid this clipping, User Agent A must be prepared to receive and play any RTP media packets as soon as the INVITE is sent.
    Likewise, User Agent B must be prepared to receive and play media packets before the ACK from User Agent A is received.
    The INVITE/200 OK completes the transaction (the ACK is not part of the same transaction for a success class response).
  • In this example, neither proxy server inserts a Record-Route header field, so the ACK sent by User Agent B is sent to the Contact URI contained in the 200 OK sent by User Agent B, which bypasses the two proxies.
    This ACK is a separate transaction, not related to the INVITE/200 OK transaction of the previous slide.
  • B decides to attempt to transfer A to another party, C. In preparation, B places A on “hold” by sending a re-INVITE (an INVITE sent within an existing dialog) in which the media stream is set to sendonly. (B also applies local mute, so no RTP packets are exchanged between A and B.)
  • B initiates the transfer by sending a REFER to A which receives a 202 Accepted response. This success-class response indicates that User Agent A has received the REFER and will attempt the transfer. However, the final outcome of the refer (success or failure) is not yet known.
    User Agent B sends an initial NOTIFY indicating that it will be trying to send an INVITE to User Agent C, which receives a 200 OK response.
  • Acting upon the REFER, User Agent A generates an INVITE and sends it to the URI in the Refer-To header field in the REFER. A Referred-By header field contains B URI, telling C that A has been transferred by B.
  • User Agent C begins alerting, sending 180 Ringing. C accepts the call and User Agent C sends a 200 OK. Again, no proxy Record-Routes, so the ACK is sent directly to C’s Contact URI.
  • User Agent A sends a NOTIFY to User Agent B informing him that the transfer was completed successfully. As a result, User Agent B disconnects with A by sending a BYE.
    If the transfer had failed, User Agent B could have attempted another transfer by sending another REFER or could have taken A off hold and continued the media session.
  • Nicolas FISCHBACH
    Senior Manager, IP Engineering/Security - COLT Telecom
    nico@securite.org - http://www.securite.org/nico/
  • Anders Kristensen
    Hewlett-Packard Laboratories, Bristol, U.K
  • www.dynamicsoft.com (SIP Summit 2001)
  • Transcript

    • 1. SIPSIP Original Slides by Alan Johnston and Henry Sinnreich, MCI (at VON’03) ALTANAI BISHT tara181989@gmail.com http://altanaitelecom.wordpress.com
    • 2. Contents 2  SIP OverviewSIP Overview  SIP in detailSIP in detail  SIP Call Flow Scenarios  SIP Security  SIP Programming
    • 3. SIP Overview What SIP is, Multimedia Protocol Stack, Short History and Related Protocols are included.
    • 4. Why packet switching? Why SIP? 4 0 10 20 30 40 50 60 70 80 90 100 1980 1985 1987 1990 1995 2000 2001 electromech analog digital Technology evolution of PSTN
    • 5. Session Initiation Protocol OverviewSession Initiation Protocol Overview 5  Application Layer Signaling Protocol  Used to establish, modify, and terminate multimedia sessions  Part of Internet Multimedia Architecture  Can use UDP, TCP, TLS, SCTP, etc.  Based on HTTP (Web)  Similar text-based structure  Uses URIs (Uniform Resource Indicators)  Applications include (but not limited to):  Voice, video, gaming, instant messaging, presence, call control, etc.
    • 6. Security & Privacy 6  SIP Authentication  Challenge/Response based on shared secret - SIP Digest  Mechanism also used by HTTP  Used for client devices  Encryption using private/public keys  Used between servers  Privacy and security  SIP signaling can be encrypted  S/MIME (Secure/Multipurpose Internet Mail Extensions)  Defined in RFC 2633  SIP can be transported over  IPSec  Defined in RFC 2401  TLS (Transport Layer Security)  Defined in RFC 2246
    • 7. Internet Multimedia ProtocolsInternet Multimedia Protocols 7 RTSP
    • 8. SIP Requests and ResponsesSIP Requests and Responses 8 SIP Responses use a numerical code and a “reason phrase” 1xx Informational 2xx Final 3xx Redirection 4xx Client Error 5xx Server Error 6xx Global Failure SIP Request types are called “methods” INVITE ACK OPTIONS CANCEL BYE REGISTER
    • 9. Related Protocols: SDPRelated Protocols: SDP 9  SIP carries (encapsulates) SDP messages  SDP specifies codecs and media termination points  Only one of many possible MIME attachments carried by SIP  SDP – Session Description Protocol  Used to describe media session.  Carried as a message body in SIP messages.  Is a text-based protocol  Uses RTP/AVP Profiles for common media types  Defined by RFC 2327  E.g. RFC 3551 “RTP Profile for Audio and Video Conferences with Minimal Control”
    • 10. Related Protocol: RTP 10  RTP – Real-time Transport Protocol  Used to transport media packets over IP  RTP adds a bit-oriented header containing:  name of media source  timestamp  codec type  sequence number  Defined by H. Schulzrinne et al, RFC 1889.  Profiles defined by RFC 1890.  RTCP for exchange of participant and quality reports.
    • 11. SIP Uniform Resource Indicators (URIs)SIP Uniform Resource Indicators (URIs) 11  Same form as email addresses: user@domain  Two URI schemes:  sip:henry@siptest.mci.com is a SIP URI Most common form introduced in RFC 2543  sips:henry@siptest.mci.com is a Secure SIP URI New scheme introduced in RFC 3261 Requires TLS over TCP as transport for security  Two types of SIP URIs:  Address of Record (AOR) (identifies a user)  sip:henry@mci.com (Needs DNS SRV records to locate SIP Servers for mci.com domain)  Contact (identifies a device and is usually a Fully Qualified Domain Name, FQDN)  sip:henry@127.24.45.4 or sip:henry@cube43.lab.mci.com (Which needs no resolution for routing)
    • 12. SIP “Trapezoid” 12 Outbound Proxy Server User Agent B Inbound Proxy Server User Agent A SIP SIP SIP Media (RTP) DNS Server DNS Location Server SIP
    • 13. SIP Elements – User Agents 13 Outbound Proxy Server Inbound Proxy Server Capable of sending and receiving SIP requests.  UAC – User Agent Client  UAS – User Agent Server End Devices  SIP phone  PC/laptop with SIP Client  PDA  mobile phone PSTN Gateways are a type of User Agent SIP SIP SIP DNS Server DNS Location Server User Agent B User Agent A Media (RTP) SIP
    • 14. SIP Elements – Proxy Servers 14 Outbound Proxy Server Inbound Proxy Server Forward or “proxy” requests on behalf of User Agents Consult databases:  DNS  Location Server Types:  Stateless  Transaction Stateful  Call Stateful No media capabilities  Ignore SDP. Normally bypassed once dialog established, but can Record-Route to stay in path. SIP SIP SIP DNS Server DNS Location Server User Agent BUser Agent A Media (RTP) SIP
    • 15. SIP Elements – Other Servers 15 Outbound Proxy Server Inbound Proxy Server Location Server Database of locations of SIP User Agents Queried by Proxies in routing Updated by User Agents by Registration DNS Server SRV (Service) Records used to locate Inbound Proxy Servers SIP SIP SIP DNS Server DNS Location Server User Agent BUser Agent A Media (RTP) SIP
    • 16. SIP Client and Server 16  SIP Elements are either  User Agents (end devices that initiate and terminate media sessions)  Servers (that assist in session setup)  Proxies  Registrars  Redirect servers  A User Agent acts as a  Client when it initiates a request (UAC)  Server when it responds to a request (UAS)
    • 17. SIP Registrar, 1  SIP server that can receive and process REGISTER requests  A user has an account created which allows them to REGISTER contacts with a particular server  The account specifies a SIP “Address of Record (AOR)” 17
    • 18. SIP Registrar, 2 18  SIP Registrars store the location of SIP endpoints  Each SIP endpoint Registers  with a Registrar using it’s Address of Record and Contact address  Address of Record for John Smith in From: header From: John Smith <sip:jsmith@zultys.com  Contact: header tells Registrar where to send messages Contact: John Smith <sip:jsmith@192.168.1.100>  SIP Proxies  query SIP Registrars for routing information  Incoming calls addressed to sip:jsmith@zultys.com  now routed by the Proxy to the Contact: header URL sip:jsmith@192.168.1.100
    • 19. Proxy Server 19  SIP Proxy servers route SIP messages  Stateless Proxies use stateless protocols like UDP to talk to endpoints  Low Proxy overhead  Ephemeral connections, dropped as soon as message is forwarded  Stateful Proxies use TCP or other stateful protocols to set up a permanent connection  High Proxy overhead  Endpoint connection must be set up, maintained and torn down for the duration of the session
    • 20. SIP Proxy Server  SIP Server which acts on behalf of User Agents  Receives a SIP request  Adds some headers  Modifies some of the headers  Forwards request to next hop server or client 20
    • 21. Stateless vs. Stateful Proxy 21  Stateless Proxy  Forwards every request downstream and response upstream  Keeps no state (does not have any notion of a transaction)  Never performs message retransmissions  Stateless proxies scale very well  can be very fast  good for network cores  Stateful Proxy  Maintains state information for the duration of either the:  Transaction (request)  Transaction Stateful  Dialogue (from INVITE to BYE)  Dialogue Stateful  Performs message retransmission
    • 22. SIP Redirect Server  Receives a request and returns a redirection response (3xx)  Contact header in response indicates where request should be retried  Similar to database query  All Server types are logical NOT Physical 22
    • 23. Locating SIP Servers 23  Manual provisioning  DHCP SIP Option 120  RFC 3361  Multicast (deprecated)  DNS SRV method  Get local domain name automatically from DHCP server  Perform SRV record query through DNS on that domain for _sip._udp.<domain name>  Send SIP REGISTER message to resolved server  phone is up and running without user intervention
    • 24. SIP in detail Now, we are going to study SIP in detail including SIP Request, SIP Response and SIP Header
    • 25. SIP Request Methods, 1 25  SIP used for Peer-to-Peer Communication though it uses a Client-Server model  Requests are called “methods”  Six methods are defined in base RFC 3261:  INVITE  ACK  OPTIONS  BYE  CANCEL  REGISTER
    • 26. SIP Request Methods, 2 26  REGISTER  Register contact with Registrar  INVITE/ACK/BYE/CANCEL/UPDATE  Creates, negotiates and tears down a call (dialogue)  MESSAGE  Creates an Instant Messaging session  SUBSCRIBE  Subscribe to a service (like message waiting indication)  NOTIFY  Notify a change in service state (new Voicemail)
    • 27. SIP Methods - INVITE, 1 27  INVITE requests the establishment of a session  Carried in Message Body (SDP)  Type of session  IP Address  Port  Codec
    • 28. SIP Methods - INVITE, 2 28  An INVITE during an existing session (dialogue) is called a re-INVITE  re-INVITEs can be used to  Place calls on or remove calls from hold  Change session parameters and codecs  The SIP UPDATE method is the proposed replacement for this technique
    • 29. SIP Methods - ACK  ACK completes the three way session setup handshake (INVITE, final response,ACK)  Only used for INVITE  If INVITE did not contain media information  ACK must contain the media information 29
    • 30. SIP Methods - OPTIONS 30  OPTIONS requests the capabilities of another User Agent  Response lists supported methods, extensions, codecs, etc.  User Agent responds to OPTIONS the same as if an INVITE (e.g. if Busy, returns 486 Busy Here)  Very basic presence information
    • 31. SIP Methods – BYE and CANCEL 31  BYE terminates an established session  User Agents stop sending media packets (RTP)  CANCEL terminates a pending session.  INVITE sent but no final response (non-1xx) yet received.  User Agents and Proxies stop processing INVITE  Can be sent by a proxy or User Agent  Useful for “forking proxy”  Parallel search using multiple registration Contacts.  First successful wins, rest are cancelled.
    • 32. SIP Methods - REGISTER 32  Registration allows a User Agent to upload current location and URLs to a Registrar  Registrar can upload into Location Service  Incoming requests can then be proxied or redirected to that location  Built in SIP support of mobility  UAs do not need static IP addresses  Obtain IP address via DHCP, REGISTER indicating new IP Address as contact
    • 33. SIP Request URI  The Request-URI indicates the destination address of the request  Proxies and other servers route requests based on Request- URI.  The Request-URI is modified by proxies as the address is resolved. 33
    • 34. SIP From and To Tags 34  Tags are pseudo-random numbers inserted in To or From headers to uniquely identify a call leg  INVITE request From header contains a tag  Any User Agent or Server generating a response adds a tag to the To header in the response  To: sip:john@company.com;tag=123456
    • 35. SIP Method - INFO 35  Used to transport mid-call signaling information  Only one pending INFO at a time  Typical use - PSTN signaling message carried as MIME attachment  E.g. ISDN User-to-User information  Defined in RFC 2976
    • 36. SIP Method - REFER 36  Indicates that recipient (identified by the Request- URI) should contact a third party using the contact information provided in the request  Typical Use: Call Transfer features  Allowed outside an established dialogue
    • 37. SIP Method - PRACK 37  Provisional Response ACKnowlegement  Used to acknowledge receipt of provisional response  183 Session Progress  Does not apply to 100 Trying responses  Only provisional responses 101-199 may be sent reliably and acknowledged with PRACK  If no PRACK sent, response retransmitted  Defined in RFC 3262
    • 38. SIP Methods – SUBSCRIBE and NOTIFY 38  SUBSCRIBE requests notification of when a particular event occurs  Use Expires=0 to unsubscribe  A NOTIFY message is sent to indicate the event status  Sample Applications  Presence  Message waiting indication for voicemail  Defined in RFC 3265
    • 39. SIP Method - MESSAGE 39  Extension to SIP for Instant Messaging (IM)  MESSAGE requests  carry the content in the form of MIME body parts  use the standard MIME headers to identify the content
    • 40. SIP Responses 40  SIP Requests generate Responses with codes borrowed from HTTP  Classes:  1xx Informational  2xx Final  3xx Redirection  4xx Client Error  5xx Server Error  6xx Global Failure  Response example “404 Not Found”
    • 41. SIP Responses: 1xx-3xx SIP Response Code Brief Description 100 Trying Request received and action is being taken 180 Ringing UA received INVITE and is alerting user 181 Call Is Being Forwarded Used by proxy to indicate call is being forwarded 182 Queued Called party unavailable, call queued 183 Session Progress Used in early media and QoS setup 200 OK Request successful 300 Multiple Choices Address resolved to several choices 301 Moved Permanently User can no longer be found at Req-URI address 302 Moved Temporarily Temporarily cannot find user at Req-URI address 305 Use Proxy Resource MUST be accessed through proxy. 380 Alternative Service Call not successful. Alternatives possible. 41
    • 42. SIP Responses: 4xx SIP Response Code Brief Description 400 Bad Request Request not understood due to malformed syntax 401 Unauthorized Request requires user authentication 402 Payment Required Reserved for future use 403 Forbidden UAS understood request and refuses to fulfill it 404 Not Found UAS finds that user doesn't exist in the domain 405 Method Not Allowed Method is understood but not allowed 406 Not Acceptable Response content not allowed by Accept header 407 Proxy Authentication Required Client must first authenticate itself with proxy 408 Request Timeout UAS could not produce response in time 410 Gone UAS resource unavailable; no forwarding addr. 413 Request Entity Too Large Request contains body longer than UAS accepts 414 Request-URI Too Long Req-URI longer than server is willing to interpret 415 Unsupported Media Type Format of the body not supported by UAS 416 Unsupported URI Scheme Scheme of URI unknown to server 420 Bad Extension UAS not understand protocol extension 421 Extension Required UAS needs particular extension process request 423 Registration Too Brief Contact header field expiration time too small 480 Temporarily Unavailable UAS contacted successfully but user unavailable 481 Call/Transaction Does Not Exist UAS Rx request not matching any existing dialog 482 Loop Detected UAS has detected a loop 483 Too Many Hops UAS received request containing Max-Forwards=0 484 Address Incomplete UAS Rx request with incomplete Request-URI 485 Ambiguous The Request-URI was ambiguous 486 Busy Here UAS contacted successfully but user busy 487 Request Terminated Request terminated by a BYE or CANCEL request 488 Not Acceptable Here Same as 606 but only applies to addressed entity 491 Request Pending UAS Rx req. & have pending req. for same dialog 493 Undecipherable UAS Rx request with encrypted MIME body & not have decryption key 42
    • 43. SIP Responses: 5xx-6xx SIP Reponse Code Brief Description 500 Server Internal Error UAS unexpected condition & cannot fulfill request 501 Not Implemented UAS not support functionality to fulfill the request 502 Bad Gateway UAS Rx invalid response from a downstream server 503 Service Unavailable UAS can't process due to overload or maintenance 504 Server Time-out UAS not Rx response from external server 505 Version Not Supported UAS not support SIP version in request 513 Message Too Large Message length exceeded UAS capabilities 600 Busy Everywhere End systems contacted, user busy at all of them 603 Decline End systems contacted, user explicitly decline 604 Does Not Exist Anywhere UAS has information Req-URI user not exist 606 Not Acceptable Some aspects of Session Desc. not acceptable 43
    • 44. SIP Message DetailsSIP Message Details INVITE sip:wh@200.201.202.203 SIP/2.0INVITE sip:wh@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 44 First line of a SIP message is Start Line which contains:  the method or Request type: INVITE (session setup request).  the Request-URI which indicates who the request is for sip:wh@200.201.202.203  Note: Request-URI can be either an AOR or Contact (FQDN)  This Request-URI is a FQDN, but the initial Request-URI was an AOR (same as To URI)  the SIP version number SIP/2.0
    • 45. SIP Headers 45  SIP Requests and Responses contain Headers (similar to Email headers)  Required Headers  To  From  Via  Call-ID  CSeq  Max-Forwards  Optional Headers:  Subject, Date, Authentication (and many others)
    • 46. SIP Message DetailsSIP Message Details INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 46 Via headers show the path the request has taken  The bottom Via header is inserted by the User Agent which initiated the request  Additional Via headers are inserted by each proxy in the path The Via headers are used to route responses back the same way Required branch parameter contains a “cookie” (z9hG4bK) then a transaction-ID.
    • 47. SIP Message DetailsSIP Message Details INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 47 Max-Forwards is a count decremented by each proxy that forwards the request. When count goes to zero, request is discarded and 483 Too Many Hops response is sent. Used for stateless loop detection.
    • 48. SIP Message DetailsSIP Message Details INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de>To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 48 Dialog (formerly called call leg) information is in headers:  To tag, From tag, and Call-ID (Note: Not URIs) To and From URIs usually contain AOR URIs. All requests and responses in this call will use this same Dialog information. Call-ID is unique identifier usually composed of  pseudo-random string “@” hostname or IP Address
    • 49. SIP Message DetailsSIP Message Details 49 CSeq Command Sequence Number  Initialized at start of call (1 in this example)  Incremented for each subsequent request  Used to distinguish a retransmission from a new request Also contains the request type (method) - INVITE INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITECSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159
    • 50. SIP Message DetailsSIP Message Details INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 50 Contact header contains a SIP FQDN URI for direct communication between User Agents  If Proxies do not Record-Route, they can be bypassed  If Record-Route is present in 200 OK, then a Route header is present in all future requests in this dialog. Contact header is also present in 200 OK response
    • 51. SIP Message DetailsSIP Message Details 51 Content-Type indicates the type of message body attachment (others could be text/plain, application/cpl+xml, etc.) Content-Length indicates the octet (byte) count of the message body. Message body is separated from SIP header fields by a blank line (CRLF). INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdpContent-Type: application/sdp Content-Length: 159Content-Length: 159
    • 52. SDP Message Body DetailsSDP Message Body Details 52 v=0 o=Tesla 289084526 28904529 IN IP4 lab.high-voltage.org s=- c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000  Version number (ignored by SIP)  Origin (only version used by SIP - 28904529)  Subject (ignored by SIP)  Connection Data (IP Address for media - 100.101.102.103)  Time (ignored by SIP)  Media (type - audio, port - 49170, RTP/AVP Profile - 0)  Attribute (profile - 0, codec - PCMU, sampling rate – 8000 Hz)
    • 53. SIP Response DetailsSIP Response Details 53 Via, To, From, Call-ID, & CSeq are all copied from request.  To now has a tag inserted by UAS Contact and Message Body contain UAS information. SIP/2.0 200 OKSIP/2.0 200 OK Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 To: Heisenberg <sip:w.heisenberg@munich.de>;tag=24019385tag=24019385 From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:wh@200.201.202.203Contact: sip:wh@200.201.202.203 Content-Type: application/sdp Content-Length: 173 v=0v=0 o=Heisenberg 2452772446 2452772446 IN IP4 200.201.202.203o=Heisenberg 2452772446 2452772446 IN IP4 200.201.202.203 s=SIP Calls=SIP Call c=IN IP4 200.201.202.203c=IN IP4 200.201.202.203 t=0 0t=0 0 m=audio 56321 RTP/AVP 0m=audio 56321 RTP/AVP 0 a=rtpmap:0 PCMU/8000a=rtpmap:0 PCMU/8000
    • 54. SIP Call Flow Scenarios As followings …
    • 55. SIP Call Flow Scenarios 55  Call Attempt - Unsuccessful  Presence Subscription  Registration  Presence Notification  Instant Message Exchange  Call Setup – Successful  Call Hold  Call Transfer Call Flows and full message details:  “SIP Basic Call Flow Examples” I-D by A. Johnston et al.  “SIP Service Examples” I-D by A. Johnston et al.
    • 56. SIP Call Setup Attempt Scenario 56 Outbound Proxy Server Inbound Proxy Server 1. INVITE Contact: A SDP A DNS Server Location Server 1. A “dials” SIP AOR URI sip:B@mci.com. User Agent A sends INVITE to outbound Proxy Server. 2. Outbound Proxy sends 100 Trying response. 2. 100 Trying User Agent B (Not Signed In) User Agent A
    • 57. SIP Call Setup Attempt Scenario 57 Outbound Proxy Server Inbound Proxy Server 1. INVITE Contact: A SDP A DNS Server Location Server 3. Outbound Proxy does DNS query to find proxy server for mci.com domain 4. DNS responds with IP address of mci.com Proxy Server 3. DNS Query: mci.com? 2. 100 Trying 4. Response: 1.2.3.4 User Agent B (Not Signed In) User Agent A
    • 58. SIP Call Setup Attempt Scenario 58 Outbound Proxy Server Inbound Proxy Server DNS Server Location Server 5. Outbound Proxy sends INVITE to Inbound Proxy Server. 6. Inbound Proxy sends 100 Trying response. 3. DNS Query: mci.com? 2. 100 Trying 4. Response: 1.2.3.4 6. 100 Trying User Agent B (Not Signed In) User Agent A 1. INVITE Contact: A SDP A 5. INVITE Contact: A SDP A
    • 59. SIP Call Setup Attempt Scenario 59 Outbound Proxy Server Inbound Proxy Server DNS Server Location Server 7. Inbound Proxy consults Location Server. 8. Location Server responds with “Not Signed In.” 3. DNS Query: mci.com? 2. 100 Trying 4. Response: 1.2.3.4 6. 100 Trying 7. LS Query: B? 8. Response: Not Signed In User Agent B (Not Signed In) User Agent A 1. INVITE Contact: A SDP A 5. INVITE Contact: A SDP A
    • 60. SIP Call Setup Attempt Scenario 60 Outbound Proxy Server Inbound Proxy Server DNS Server Location Server 9. Inbound Proxy sends 480 Temporarily Unavailable response. 10. Outbound Proxy sends ACK response. 3. DNS Query: mci.com? 2. 100 Trying 4. Response: 1.2.3.4 6. 100 Trying 7. LS Query: B? 8. Response: Not Signed In 9. 480 Temporarily Unavailable 10. ACK User Agent B (Not Signed In) User Agent A 1. INVITE Contact: A SDP A 5. INVITE Contact: A SDP A
    • 61. SIP Call Setup Attempt Scenario 61 Outbound Proxy Server Inbound Proxy Server DNS Server Location Server 11. Outbound Proxy forwards 480 response to A. 12. A sends ACK response. 3. DNS Query: mci.com? 2. 100 Trying 4. Response: 1.2.3.4 6. 100 Trying 7. LS Query: B? 8. Response: Not Signed In 9. 480 Temporarily Unavailable 11. 480 Temporarily Unavailable 10. ACK 12. ACK User Agent B (Not Signed In) User Agent A 1. INVITE Contact: A SDP A 5. INVITE Contact: A SDP A
    • 62. SIP Presence Example 62 Outbound Proxy Server Inbound Proxy Server 1. SUBSCRIBE DNS Server Presence Server 1. A wants to be informed when B signs on, so sends a SUBSCRIBE 2. Outbound Proxy forwards to Inbound Proxy 3. Inbound Proxy forwards to B’s Presence Server 2. SUBSCRIBE 3. SUBSCRIBE User Agent B (Not Signed In) User Agent A
    • 63. SIP Presence Example 63 Outbound Proxy Server Inbound Proxy Server 1. SUBSCRIBE DNS Server Presence Server 4. Presence Server authorizes subscription by sending a 200 OK. 5. & 6. 200 OK proxied back to A. 6. 200 OK 2. SUBSCRIBE 5. 200 OK 3. SUBSCRIBE 4. 200 OK User Agent B (Not Signed In) User Agent A
    • 64. SIP Presence Example 64 Outbound Proxy Server Inbound Proxy Server DNS Server Presence Server 7. Presence Server sends NOTIFY containing current presence status of B (Not Signed In). 8. and 9. NOTIFY is proxied back to A. 10. A acknowledges receipt of notification with 200 OK. 11. & 12. 200 OK is proxied back to B’s Presence Server. 10. 200 OK 11. 200 OK 7. NOTIFY <Not Signed In> 12. 200 OK User Agent B (Not Signed In) User Agent A 8. NOTIFY <Not Signed In> 9. NOTIFY <Not Signed In>
    • 65. SIP Registration Example 65 Outbound Proxy Server Outbound Proxy Server DNS Server Location Server 2. Update database: B = B@2.3.4.5 1. REGISTER Contact: B@2.3.4.5 1. B signs on to his SIP Phone which sends a REGISTER message containing the FQDN URI of B’s User Agent. 2. Database update is sent to the Location Server User Agent BUser Agent A
    • 66. SIP Registration Example 66 Outbound Proxy Server Outbound Proxy Server DNS Server Location Server 2. Update database: B = B@2.3.4.5 3. OK 1. REGISTER Contact: B@2.3.4.5 4. 200 OK Contact: B@2.3.4.5 3. Location Server database update is confirmed. 4. Registration is confirmed with a 200 OK response. User Agent BUser Agent A
    • 67. SIP Presence Example 67 Outbound Proxy Server Inbound Proxy Server DNS Server Presence Server 13. Presence Server learns of B’s new status from the Location Server and sends a NOTIFY containing new status of B (Signed In). 14. & 15. NOTIFY is proxied back to A. 16. A acknowledges receipt of notification with 200 OK. 17. & 18. 200 OK is proxied back to Presence Server. 16. 200 OK 17. 200 OK 18. 200 OK User Agent BUser Agent A 13. NOTIFY <Signed In> 14. NOTIFY <Signed In> 15. NOTIFY <Signed In>
    • 68. SIP Instant Message Scenario 68 Outbound Proxy Server Inbound Proxy Server 1. MESSAGE <Can you talk now?> DNS Server Location Server 1. A sends an Instant Message to B saying “Can you talk now?” in a MESSAGE request. 2., 3. & 4. MESSAGE request is proxied, Location Server queried. 5. Inbound Proxy forwards MESSAGE to B. 6. User Agent B responds with 200 OK. 7. & 8. 200 OK is proxied back to A. 8. 200 OK 7. 200 OK 3. LS Query: B? 4. Response: sip:B@2.3.4.5 6. 200 OK User Agent BUser Agent A 2. MESSAGE <Can you talk now?> 5. MESSAGE <Can you talk now?>
    • 69. SIP Instant Message Scenario 69 Inbound Proxy Server Outbound Proxy Server Location Server DNS Server 1. B sends an Instant Message to A saying “Sure.” in a MESSAGE sent to A’s AOR URI. 2. & 3. DNS Server is queried. 4. Outbound Proxy forwards MESSAGE to Inbound Server. 5. & 6. Location Server is queried. 7. Inbound Proxy forwards to A. 8. User Agent A responds with 200 OK. 9. & 10. 200 OK is proxied back to B. 8. 200 OK 9. 200 OK 10. 200 OK 5. LS Query: A? 6. Response: sip:A@4.5.3.2 2. DNS Query: globalipcom.com? 3. Response: 5.6.7.8 User Agent BUser Agent A 7. MESSAGE <Sure.> 4. MESSAGE <Sure.> 1. MESSAGE <Sure.>
    • 70. SIP Call Setup Attempt Scenario 70 Outbound Proxy Server Inbound Proxy Server DNS Server Location Server 1. to 5. A retries INVITE to B which routes through two Proxy Servers. 6. Location Server responds with the FQDN SIP URI of B’s SIP Phone. 7. Inbound Proxy Server forwards INVITE to B’s SIP Phone. 2. 100 Trying 4. 100 Trying 5. LS Query: B 6. Response: sip:B@2.3.4.5 User Agent BUser Agent A 1. INVITE Contact: A SDP A 3. INVITE Contact: A SDP A 7. INVITE Contact: A SDP A
    • 71. SIP Call Setup Scenario 71 Outbound Proxy Server Inbound Proxy Server 10. 180 Ringing DNS Server Location Server 8. User Agent B alerts B and sends 180 Ringing response. 9. & 10. 180 Ringing is proxied back to A. 9. 180 Ringing 8. 180 Ringing User Agent BUser Agent A
    • 72. SIP Call Setup Scenario 72 Outbound Proxy Server Inbound Proxy Server 10. 180 Ringing DNS Server Location Server 11. B accepts call and User Agent B sends 200 OK response. 12. & 13. 200 OK is proxied back to A. 9. 180 Ringing 8. 180 Ringing User Agent BUser Agent A 11. 200 OK Contact: B SDP B 12. 200 OK Contact: B SDP B 13. 200 OK Contact: B SDP B
    • 73. SIP Call Setup Scenario 73 Outbound Proxy Server Inbound Proxy Server 10. 180 Ringing DNS Server Location Server 14. ACK is sent by A to confirm setup call bypassing proxies. Media session begins between A and B! 9. 180 Ringing 8. 180 Ringing 14. ACK Media (RTP) User Agent BUser Agent A 11. 200 OK Contact: B SDP B 12. 200 OK Contact: B SDP B 13. 200 OK Contact: B SDP B
    • 74. SIP Call Hold (re-INVITE) 74 Outbound Proxy Server Inbound Proxy Server DNS Server Location Server 15. B places A on hold by sending a re- INVITE. 16. A accepts with a 200 OK. 17. B sends ACK to A. No media between A and B.15. INVITE SDP a=sendonly 17. ACK User Agent BUser Agent A 16. 200 OK SDP A
    • 75. SIP Call Transfer Scenario 75 20. NOTIFY <100 Trying> 21. 200 OK Outbound Proxy Server Inbound Proxy Server DNS Server Location Server 18. B transfers A to C using REFER. 19. Transfer is accepted by A with 202 Accepted response. 20. Notification of trying transfer is sent to B in NOTIFY. 21. B sends 200 OK response to NOTIFY 18 REFER Refer-To: sip:C@mci.com 19. 202 Accepted User Agent BUser Agent A
    • 76. SIP Call Transfer Scenario 76 Outbound Proxy Server Inbound Proxy Server DNS Server Location Server 1. to 5. A sends new INVITE to C which routes through two Proxy Servers. 6. Location Server responds with the FQDN SIP URI of C’s SIP Phone. 7. Inbound Proxy Server forwards INVITE to C’s SIP Phone. 2. 100 Trying 4. 100 Trying 5. LS Query: C? 6. Response: sip:C@6.7.8.9 User Agent BUser Agent A User Agent C 1. INVITE Contact: A Ref-By: B SDP A 3. INVITE Contact: A Ref-By: B SDP A 7. INVITE Contact: A Ref-By: B SDP A
    • 77. SIP Call Transfer Scenario 77 Outbound Proxy Server Inbound Proxy Server 10. 180 Ringing DNS Server Location Server 8. User Agent C alerts C and sends 180 Ringing response. 9. & 10. 180 Ringing is proxied back to A. 11. C accepts call and sends 200 OK response. 12. & 13. 200 OK is proxied back to A. 14. ACK is sent by A to confirm setup call. Media session between A and C begins. 9. 180 Ringing 8. 180 Ringing 14. ACK User Agent C Media (RTP) User Agent B User Agent A 11. 200 OK Contact: C SDP C 12. 200 OK Contact: C SDP C 13. 200 OK Contact: C SDP C
    • 78. SIP Call Transfer Scenario 78 Outbound Proxy Server Inbound Proxy Server DNS Server Location Server 20. Notification of successful transfer is sent to B in NOTIFY. 21. B sends 200 OK response to NOTIFY 22. B hangs up by sending a BYE. 23. 200 OK response to BYE is sent. 20. NOTIFY <200 OK> 21. 200 OK 22. BYE 23. 200 OK User Agent BUser Agent A
    • 79. SIP Security
    • 80. Authorization 80  SIP uses standard HTTP Digest Authentication with minor revisions  Simple Challenge/Response scheme REGISTER -> <- 407 Challenge + nonce REGISTER + MD-5 hash (pw + nonce) -> <- 200 OK  Password is never sent in the clear, just the MD-5 hash generated with the password and nonce  Defeats Man-in-the-middle attacks since source address can’t be spoofed or second REGISTER will never arrive  Required by many Internet Telephony Service Providers (ITSPs)  Service Provider supplies Username and password  SIP leverages Digest Authentication features to do this
    • 81. TLS and sips: 81  Implementation of TLS is mandatory for proxies, redirect servers and registrars  The ;transport=tls URI parameter value is deprecated  A sips: URI scheme (otherwise identical to the sip: scheme) indicates that all hops between the requestor and the resource identified by the URI must be encrypted with TLS.  If the request is retargeted once the resource is reached, it must use secured transports.
    • 82. S/MIME 82  Provides end-to-end security of message body and/or headers.  Certificate identified by end user address  Public key can be transported in SIP  Entire message can be protected by “tunneling” the message in an S/MIME body Header Fields Header Fields Body Signature
    • 83. Attacks 83  IPhreakers  IP knowledge  Known weaknesses  Evolution 2600Hz -> voicemail/int’l GWs -> IP telephony  Internal or external threat ?  Targets: home user, enterprise, government, etc ?  Protocol implementations  PROTOS  The human element
    • 84. Attacks : denial of service 84  Denial of service  Network  Protocol (SIP INVITE)  Systems / Applications  Phone  Availability (BC/DR)  Requires: power  Alternatives (Business Continuity/Disaster Recovery) ?  E911 (laws and technical aspect)  GSM  PSTN-to-GSM
    • 85. Attacks : fraud 85  Call-ID spoofing  User rights takeover  Fake authentication server  Effects  Access to voicemail  Value added numbers  Social engineering  Replay
    • 86. Attacks: interception 86  Interception  “Who talks with who” (Network sniffing, Servers (SIP, CDR, etc)  LAN  Physical access to the LAN  ARP attacks  Unauthenticated devices (phones and servers)  Different layers (MAC address, user, physical port, etc)  Where to intercept ?  Where is the user located ?  Networks crossed ?  Lawful Intercept  CALEA  ETSI standard  Architecture and risks
    • 87. Attacks : systems 87  Systems  Mostly none is hardened by default  Worms, exploits, Trojan horses Attacks : phone (S)IP phone  Startup  DHCP, TFTP, etc.  Physical access  Hidden configuration tabs  TCP/IP stacks  Firmware/configuration  Trojan horse/rootkit
    • 88. Defense 88  Signaling: SIP  Secure SIP vs SS7 (physical security)  Transport: Secure RTP (with MiKEY)  Network: QoS [LLQ] (and rate-limit)  Firewall: application level filtering  Phone: signed firmware  Identification: TLS  Clients by the server  Servers by the client  3P: project, security processes and policies
    • 89. SIP Programming
    • 90. SIP based Application Interfaces 90  These include :  JAIN SIP  Low level and very complex API  CNRSIP API is one of available reference implementations.  SIP Servlets  proposed within JAIN  SIP API for J2ME  intermediate level API (minimal SIP knowledge required)  SIP CGI  CPL ( Call Processing Language)  XML based
    • 91. HTTP Servlets 91  HTTP Java Servlets Widely Used in Web Application Development  Applications Consist of Sets of HTTP Servlets, Each of Which Processes a Single Web Request in the Application  HTTP Servlets Return Web Pages to Display  HTTP Servlets Can Create “Session Data”  e.g., shopping cart, that spans multiple requests  “Container” Manages HTTP Servlet Lifecycles, Fault Tolerance, Session State  HTTP Servlets Collected into a War File – Web Archive HTTP Servlets Web Server Developer Deployer War File
    • 92. SIP Servlet API 92  Java extension API for SIP servers  Similar in spirit to HTTP servlet API  Server matches incoming messages against local rules in order to decide which servlet to pass message to  The API gives full control to servlets to handle SIP messages, e.g.  has full access to headers and body  proxy or redirect requests  respond to or reject requests  forward responses upstream  initiate requests  Servers may choose to provide constrained environment to selected servlets (e.g. using sandbox security model)
    • 93. Basic SIP Servlet Model 93 S e rvle t E n g in e S IP S e rve r re q u e s t s re s p o n s e s re q u e s t s re s p o n s e s s e r v le ts e r v le t Location of SIP Server and servlet engine:  in same Java Virtual Machine  different process, same host  different hosts: 1:1, 1:n, n:1, n:m
    • 94. Example: Routing Services 94  Servlet proxies request to one or more destinations  - forwards response to caller S e rve r s e r v le t U A C U A S S IP S IP R T P
    • 95. Example: Servlet as UAS 95 S e rve r s e r v le t U A C S IP R T P Servlets can reject (screen) calls Can accept and set up media streams
    • 96. Benefits of Servlet Model 96  Powerful:  Full access to SIP signaling  Performance:  No need to fork new process for each request  The same servlet can handle many requests simultaneously  Safety: type checked; no pointers; exception handling  Convenience:  high level abstractions.  Tight integration with server: logging, security, location database  Lifecycle model allows servlets to  maintain state, e.g. database connections  manage timers  Access to wide range of APIs
    • 97. An Example: RejectServlet 97 import org.ietf.sip.*; public class RejectServlet extends SipServletAdapter { protected int statusCode, reasonPhrase; public void init(ServletConfig config) { super.init(config); try { statusCode = Integer.parseInt(getInitParameter("status-code")); reasonPhrase = getInitParameter("reason-phrase"); } catch (Exception _) { statusCode = SC_INTERNAL_SERVER_ERROR; } } public boolean doInvite(SipRequest req) { SipResponse res = req.createResponse(); res.setStatus(statusCode, reasonPhrase); res.send(); return true; } }
    • 98. Relationship to JAIN SIP 98  JAIN SIP is a generic, low-level interface for accessing SIP services  Can be used in  Clients  Servers  Gateways  Focuses purely on the protocol  Complete access to SIP capabilities  Supports transactions only  SIP Servlet Container is a particular application of JAIN SIP SIP Protocol SIP Servlet Container Servlet JAIN SIP SIP Servlet API Servlet
    • 99. Relationship to JAIN SIP 99  Servlets focus on high volume carrier grade servers  Add significant, non-SIP protocol functions  Lifecycle management  Domain objects  Context and configuration  Deployment descriptors  Archive files  Synchronization primitives  Security  Add significant SIP protocol functions  Construction of requests and responses from domain objects  Hide many parts of JAIN SIP  Direct access to many headers is not provided  Write access to most everything is often restricted  Servlets should be defined to allow a SIP container to be built using JAIN SIP  SIP Objects in Servlet API defined with interfaces that match JAIN SIP signatures  Cannot directly expose JAIN SIP objects, though
    • 100. SIP CGI 100  Almost identical to HTTP CGI  Language independent ( Perl, Tcl, C, C++, ... )  Any binary may be executed as a separate program  Suitable for services that contains substantial web content  Passes message parameters through environmental variables to a separate program.  More flexible but more risky  Feb. 1, 2001: RFC 3050 (Common Gateway Interface for SIP) published
    • 101. Call Processing Language (CPL) 101  Designed by the IETF to support sophisticated telephony services  May be used by both SIP or H.323.  XML based scripting language for describing controlling call services  Simple Syntax  Extendible  Easily edited by GUI tools  Scripts runs on network SIP signaling server to create end user services  Lightweight CPL interpreter is need to parser & validate scripts
    • 102. CPL Example 102  A simple script that blocks anonymous callers <?xml version="1.0" ?> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <cpl> <incoming> <address-switch field="origin" subfield="user"> <address is="anonymous"> <reject status="reject" reason="I don't accept anonymous calls" /> </address> </address-switch> </incoming> </cpl>

    ×