| A server transaction is used by a SipProvider to handle incoming Request
messages to fire Request events to the SipListener on a specific server
transaction and by a User Agent Server application to send Response
messages to a User Agent Client application. This interfaces enables an
application to send a
javax.sip.message.Response to a recently
received Request in a transaction stateful way.
A new server transaction is generated in the following ways:
- By the application by invoking the
SipProvider.getNewServerTransaction(Request) for Requests that the
application wishes to handle.
- By the SipProvider by automatically populating the server transaction
of a RequestEvent for Incoming Requests that match an existing Dialog. Note
that a dialog-stateful application is automatically transaction
stateful too
A server 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.
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 RFC 3261, the
allowable transitions are summarized below:
Invite Transaction:
Proceeding --> Completed --> Confirmed --> Terminated
Non-Invite Transaction:
Trying --> Proceeding --> Completed --> Terminated
author:
BEA Systems, NIST
version:
1.2 |