IBM Israel Software Lab (ILSL) SIP Education. Avshalom Houri June Version IBM Corporation

Transcription

1 SIP Education Avshalom Houri June 2007 Version 2.0

2 Please send comments on: What is missing What is not described well Mistakes To: Avshalom Houri/Haifa/IBM or to: Thanks!

3

4 What is SIP? SIP (Session Initiation Protocol) is a signaling protocol Original usage for SIP is to enable negotiation (and modification) of media sessions between end points The negotiated media can be any media The media may not be going on the same network path as the control protocol After the SIP session is established, it continues to live and may be updated SIP now covers many more areas then only session initiation SIP is a combinatorial protocol with endless compositions

5 Where We Can See SIP Being Used? Session Initiation and Negotiation Presence Instant Messaging Conferences Most common use is in VoIP but this is only the beginning SIP usage have barely scratched the surface (Internet Pioneer Vin Cerf, June 2005)

6 Don t Know Much About History Initial RFC 2543 approved in 1999 as part of the MMUSIC group in the IETF Separate SIP group established in September 1999 Other SIP working group also established: SIPPING SIP Protocol INvestiGation is the requirements group SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions is the presence and IM group P2P SIP Peer-to-Peer SIP SPEERMINT Session PEERing for Multimedia INTerconnect RFC 3261 that obsoletes RFC 2543 was approved in June 2002 A lot of extensions were done and are being done to SIP More then 100 RFCs and 100 I-Ds (Internet Drafts) that relate to SIP currently exist

7 SIP Standardization Protocols: IETF Internet Engineering Task Force IMS: 3GPP Third Generation Partnership program Enablers: OMA Open Mobile Alliance Others: ITU, JCP, ETSI and many more

8 The IETF The standards body that defines internet protocols The IETF is divided into areas Each area has 10 or more working groups Real-Time Applications and Infrastructure (RAI) area is responsible for any real time related work including SIP

9 RFCs & Internet drafts RFC Request For Comments E.g. RFC Internet drafts are work in progress in the IETF E.g. ietf-simple-rpid-0x.txt IETF tracker: IETF tools:

10 MUST, SHOULD, MAY Defined in RFC 2119 Define what should be implemented in order to get an implementation that is compliant with the standard

11 MUST MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification

12 SHOULD SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label

13 MAY MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item while another vendor may omit the same item. All implementations MUST be prepared to interoperate though perhaps with reduced functionality

14 SIP Working Groups SIP Session Initiation Protocol; SIP core group SIPPING SIP Protocol INvestiGation; SIP requirements group SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions; presence and IM group. Note that SIP and SIMPLE are not two protocols but a single protocol SPEERMINT Session PEERing for Multimedia INTerconnect; Connecting SIP domains P2P SIP Peer to Peer SIP; deals with peering at the user level

15 Other Real-Time Working Groups MMUSIC Multiparty Multimedia Session Control; media related protocols IPTEL IP Telephony; Telephony over IP routing and gateway issues ENUM Telephone Number Mapping; DNS mapping of E.164 numbers to URIs BEHAVE Behavior Engineering for Hindrance Avoidance NATs requirements and best current practices XCON Centralized Conferencing; Configuration and Control of conferences and media in conferences

16

17 Main Current Issues at the IETF for SIP Security: How to create end to end security Need to define the meaning of the SIPS URI NAT The ICE protocol Definition of NAT behavior Connecting Domains Presence scalability

18

19 Core SIP Specs RFC 3261 SIP: Session Initiation Protocol Describes the very core of SIP First spec to read although very long (269 pp) RFC 3263 Locating SIP Servers How to locate SIP servers (DNS) based on a SIP URI RFC 3265 SIP Specific Event Notification Defines the SIP methods that enable subscription and notifications See also:

20 SIP Session Example atlanta.com biloxi.com proxy proxy Alice's Bob's softphone SIP Phone INVITE F > INVITE F2 100 Trying F > INVITE F4 < Trying F > < Ringing F6 180 Ringing F7 < Ringing F8 < OK F9 < OK F10 < OK F11 < < ACK F > Media Session <================================================> BYE F13 < OK F > Alice initiates a call to Bob Invite is sent through the SIP proxies of Alice and Bob The 100 and 180 responses are provisional responses SIP invite uses a three way handshake to establish a session After the session is established media can pass between Alice and Bob

