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