|
|
|
|
|
This example illustrates, as a slide show, the structure of the SIP protocol, as outlined in chapter 5 of RFC 3261:
|
| - |
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.
|
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 Protocol Structure |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
