etf.org/rfc/rfc3261.txt">RFC3261 specifies that the User Agent MUST respond with a certain error. This does not apply for successful responses like 200 OK. The error condition relates directly to the dialog layer and the SipListener can add no meaningful information to the response. Such a response can be constructed and sent entirely by the dialog layer on behalf of the SipListener. Under such circumstances, it makes sense to let the dialog support handle the response and not bother the SipListener with it. The SipListener will not be notified with the RequestEvent upon which the Response was sent on its behalf by the Dialog layer. However, if no Dialog is registered for the transaction either automatically or under application control, then the SipListener is expected to generate and send the appropriate (error) response.
For example: In RFC3261 Chapter 14 a User Agent Server that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. In this release of this specification, the implementation handles retransmissions of Responses that are specified as being handled by the UA core, if there is an associated Dialog for a given transaction. If there is no associated Dialog for a given transaction, the application will be alerted to perform the retransmissions required by the UA core if desired. Applications should explicitly request such alerts see {@link ServerTransaction#enableRetransmissionAlerts()}. Once enabled the SipProvider will deliver retransmission timer events to the Listener with a {@link Timeout#RETRANSMIT} notification. TheSipListener can then retransmit the Response as necessary, see {@link SipListener#processTimeout(TimeoutEvent)}.
For INVITE Client Transactions:
- UAC ACKs first 2xx response
- Additional 2xx responses will be ACKed automatically if a Dialog is asssociated with the response
- Additional 2xx responses will be presented to the listener if no dialog is associated with the response. In such a case the listener is expected to ACK the 2xx response.
For INVITE Server Transaction 2xx response:
- Application sends first 2xx response {@link ServerTransaction#sendResponse(Response)}.
- If a Dialog is not associated with a ServerTransaction, and if the application explicitly requests to be notified of such timeouts (see {@link ServerTransaction#enableRetransmissionAlerts()} the SipListener isperiodically alerted to retransmit 2xx responses for the ServerTransaction.
- If a Dialog is associated with a ServerTransaction then the implementation takes care of retransmitting final responses until the ACK is received i.e. the SipListener will receive no notifications to retransmit responses.
For an INVITE server Transaction 300-699 response:
- Either the application or the dialog layer sends the first response
- Retransmissions of 300-699 responses from the INVITE Server Transaction are handled by the transaction layer independent of existence of an associated Dialog.
Because reliable provisional responses are always sent by the Dialog layer, the Dialog layer takes care of retrasmitting these. The application is never alerted for retransmissions of Reliable Provisional responses:
- The application sends a reliable provisional Response to an Invite Dialog using {@link javax.sip.Dialog#sendReliableProvisionalResponse(Response) }
- The Stack takes care of retransmitting the provisional response with exponentially increasing intervals until a PRACK is received or the Transaction times out.
Processing Forking INVITES:
Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the TO header field, and each represents a distinct Dialog, with a distinct Dialog identifier. In this case the first 2xx terminates the original INVITE additional 2xx responses will be presented to the SipListener as a ResponseEvent with null Client Transaction ID but with a valid and distinct Dialog. The Listener is expected to ACK the 2xx response - otherwise the Dialog is terminated after a timeout period. Note that unless automatic dialog creation is explictly disabled, the 2xx ResponseEvent will always contain a Dialog whether or not the outgoing INVITE was sent through a ClientTransaction or statelessly via a SipProvider.
@author BEA Systems, NIST
@version 1.2