21 SIP & HTTP Protocol/Feature HTTP SIP Scope Operation Data access & manipulation Transaction Communication Session Complexity Several drafts 100s of RFCs drafts Connection Authentication TCP Basic or stronger TCP, UDP, SCTP Digest or stronger

22 SIP Protocol Functional Layers UDP Transaction User Transaction Transport Syntax/Encoding TLS TCP/SCTP Syntax/Encoding layer encodes/decodes SIP messaged according to the BNF of SIP Transport layer defines how SIP client send requests and receive responses and how a SIP server receive requests and send responses Transaction layer is where a single SIP transaction is created and handled The Transaction User layer is the logical/application layer Layers are logical and do not dictate implementation

23 SIP User Agents User Agent (UA) A logical entity that acts on behalf of the user (AKA client). When a user agent is sending a message it is a user agent client (UAC) and when it receives a message it is a user agent server (UAS) B2BUA Back to Back User Agent. Two user agents working back to back to each other. One is a UAS, the other is a UAC. Useful when there is a need to do more then just route the call

24 UAC (sends request) UAS (receives request) Alice sends a request to Bob Alice s client is a UAC and Bob s client is a UAS Bob sends a request to Alice Bob s client is a UAC and Alice s client is a UAS

25 UAC Req B2BUA UAS UAC Req UAS Res Res B2BUA (Back 2 Back User Agent) is used when there is a need to change something in the request or responses and the change is not allowed for a proxy The B2BUA gets the request manipulates it and sends a new request towards the destination

26 SIP Message Types Request A message sent form the UAC to the UAS Response A response sent from the UAS for the UAC Provisional response A response sent by the server to indicate progress but do not terminate the transaction

27 SIP Session Example (again) atlanta.com biloxi.com proxy proxy Alice's Bob's softphone SIP Phone INVITE F > INVITE F2 100 Trying F > INVITE F4 < Trying F > < Ringing F6 180 Ringing F7 < Ringing F8 < OK F9 < OK F10 < OK F11 < < ACK F > Media Session <================================================> BYE F13 < OK F > INVITE is a SIP request The 100 and 180 responses are provisional responses 200 OK is a SIP response ACK is also a SIP response Bye is a SIP request 200 OK (for the BYE) is a SIP response

28 SIP URIs Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that can be mapped to another URI (contact) where the user might be available. An AOR is frequently thought of as the "public address" of the user SIP URI A uniform resource identifier as sip:bob@example.com. The SIP URI is the logical identifier of a user. SIPS URI Same as SIP URI but with an S that denotes security. SIPS URI means that all the connections that the message traverse must be of a secure type as TLS (Transport Layer Security) Contact Provides a SIP/SIPS URI that can be used to contact that specific instance of the UA for subsequent requests

29 Example - REGISTER Message REGISTER sip:registrar.xyz.com SIP/2.0 Via: SIP/2.0/UDP bobspc.xyz.com:5060;branch=z9hg4bknashds7 Max-Forwards: 70 To: Bob <sip:bob@xyz.com> From: Bob <sip:bob@xyz.com>;tag= Call-ID: @998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@bobspc.xyz.com> Expires: 7200 Content-Length: 0

30 Transaction Alice Bob Request Provisional (s) Response

31 Dialogs SIP Dialog represents a peer-to-peer relationship between two user agents that persists for some time Dialog identification is composed from Call-ID, the local tag and the remote tag The dialog ID on each side of the dialog is not the same (the remote on one side is local on the other and vice versa) Message headers To: <sip:carol@chicago.com>;tag= From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710 Dialog ID on the UAC is <a84b4c76e66710, , > On the UAS the dialog ID is <a84b4c76e66710, , >

32 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) SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hg4bknashds8;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds ;received= To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown)

33 Dialog Alice Bob Request Early Dialog Dialog Established Provisional (s) Response Dialog Updates Dialog Termination

34 Basic SIP Server

35 SIP Proxy The primary role of a SIP proxy is to route SIP message Sometimes a SIP proxy will be referred to as the SIP server Proxies can also enforce policy (for example, making sure a user is allowed to make a call) A proxy may interpret, and, if necessary, rewrite specific parts of a request message before forwarding it Several types of proxies: stateless, transaction stateful and dialog stateful SIP does NOT require proxy to maintain state, e.g. After the INVITE transaction succeeds, media can be exchanged between endpoints However, for practical deployment reasons (eg charging for length of session), proxies MAY maintain state

