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