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 Transaction

17.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.

<< Prev - Next >>