in2EPS
into the Evolved Packet System
IETF     RFC index  ~~  Areas/Groups  ~~  Stats  ~~  SIP  ~~  SEC  ~~  QoS
3GPP     TS/TR series  ~~  Glossaries  ~~  RELxx  ~~  EPC  ~~  IMS  ~~  subsData  ~~  UICC
ETSI    SCP  ~~  SmartM2M  ~~  LI  ~~  INT  ~~  TISPAN         OMA
 
Info
Search

SIP – Session Initiation Protocol

RFC 3261 example SIP Protocol structure
SIP Service examples SIP Dialogs and Routing
History-Info examples SIP/SIMPLE Presence
RFC 3665-6 examples
 
SIP Messages SIP Headers (A to G) ABNF for SDP ABNF for HTTP Media Types
SIP URIs SIP Headers (H to R) SDP Attributes ABNF for IMF
SIP Response Codes SIP Headers (S to Z) ABNF for RTSP 2.0 ABNF for URI/IRI
SIP Common Rules SIP P-Headers ABNF for MSRP ABNF Notation

SIP protocol structure through an example

This example illustrates, as a slide show, the structure of the SIP protocol, as outlined in RFC 3261 – chapter 5:
The lowest layer is the Transport layer. It defines how a Client sends requests and receives responses and how a Server receives requests and sends responses over the network. All SIP elements contain a transport layer.
The second layer is the Transaction layer. A Transaction is a request sent by a Client transaction (using the transport layer) to a Server transaction, along with all responses to that request sent from the server transaction back to the client. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions. Stateless proxies do not contain a transaction layer.
The layer above the transaction layer is called the Transaction User (TU). Each of the SIP entities, except the stateless proxy, is a transaction user.
Navigation Tips: Click Here to display the sequence chart at the top of your window, then click on "Start", or on a number and the associated request or response for a direct access to the detailed image.


Top

Start
SIP Session Set-Up Sequence Chart  
In this example, the rejection of the first INVITE request, followed by a valid INVITE request, enables the analysis of the processing of the ACK for these two situations.

It is assumed that both Proxy 1 and Proxy 3 stateful proxy servers are in the final signalling path because they requested it in the INVITE requests they routed on.
SIP protocol structure through an example
Top   Up
Prev
Next

(1)

SIP INVITE request from Initiating UAC to Proxy 1
 

SIP INVITE request transaction from Initiating UAC to Proxy

At Initiating UA:
The UAC (User Agent Client) TU:
Creates the initial INVITE request;
Creates a new client transaction (in the transaction layer) and passes it the INVITE message, plus the IP address, port and transport.
The new "INVITE" Client Transaction (state="calling") is identified by the CSeq header field and the "branch" parameter of the Via header field. The T1 timer is started (if UDP) before passing the message request to transport.
The Client Transport, before sending the request, inserts the 'sent-by' parameter in the Via header field.

At Proxy 1:
When receiving the request, the Server Transport, by examining the 'sent-by' parameter in the top Via header field, matches it to the relevant server transaction and adds the "received" parameter.
The new "INVITE" server transaction (state="proceeding") is created by the proxy core (not acting as TU). The server transaction transmits the INVITE request to the TU and somehow knows that this TU will generate a response within 200ms: it does not send back a 100 Trying response.
The proxy core TU first validates the INVITE request. It cannot authenticate the originator because no credentials are provided. It rejects the request by sending back (see next slide) a 407 (Proxy Authentication Required) response.
SIP protocol structure through an example
Top   Up
Prev
Next

(2) +
(3)

SIP 407 response (Proxy Authentication Required) from Proxy 1 to
Initiating UAC, and SIP ACK request from UAC to Proxy 1

At Proxy 1:
The proxy core TU sends back a 407 (Proxy Authentication Required) response.
The server transaction enters the "completed" state and passes the 407 response to transport. When ACK (request) is received: passes to "confirmed" state and starts the I timer. When the I timer fires, the server transaction is destroyed.
The server transport:
before sending the response: retrieve IP@ & port from 'sent-by' and "received"
when receiving the (ACK) request: by examining 'sent-by' parameter in top Via header field, matches it to relevant server transaction + adds "received" parameter.

At Initiating UA:
The client transport:
When receiving the response: matches it to the relevant client transaction by examining 'sent-by' parameter in top Via header field
Before sending the (ACK) request: inserts 'sent-by' parameter in Via header field.
When receiving the 407 response, the client transitions to state="completed", passes the response up to the TU, generates an ACK, and passes it to transport. D timer started. When D timer fires, the client transaction is destroyed.
The UAC analyses the response and prepares a new INVITE request.
SIP protocol structure through an example
Top   Up
Prev
Next