36 Transaction Stateless Proxy Alice Transaction Stateless Proxy Bob INVITE ACK 200 OK Simply forwards requests and responses Maintains no timers, does not retransmit any request or responses on its own High-performance

37 Transaction Stateful Proxy Alice Transaction Stateful Proxy Bob INVITE ACK 200 OK Maintains state and executes state-transitions depending on timers and responses e.g. for an INVITE transaction, retransmit INVITE 6 times or till timer B fires (whichever is earlier)

38 Dialog-Stateful Proxy Alice Dialog Stateful Proxy Bob INVITE ACK 200 OK Maintains state from an INVITE to a BYE

39 Redirect Proxy Alice INVITE bob Redirect (3XX) Proxy-1 Enables user migration, load balancing and more INVITE bob Proxy-2

40 SIP Registrar SIP user agent registers to a SIP registrar SIP registrar is a logical database that holds the list of registered users Enables mapping users to their physical locations The registrar can also enable specifying preferences of contacts

41 Registrar Definitions Registrar A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles. Location Service A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of addressof-record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings

42 REGISTER Sequence Alice s Client (alice@xyz.com) SIP Domain (xyz.com) Bob s Client (bob@xyz.com) REGISTER 200 OK REGISTER 200 OK

43 Forking A user may have multiple devices registered in the SIP system A SIP proxy may decide to fork the request to all registered devices of the user Forking may be parallel or sequential The UAC should be prepared to accept multiple responses to the same request

44 Parallel Forking T=2, Req Bob (1) Alice T=1, Req Proxy Bob (2) Bob (3)

45 Sequential Forking T=2, Req Bob (1) Alice T=1, Req Proxy Bob (2) Bob (3)

46 Sequential Forking Alice T=1, Req Proxy T=2, Req T=3, Error Bob (1) Bob (2) Bob (3)

47 Sequential Forking Alice T=1, Req Proxy T=2, Req T=3, Error T=4, Req Bob (1) Bob (2) Bob (3)

48 Sequential Forking Alice T=1, Req Proxy T=2, Req T=3, Error T=4, Req T=5, Error Bob (1) Bob (2) Bob (3)

49 Sequential Forking Alice T=1, Req Proxy T=2, Req T=3, Error T=4, Req T=5, Error T=6, Req Bob (1) Bob (2) Bob (3)

50 Sequential Forking Alice T=1, Req Proxy T=2, Req T=3, Error T=4, Req T=5, Error T=6, Req Bob (1) Bob (2) T=7, 200 OK Bob (3)

51 SIP Timers For unreliable transports as UDP the UAC will use timers when sending a message Basic timer is T1 which is set to the round time between the client and the server The default is 500ms and should be changed only if there is a specific reason as a close fast network or the server being in a far slow network Timer B is set to 64*T1 and when it fires while the transaction is not completed, the transaction is canceled Timer A is initially set to T1 and when it fires while the transaction is not completed, the message is sent again and the timer doubles If a provisional response have been received, timer A is reset and the message is not retransmitted again The message can be retransmitted 6 (7 total) times before timer B fires There are other timers (C to K) that are used during the dialog transition state but will not be covered here

52 SIP Timers (A and B) INVITE T1 2*T1 4*T1 8*T1 16*T1 32*T1 64*T1 Initial Ret. Ret. Ret. Ret. Ret. Ret. Cancel

53 Locating SIP Servers SIP uses several type of transports: TCP, UDP, SCTP, TLS Therefore SIP uses NAPTR and SRV records that enable it to find the servers for a domain and select the appropriate servers from the list Locating SIP servers is defined in RFC 3263

54 Locating SIP Servers Resolving Performing NAPTR query yields: ; order pref flags service regexp replacement IN NAPTR "s" "SIPS+D2T" "" _sips._tcp.example.com. IN NAPTR "s" "SIP+D2T" "" _sip._tcp.example.com IN NAPTR "s" "SIP+D2U" "" _sip._udp.example.com. Client needs TCP and issues an SRV lookup of _sip._tcp.example.com that yields: ;; Priority Weight Port Target IN SRV server1.example.com IN SRV server2.example.com The client will initially use server1 since it has highest priority

