|
Page 2 of 8
17.1 Client Transaction
The client transaction provides its functionality through the
maintenance of a state machine.
The TU communicates with the client transaction through a simple
interface. When the TU wishes to initiate a new transaction, it
creates a client transaction and passes it the SIP request to send
and an IP address, port, and transport to which to send it. The
client transaction begins execution of its state machine. Valid
responses are passed up to the TU from the client transaction.
There are two types of client transaction state machines, depending
on the method of the request passed by the TU. One handles client
transactions for INVITE requests. This type of machine is referred
to as an INVITE client transaction. Another type handles client
transactions for all requests except INVITE and ACK. This is
referred to as a non-INVITE client transaction. There is no client
transaction for ACK. If the TU wishes to send an ACK, it passes one
directly to the transport layer for transmission.
The INVITE transaction is different from those of other methods
because of its extended duration. Normally, human input is required
in order to respond to an INVITE. The long delays expected for
sending a response argue for a three-way handshake. On the other
hand, requests of other methods are expected to complete rapidly.
Because of the non-INVITE transaction's reliance on a two-way
handshake, TUs SHOULD respond immediately to non-INVITE requests.
17.1.1 INVITE Client Transaction17.1.1.1 Overview of INVITE Transaction
The INVITE transaction consists of a three-way handshake. The client
transaction sends an INVITE, the server transaction sends responses,
and the client transaction sends an ACK. For unreliable transports
(such as UDP), the client transaction retransmits requests at an
interval that starts at T1 seconds and doubles after every
retransmission. T1 is an estimate of the round-trip time (RTT), and
it defaults to 500 ms. Nearly all of the transaction timers
described here scale with T1, and changing T1 adjusts their values.
The request is not retransmitted over reliable transports. After
receiving a 1xx response, any retransmissions cease altogether, and
the client waits for further responses. The server transaction can
send additional 1xx responses, which are not transmitted reliably by
the server transaction. Eventually, the server transaction decides
to send a final response. For unreliable transports, that response
is retransmitted periodically, and for reliable transports, it is
sent once. For each final response that is received at the client
transaction, the client transaction sends an ACK, the purpose of
which is to quench retransmissions of the response.
|
