to a recently received Request in a transaction stateful way.
A new server transaction is generated in the following ways:
for Requests that the application wishes to handle.
The server transaction Id must be unique within the underlying implementation. This Id is commonly taken from the branch parameter in the topmost Via header (for RFC3261 compliant clients), but may also be computed as 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 determine the id is implementation-dependent.
For the detailed server transaction state machines refer to Chapter 17 of, the allowable transitions are summarized below:
Proceeding --> Completed --> Confirmed --> Terminated
Trying --> Proceeding --> Completed --> Terminated
and then passes that Response to this method. The Response message gets sent out on the network via the ListeningPoint information that is associated with the SipProvider of this ServerTransaction.
This method implies that the application is functioning as either a UAS or a stateful proxy, hence the underlying implementation acts statefully. When a UAS sends a 2xx response to an INVITE, the server transaction is transitions to the TerminatedState. The implementation may delay physically removing ServerTransaction record from memory to catch retransmissions of the INVITE in accordance with the reccomendation of.
ACK Processing and final response retransmission:
If a Dialog is associated with the ServerTransaction then when the UAC sends the ACK ( the typical case for User Agents), the Application ( i.e. Listener ) will see a ServerTransaction corresponding to the ACK and the corresponding
presented to it. The ACK will be presented to the Listener only
once in this case. Retransmissions of the OK and filtering of ACK retransmission
are the responsibility of the Dialog layer of this specification. However
is associated with the INVITE Transaction, the ACK will be presented
to the Application with a null Dialog in the
and there will be
no Dialog associated with the ACK Transaction
In this case (when there is no Dialog associated with the original INVITE or ACK)
the Application is responsible for retransmission
of the OK for the INVITE if necessary (i.e. if it wants to manage its own dialog layer and
function as a User Agent) and for dealing with retransmissions of the ACK. This
requires that the three way handshake of an INVITE is managed by the UAS
application and not the implementation of this specification.
Note that Responses created via
should be sent using
responsethe Response to send to the Request.
SipExceptionif the SipProvider cannot send the Response for any other reason.
InvalidArgumentExceptionif the Response is created by
and the application attempts to use this method to send the response.
until the application calls
or a the listener receives a
callback. Note that the stack calls
asynchronously after it removes the transaction some time after the Transaction state is set to
; after which, it maintains no record of the Transaction.
SipExceptionif a Dialog is already associated with the ServerTransaction when the method is called.