(4a) +
(5a)

SIP INVITE Request (with credentials) from Initiating UAC to Proxy 1, and SIP 100 Trying response from Proxy 1 to UAC

INVITE Request (with credentials) from Initiating UAC to Proxy

At Initiating UA:
The UAC (User Agent Client) TU:
(1) creates the new INVITE request containing the correct credentials
(2) creates a new client transaction and passes it the INVITE message, plus the IP address, port and transport
The new "INVITE" client transaction (state="calling") is identified by CSeq header field and "branch" parameter of Via header field. T1 timer started (if UDP) before passing message request to transport. When receiving 1xx response: state="proceeding" and T1 reset.
Client: (1) before sending a request: insert 'sent-by' parameter in Via header field (2) when receiving a response: match it to relevant client transaction by examining 'sent-by' parameter in top Via header field

At Proxy 1:
Server: (1) when receiving a request: by examining 'sent-by' parameter in top Via header field, match it to relevant server transaction + add "received" parameter; (2) before sending a response: retrieve IP@ and port from 'sent-by' and "received"
The new "INVITE" server transaction (identified by CSeq header field and "branch" parameter of Via header field) is created by proxy core (not acting as TU). The server transaction sends back a 100 Trying response and transmits the INVITE request to proxy core (acting as TU).
The proxy core TU: (1) validates the request;   (2) determines the target for the request;   (3) forwards the request (see next slide) towards the target;
SIP protocol structure through an example
Top   Up
Prev
Next

(4b) +
(4c)+(5b)

SIP INVITE Request from Proxy 1 to Proxy 2, and from Proxy 2 to Proxy 3, and SIP 100 Trying from Proxy 3 to Proxy 2

SIP INVITE Request from Proxy to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(4d) +
(6a)

SIP INVITE Request from Proxy 2 to Responding UAS,
and SIP 180 Ringing response from Responding UAS to Proxy 3

SIP INVITE Request from Proxy to Responding UAS

SIP protocol structure through an example
Top   Up
Prev
Next

(6b) +
(6c)

SIP 180 Ringing response from Proxy 3 to Proxy 2,
and from Proxy 2 to Proxy 1

SIP 180 Ringing response from Proxy to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(6d)

SIP 180 Ringing response from Proxy 1 to Initiating UA

SIP 180 Ringing response from Proxy to Initiating UAC

SIP protocol structure through an example
Top   Up
Prev
Next

(7a)

SIP 200 OK response from Responding UAS to Proxy 3

SIP 200 OK response from Responding UAS to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(7b) +
(7c)

SIP 200 OK response from Proxy 3 to Proxy 2,
and from Proxy 2 to Proxy 1

SIP 200 OK response from Proxy to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(7d)

SIP 200 OK response from Proxy 1 to Initiating UAC

SIP 200 OK response from Proxy to Initiating UAC

SIP protocol structure through an example
Top   Up
Prev
Next

(8a)

SIP ACK request from Initiating UAC to Proxy 1

SIP ACK request from Initiating UAC to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(8b)

SIP ACK request from Proxy 1 to Proxy 3

SIP ACK request from Proxy to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(8c)

SIP ACK request from Proxy 3 to Responding UAS

 ACK request from Proxy to Responding UAS

SIP protocol structure through an example
Top   Up
Prev
Next

SIP Media Session between Alice's UA and Bob's UA

SIP Media Session between User Agents

SIP protocol structure through an example
Top   Up
Prev
Next

(9a)

SIP BYE request from Bob's Initiating UAC to Proxy 3

SIP BYE request from Initiating UAC to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(9b)

SIP BYE request from Proxy 3 to Proxy 1

 BYE request from Proxy to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(9c)

SIP BYE request from Proxy 1 to Alice's Responding UAS

SIP BYE request from Proxy to Responding UAS

SIP protocol structure through an example
Top   Up
Prev
Next

(10a)

SIP 200 OK response from Responding UAS to Proxy 1

SIP 200 OK response from Responding UAS to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(10b)

SIP 200 OK response from Proxy 1 to Proxy 3

SIP 200 OK response from Proxy to Proxy

SIP protocol structure through an example
Top   Up
Prev
Next

(10c)

SIP 200 OK response from Proxy 3 to Initiating UAC
(end of example)

SIP 200 OK response from Proxy to Initiating UAC