3.1 SESSION INITIATION PROTOCOL (SIP) OVERVIEW SIP is an application layer protocol that is used for establishing, modifying and terminating multimedia sessions in an Internet Protocol (IP) network. SIP is based on HTTP and, so, is a textual request-response protocol. Clients send requests, and servers answer with responses. In SIP there is just one single protocol, which works end-to-end and supports the establishment and termination of user location, user availability, user capability, session set-up and session management. SIP is also designed to enable additional multimedia sessions and participants to be dynamically added or removed from a session. These are the major reasons SIP has been selected in IMS; it is also considered to be flexible and secure [3]. 3.2 REGISTRAR The Registrar is a repository of user agent's location information. The registrar accepts registration requests from user agents and places the information (the SIP address and associated IP address) in location database. A SIP Register message will tell the Registrar (and the network) at which address (or multiple addresses) the user will be available. 3.3 SIP MESSAGES SIP signaling - the setting up, modification and termination of communication and collaboration sessions - is realized through the exchange of messages. There are two types of messages: requests and responses. Requests are sent to initiate some action and responses are sent as replies to requests acknowledging receipt of requests and indicating the processing status. Requests and responses share a common message format which consist of a start-line (The start line contents vary depending on whether the SIP message is a request or a response. For requests it is referred to as a request line and for responses it is referred to as a status line ), one or more header fields, an empty line indicating the end of the header fields, and an optional message-body. 15
Figure 3.1: SIP message format [4]. An example SIP request looks like: INVITE sip:bob.smith@nokia.com SIP/2.0 Via: SIP/2.0/UDP cscf1.example.com:5060;branch=z9hg4bk8542.1 Via: SIP/2.0/UDP [5555::1:2:3:4]:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 From: Alice <sip:alice@nokia.com>;tag=312345 To: Bob Smith <sip:bob.smith@nokia.com> Call-ID: 105637921 CSeq: 1 INVITE Contact: sip:alice@[5555::1:2:3:4] Content-Type: application/sdp Content-Length: 159 [Body] 3.3.1 SIP REQUEST MESSAGE SIP requests are distinguished from responses using the start line. Figure 3.2 Format of a request message start-line [1]. 16
Method the method indicates the type of request. Six are defined in the base SIP as shown in table 3.1. Request-URI the request-uri is a SIP URI that identifies a resource that the request is addressed to. Protocol version the current SIP version is 2.0. The request-line ends with a carriage-return line-feed sequence (CRLF). Also, no linear white wash is allowed in any of the elements. Table 3.1: List of SIP request methods [1] Method Description REGISTER This method is used to provides the Registrar with information specifying the UA s location and available for incoming SIP requests. When the user agent s location changes, another REGISTER message is sent to update the Registrar s database. INVITE This method is used to initiate a communication session between two UA peers. Sent message is sent by a user to initiate a session with another peer user. ACK This method is used for acknowledgement. It indicates that the final response has been received. CANCEL This method is used to terminate pending requests. A calling party can cancel an INVITE message before it receives the final response. OPTIONS This method is used to query a server on its capabilities. For example, it can be used to query if a to-be-called party can support a particular type of media. BYE This method is used to indicate the termination of a session. 17
3.3.2 SIP RESPONSE MESSAGE SIP responses can be distinguished from requests by looking at the start line. Figure 3.3: Format of a response message start-line [1]. Protocol version this is identical to the protocol version in the request line. Status code the status code is a three-digit code that identifies the nature of the response. It indicates the outcome of the request. Reason phrase this is a free text field providing a short description of the status code. It is mainly aimed at human users [4]. Status codes are classified in six classes: 1xx provisional/informational responses. They indicate that the request was received and the recipient is continuing to process the request. 2xx success responses. The request was successfully received, understood and accepted. 3xx re-direction responses. Further action needs to be taken by the requester in order to complete the request. 4xx client error responses. The request contains a syntax error. It can also indicate that the server cannot fulfill the request. 5xx server error responses. The server failed to fulfill a valid request. It is the fault of the server. 6xx global failure responses. The request cannot be fulfilled at any server. The server responding with this response class needs to have definitive information about the user. 18
The xx are two digits that indicate the exact nature of the response: for example, a 180 provisional response indicates ringing at the remote end [4]. 3.3.3 HEADER FIELDS Header fields contain information related to the request: for example, the initiator of the request, the recipient of the request and call identifier. Header fields also indicate message body characteristics. Where some fields are optional such as content type and length, some fields are mandatory for every SIP message. The format of the header fields is as follows: Header-name: header-value Table 3.2: SIP message mandatory header fields [1] Field name Description To The request destination s SIP address. From Indicates the originator of the request. CSeq The command sequence that ensures messages are dealt with, in the order they were generated. Call-ID A randomly generated string that uniquely identify SIP sessions. SIP proxy servers use Call-ID to identify messages belonging to a SIP session. Via Contains information about SIP devices a message has passed through as it moves between caller and callee. The Via field is also used to route responses in the reverse direction. Contact Contains the actual location of the callee, which might be different from the address of the originator in the From header. 19
3.3.4 MESSAGE BODY The message body (payload) can carry any text-based information. When describing a session the SIP message body is typically a Session Description Protocol (SDP) message. 3.4 SIP EXTENSIONS: SIP can be extended by defining new methods. We saw in Table 3.1 that there are many SIP methods, but that the core protocol only uses a subset of them. The rest of the methods are defined in SIP extensions. 3.4 Message Flow for Session Establishment [2] Using SIP to establish a multimedia session, First of all, the user e.g. Alice registers her current location sip:alice@pda.com with the registrar at domain.com, as shown in Figure 3.4 Figure 3.4: Alice registers her location To do this, Alice sends a REGISTER request (Figure 3.5) indicating that requests addressed to the URI in the To header field sip:alice.smith@domain.com should be relayed to the URI in the Contact header field sip:alice@pda.com The Request-URI of the REGISTER request contains the domain of the registrar (domain.com). 20
REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP 192.0.0.1:5060;branch=z9hG4bKna43f Max-Forwards: 70 To: <sip:alice.smith@domain.com> From: <sip:alice@pda.com>;tag=453448 Call-ID: 843528637684230@998sdasdsfgt Cseq: 1 REGISTER Contact: <sip:alice@pda.com> Expires: 7200 Content-Length: 0 Figure 3.5: (1) REGISTER OF FIGURE 3.4 The registrar responds with a 200 (OK) response (Figure 3.6) indicating that the transaction was successfully completed. SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.0.1:5060;branch=z9hG4bKna43f ;received=192.0.0.1 To: <sip:alice.smith@domain.com>;tag=54262 From: <sip:alice@pda.com>;tag=453448 Call-ID: 843528637684230@998sdasdsfgt Cseq: 1 REGISTER Contact: <sip:alice@pda.com> Expires: 7200 Content-Length: 0 Figure 3.6: (2) 200 OK OF FIGURE 3.4 At a later time, Bob invites Alice to an audio session. Figure 3.7 shows the establishment of the audio session between Bob and Alice through the proxy server at domain.com. Bob sends an INVITE request (Figure 3.8) using Alice s public URI (As the Request-URI) sip:alice.smith@domain.com 21
Figure 3.7: Session establishment through a proxy INVITE sip:alice.smith@domain.com SIP/2.0 Via: SIP/2.0/UDP ws1.domain2.com:5060;branch=z9hg4bk74gh5 Max-Forwards: 70 From: Bob <sip:bob.brown@domain2.com>;tag=9hx34576sl To: Alice <sip:alice.smith@domain.com> Call-ID: 6328776298220188511@192.0.100.2 Cseq: 1 INVITE Contact: <sip:bob@192.0.100.2> Figure 3.8: (1) INVITE OF FIGURE 3.7 The proxy at domain.com relays the INVITE request (Figure 3.9) to Alice at her current location (her PDA). Alice accepts the invitation sending a 200 (OK) response (Figure 3.10), which is relayed by the proxy to Bob (Figure 3.11). Note that Alice has included a Contact header field in her 200 (OK) response. This header field is used by Bob to send subsequent messages to Alice. This way, once the proxy at domain.com has helped Bob locate Alice, Bob and Alice can exchange messages directly between them. Bob uses the URI in the Contact header field of the 200 (OK) response to send his ACK (Figure 3.12). Now that the session (i.e., an audio stream) is established, Bob and Alice can talk about whatever they want. 22
INVITE sip:alice.smith@domain.com SIP/2.0 Via: SIP/2.0/UDP p1.domain.com:5060;branch=z9hg4bk543fg Via: SIP/2.0/UDP ws1.domain2.com:5060;branch=z9hg4bk74gh5 ;received=192.0.100.2 Max-Forwards: 69 From: Bob <sip:bob.brown@domain2.com>;tag=9hx34576sl To: Alice <sip:alice.smith@domain.com> Call-ID: 6328776298220188511@192.0.100.2 Cseq: 1 INVITE Contact: <sip:bob@192.0.100.2> Figure 3.9: (2) INVITE OF FIGURE 3.7 SIP/2.0 200 OK Via: SIP/2.0/UDP p1.domain.com:5060;branch=z9hg4bk543fg ;received=192.1.0.1 Via: SIP/2.0/UDP ws1.domain2.com:5060;branch=z9hg4bk74gh5 ;received=192.0.100.2 From: Bob <sip:bob.brown@domain2.com>;tag=9hx34576sl To: Alice <sip:alice.smith@domain.com>;tag=1df345fkj Call-ID: 6328776298220188511@192.0.100.2 Cseq: 1 INVITE Contact: <sip:alice@192.0.0.1> Figure 3.10: (3) 200 OK OF FIGURE 3.7 SIP/2.0 200 OK Via: SIP/2.0/UDP ws1.domain2.com:5060;branch=z9hg4bk74gh5 ;received=192.0.100.2 From: Bob <sip:bob.brown@domain2.com>;tag=9hx34576sl To: Alice <sip:alice.smith@domain.com>;tag=1df345fkj Call-ID: 6328776298220188511@192.0.100.2 Cseq: 1 INVITE Contact: <sip:alice@192.0.0.1> Figure 3.11: (4) 200 OK OF FIGURE 3.7 23
ACK sip:alice@192.0.0.1 SIP/2.0 Via: SIP/2.0/UDP ws1.domain2.com:5060;branch=z9hg4bk74765 Max-Forwards: 70 From: Bob <sip:bob.brown@domain2.com>;tag=9hx34576sl To: Alice <sip:alice.smith@domain.com>;tag=1df345fkj Call-ID: 6328776298220188511@192.0.100.2 Cseq: 1 ACK Contact: <sip:bob@192.0.100.2> Content-Length: 0 Figure 3.12: (5) ACK OF FIGURE 3.7 24