[SR-Users] Reinvite/ACK race

[Frank Carmickle]

Alex,

> On Oct 30, 2017, at 1:20 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
> 
> Hi,
> 
> I've got a scenario like so:
> 
>   UA A -----> Kamailio P ----> UA B
> 
> 1. UA A initiates call through Kamailio 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;

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?

> 
> 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.
> 
> 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.
> 
> The cause, as we all know, is that Kamailio's worker threads are loosely
> coupled, and incoming UDP datagrams are distributed directly by the
> kernel. 
> 
> 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.
> 
> I know Kamailio has some config locking primitives, but I am extremely
> wary of complex synchronisation on dialog-identifying attributes,
> particularly if there is a possibility that such locks could stall a
> worker perpetually.
> 
> Any other thoughts welcome!

I’m not certain that I’m understanding your scenario, but if so, maybe this would help.

http://ietf-sip.1820103.n4.nabble.com/Re-Invite-before-ACK-td1820408.html <http://ietf-sip.1820103.n4.nabble.com/Re-Invite-before-ACK-td1820408.html>


—FC



> 
> 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171030/01041c18/attachment.html>