Session Initiation Protocol (SIP) - PowerPoint PPT Presentation

session initiation protocol sip l.
Skip this Video
Loading SlideShow in 5 Seconds..
Session Initiation Protocol (SIP) PowerPoint Presentation
Download Presentation
Session Initiation Protocol (SIP)

play fullscreen
1 / 59
Download Presentation
Session Initiation Protocol (SIP)
Download Presentation

Session Initiation Protocol (SIP)

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Session Initiation Protocol (SIP) Ram Dantu (Compiled from different sources, see the references list)

  2. SIP based VoIP Architecture I NTELL I GENT SERV I CES Application Services 3pcc CPL eMail CPL LDAP XML Oracle SIP Proxy, Registrar & Redirect Servers SIP SIP SIP PSTN SIP User Agents (UA) CAS or PRI RTP (Media) Legacy PBX

  3. Basic SIP Call-Flow SIP UA1 SIP UA2 INVITE w/ SDP for Media Negotiation 100 Trying 180/183 Ringing w/ SDP for Media Negotiation MEDIA 200 OK ACK MEDIA BYE 200 OK

  4. SIP Call Flow with Proxy Server Proxy Server Register Register OK (200) OK (200) Invite Invite Trying (100) Ringing (180) Ringing (180) OK (200) OK (200) ACK ACK RTP/RTCP media channels

  5. VoIP Migration

  6. Step1: IPPBX deployments in Enterprises PSTN Network Customer Premises Customer Premises IP Core Network DNS Server for URL resolution • Large enterprises will handle VOIP calls directly • PSTN connectivity provided by Media Gateways • Regulation can not stop spammers outside USA • (similar to SMTP spam)

  7. STEP 2: Hosted IP Centrex FW, NAT, VoIP service provided by Carrier Networks Softswitches, MGW VoIP Proxy Server, SGW SGC, VoIP Centrex Server, Internet Carrier Network Customer Premises

  8. Step 3: Carrier VoIP Network VoIP Trunk Softswitches, MGW VoIP Proxy Server, SGW SGC, VoIP Centrix Server, Internet Carrier Network - VoIP FW, NAT and Security provided by Carriers Customer Premises

  9. SIP Architecture

  10. The Popularity of SIP • Originally Developed in the MMUSIC • A separate SIP working group • RFC 2543, RFC 3261 • Many developers • SIP + MGCP/MEGACO • The VoIP signaling in the future • “back-off” or SIPit (SIP Interoperability Tests) • Test products against each other • Will be hosted by ETSI

  11. SIP Architecture • A signaling protocol • The setup, modification, and tear-down of multimedia sessions • SIP + SDP • Describe the session characteristics • Separate signaling and media streams

  12. SIP Network Entities • Clients • User agent clients • Application programs sending SIP requests • Servers • Responds to clients’ requests • Clients and servers may be in the same platform • Proxy • Acts as both clients and servers

  13. Four types of servers • Proxy servers • Handle requests or forward requests to other servers • Can be used for call forwarding

  14. Redirect servers • Map the destination address to zero or more new addresses • Do not initiate any SIP requests

  15. A user agent server • Accept SIP requests and contacts the user • The user responds → an SIP response • A SIP device • E.g., an SIP-enabled telephone • A registrar • Accepts SIP REGISTER requests • Indicating the user is at a particular address • Typically combined with a proxy or redirect server

  16. SIP Call Establishment • It is simple • A number of interim responses

  17. SIP Advantages • Attempt to keep the signaling as simple as possible • Offer a great deal of flexibility • Various pieces of information can be included within the messages • Including non-standard information • Enable the users to make intelligent decisions • The user has control of call handling • No need to subscribe call features

  18. Call Completion to Busy Subscriber service

  19. Via contains the address (e.g., • Contact contains a SIP or SIPS URI that represents a direct route to contact the called party, usually composed of username at a fuly qualified domain name (FQDN). While the FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While Via header field tells other elements where to send response, the Contact header field tells other elements where the called party can be reached directly. • In a response, Via, To, From, Call-ID, and CSeq header fields are copied from the INVITE request. • In addition to DNS and location service lookups, proxy servers can make flexible “routing decisions” to decide where to send a request. For example, if Bob’s SIP phone returned 486 (busy) response, the proxy server could proxy the INVITE to Bob’s voicemail server. A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking.

  20. After learning the end point addresses, the end points can communicate directly

  21. Overview of SIP Messaging Syntax • Text-based • Similar to HTTP • SIP messages • message = start-line *message-header CRLF [message-body] • start-line = request-line | status-line • Request-line specifies the type of request • The response line • The success or failure of a given request

  22. Message headers • Additional information of the request or response • E.g., • The originator and recipient • Retry-after header • Subject header • Message body • Describe the type of session • The media format • SDP, Session Description Protocol • Could include an ISDN User Part message • Examined only at the two ends

  23. SIP Requests • method SP request-URI SP SIP-version CRLF • request-URI • The address of the destination • Methods • INVITE, ACK, OPTIONS, BYE, CANCLE, REGISTER • extensions: INFO, REFER, UPDATE, … • INVITE • Initiate a session • Information of the calling and called parties • The type of media • ~IAM (initial address message) of ISUP • ACK only the final response

  24. BYE • Terminate a session • Can be issued by either the calling or called party • Options • Query a server as to its capabilities • A particular type of media • The response if sent an INVITE • CANCEL • Terminate a pending request • E.g., an INVITE did not receive a final response

  25. REGISTER • Log in and register the address with a SIP server • “all SIP servers”– multicast address ( • Can register with multiple servers • Can have several registrations with one server • INFO • RFC 2976 • Transfer information during an ongoing session • DTMF digits • account balance information • midcall signaling information generated in another network

  26. SIP Responses • SIP version SP status code SP reason-phrase CRLF • reason-phrase • A textual description of the outcome • Could be presented to the user • status code • A three-digit number • 1XX Informational • 2XX Success (only code 200 is defined) • 3XX Redirection • 4XX Request Failure • 5XX Server Failure • 6XX Global Failure • All responses, except for 1XX, are considered final • Should be ACKed

  27. “One number” service

  28. SIP Addressing • SIP URLs (Uniform Resource Locators) • user@host • E.g., • • • Supplement the URL •;user=phone • sip:user:password@host:port;uri-parameters?headers

  29. Message Headers • Provide further information about the message • ~information elements • E.g., • To:header in an INVITE • The called party • From:header • The caling party • Four main categories • General, request, response, and entity headers • A list in Table 5-2 • Mapping in Table 5-3

  30. General Headers • Used in both requests and responses • Basic information • E.g., To:, From:, Call-ID:, … • Contact: • A URL for future communication • May be different from the From: header • Requests passed through proxies

  31. Request Headers • Apply only to SIP requests • Addition information about the request or the client • E.g., • Subject: • Priority:, urgency of the request • Authorization:, authentication of the request originator • Response Headers • Further information about the response • E.g., • Unsupported:, features • Retry-After

  32. Entity Header • Session information presented to the user • Session description, SDP • The RTP payload type, an address and port • Content-Length, the length of the message body • Content-Type, the media type of the message • Content-Encoding, for message compression • Content Disposition, • Content-Language, • Allow, used in a Request to indicate the set of methods supported • Expires, the date and time

  33. Example of SIP Message Sequences • Registration • Via: • Call-ID: • host-specific • Content-Length: • Zero, no msg body • Cseg: • Avoid ambiguity • Expires: • TTL • 0, unreg • Contact: • *

  34. A two-party call Subject: optional Content-Type: application/sdp Invitation

  35. Cseq: Has changed Termination of a Call

  36. An alternative address 302, Moved temporarily Another INVITE Same Call-ID Cseq ++ Redirect Servers

  37. Entity headers are omitted Changes the Req-URI Via: The path Loop detected, 482 For a response The 1st Via: header Checked removed Proxy Servers

  38. Proxy state • Can be either stateless or stateful • Record-Route: • The messages and responses may not pass through the same proxy • Use Contact: • A Proxy might require that it remains in the signaling path • In particular, for a stateful proxy • Insert its address into the Record-Route: header • The response includes the Record-Route: header • The Record-Route: header is used in the subsequent requests • The Route: header = the Record-Route: header in reverse order, excluding the first proxy • Each proxy remove the next from the Route: header

  39. “fork” requests A user is registered at several locations ;branch=xxx Forking Proxy

  40. The Session Description Protocol • The message body • SDP, RFC 2327 • The Structure of SDP • Session Level Info • Name • The originator • The time • Media Level Info • Media type • Port number • Transport protocol • Media format

  41. SDP session description structure

  42. SDP Syntax • A number of lines of text • In each line • field=value • Session-level fields first • Media-level fields • Begin with media description field (m=)

  43. Mandatory Fields • v=(protocol version) • o=(session origin or creator and session id) • s=(session name), a text string • t=(time of the session) • t=<start time> <stop time> • NTP time values in seconds • m=(media) • m=<media> <port> <transport> <fmt list> • Media type • The transport port • The transport protocol • The media format, an RTP payload format

  44. Optional Fileds • i=(session information) • A text description • At both session and media levels • u=(URI of description) • Where further session information can be obtained • Only at session level • e=(e-mail address) • Who is responsible for the session • Only at the session level • p=(phone number) • Only at the session level

  45. c=(connection information) • Connection type, network type, and connection address • At session or media level • b=(bandwidth information) • In kilobits per second • At session or media level • r=<repeat interval> <active duration> <list of offsets from start- time> • For regularly scheduled session • How often and how many times

  46. z=(timezone adjustments) • z=<adjustment time> <offset> <adjustment time> <offset> .... • For regularly scheduled session • Standard time and Daylight Savings Time • k=(encryption key) • k=<method>:<encryption key> • An encryption key or a mechanism to obtain it • At session or media level • a=(attributes) • Describe additional attributes

  47. Session Level Protocol version (v) Origin (o) Session name (s) Session information (i) URI (u) E-mail address (e) Phone number (p) Connection info (c) Bandwidth info (b) Time description (t) Repeat info (r) Time zone adjustments (z) Encryption key (k) Attributes (a) Media level Media description (m) Media info (i) Connection info (c) Optional if specified at the session level Bandwidth info (b) Encryption key (k) Attributes (a) Ordering of Fields