1 SIP Overview

7/31/2019 1 SIP Overview

1/26

1 Nokia Siemens Networks Presentation / Author / Date

Soc Classification level

SESSION INITIATION PROTOCOL

Andrea De IuriNSN ITALY


2/26



Overview

SIP is an application layer protocol that is used forestablishing, modifying

and terminating multimedia sessions in an Internet Protocol (IP) network.

SIP was created with the following design goals in mind:

transport protocol neutrality able to run over reliable (TCP, SCTP)and unreliable (UDP) protocols;

request routing direct or proxy-routed (control); separation ofsignaling and media description can add new

applications or media;

extensibility;

personal mobility.


3/26



SIP Architecture

Elements in SIP can be classified as User Agents (UAs) and

Intermediaries (servers).

A SIP UA or terminal is the end point of dialogs: it sends and receives SIPrequests and responses, it is the end point of multimedia streams

The UA consists of two parts:

User Agent Client (UAC) the caller application that initiates requests;

User Agent Server (UAS) accepts, redirects, rejects requests and sendsresponses to incoming requests on behalf of the user.

SIP intermediaries are logical entities through which SIP messages pass ontheir way to their final destination. These Intermediaries are used to routeand redirect requests.


4/26



SIP Architecture (continued)

The Intermediary Servers are:

Proxy server receives and forwards SIP requests. It can interpret or re-write certain parts of SIP messages that do not disturb the state of arequest or dialog at the end points, including the body.

Redirect server maps the address of requests to new addresses. Itredirects requests but does not participate in the transaction.

Location server keeps track of the location of users.

Registrar server a server that accepts REGISTER requests. It is usedto store explicit binding between a users address of record (SIP address)and the address of the host where the user is currently residing or wishesto receive requests.


5/26



SIP Architecture (continued)

Two more elements that are used to provide services for SIP users:

Application Server an AS is an entity in the network that provides end-users with a service. Typical examples of such servers are presence andconferencing servers.

Back-to-Back-User-Agent as the name depicts, a B2BUA is where aUAS and a UAC are glued together. The UAS terminates the request justlike a normal UAS. The UAC initiates a new request that is somehowrelated to requests received at the UAS end, but not in any protocol-specific link. This entity is almost like a proxy, but breaks all the rules thatgovern the way a proxy can modify a request.


6/26



SIP Entities


7/267 Nokia Siemens Networks Presentation / Author / Date


SIP TRAPEZOID




Private and Public User Identities




Private and Public User Identities (continued)




Public Identifiers Used in SIP

Two main types of identifiers are used in SIP:

SIP URI (sip:[email protected])

and

TEL URI (tel:+358912345678)




SIP Protocol Message Format




SIP Message Format (Start Line)

The SIP message is made up of three parts: the start line, message headers and body.The start line contents vary depending on whether the SIP message is a request or aresponse. For requests it is referred to as a request line and for responses it is referred to asa status line.

An example SIP request looks like:

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP cscf1.example.com:5060;branch=z9hG4bK8542.1Via: SIP/2.0/UDP [5555::1:2:3:4]:5060;branch=z9hG4bK45a35h76

Max-Forwards: 69

From: Alice ;tag=312345

To: Bob Smith

Call-ID: 105637921

CSeq: 1 INVITE Contact: sip:alice@[5555::1:2:3:4]

Content-Type: application/sdpContent-Length: 159

[body]


13/26



SIP Requests (Start Line = Request Line)

SIP requests are distinguished from responses using the start line. The start

line in the request is often referred to as the request line. It has threecomponents: a method name, a request-URI and the protocol version.

Method the method indicates the type of request. Six are defined in thebase SIP specification [RFC3261]: the INVITE, CANCEL,

ACK,BYE,REGISTER,OPTIONS.Other methods have been created as anextension to [RFC3261].

Request-URI the request-URI is a SIP or a Secure SIP (SIPS) URI thatidentifies a resource that the request is addressed to.

Protocol Version the current SIP version is 2.0.


14/26



SIP Responses (Start Line = Status Line)

SIP Responses can be distinguished from requests by looking at the start

line. The start line in the response is often referred to as the status line.It has three components: the protocol version, status code and reasonphrase.

