Chap.

5 Session Initiation Protocol

Reference: RFC3261

1. Core SIP
1.1 Introduction
SIP is a signalling protocol. Signaling: Establishing a session Terminating a session Update a session (e.g. media codec) Invoke higher services

SIP messages contain SDP (Session Description Protocol) that describes media. Media: Encoded voice stream, video stream

After a SIP session is established, RTP (Real Time Protocol) is exchanged. It conveys the media.

Importance and advantages of SIP

The signalling protocol adopted by 3GPP, 3GPP2, PacketCable, etc. HTTP-like protocol Plain text Client-server Application layer protocol: programmability

SIP specification suite

IETF specification suite including: SIP core signalling: o RFC 2543, March 1999 o RFC 3261, June 2002 (obsoletes RFC 2543) SIP extensions (e.g. RFC 3265, June 2002 - Event notification)

IMS related extensions. Used in conjunction with other IETF protocols o QOS related protocol (e.g. RSVP) o Media transportation protocol (e.g. RTP - RFC 1989) o Others (e.g. SDP - RFC 2327)

SIP architecture

SIP has a client-server model in which the caller (the client) establishes the connection by sending a request message to the callee (the server) who reacts to requests by appropriate response messages. It supports five features: specifying the user location, determination of the user availability, specifying the user device capabilities, initiating session parameters for calling parties, and control sessions.

SIP architecture consists of the following: user agents, proxy, registrar, and redirect servers. User Agent (UA) represents the endpoint entity in the SIP session and the one that starts and ends SIP media sessions by exchanging SIP messages.

UA is capable of playing the role of client (User Agent Client) and server (User Agent Server) depending on its kind of participation in the call. Proxy server: acts as a median entity which routes calls and can play the role of a client and a server at the same time. It forwards requests on behalf of clients after rewriting parts of the message if necessary, forwards responses on behalf of servers to clients, and can be used to apply policies on the exchanged SIP messages. Redirect server: receives SIP requests and maps addresses in the SIP requests to alternate URIs. Unlike the proxy server, it does not route requests to other servers instead it allows proxy servers to forward calls to exterior domains. Registrar server: responsible for receiving REGISTER SIP messages and updating the user information in the location server of its domain. Usually it is located with proxy or redirect servers.. Location server simply manages the database of the architecture. It mainly stores and retrieves SIP URIs (addresses of SIP user devices and other SIP servers).

SIP messages
SIP protocol is a text-based protocol and its messages are readable. SIP has two types of messages: Request- A SIP message initiated by the client. Response- A SIP message initiated by the server.

Message structure
Quite similar to HTTP messages. It consists of start line, headers and body as follows:

The start line indicates the message type, whether it is a request or a response, and the header contains necessary information for routing the message to the destination. The optional body contains the media description (video, audio or data). It conforms to another protocol: the Session Description Protocol (SDP).

SIP requests
The request message consists of a method token, URI address for the destination. RFC3261 introduced six types of request SIP messages as follows:

Method INVITE ACK BYE CANCEL OPTIONS REGISTER

Purpose Establish a call. Contains information about the participating parties in the call and the media being exchanged. A confirmation message sent by the caller to commit the call establishment To terminate an established call. It can be sent either by the caller or the callee. To end a pending SIP request. To inquire about the capabilities of the other party. Used by a UA to register its address in a registrar server.

SIP responses
A SIP response consists of a three-digit status-code, and a reason expression that indicates the status of the request. The status-code is classified into six different classes with values ranging over 100 - 699. There are two types of SIP response: Provisional: response messages that start with 1xx status-code. Used by the server to indicate the message progress without terminating SIP sessions Final: any response with a status-code other than 1xx can terminate the SIP session: 2xx, 3xx, 4xx, 5xx, 6xx classes. The following table explains the six different response classes:
Status-code 1xx- Provisional 2xx-Success 3xx- Redirection 4xx- Client Error 5xx- Server Error 6xx- Global Failure Description Indicates that the received request is now being processed by the server. Indicates that a message has been received successfully. Indicates the need of intermediate step to complete processing the request. Indicates typography error by the user or a request that could not be done by the server. Indicates that a server could not fulfill a valid client request. Indicates that a request could not be processed/fulfilled by any of the servers.

Example SIP responses

