Hi, I've got a scenario like so:
UA A -----> Proxy P ----> UA B 1. UA A initiates call through Proxy P; 2. Dialog is established and confirmed, with Record-Route; 3. UA B sends reinvite #1 through P to A; 4. UA B sends 2xx reply; 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. 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 § 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". Switching to TCP would presumably help, since any given flow would involve a single connection to a single worker thread and the transport would guarantee ordering. However, that's not really feasible in this implementation for a host of reasons. Any other thoughts welcome! Cheers, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
