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

SS7 - REQUEST and INDICATION primitives

primitive (Definition from webopedia.com)

A low-level object or operation from which higher-level, more complex objects and operations can be constructed. In graphics, primitives are basic elements, such as lines, curves, and polygons, which you can combine to create more complex graphical images. In programming, primitives are the basic operations supported by the programming language. A programmer combines these primitives to create more complex operations, which are packaged as functions, procedures, and methods.

CCS (Common Channel Signaling)

CAS (Channel Associated Signalling)

TBD

SS7-SCCP (Signalling Connection Control Part)

Introduction



Terms/Abbreviations
SLR
DLR

DTAP

SS7 - ISUP Notes

Fully Associated Signaling
Quasi Associated Signaling

SS7 - ISUP

Terms/Abbreviations

CIC: Circuit Identification Code
OPC: Origination Point Code
DPC: Destination Point Code
SLS: Signalling Link Selection

COT (Continuity Test): To test continuity of bearer channel



ISUP Messages

Complete list of ISUP messages and descriptions:
http://www.asknumbers.com/SS7ISUPMessages.aspx

ACM (Address Complete Message)
An Address Complete Message (ACM) is sent in the "backward" direction to indicate that the remote end of a trunk circuit has been reserved.

The originating switch responds to an ACM message by connecting the calling party's line to the trunk to complete the voice circuit from the calling party to the called party. The terminating switch sends a ringing tone to the calling party's line.



ANM (Answer Message)
When the called party answers, the destination switch terminates power ringing of the called line, removes audible ringing tone from the calling line and sends an Answer Message (ANM) to the originating switch. The originating switch initiates billing after verifying that the calling party's line is connected to the reserved trunk.



Call Progress Message (CPG)
CPG is sent in either direction during the set-up or active phase of the call, indicating that an event, which is of significance, and should be relayed to the originating or terminating access, has occurred.


Circuit Group Response Message (CQR)
Sent in response to a Circuit/CIC Group Query message to indicate the state of all circuits/CICs in a particular range.


Circuit Group Reset Acknowledgement Message (GRA)
GRA is sent in response to a Circuit/CIC Group Reset message indicating that the requested group of circuits/CICs has been reset. The message also indicates the maintenance blocking state of each circuit/CIC.


Confusion Message (CFN)
CFN is sent in response to any message (other than a confusion message) if the node does not recognize the message or detects a part of the message as being unrecognized.


Connect Message (CON)
CON is sent in the backward direction indicating that all the address signals required for routeing the call to the called party have been received and that the call has been answered.

Continuity Message (COT)
COT is sent in the forward direction indicating whether or not there is continuity on the preceding circuit(s) as well as of the selected circuit to the following exchange, including verification of the communication path across the exchange with the specified degree of reliability.

Facility Reject Message (FRJ)
FRJ is sent in response to a facility request message to indicate that the facility request has been rejected.

Information Message (INF)
INF is sent to convey information in association with a call, which may have been requested in an information request message.


Information Request Message (INR)
INF is sent by a node to request information in association with a call.

ISUP - Continuity bit

ISUP - CPG

SS7 - Flow Control - SIB LSSU

SS7 - Signalling Link Alignment

There are two forms of alignment procedures: the emergency procedure and the normal alignment procedure. The emergency procedure is used when the link being aligned is the only available link for any of the routes defined within the SSP. Otherwise, the normal alignment procedure is used.

SS7 - MTP3 (Message Transfer Part 3)

MTP3 does message handling and network management.

Message handling


Signaling Link Management
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signaling link activation,deactivation
SLTM - Signaling Link Test Message
SLTA - Signaling Link Test Acknowledge


Traffic Management
~~~~~~~~~~~~~~~~~~~~~~~~~~
Changeover (COO and COA)
COO - Change Over Order
COA - Change Over Acknowledgment
Changeback (CBD and CBA)
CBD - Change Back Declaration
CBA - Change Back Acknowledgment
Management inhibiting/Uninhibiting
MTP restart
Signaling traffic control
Forced rerouting
Controlled rerouting




Route Management
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TFP (Transfer Prohibited)
FTR (Transfer Restricted)
TFC (Transfer Controlled)
TFA (Transfer Allowed)
SRSM (Signaling-route-set-test)




Clusters
~~~~~~~~~~~~~~



MTP3 Timers -
~~~~~~~~~~~~~~


Timer T17 : Timer T17 (MTP3) prevents the rapid oscillation from in service to out of service. Timer T17 is started when the link begins the alignment procedure. No further alignment attempts are accepted from a remote or local SP until T17 has expired.

SS7 - MTP2 (Message Transfer Part 2)

MTP2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SIO - status indication out of alignment
SIN - status indication normal alignment
SIE - status indication emergency alignment
SIOS - status indication out of service
SIPO - status indication processor outage
SIB - status indication busy


BEC - Basic Error Correction
PCR (Preventive Cyclic Retransmission) Technique
Difference between BEC and PCR
Forced Retransmission
Signaling Link Alignment
Proving Period (T4)
AERM - Alignment Error Rate Monitor
SUERM - Signal Unit Error Rate Monitor
PO - Processor Outage


Link Alignment (Normal and Emergency Alignment)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~







MTP2 Flow Control (SIB - Status Indication Busy)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




MTP2 Timers
~~~~~~~~~~~~~~~~~~~~~~~
T1
T2
T3
T4
T5 -- sending SIB (80 to 120 ms),
T6 -- remote congestion
T7 -- excessive delay of acknowledgment
T8

SS7 - Difference between SLS and SLC

SS7 - Links and books

SS7 Standards

List of SS7 Standards: http://www.c7.com/ss7/ss7_standards.htm

ITU-T Q Series standards: http://www.itu.int/rec/T-REC-Q/en



Books


Signaling System No. 7 (SS7/C7): Protocol, Architecture, and Services
by Lee Dryburgh, Jeff Hewett





























Signaling System 7
By Travis Russell

SS7 - Signalling System 7 - Introduction

Introduction
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~







Power point slide for this picture: SSP-STP-SCP.ppt








SSP: Service Switching Point
STP: Signal Transfer Point
SCP: Service Control point




Terms/Abbreviations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PC (Point Code) : Wikipedia page for point code




SS7 Stack
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




MTP - Message Transfer Part
SCCP - Signalling Connection and Control Part
ISUP - ISDN User Part
TUP - Telephone User Part
TCAP -Transaction Capabilities
MAP - Mobile Application Part
INAP - Intelligent Network Application Part


Power point slide of this picture: SS7-stack.ppt













MTP Layer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FISU - Fill In Signal Unit
LSSU - Link Status Signal Unit
MSU - Message Signal Unit


Flag - 01111110 - Separates two message units.
BSN - Backward Sequence Number
BIB - Backward Indicator Bit
FSN - Forward Sequence Number
FIB - Forward Indicator Bit
The value of the LI (Length Indicator) field determines the signal unit type.

SIO - Service Information Octet
SIF - Signaling Information Field


Power point slide of this figure: FISU-LSSU-MSU.ppt






The FISU is sent when no other signal units are available.

The LSSU is used by the signalling link level to bring the link into alignment.

The MSU carries the actual upper-level information. For example, if ISDN User Part (ISUP) information is to be sent, it will be carried in an MSU.



Service Switching Point (SSP)

Signal Transfer Point (STP)

Service Control Points (SCP)