Protocol Version this is identical to the protocol version in the requestline.

Status Code the status code is a three-digit code that identifies thenature of the response. It indicates the outcome of the request.

Reason Phrase this is a free text field providing a short description ofthe status code. It is mainly aimed at human users.


15/26



SIP Responses (Status Codes)

Status codes are classified in six classes (classes 2xx to 6xx are final responses):

1xx provisional/informational responses. They indicate that the request was received andthe 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 tocomplete the request.

4xx client error responses. The request contains a syntax error. It can also indicate thatthe server cannot fulfill the request.

5xx server error responses. The server failed to fulfill a valid request. It is the fault of theserver.

6xx global failure responses. The request cannot be fulfilled at any server. The serverresponding with this response class needs to have definitive information about the user.


16/26



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.Examples:

To header To: SIP-URI(;parameters)

From header From: SIP-URI(;parameters)

Call-ID header Call-ID: unique-id

CSeq header CSeq: digit method

Via header Via: SIP/2.0/[transport-protocol] sent-by(;parameters)

Max-Forwards header Max-Forwards: digit

Contact header Contact: SIP-URI


17/26



Message Body

The message body (payload) can carry any text-based information, while

the request method and the response status code determine how the bodyshould be interpreted. When describing a session the SIP message body istypically a Session Description Protocol (SDP) message.

Example of SDP:

v=0

o=User.Alpha 2890844526 2890844526 IN IP4 here.com

t=0 0

c=IN IP4 100.101.102.103m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000


18/26



Session, Dialog, Transaction, and Branch

The term SESSION describes the media connections between the two

users. The exchange of media is done on the so-called bearer level: thismeans that Real-time Transport Protocol (RTP) packets are sent between 2or among more SIP UAs.

A SIP DIALOG is the signaling relation between the two UEs which isneeded to establish, modify and release the multimedia session. The dialog

will be first established (with the INVITE request) and will exist as long as therelated session is active.

Every SIP dialog is identified by the value of the Call-ID header and by thetags in the To and the From headers of the SIP requests, which in ourexample look like:

From: "Your Brother" ;tag=veli

To: "My beloved Sister" ;tag=schwester

Call-ID: apb03a0s09dkjdfglkj49555


19/26



Session, Dialog, Transaction, and Branch(continued)

A SIP transaction comprises a single SIP request and all the responses

related to it. In order to establish the session, user A sends an INVITErequest to user B. At the very outset it receives a 100 (Trying) response fromthe SIP Proxy in response to the request. Afterwards, user B responds with a180 (Ringing) and, finally, a 200 (OK) response. All these 4 messagesbelong to the same transaction and have the same Branch ID and CSeqnumber:

From: "Your Brother" ;tag=veli

To: "My beloved Sister"

;tag=schwester

Call-ID: apb03a0s09dkjdfglkj49555

CSeq: 1112 INVITE

Every subsequent request sent from the same end will have a higher CSeqnumber than the preceding request


20/26



Session, Dialog, Transaction, and Branch(continued)

Every entity either UA or Intermediary will correlate the responses that

are received for a sent request on the basis of the branch parameter that itadded as a parameter to its Via header entry: for example, the SIP Proxy ofuser A adds the following Via header to the INVITE request:

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP proxy1.visited1.fi;branch=9pctb

The branch parameter identifies the INVITE transaction (i.e., the INVITErequest and the responses to it) at the Proxy1.visited.fi


21/26



Basic Message Flow Concepts (Session Estab.)


22/26



EXTENDING SIP (Extensions Negotiation)


23/26



Example: EXTENDING SIP to Make it Reliable

Transmission of Hop-by-Hop Provisional Responses(Unreliable)


24/26



Example: EXTENDING SIP to Make it Reliable (continued)

Transmission of E2E Provisional Responses (Unreliable)


25/26




Transmission of Provisional Responses (100rel Reliable)


26/26




Preconditions (carried in UPDATE and SDP)

SDP Payload:

m=audio 20000 RTP/AVP 0

a=curr:qos local sendrecv

a=curr:qos remote nonea=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

Documents

1 SIP Overview