55 SIP Event Mechanism The SIP event mechanism (RFC 3265) enables subscribing to any object and receiving notification on the changes to the state of the object The SIP event mechanism defines the methods and functionality that enables sub/notify Actual usages of the SIP events use the mechanism as a basis and define an event package for various types of objects The most known usage of the SIP event packages is presence on people but this is not the only usage Other event packages that were defined in SIP are: Reg-Event subscribing to the registrations of a user Dialog-State subscribing to the state of a dialog Message Waiting Indicator Getting a notification when there is e.g. a voice mail Many others

56 Presence Presence is one example of the usage of the basic SIP event mechanism Presence includes awareness on people and on watchers of people Core presence RFC is 3856 Basic presence document is based on PIDF Presence extensions that enable a lot more information on a user have been standardized (RPID, Location) The information that is managed by the presence server can actually replace the registrar (especially if the presence server gets the registrar information from the registrar using the reg-event package)

57 Presence Server Bob s Dev1 Bob s Dev2 Publish Status Presence Server Sub/Notify Alice

58 SUBSCRIBE/NOTIFY Sequence Alice s C lie n t (a xyz.co m) SIP D o ma in (xyz.co m) Bo b s C lie n t (b o xyz.co m) SUBSC R IBE O K NOTIFY O K PUBL ISH O K NOTIFY O K

59 Presence Document Sample <presence xmlns="urn:ietf:params:cpim-presence:"> <presentity <tuple id="sip-useragent"> <status> <basic>open</basic> </status> <contact <note>ready to chat!</note> </tuple> </presence>

60 Messaging (Chat) Enables text messaging via SIP Initially page mode messaging only was defined in SIP Page mode contradicts the SIP philosophy of not passing media through the protocol Usage of page mode message is being strongly discouraged MSRP Message Session Relay Protocol has been standardized Actually it does what is very logical to SIP: Defining a new media for text and sending it after SIP session establishment

61 Page Mode (MESSAGE) Sequence Alice s Client (alice@xyz.com) SIP Domain (xyz.com) Bob s Client (bob@xyz.com) MESSAGE MESSAGE 200 OK 200 OK

62 MSRP Sequence

63 SIP Security Why is it Complex? SIP is not a client server protocol Typical SIP deployment contains many components It may be that not all components are under the same control For example in the simplest example where Alice calls Bob, there are the following components involved: Alice s client Alice s proxy Bob s proxy Bob s registrar Bob s client

64 SIP Security Current Solutions There is no overall security solution in SIP There are several building blocks (more like a Lego) that can be used In reality a full security solution can be more realized in a closed system like IMS where the control is by single authority or by several trusted authorities

65 SIP Security Building Blocks Digest Authentication Enables a user to authenticate with a proxy It is possible to use digest authentication with other user but it is less realistic since the other user needs to have a access to the authenticating user credentials TLS/IPSEC Enables securing single or more hops Usually used between client and proxy and between proxies S/MIME Secure MIME Enables real end to end protection of data but requires private/public keys to be installed at end points

66 SIP Security Other Building Blocks SIPS URL Indicates secure path of the message Can not be really trusted if middle points are not trusted Problem with last hop (last proxy to client) since it is not required to be secured Privacy Hide the user ID Defined in RFC Main challenge is how to hide the identity of the user while still enabling routing Domain Identity Domain to domain assertion Defined in RFC Uses P-Asserted-Identity header. Heavily used in IMS User Identity Assert the identity of a user Defined in RFC Asserts the identity of the user while using some authorization authority without using public/private keys

67 SIP, NATs and Firewalls Why is it Complex? Normal protocols like HTTP are in one direction client to server SIP is bi-directional. Either side can initiate a request HTTP is only TCP SIP is UDP also HTTP session is short SIP session is long NATs translate IPs and ports SIP negotiates media IPs and ports

68 SIP and Firewalls Firewalls control ingoing and outgoing traffic into a network In order to enable SIP traffic the firewall should be SIP aware and configured to allow the traffic There is no need for IP/port translation as in NATs

69 SIP and NATs Like Oil and Water Need to translate internal to external IP addresses and ports, including: Contact headers Via headers Route headers SDP IP and ports v=1 Internal o=- V=- C=IN IP t=m=video 4004 RTP/AVP a=rtpmap:14 MPA/90000 v=1 External o=- V=- C=IN IP t=m=video 3201 RTP/AVP a=rtpmap:14 MPA/90000

