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).
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
