See RFC 6026 section 7.2; it discusses Timer M and stray INVITE 200 responses.
"Any response received that does not match an existing client transaction state machine is simply dropped. (Implementations are, of course, free to log or do other implementation-specific things with such responses, but the implementer should be sure to consider the impact of large numbers of malicious stray responses.)" > -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Peter Krebs > Sent: Wednesday, January 12, 2011 9:10 AM > To: [email protected] > Subject: Re: [Sip-implementors] Dialog establishment and stray/forking > responses > > First of all, many thanks for your answers. > > Regarding point 2: Keeping the transaction state would essentially > emulate > the Sparks-INVITE-fix, and keeping the data of terminated dialogs > wouldn't > help when stray/forking responses arrive even later than 64*T1 (or > completely unconnected to a call) or am I missing something? > In case there is really no clean solution without the fix, I think > about > following compromise: the UAC core never creates new dialogs when stray > 200 > responses are received but only sends an ACK for a matching dialog if > one > still exists (dialog data is cleaned after 64*T1 after termination via > BYE). > Could this approach have any unfortunate impact besides disabling > dialogs > for forking responses (which can be enabled again when using the Sparks > fix)? _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
