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;
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!
Cheers,
-- Alex
Alex,
On Oct 30, 2017, at 1:20 PM, Alex Balashov abalashov@evaristesys.com wrote:
Hi,
I've got a scenario like so:
UA A -----> Kamailio P ----> UA B
UA A initiates call through Kamailio P;
Dialog is established and confirmed, with Record-Route;
UA B sends reinvite #1 through P to A;
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?
- 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/
On Mon, Oct 30, 2017 at 01:37:57PM -0400, Frank Carmickle wrote:
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?
Yep, I meant to say A there. :-) It's not a retransmission.
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
Thanks!
-
Alex Balashov -
Frank Carmickle