Session Initiation Protocol

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

48. ( ㅡ_-)’’

49. 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)

50. Any Questions