It is discussed within the following link. http://lists.cs.columbia.edu/pipermail/sip-implementors/2006-October/014 458.html
Your stack ignoring the re-INVITE is one of the many potential solutions if re-INVITE retries are expected. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Stephen Paterson > Sent: Wednesday, November 01, 2006 11:41 AM > To: SIP Implementors (E-mail) > Subject: [Sip-implementors] Handling a of re-INVITE before > initial ACK isreceived > > Hi all, > > Section 14.2 of RFC 3261 states: > > 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. > A UAS that receives an INVITE on a dialog while an INVITE it > had sent on that dialog is in progress MUST return a 491 > (Request Pending) response to the received INVITE. > > Question is: What should the UAS do if it receives a > re-INVITE after it has sent the final response but before it > receives the ACK for the initial INVITE? > > This situation doesn't fit either of the above two scenarios > and I can't find anything elsewhere in the RFC to help. > Currently our stack ignores the second INVITE but my gut > feeling is there should be some sort of 4xx response, > possibly containing a Retry-After header. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
