In section 14.2 of RFC-3261 written the following: A UAS 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 my scenario the UAS has sent the final response and waiting for the confirmation (ACK)... So it is not exactly the same case as described in 14.2.... Leonid -----Original Message----- From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] Sent: Saturday, May 20, 2006 9:39 PM To: Leonid Fainshtein Cc: [email protected] Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request Leonid, It MUST send a 500 response with Retry-After, see RFC3261 section 14.2. Furthermore, if it doesn't receive the ACK it SHOULD generate a BYE Regards, jeroen ----- Original Message ----- From: "Leonid Fainshtein" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Saturday, May 20, 2006 9:24 PM Subject: [Sip-implementors] Miss-ordered re-INVITE request > 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