70 SIP and NATs Some Solutions STUN Simple Traversal of UDP through NATs is the main protocol that is used for traversing firewalls in SIP (RFC 3489) ICE (Interactive Connectivity Establishment) draft-mmusicice-15.txt converges current solutions of NATs and FWs and defines an overall methodology (6 years of work) Session Border Controller (SBC) and/or Application Level Gateway (ALG) Reads and understands the protocol and translates addresses Capacity problems Security problems Liked by service providers since it gives them control

71 Interoperability SIP does not have many methods however, the possible combination of SIP methods, headers and scenarios is endless There is a very strong need to make sure that different implementations of SIP are correct and interoperate with each other There are differences in implementations due to differences in how the RFC is interpreted and old implementations that implemented RFC 2543 Several interoperability events are being held by several organizations, e.g. SIPit, OMA TestFests and more

72 SIP Conferencing Several RFCs talk about conferences in SIP: internet drafts were lately approved as RFCs for SIP conferencing 4353 A Framework for Conferencing with the Session Initiation Protocol (SIP) RFC A Session Initiation Protocol (SIP) Event Package for Conference State 4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents The XCON working group is responsible for defining centralized conference control and media control XCON does not deal with the way the conference itself is implemented Every protocol that implements conferencing can do it on its way

73 SIP Conference

74 Gateways In order for SIP to succeed it has to be able to work with other protocols Protocols can be legacy as PSTN and H.323 or new as XMPP SIP Other gateways are becoming and important product in the SIP market Most RFCs and drafts that specify gateways behavior are informational or BCP (Best Current Practice)

75 SIP PBX

76 SIP PBX + PSTN Gateway

77 XMPP A Competing protocol in presence and IM XMPP extensible Messaging and Presence Protocol XMPP is a competitor protocol for the presence and IM part of SIP It is much simpler to implement since it is TCP only and does not deal with session management and the numerous extensions that SIP has The simplicity of the protocol is also its disadvantage since it does not deal with the media session creation world that is a huge market The telco industry have adopted SIP in all fronts Google Talk is using a version of XMPP It seems that both protocols will live together for the near future

78 Configuration (XCAP) Configuration of SIP devices and other components is important due to the vast amount of devices that will be in a SIP system XCAP XML Configuration Access Protocol is emerging as the choice protocol for SIP configuration XCAP was already adopted by the mobile industry as the choice protocol for configuration XCAP is also important for SIP presence. Used for: User list (buddy list) Authorization (privacy) list Note that XCAP is actually an HTTP protocol and not an extension of SIP but in a lot of deployments (e.g. 3GPP IMS) is used in conjunction with SIP

79 Questions? Thanks

80

81 SIP Messages SIP is text based protocol and uses the UTF-8 charset (RFC 2279) A SIP message is either a request from a UAC or response from a UAS Generic SIP message format: generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line

82 SIP Requests Request-Line = Method SP Request-URI SP SIP-Version CRLF Method The method name, e.g. INIVITE, ACK BYE Request-URI A URI that indicates the user or the service to which the request is intended. The URI can be sip:, sips: or other URI as tel: URI SIP-Version Should be SIP/2.0 Example: REGISTER sip:registrar.xyz.com SIP/2.0

83 SIP Responses Status Line: SIP-Version SP Status-Code SP Reason-Phrase CRLF SIP-Version Should be SIP/2.0 Status-Code 3 digit code that indicates that outcome of an attempt to understand and satisfy a request Reason-Phrase A text that describes the status-code. The text content and processing of it is not mandatory

84 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) SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hg4bknashds8;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds ;received= To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) Request Line

85 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) SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hg4bknashds8;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds ;received= To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) Status Line

86 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) SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hg4bknashds8;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds ;received= To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) Method

87 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) SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hg4bknashds8;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds ;received= To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) Request URI

88 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) SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hg4bknashds8;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds ;received= To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) SIP Version SIP Version

89 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) SIP/ OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hg4bknashds8;received= Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds ;received= To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) Reason Phrase Status Code