100 Trying Indicates that the request has been received by the server 180 Ringing The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate ringback. 200 OK The request has succeeded. 301 Moved Permanently The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field. 302 Moved Temporarily The requesting client SHOULD retry the request at the new address(es) given by the Contact header field. 400 Bad Request The request could not be understood due to malformed syntax. 401 Unauthorized The request requires user authentication.

403 Forbidden The server understood the request, but is refusing to fulfill it. 404 Not Found The server has definitive information that the user does not exist at the domain specified in the Request-URI. 408 Request Timeout The server could not produce a response within a suitable amount of time. 486 Busy Here The callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. 500 Server Internal Error The server encountered an unexpected condition that prevented it from fulfilling the request. 503 Service Unavailable The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. 603 Decline The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate.

SIP typical call scenario

[http://www.tech-invite.com]

Example SIP headers

To Specifies the targeted recipient of the request. From Indicates the identity of the initiator of the request, possibly the user's address.

Call-ID Acts as a unique identifier to group together a series of messages. Contact Provides a SIP URI that can be used to contact the UA for subsequent requests.
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>

Expires Gives the relative time after which the message (or content) expires.
Expires: 1800

Priority Indicates the urgency of the request as perceived by the client. The header field can have the values "non-urgent", "normal", "urgent", and "emergency", but additional values can be defined. It is recommended that the value of "emergency" only be used when life or property are in imminent danger. Subject Provides a summary or indicates the nature of the call, allowing call filtering.
Subject: Weekend plans Priority: non-urgent

User-Agent Contains information about the UAC originating the request.

User-Agent: Softphone Beta1.5

SIP event notification (RFC 2563, 2779, 3863)

A SIP node may need to be notified of events happening in other nodes Busy / not busy (SIP phones). User A can call again user B when notified that B is now not busy (Automatic Redial service, see below) - Presence service: status of other users o Available, Away, Busy, In-a-meeting, Not-available, On-the-phone, On-vacation, Out-for-lunch.

Presence service

PUA | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

SERVER | | | | | | | | | | ---- M5: PUBLISH ---> | | <--- M6: 200 OK ---- | | | | | | ---- M9: PUBLISH ---> | | <--- M10: 200 OK --- | | | --- M11: PUBLISH ---> | | <-- M12: 200 OK ---- | | | | | |

WATCHER

| <---- M1: SUBSCRIBE --- | | ----- M2: 200 OK -----> | | ----- M3: NOTIFY -----> | | <---- M4: 200 OK ------ | | | | | | | ----- M7: NOTIFY -----> | | <---- M8: 200 OK ------ | | | | | | | | | | | ----- M13: NOTIFY ----> | | <---- M14: 200 OK ----- | |

SUBSCRIBE sip:presentity@example.com SIP/2.0 To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag=12341234 Call-ID: 12345678@host.example.com CSeq: 1 SUBSCRIBE Max-Forwards: 70 Expires: 3600 Event: presence Contact: sip:user@host.example.com Content-Length: 0

PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag=1234wxyz

Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ... <?xml version="1.0" encoding="UTF-8"?> <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf" entity="presentity@example.com "> <impp:tuple id="sg89ae"> <impp:status> <impp:basic>open</impp:basic> <impp:activities> <impp:on-the-phone/> <impp:busy/> </impp:activities> </impp:status> <impp:contact>tel:+09012345678</impp:contact> </impp:tuple> </impp:presence>

NOTIFY sip:user@host.example.com SIP/2.0 To: <sip:watcher@example.com>;tag=12341234 From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 2 NOTIFY Event: presence Contact: sip:pa.example.com Content-Type: application/pidf+xml Content-Length: ... <?xml version="1.0" encoding="UTF-8"?> <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf" entity="presentity@example.com "> <impp:tuple id="sg89ae"> <impp:status> <impp:basic>open</impp:basic> <impp:activities> <impp:on-the-phone/> <impp:busy/> </impp:activities> </impp:status> <impp:contact>tel:+09012345678</impp:contact> </impp:tuple> </impp:presence>

SIP Instant Messaging (RFC 3428)

User 1 Proxy User 2

| F1 MESSAGE |--------------------> | | | | | F4 200 OK |<-------------------| | |

| | | F2 MESSAGE | | ----------------------->| | | | F3 200 OK | | <-----------------------| | | | | | | | | | |

MESSAGE sip:user2@domain.com SIP/2.0 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 ... text here SIP/2.0 200 OK From: sip:user1@domain.com;tag=49394 To: sip:user2@domain.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Length: 0