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.
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 ?
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.
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.
which means 2 or maximum 3 retransmissions.
regards,
bogdan