[Users] ACK and re-INVITE ordering

[Bogdan-Andrei Iancu]

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