Alex Balashov <abalas...@evaristesys.com> writes: > 5. UA B sends end-to-end ACK for reinvite #1 and almost > simultaneously sends reinvite #2. The temporal delta is > between reinvite #2 and ACK for reinvite #1 on the wire > is 3 ms. > > The issue is that the concurrency characteristics of proxy P are such > that its worker threads are very loosely coupled, and there's no > synchronisation among them for message ordering. Transport is UDP, > naturally.
As others have said, the problem must be solved by the UAs, not the proxy. Indeed, what with possible network delays and re-sending of lost packets, there's no way to guarantee end-to-end sequencing of messages. Even with TCP service, there's no guarantee that none of the intermediate proxies aren't using multiple TCP connections to carry messages between themselves. > So, the result -- for all kinds of stochastic processing and userspace > scheduling type reasons -- is that the reinvite is forwarded first, > before the ACK. That leads to a 500 / 491 scenario UA A. > > Is there any general guidance on what to do with these scenarios? I > looked at RFC 5407 [section] 3.1.4, which appears to describe a > similar, but not identical scenario involving an initial INVITE and > subsequent reinvite. As far as I can tell, the recommendation in that > standard is "space the messaging out more in time". You're correct to look to 5407 (which is important enough to be known as just "Hasebe") for guidance. And it does look like section 3.1.4 is the relevant case, or very close to it. This scenario illustrates the race condition that occurs when a UAS in the Moratorium state [having sent 2xx but not received ACK] receives a re-INVITE sent by a UAC in the Established state. And as the text goes on, sending 2xx is recommended, rather than 491, because all of the state changes within the UA associated with the first re-INVITE have already been completed. But a 491 response is also permissible. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
