Hi shivelx, In this case as being Client UA you don't care about the sending second ACK to 6xx response , If you are B2BUA then you have to store dialog and transaction parameters of All calls hence you can send ACK to 6xx UAS too. FYI the SIP Endpoints doesn't care about receiving ACK if it has sent any non-2xx response. Regards Ravi Rupela Hi, Need some inputs for this scenario in UDP case: UAC is sending invite,UAS sends a 4xx for it,UAC sends ACK for it. Before the invite client transaction has cleared up , UAC receives a 6xx with a different to-tag for the same invite.(all other parameters are same as 4xx). I guess that in general this wont be happening,but assume that we receive this second final non-2xx response with different
to-tag. RFC 3261 says ".... it is possible that it will generate multiple responses from different servers. These responses will all have the same branch parameter in the topmost Via, but vary in the To tag. The first response received, based on the rules above, will be used, and others will be viewed as retransmissions. That is not an error;" RFC 3261 also says that "The ACK request matches a transaction if the Request-URI, From tag, Call-ID, CSeq number (not the method), and top Via header field match those of the INVITE request which created the transaction, and the To tag of the ACK matches the To tag of the response sent by the server transaction" How should the client transaction behave? 1]Should it retransmit the same ack which it sent for the 4xx? 2] If client retransmits the same ack,then the to-tag in that ack will be that of one received in 4xx.It will be treated as stray message. 3] How should the invite server transaction handle such ack with different to-tag(if the ack of 4xx was retransmitted with old tag)? Inputs will be appreciated. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