90 SIP URI User identifies the user in the domain and the password is the password for the user. Sending passwords in SIP URI is not recommended The is optional Host is the host that can provide the requested resource. The host can be either an FQDN or an actual IP (v4 and v6 are supported) Port The port number where the request is to be sent. Port is optional and the default SIP port of 5060 is assumed when it is missing URI parameters are in the form of parameter-name=parameter-value and can affect the request. Parameters are extensible and SIP components must ignore parameters that they do not understand Headers are header fields to be part of the request constructed from the URI Headers are encoded as ampersand separated hname=havalue pairs

91 Other URI Types SIPS is equivalent to SIP URI but indicates that the message must be sent only via secure transports e.g. TLS The security must be from the UAC to its proxy and in every hop until the destination is reached Additional URIs that may be supported by SIP components as: tel:, pres:, im: and more

92 SIP Headers There are dozens of header fields in SIP Some of the header fields must appear in every message while others must or may appear only under certain conditions Forty four headers are defined in RFC 3261 SIP extensions define additional header fields or define new meaning to header fields in new SIP methods The headers that are mostly used are described in next slides

93 From & To Headers From: "A. G. Bell" ;tag=a48s To: The Operator From header indicates the initiator of the request To header indicates the logical recipient of the request Display name is optional and is meant to be rendered for human user interface Tags are used for dialog ID construction

94 Via Header Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hg4bk87asdks7 Via headers indicate the route that the messages have taken so far, thus indicating the reverse route that the response should take The first via header is added by the initial hop of the request which is the UAC that sends the request The branch parameter identifies the transaction and must start with the magic cookie: "z9hg4bk. The cookie indicates that the via header was created by an implementation that is compliant with RFC 3261 Via headers are not route headers. They are valid only for the transaction while the route headers are valid for the dialog

95 Record-route and Route Headers Record-route is added by each stateful proxy indicating the it needs to be part of the routing path After the initial response is received the Record-route(s) becomes the route set Record routing is one of the major differences between RFC 2534 and RFC 3261 Implementations of RFC 3261 have to be backward compatible with RFC 2534, thus making record routing implementation a complex issue

96 Record-route and Route Headers INVITE INVITE SIP/2.0 Contact: Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr> 200 OK SIP/ OK Contact: Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr> BYE BYE SIP/2.0 Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>

97 Call-ID Header Call-ID: Call-ID identifies a particular invitation or all registrations of a particular client Call-ID is case sensitive The Call-ID combined with the To and From tag identifies a dialog between two SIP components

98 CSeq Header CSeq: 4711 INVITE CSeq orders transactions within a dialog. E.g. re- INVITE Two CSeq headers are considered equal is the number and the method are equal The number in CSeq is a 32 bit unsigned number and the initial number can be arbitrary Subsequent transactions within a dialog must increment the number by one

99 Contact Header Contact: "Mr. Watson" ;q=0.7; expires=3600 The contact header field contains SIP or SIPS URI and enables getting back to the specific SIP UA for subsequent requests The contact header field must be present in every request that may lead to a dialog. E.g. INVITE, SUBSCRIBE The q and expires parameters are only valid in the REGISTER method In the SIP MESSAGE method, the contact header is not allowed to prevent using the page-mode message method for the creation of SIP sessions

100 Max-Forwards Header Max-Forwards: 70 The Max-Forwards header provides for loop prevention in SIP Every time the message passes a hop the number is decremented and the message is rejected with the error 483 (too many hops) when the count reaches 0 70 was chosen as the initial default value so it will not be too small and not too large

101 WWW-Authenticate & Authorization Headers The WWW-Authenticate is usually sent in an 401 error response and it contains the challenge for the digest authentication as defined in RFC 2617 The receiver of the authentication challenge responds by regenerating the request with the Authorization header that contains an encrypted secret (e.g. password) where the encryption is based on the parameters sent in the WWW- Authenticate header

102 WWW-Authenticate & Authorization Headers WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41 Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", qop=auth, nc= , cnonce="0a4f113b", response="6629fae49393a c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"

103 Supported & Unsupported Headers Supported: 100rel Unsupported: foo The Supported and Unsupported header fields indicate standard track SIP extensions that are either supported or unsupported by the UAC or UAS This enables the UAC and UAS to be able to use or not use SIP extensions that may be available on either side

