Hi Leonid, in my opinion a 200 OK for the second Re-INVITE should be the right answer. The Re-INVITE-1/200 OK transaction is over the ACK transaction is started (which I do not see in you example). So it seems that UA-1 does not work rfc 3261 conform. But this scenario can happen through network problems that an new Re-INVITE-2 is faster as an ACK (RE-INVITE-1).
If you will never receive an ACK for the Re-INVITE-1 you UA-2 (tries to get an ACK be retransmit 200 OK (Re-INVIT-1) must send a BYE. I think the race condition does not affect the signalling and the the media path. Regards, Markus Leonid Fainshtein wrote: > Hi, > > Is the following UAS behavior correct? > > UA-1 UA-2 > ------INVITE ---------> > <------200 ------------ > ------- ACK ----------> > ------ re-INVITE-1-----> > <------200 ------------ > > ------ re-INVITE-2-----> > <------ 400( with Retry-After header) ---- > > As you can see, the second re-INVITE arrives to the UAS when the > previous re-INVITE transaction is not confirmed yet (ACK is not > received). > What should UAS do in this situation? Silently ignore re-INVITE2? Reject > it with response 400 or 500? > Thanks, > Leonid > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
