1 / 50

Session Initiation Protocol

Session Initiation Protocol. The department of Information & Communications Engineering Dong-uk, kim ghost@hufs.ac.kr. Table of Contents. Introduction Transaction Transport Registration Dialog Initiating a session Terminating a session Headers. Introduction. Introduction.

rufus
Download Presentation

Session Initiation Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Session Initiation Protocol The department of Information & Communications Engineering Dong-uk, kim ghost@hufs.ac.kr

  2. Table of Contents • Introduction • Transaction • Transport • Registration • Dialog • Initiating a session • Terminating a session • Headers

  3. Introduction

  4. Introduction • Many Applications that require the creation and management of a session. • The Session initiation Protocol • Can enabling UA to discover one another • General-purpose tool for creating, modifying and terminating session • Works independently of underlying transport protocols

  5. SIP URIs • Two URI schemes • Similar to the form of an e-mail address: user@domain • SIP URI - introduced in RFC 2543 • example: sip:bob@cnn.com • Secure SIP URI - introduced in RFC 3261 • example: sips:bob@cnn.com • Requires TLS over TCP as transport for security

  6. SIP URIs (cont’d) • Several types of SIP URIs: • Address of Record (AOR) (identifies a user) • example: sip:user@domain.com • Need DNS records to locate SIP Servers for “domain.com” • Fully Qualified Domain Name (FQDN) (identifies a specific device) • sip:maguire@130.237.212.2 • sip:user@pc.domain.com • sip:+82-11-9389-9900@domain.com;user=phone

  7. Functionality

  8. Operation

  9. SIP Message structure INVITE sip:bob@biloxi.com SIP/2.0 <CRLF> Start Line Via: SIP/2.0/UDP 169.130.12.5 Call-ID: 78928748@169.130.12.5 From: <sip:alice@atlanta.com> To: Bob<sip:bob@biloxi.com> CSeq: 1 INVITE Max-forwards: 70 Content-Type: application/sdp Content-Length:885 Headers Blank Line <CRLF> v=0 o=xener 53655765 2353687 IN IP4 169.130.12.5 s=hello session c=IN IP4 169.130.12.5 m=audio 3456 RTP/AVP 0 3 4 5 Content

  10. Request Method Basic Extention • INVITE • ACK • BYE • CANCEL • OPTIONS • REGISTER • REFER • PUBLISH • SUBSCRIBE • NOTIFY • MESSAGE • INFO • UPDATE

  11. Response code • 1xx: Provisional • request received, continuing to process the request • 2xx: Success • the action was successfully received, understood, and accepted • 3xx: Redirection • further action needs to be taken in order to complete the request • 4xx: Client Error • the request contains bad syntax or cannot be fulfilled at this server • 5xx: Server Error • the server failed to fulfill an apparently valid request • 6xx: Global Failure • the request cannot be fulfilled at any server

  12. Transaction

  13. Transaction • A SIP Transaction consists of • A single request • Zero or more provisional responses • One or more final responses • i.e.> • An INVITE request • Final response (which is not 2xx response) • The final ACK is part of the transaction

  14. Transaction Process

  15. INVITEClient Transaction • Timer A • At each retransmit. • T1 = 500ms(default) • Timer B • 64 * T1 • Timer D • At least 32sec. In unreliable transport • The duration, the server transaction can remain in the Complete state • == at INV. Server trans. • Timer C ? • Managed by TU • Update at recv 101 ~199 • Reset to different value • But At least 3 min. • If Fires • CANCLE / treat like 408

  16. INVITE Server Transaction • Timer G • At each retransmit. • T1 = 2 * T1 • T1 = 500ms(default) • Timer H • 64 * T1 • == timer B • Timer I

  17. Non-INVITE Client Transaction • Non-INVITE transaction do not make use of ACK • Simple req-res interactions

  18. Non-INVITEServer Transaction

  19. Transport

  20. Transport Layer • Mandatory • UDP & TCP • If Message size is larger than • Path MTU – 200 • 1300 (at unknown path MTU) • Must be sent using an RFC 2914 (such as TCP)

  21. Registrations

  22. Overview • SIP offers a discovery capability • Registration creates bindings in a location service • Associates • AoR ∈ Contact addresses

  23. Registration Msg.

  24. Discover a Registrar • UA can use three ways to determine the address to which to send registrations • Configuration • With a registrar address • Using AoR • A UA should use the host part of the AoR as the Request-URI and address the request there, using the normal SIP server locations mechanisms • Multicast • Well-known (by all SIP servers) “sip.mcast.net”(224.0.1.75)

  25. Registrar

  26. Dialog

  27. Dialog • Represents a Peer to Peer SIP relationship between two user agents • Facilitates sequencing of messages between the UAs and proper routing of requests • A dialog is identified at each UA with a dialog IDwhich consists of • Call-ID value • A local tag • A remote tag

  28. Creating A Dialog

  29. Requests within a Dialog

  30. Initiating a Session

  31. Overview

  32. UAC Processing • Initial Offer MUST be in either • An INVITE • Answer : 2xx Msg. • Final 2xx response • Answer : ACK • Send INVITE Msg. • UAC waits for response for the INVITE • “Expire:” • Transaction returns a timeout • Treat as if “408”

  33. UAC Processing • 1xx Response • Early dialog • 3xx Response • Using Contact Addr. Depend on Response Code • 4xx ~ 6xx Response • Terminating early dialog

  34. UAS Processing • “Expires:” in INVITE Request • If fires  487 (Request Terminated) • Progress • Can not answer the invitation immediately • Provisional response • To prevent cancelation • UAS must send a non-100 provisional response at every min. • Redirected • 300, 301, 302 • “Contact : ” • Rejected • 488 response should include a warning header • Why the offer was rejected

  35. UAS Processing • Accepted • The UAS core generates a 2xx response. • INVITE contains offer msg. • 2xx response should contain answer

  36. Terminating a Session

  37. Terminating a Session • Each session is Associated with a single dialog • When a BYE is received on a dialog • Any session associated with the dialog should terminated • A UA must not send BYE outside of a dialog

  38. UAs Behavior • UAC • Creates a new non-INVITE client transaction • UAS • UAS receiving BYE msg. • Must check if it matches an existing dialog • If not, responses 481 (Call/Transaction does not exists)

  39. Headers

  40. Summary of SIP headers

  41. Summary of SIP headers(2)

  42. Summary of SIP headers(3)

  43. Summary of SIP headers(4)

  44. Summary of SIP headers(5) • ▶ In “where” • R: in requests • r: in responses • 2xx, 4xx, etc: response code • c: copied from request to response • ▶ In “proxy” • a: can add/concatenate if not present • m: can modify value • d: can delete value • r: must be able to be read (cannot be encrypted) • ▶ In methods • c: conditional o: optional • m: mandatory t: should be sent, but can be omitted • m*: should be sent, but can be omitted (mandatory in stream-based transport protocol)

  45. IETF WGs • Applications Area • General Area • Internet Area • Operations and Management Area • Real-time Applications and Infrastructure Area • Routing Area • Security Area • Transport Area

  46. WGs

  47. ( ㅡ_-)’’

  48. SIP-overload WG Rate-based Overload Control • Limit the request rate a server receives from an upstream element. • Feedback: X requests per second. Loss-based Overload Control • Reduce the request rate a server receives by a percentage X. • Feedback: reduce load by X%. Window-based Overload Control • Limit the number of request a server can receive without confirming a request. • Feedback: send X more requests. Overload Signal-based Overload Control • De-/increase of request rate until a target overload notification rate is reached. • Feedback: server overloaded (503 response without Retry–After header)

  49. Any Questions

More Related