104 Require Header Require: 100rel The Require header is inserted by the UAC and lists the SIP extensions that must be supported by the UAS in order to be able process the request properly If the UAS does not support the extensions listed in the Require header the UAS must respond with an 420 error (bad extension) listing the unsupported extensions using the Unsupported header Example: UAC->UAS: INVITE SIP/2.0 Require: 100rel UAS->UAC: SIP/ Bad Extension Unsupported: 100rel

105 User Agent Header User-Agent: Softphone Beta1.5 The User-Agent header specifies the type and version of the user agent Even if it is good for debugging in general attackers may use this knowledge in order to attack vulnerabilities that are known to exist in that user agent Therefore the inclusion of the User-Agent header should be configurable

106 SIP Status Codes Status codes are 3 digit codes First digit of the code defines the class of the response Last two digit do not have any classification, therefore responses between the range of are referred to as 1XX response and so on

107 SIP Status Codes Classes Six classes are defined in current version of SIP: 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

108 REGISTER Enables a user to register his/hers devices to the registrar The registrar forms the database for the location server When a user initiates a session with a user the registrar is consulted in order to find the contacts where the user may be found

109 REGISTER Message REGISTER sip:registrar.xyz.com SIP/2.0 Via: SIP/2.0/UDP bobspc.xyz.com:5060;branch=z9hg4bknashds7 Max-Forwards: 70 To: Bob From: Bob Call-ID: CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0

110 REGISTER Sequence Alice s Client (alice@xyz.com) SIP Domain (xyz.com) Bob s Client (bob@xyz.com) REGISTER 200 OK REGISTER 200 OK

111 INVITE The INVITE method is what SIP was created for initially The INVITE creates a dialog (a session) between two SIP endpoints The INVITE is one of the few SIP methods that is a three way handshake

112 INVITE Sequence

113 INVITE Message INVITE SIP/2.0 Via: SIP/2.0/UDP pc33.xyz.com;branch=z9hg4bknashds8 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: INVITE Max-Forwards: 70 Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=usera IN IP4 here.com s=session SDP c=in IP4 pc33.atlanta.com t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000

114 ACK, CANCEL, BYE ACK method is the last message that is sent on an INVITE three way handshake and it establishes the INVITE session CANCEL can be sent only on INVITE and it is sent by the UAC that initiated the INVITE if it wishes to cancel the request BYE can be sent by either side of the INVITE after the session is established The BYE method followed by 200 OK closes the session that was created by the INVITE

115 OPTIONS The OPTIONS method enables querying a user or a proxy about their capabilities The OPTIONS may be used also inside a dialog in order to know the capabilities of the other side to the dialog The result of the OPTIONS query is returned as part of the content of the 200 OK that responds to the OPTIONS request

116 OPTIONS Request OPTIONS SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bkhjhs8ass877 Max-Forwards: 70 From: Alice To: Call-ID: a84b4c76e66710 CSeq: OPTIONS Contact: Accept: application/sdp Content-Length: 0

117 Options Response SIP/ OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bkhjhs8ass877;received= To: From: Alice Call-ID: a84b4c76e66710 CSeq: OPTIONS Contact: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp Accept-Encoding: gzip Accept-Language: en Supported: foo Content-Type: application/sdp Content-Length: 274 (SDP not shown)

118 INFO The INFO method (RFC 2976) is a simple way to convey information from one SIP component to the other It can be used for example during a dialog for conveying application information to the other side The body of the INFO method is not standardized

119 PRACK PRACK PRovisional ACK (RFC 3262), is used for sending provisional responses ( ) reliably 100 (Trying) is an hop-by-hop message and therefore can not use the PRACK method which is a end-to-end method UAC INVITE 183 In progress+100rel PRACK 200 OK (on PRACK) UAS

120 UPDATE The UPDATE method (RFC 3311) enables updating a session even before it is established re-invite can also be used to update a session but re-invite Affects the status of the dialog while UPDATE affects only the status of the session UPDATE can be used only before the initial INVITE has been completed

121 UPDATE Example Caller Callee (1) INVITE with offer > (2) 180 with answer 1 < (3) PRACK > (4) 200 PRACK < (5) UPDATE with offer > (6) 200 UPDATE with answer 2 < (7) UPDATE with offer 3 < (8) 200 UPDATE with answer > (9) 200 INVITE < (10) ACK >

122 REFER REFER method (RFC 3515) enables referring another user to some resource REFER will be used for example in call transfer when for example Alice is in a a call with Bob and decides that Bob needs to talk to Carol It is possible for the referrer to get notified regarding the progress of the referred call using the SIP event mechanism

