30 nov 2006 kl. 10.57 skrev Jerome Martin:
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.
You can also send a "pending" reply if you're already processing one
INVITE
and get another in the meantime.
/O