android.javax.sip

Interface ServerTransaction

All Superinterfaces:

Serializable, Transaction

All Known Subinterfaces:

ServerTransactionExt, SIPServerTransaction

All Known Implementing Classes:

SIPServerTransactionImpl

public interface ServerTransaction
extends Transaction

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

Version:

1.2

Author:

BEA Systems, NIST

Method Summary

Methods

Modifier and Type	Method and Description
void	enableRetransmissionAlerts() Enable the timeout retransmit notifications for the ServerTransaction.
void	sendResponse(Response response) Sends the Response to a Request which is associated with this ServerTransaction.

Methods inherited from interface android.javax.sip.Transaction

getApplicationData, getBranchId, getDialog, getRequest, getRetransmitTimer, getState, setApplicationData, setRetransmitTimer, terminate

Method Detail

sendResponse

void sendResponse(Response response)
                  throws SipException,
                         InvalidArgumentException

Sends the Response to a Request which is associated with this ServerTransaction. When an application wishes to send a Response, it creates a Response using the MessageFactory 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 http://bugs.sipit.net/show_bug.cgi?id=769 .

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 Dialog 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 if no Dialog is associated with the INVITE Transaction, the ACK will be presented to the Application with a null Dialog in the RequestEvent and there will be no Dialog associated with the ACK Transaction (i.e. Transaction.getDialog() returns null). 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 Dialog.createReliableProvisionalResponse(int) should be sent using Dialog.sendReliableProvisionalResponse(Response)

Parameters:

response - the Response to send to the Request.

Throws:

SipException - if the SipProvider cannot send the Response for any other reason.

InvalidArgumentException - if the Response is created by Dialog.createReliableProvisionalResponse(int) and the application attempts to use this method to send the response.

See Also:

Response

enableRetransmissionAlerts

void enableRetransmissionAlerts()
                                throws SipException

Enable the timeout retransmit notifications for the ServerTransaction. This method is invoked by UAs that do want to be alerted by the stack to retransmit 2XX responses but that do NOT want to associate a Dialog. The Default operation is to disable retransmission alerts for the Server Transaction when no Dialog is associated with the Server Transaction, as is common for a Proxy server. When this method is called, the stack will continue to generate Timeout.RETRANSMIT until the application calls Transaction.terminate() or a the listener receives a SipListener.processTransactionTerminated(TransactionTerminatedEvent) callback. Note that the stack calls SipListener.processTransactionTerminated(TransactionTerminatedEvent)asynchronously after it removes the transaction some time after the Transaction state is set to TransactionState.TERMINATED ; after which, it maintains no record of the Transaction.

Throws:

SipException - if a Dialog is already associated with the ServerTransaction when the method is called.

Since:

1.2