On Wed, 2007-06-06 at 10:02 +0100, SHIV SINGH wrote: > 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.
I think this can only happen if you're talking to something that's broken - either a UA that sends more than one final response to the same request, or a proxy that is returning more than one to you (it is correct for a proxy to return multiple 2xx responses, but anything >= 300 should be cause the proxy to just choose one). In any event, it seems to me that the simplest thing to do is to just construct an ACK that matches the new response and send it (otherwise the broken thing downstream may keep resending it). -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:[EMAIL PROTECTED] sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
