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
Figure 3.1: SIP message format [4].
An example SIP request looks like: INVITE sip:[email protected] 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:[email protected]>;tag=312345 To: Bob Smith <sip:[email protected]> 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
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.
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.
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.
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
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
should be relayed to the URI in the Contact header field sip:[email protected]
REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/UDP 192.0.0.1:5060;branch=z9hG4bKna43f Max-Forwards: 70 To: <sip:[email protected]> From: <sip:[email protected]>;tag=453448 Call-ID: 843528637684230@998sdasdsfgt Cseq: 1 REGISTER Contact: <sip:[email protected]> 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:[email protected]>;tag=54262 From: <sip:[email protected]>;tag=453448 Call-ID: 843528637684230@998sdasdsfgt Cseq: 1 REGISTER Contact: <sip:[email protected]> 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)
Figure 3.7: Session establishment through a proxy
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP ws1.domain2.com:5060;branch=z9hG4bK74gh5 Max-Forwards: 70
From: Bob <sip:[email protected]>;tag=9hx34576sl To: Alice <sip:[email protected]>
Call-ID: [email protected] Cseq: 1 INVITE
Contact: <sip:[email protected]>
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).
INVITE sip:[email protected] 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:[email protected]>;tag=9hx34576sl To: Alice <sip:[email protected]>
Call-ID: [email protected] Cseq: 1 INVITE
Contact: <sip:[email protected]>
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:[email protected]>;tag=9hx34576sl To: Alice <sip:[email protected]>;tag=1df345fkj Call-ID: [email protected]
Cseq: 1 INVITE
Contact: <sip:[email protected]>
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:[email protected]>;tag=9hx34576sl To: Alice <sip:[email protected]>;tag=1df345fkj Call-ID: [email protected]
Cseq: 1 INVITE
Contact: <sip:[email protected]>
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP ws1.domain2.com:5060;branch=z9hG4bK74765 Max-Forwards: 70
From: Bob <sip:[email protected]>;tag=9hx34576sl To: Alice <sip:[email protected]>;tag=1df345fkj Call-ID: [email protected]
Cseq: 1 ACK
Contact: <sip:[email protected]> Content-Length: 0
