[Users] ACK and re-INVITE ordering

[Bogdan-Andrei Iancu]

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.
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.

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.

regards,
bogdan

Jerome Martin wrote:

>>Dropping the reInvite on the floor in the case of UDP transport certainly is
>>easier than delay/resending
>>    
>>
>
>Nice one.
>Do you have an idea of the average timeout waiting for an INVITE reply ?
>I mean before resending ? Because I makes no sense anyway to delay for
>more than this timeout instead of dropping the request ... but dropping
>requires DB overhead.
>
>But still, only delaying the reINVITE for a fixed amount of time indeed
>will generate escalating resends if delay is too big, and might no solve
>100% of the issue (WILL not) if delay is too short (so to avoid
>resends). So in order to keep the UA from resending, one must carefully
>send provisionnal replies while delaying, which starts to get unpleasant
>to the eye (IMHO).
>
>  
>