Jerome Martin wrote:
On Thu, 2006-11-30 at 11:52 +0200, Bogdan-Andrei Iancu wrote:
Hi Jerome,
I this this is an interesting solution to the problem.
- use the dialog module ; we can add a function to access the dialog
state from the script.
Yes, that's what I wanted to do, but I fear there could be a race condition for reading/setting the cookie between openser processes handling the ACK and the following reINVITE. What do you think ?
with or without a control you will still have this race - actually is quite impossible to get rid of it. Important is to be able to handle it and to recover properly if it occurs. so, if you are parallely processing the re-INVITE and ACK, in the worst case you will not see the ACK and you will trigger a re-INVITE retransmission.
I wanted to add a "PendingACK" parameter to the dialog cookie upon successfull INVITE transaction, and check that parameter for every reINVITE received (and drop the reINVITE as suggested by T.R. Missner).
you do not need a parameter or cookie. The idea is to use the current "dialog" module and just to extend a bit to be able to see the dialog status from the script.
- when receiving a re-INVITE, if dialog state is NOT-ACKed, drop the
request - the delay between re-INVITE and ACK should not be too long (as there were 2 requests going in the same direction, generated in reversed order), so 2, maximum 3 retransmission cycles should cover it up.
Agreed.
At least you can run some test to see what is the average delay between re-INVITE and ACK to get an idea what you should expect for.
Just for a test, by using a systematic (blindly) delay of 1 second when receiving a reINVITE, the probleme fully disapears in my tests.
which means 2 or maximum 3 retransmissions.
regards, bogdan