SIP (Session Initiation Protocol) -- Introduction

Introduction

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating multimedia sessions(voice/video calls) with one or more participants.

SIP support following five facets of establishing and terminating multimedia communications:

1. User Location: Determination of End System to be used for communication.
2. User Availability: Determination of the willingness of the called party to engage in communications
3. User Capabilities: Determination of the media and media parameters to be used.
4. Session Setup: “Ringing”, establishment of session parameters at both called and calling party.
5. Session Management: Including transfer and termination of sessions, modifying session parameters, and invoking services.


BASIC SIP CALL FLOW























Few Terms/Abbreviations

URI: Uniform Resource Identifier – ex: sip:abc@xyz.com
UAC - User Agent Client
UAS - User Agent Server
UA - User Agent
B2BUA - Back To Back Uger Agent (UAC + UAS): It is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.


Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543.

SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.

Loose Routing: A proxy is said to be loose routing if it follows the procedures defined in RFC 3261 for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.


Strict Routing: A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 and many prior work in progress versions of this RFC. That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present. Strict routing behavior is not used in RFC 3261, in favor of a loose routing behavior. Proxies that perform strict routing are also known as strict routers.


Few salient points about SIP

• SIP is end-to-end, client-server session signaling protocol
  
• SIP clients use TCP or UDP typically using port 5060 to connect to SIP servers and other SIP endpoints.Most implementation use UDP.
• Transport-independent, because SIP can be used with UDP, TCP, ATM, TLS,SCTP & so on.
• Lightweight, in that SIP has only six methods, reducing complexity.
• Text-based, allowing for humans to read SIP messages.
• Involved only in the signaling portion of a communication session.
  
  

SIP Components

SIP Proxy Server
Relays call signaling, i.e. acts as both client and server operates in a transactional manner, i.e., it keeps no session state (stateless/stateful proxies??).
It helps route requests to the user's current location, authenticates and authorizes users for services, implements provider call-routing policies, and provides features to users."

Forking proxies needs to be stateful

SIP Redirect Server
Redirects callers to other servers

SIP Registrar
Accept registration requests (REGISTER) from users maintains user’s whereabouts at a Location Server (like GSM's HLR)

SIP Location Server
Used by a SIP redirect or proxy server to obtain information about a called party’s possible location (s)



SIP Call Flow (SIP Trapezoid)

SIP Methods

INVITE - Requests a session
ACK - Final response to the INVITE
OPTIONS - Ask for server capabilities
CANCEL - Cancels a pending request
BYE - Terminates a session
REGISTER - Sends user’s address to server

SIP Responses

1XX Provisional 100 Trying

2XX Successful 200 OK

3XX Redirection 302 Moved Temporarily

4XX Client Error 404 Not Found

5XX Server Error 504 Server Time-out

6XX Global Failure 603 Decline


SIP Header Fields

Request Line:
INVITE sip:marconi@radio.org SIP/2.0
(Method) Rx-URI SIP-VERSION

To:
The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or maynot be the ultimate recipient of the request.

From:
The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record.

Call-ID:
The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA.

From SIP RFC 3261 - The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive and are simply compared byte-by-byte.

The compact form of the Call-ID header field is i.
Examples:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4


CSeq: (32 it)
The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request.

From SIP RFC 3261 - A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number MUST be expressible as a 32-bit unsigned integer. The method part of CSeq is case-sensitive. The CSeq header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if the sequence number and the request method are identical.
Example: CSeq: 4711 INVITE

Max-Forwards: (Default Value 70??)
The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response.

VIA:
The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent.

When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server.
The branch parameter value MUST be unique across space and time all requests sent by the UA.
The branch ID inserted by an element compliant with RFC3261 MUST always begin with the characters "z9hG4bK".

Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b


Contact:
The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in Rfc3261 specification, that includes only the INVITE request.
Contact: ~~sip:n.tesla@lab.high-voltage.org~~ (~~X~~ encloes in angular bracket)

SIP Registeration

~~~~~ TBD~~~~~

SIP Redirection

SIP Routing

• A request from User Agent – A to User Agent – B may be routed through several proxies.
• Via Header: Each time a proxy forwards a message it appends a ‘Via’ Header to the list of forwarding proxies. It is useful to detect the routing loops.
• SIP Clients can add a Contact header so that each client can send them requests directly and therefore proxies are not guaranteed to be in the path of all request.
• Record Route Header: It may be desirable to follow the same route back. For example, proxy might be Billing Proxy and needs to have access to all the information regarding the call. When the proxies get the request then they insert the Record-Route header inserting their SIP URL.

More SIP Call Flows

TBD



FAQs

How SIP request is distinguished from response?

SIP - Redirect Servers

From SIP RFC 3261
8.3 Redirect Servers
In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection.

Redirection allows servers to push routing information for a request back in a response to the client, thereby taking themselves out of the loop of further messaging for this transaction while still aiding in locating the target of the request. When the originator of the request receives the redirection, it will send a new request based on the URI(s) it has received. By propagating URIs from the core of the network to its edges, redirection allows for considerable network scalability.

A redirect server is logically constituted of a server transaction layer and a transaction user that has access to a location service of some kind (see Section 10 for more on registrars and location services). This location service is effectively a database containing mappings between a single URI and a set of one or more alternative locations at which the target of that URI can be found.

A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server either refuses the request or gathers the list of alternative locations from the location service and returns a final response of class 3xx. For well-formed CANCEL requests, it SHOULD return a 2xx response. This response ends the SIP transaction. The redirect server maintains transaction state for an entire SIP transaction. It is the responsibility of clients to detect forwarding loops between redirect servers.

When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alternative locations into the Contact header field. An "expires" parameter to the Contact header field values may also be supplied to indicate the lifetime of the Contact data.

The Contact header field contains URIs giving the new locations or user names to try, or may simply specify additional transport parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) response may also give the same location and username that was targeted by the initial request but specify additional transport parameters such as a different server or multicast address to try, or a change of SIP transport from UDP to TCP or vice versa.

However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server MAY proxy the request to the destination URI, or MAY reject it with a 404.

If a client is using an outbound proxy, and that proxy actually redirects requests, a potential arises for infinite redirection loops.

Note that a Contact header field value MAY also refer to a different resource than the one originally called. For example, a SIP call connected to PSTN gateway may need to deliver a special informational announcement such as "The number you have dialed has been changed."

A Contact response header field can contain any suitable URI indicating where the called party can be reached, not limited to SIP URIs. For example, it could contain URIs for phones, fax, or irc (if they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 discusses implications and limitations of redirecting a SIPS URI to a non-SIPS URI.

The "expires" parameter of a Contact header field value indicates how long the URI is valid. The value of the parameter is a number indicating seconds. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Malformed values SHOULD be treated as equivalent to 3600.

This provides a modest level of backwards compatibility with RFC 2543, which allowed absolute times in this header field. If an absolute time is received, it will be treated as malformed, and then default to 3600.

Redirect servers MUST ignore features that are not understood (including unrecognized header fields, any unknown option tags in Require, or even method names) and proceed with the redirection of the request in question.

SIP - Route and Record-route

SIP-Route and Record-route: My Google Doc

SIP versus H.323

H.323 v/s SIP

SIP - Books and Links

SIP Books


























Links

SIP RFC 3261
SIP RFC 3261: My Google Doc
SIP PSTN Call Flows: My Google Doc
IETF SIP Charter