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
7/31/2019 1 SIP Overview
2/26
2 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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.
7/31/2019 1 SIP Overview
3/26
3 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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.
7/31/2019 1 SIP Overview
4/26
4 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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.
7/31/2019 1 SIP Overview
5/26
5 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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.
7/31/2019 1 SIP Overview
6/26
6 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
SIP Entities
7/31/2019 1 SIP Overview
7/267 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
SIP TRAPEZOID
7/31/2019 1 SIP Overview
8/268 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
Private and Public User Identities
7/31/2019 1 SIP Overview
9/269 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
Private and Public User Identities (continued)
7/31/2019 1 SIP Overview
10/2610 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
Public Identifiers Used in SIP
Two main types of identifiers are used in SIP:
SIP URI (sip:[email protected])
and
TEL URI (tel:+358912345678)
7/31/2019 1 SIP Overview
11/2611 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
SIP Protocol Message Format
7/31/2019 1 SIP Overview
12/2612 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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]
7/31/2019 1 SIP Overview
13/26
13 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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.
7/31/2019 1 SIP Overview
14/26
14 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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.
7/31/2019 1 SIP Overview
15/26
15 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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.
7/31/2019 1 SIP Overview
16/26
16 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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
7/31/2019 1 SIP Overview
17/26
17 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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
7/31/2019 1 SIP Overview
18/26
18 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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
7/31/2019 1 SIP Overview
19/26
19 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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
7/31/2019 1 SIP Overview
20/26
20 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
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
7/31/2019 1 SIP Overview
21/26
21 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
Basic Message Flow Concepts (Session Estab.)
7/31/2019 1 SIP Overview
22/26
22 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
EXTENDING SIP (Extensions Negotiation)
7/31/2019 1 SIP Overview
23/26
23 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
Example: EXTENDING SIP to Make it Reliable
Transmission of Hop-by-Hop Provisional Responses(Unreliable)
7/31/2019 1 SIP Overview
24/26
24 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
Example: EXTENDING SIP to Make it Reliable (continued)
Transmission of E2E Provisional Responses (Unreliable)
7/31/2019 1 SIP Overview
25/26
25 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
Example: EXTENDING SIP to Make it Reliable (continued)
Transmission of Provisional Responses (100rel Reliable)
7/31/2019 1 SIP Overview
26/26
26 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
Example: EXTENDING SIP to Make it Reliable (continued)
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