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.
Yes. We just need to store "pendingACK" in RR, so if we drop a reINVITE
wrongly (because of the race condition occuring), this will just
increase delay a bit. It is possible because we are storing
"pendingACK", and not the opposite which would be "NoPendingACK".
We're
sort of lucky because the first one is the easiest in our case and make
handling the race simple. If we were to store the opposite, then the
race condition would be a real problem. Am I right ?
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.
Yes.
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.
Well, I was referring to the "dialog cookie" added to RR parameters BY
the dialog module, as referenced in
http://www.openser.org/docs/modules/1.1.x/dialog.html#AEN93
I really want to implement it using RR storage (via the dialog module)
instead of an external database. I haven't looked at either TM or DIALOG
source code yet, but if it is trivial for you, I'd gladly test in
preproduction any patch you send to me to add/read an arbitrary
parameter. But what would be the added sugar in those functions compared
to RR module add_rr_param(param) and check_route_param(re) ? Can't I use
those already ?
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.
Right.