123 REFER Sequence Agent A Agent B F1 REFER > F2 202 Accepted < F3 NOTIFY < F4 200 OK > > (whatever) < F5 NOTIFY < F6 200 OK >

124 REFER Message REFER SIP/2.0 Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hg4bk To: From: Call-ID: CSeq: REFER Max-Forwards: 70 Refer-To: (whatever URI) Contact: Content-Length: 0

125 SIP Event Mechanism The SIP event mechanism (RFC 3265) enables subscribing to any object and receiving notification on the changes to the state of the object The SIP event mechanism defines the methods and functionality that enables sub/notify Actual usages of the SIP events use the mechanism as a basis and define an event package for various types of objects The most famous usage of the SIP event packages is presence on people but this is not the only usage Other event packages that were defined in SIP are: reg-event subscribing to the registrations of a user dialog-state subscribing to the state of a dialog Many more

126 SUBSCRIBE SUBSCRIBE enables subscribing to a URI where the URI identifies an object on which the subscriber wants to get notifications on status change The SUBSCRIBE method specifies the event type that it subscribes to The event type may is defined as part of the event package that is defining event mechanism for specific type of object

127 SUBSCRIBE Example SUBSCRIBE SIP/2.0 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hg4bknashds7 To: From: Call-ID: CSeq: SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: Expires: 600 Content-Length: 0

128 SUBSCRIBE Example SIP/ OK Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hg4bknashds7 ;received= To: From: Call-ID: CSeq: SUBSCRIBE Expires: 600 Contact: sip:server.example.com Content-Length: 0

129 NOTIFY The NOTIFY method is used to notify the subscriber on a resource on a change to the status of the subscribed resource An initial NOTIFY is sent upon the acceptance of the subscription and subsequent notifies are sent when the status of the resource changes The default NOTIFY sends all the information about the resource Work is underway in the IETF to enable partial notifies in which only what is changed will be sent in the NOTIFY

130 NOTIFY Example NOTIFY SIP/2.0 Via: SIP/2.0/TCP server.example.com;branch=z9hg4bkna998sk From: To: Call-ID: Event: presence Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: sip:server.example.com Content-Type: application/pidf+xml Content-Length:... [PIDF Document]

131 PUBLISH PUBLISH method (RFC 3903) enables a resource to publish changes on its state The PUBLISH method is one way for a resource to publish the changes. Other methods may exist which are not SIP based for publishing a state of resource Current PULISH method publishes the whole state of the resource Work is underway to define partial publication of a state

132 PUBLISH Example PUBLISH SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hg4bk652hsge To: From: Call-ID: CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length:... [Published PIDF document]

133 SUBSCRIBE/NOTIFY Sequence Alice s C lie n t (a xyz.co m) SIP D o ma in (xyz.co m) Bo b s C lie n t (b o xyz.co m) SUBSC R IBE O K NOTIFY O K PUBL ISH O K NOTIFY O K

134 Presence Document Sample <presence xmlns="urn:ietf:params:cpim-presence:"> <presentity <tuple id="sip-useragent"> <status> <basic>open</basic> </status> <contact <note>ready to chat!</note> </tuple> </presence>

135 MESSAGE The MESSAGE method (RFC 3428) is a page-mode message that is sent from one user to the other There is no notion of session in the MESSAGE method and therefore there is no guarantee that two subsequent messages will arrive at the order that they were sent The MESSAGE method is a deviation from the SIP philosophy that media should not be sent on the control path and therefore its usage is only for page-mode messages Work is underway to define media for instant messaging. The work is known as MSRP Message Session Relay Protocol and is very close to be finished

136 MESSAGE Sequence Alice s Client (alice@xyz.com) SIP Domain (xyz.com) Bob s Client (bob@xyz.com) MESSAGE MESSAGE 200 OK 200 OK

137 MESSAGE Message Note that Contact header is not allowed in MESSAGE. This is done in order to discourage using the MESSAGE method for sessions MESSAGE SIP/2.0 To: From: Call-ID: 22_0c10c3f CSeq: 2 MESSAGE Via: SIP/2.0/TCP :5060;branch=z9hG4bK0 Content-Type: text/plain Content-Length:11 Max-Forwards: 70 Hello

138 Thanks