<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Alex,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 30, 2017, at 1:20 PM, Alex Balashov <<a href="mailto:abalashov@evaristesys.com" class="">abalashov@evaristesys.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">I've got a scenario like so:<br class=""><br class=""> UA A -----> Kamailio P ----> UA B<br class=""><br class="">1. UA A initiates call through Kamailio P;<br class=""><br class="">2. Dialog is established and confirmed, with Record-Route;<br class=""><br class="">3. UA B sends reinvite #1 through P to A;<br class=""><br class="">4. UA B sends 2xx reply;<br class=""></div></div></blockquote><div><br class=""></div><div>It’s not clear to me if the 2xx reply from B is a retransmit, and thus the dialog isn’t actually established everywhere? As you know, the 2xx to the reinvite should be coming from A and not B. Maybe you meant to say A here?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class="">5. UA B sends end-to-end ACK for reinvite #1 and almost<br class=""> simultaneously sends reinvite #2. The temporal delta is<br class=""> between reinvite #2 and ACK for reinvite #1 on the wire<br class=""> is 3 ms.<br class=""><br class="">So, the result — for all kinds of stochastic processing and userspace<br class="">scheduling type reasons — is that the reinvite is forwarded first,<br class="">before the ACK. That leads to a 500 / 491 scenario UA A.<br class=""><br class="">The cause, as we all know, is that Kamailio's worker threads are loosely<br class="">coupled, and incoming UDP datagrams are distributed directly by the<br class="">kernel. <br class=""><br class="">Is there any general guidance on what to do with these scenarios? I<br class="">looked at RFC 5407 § 3.1.4, which appears to describe a similar, but not<br class="">identical scenario involving an initial INVITE and subsequent reinvite.<br class="">As far as I can tell, the recommendation in that standard is "space the<br class="">messaging out more in time". <br class=""><br class="">Switching to TCP would presumably help, since any given flow would<br class="">involve a single connection to a single worker thread and the transport<br class="">would guarantee ordering. However, that's not really feasible in this<br class="">implementation for a host of reasons.<br class=""><br class="">I know Kamailio has some config locking primitives, but I am extremely<br class="">wary of complex synchronisation on dialog-identifying attributes,<br class="">particularly if there is a possibility that such locks could stall a<br class="">worker perpetually.<br class=""><br class="">Any other thoughts welcome!<br class=""></div></div></blockquote><div><br class=""></div><div>I’m not certain that I’m understanding your scenario, but if so, maybe this would help.</div><div><br class=""></div><div><a href="http://ietf-sip.1820103.n4.nabble.com/Re-Invite-before-ACK-td1820408.html" class="">http://ietf-sip.1820103.n4.nabble.com/Re-Invite-before-ACK-td1820408.html</a></div><div><br class=""></div><div><br class=""></div><div>—FC</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Cheers,<br class=""><br class="">-- Alex<br class=""><br class="">-- <br class="">Alex Balashov | Principal | Evariste Systems LLC<br class=""><br class="">Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br class="">Web: <a href="http://www.evaristesys.com/" class="">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" class="">http://www.csrpswitch.com/</a><br class=""></div></div></blockquote></div><br class=""></div></body></html>