in2EPS
 into the 3GPP
 Evolved Packet System
IETF   |  RFC index   |  Areas/Groups   |  Stats   |  SIP   |  SEC   |  QoS
3GPP   |  Specs   |  Glossaries   |  Releases   |  EPC   |  IMS   |  subData   |  UICC   |  ETSI
 
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 ABNF Notation
SIP URIs SIP Headers (H to R) SDP Attributes ABNF for IMF Media Types
SIP Response Codes SIP Headers (S to Z) ABNF for RTSP 2.0 ABNF for URI
SIP Common Rules SIP P-Headers ABNF for MSRP ABNF for IRI

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.
Here Top Start Tip:   clicking on a number provides a direct access to the detailed figure 
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.
Top Up Prev Next  
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.
Top Up Prev Next  
SIP 407 response (Proxy Authentication Required) from Proxy to Initiating UAC
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.
Top Up Prev Next  
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;
Top Up Prev Next  
SIP INVITE Request from Proxy to Proxy
Top Up Prev Next  
SIP INVITE Request from Proxy to Responding UAS
Top Up Prev Next  
SIP 180 Ringing response from Proxy to Proxy
Top Up Prev Next  
SIP 180 Ringing response from Proxy to Initiating UAC
Top Up Prev Next  
SIP 200 OK response from Responding UAS to Proxy
Top Up Prev Next  
SIP 200 OK response from Proxy to Proxy
Top Up Prev Next  
SIP 200 OK response from Proxy to Initiating UAC
Top Up Prev Next  
SIP ACK request from Initiating UAC to Proxy
Top Up Prev Next  
SIP ACK request from Proxy to Proxy
Top Up Prev Next  
 ACK request from Proxy to Responding UAS
Top Up Prev Next  
SIP Media Session between User Agents
Top Up Prev Next  
SIP BYE request from Initiating UAC to Proxy
Top Up Prev Next  
 BYE request from Proxy to Proxy
Top Up Prev Next  
SIP BYE request from Proxy to Responding UAS
Top Up Prev Next  
SIP 200 OK response from Responding UAS to Proxy
Top Up Prev Next  
SIP 200 OK response from Proxy to Proxy
Top Up Prev Next  
SIP 200 OK response from Proxy to Initiating UAC