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.
1) 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 ?
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).
2) 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.