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 {@link 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 {@link Dialog} is associated with the INVITE Transaction, the ACK will be presentedto the Application with a null Dialog in the {@link RequestEvent} and there will be no Dialog associated with the ACK Transaction (i.e. {@link 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 {@link Dialog#createReliableProvisionalResponse(int)} should be sent using {@link Dialog#sendReliableProvisionalResponse(Response)} @param response the Response to send to the Request. @throws SipException if the SipProvider cannot send the Response for anyother reason. @throws InvalidArgumentException if the Response is created by{@link Dialog#createReliableProvisionalResponse(int)} andthe application attempts to use this method to send the response. @see Response
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|