's statefully. A new client transaction is generated by the application calling the
A client transaction of the transaction layer is represented by a finite state machine that is constructed to process a particular request under the covers of a stateful SipProvider. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts. Any task that a User Agent Client accomplishes takes place using a series of transactions.
The client transaction must be unique within the underlying implementation. A common way to create this value is to compute a cryptographic hash of the To tag, From tag, Call-ID header field, the Request-URI of the request received (before translation), the topmost Via header, and the sequence number from the CSeq header field, in addition to any Proxy-Require and Proxy-Authorization header fields that may be present. The algorithm used to compute the hash is implementation-dependent.
For the detailed client transaction state machines refer to Chapter 17 of, the allowable transitions are summarized below:
Calling --> Proceeding --> Completed --> Terminated
Trying --> Proceeding --> Completed --> Terminated
and then creates a new ClientTransaction from
. Calling this method on the ClientTransaction sends the Request onto the network. The Request message gets sent via the ListeningPoint information of the SipProvider that is associated to this ClientTransaction.
This method assumes that the Request is sent out of Dialog. It uses the Router to determine the next hop. If the Router returns a empty iterator, and a Dialog is associated with the outgoing request of the Transaction then the Dialog route set is used to send the outgoing request.
This method implies that the application is functioning as either a UAC or a stateful proxy, hence the underlying implementation acts statefully.
Note that both the transaction corresponding to the original request and
the CANCEL transaction will complete independently. However, a UAC
canceling a request cannot rely on receiving a 487 (Request Terminated)
response for the original request, as an RFC 2543 compliant UAS will
not generate such a response. Therefore if there is no final response for
the original request the application will receieve a TimeoutEvent with
and the client should then consider the
original transaction cancelled.
SipExceptionif this method is called to cancel a request that can't be cancelled i.e. ACK.
method should be used. Otherwise the stack will automatically create and send the ACK for non-2xx responses that need to be acknowledged. That is the application should never need to use this method.
SipExceptionif this method is called before a final response is received for the transaction.