Hi,
Thanks for answer my post,
On Wed, 2006-11-29 at 17:27 -0500, T.R. Missner wrote:
We solved this problem in a SBC I used to work on by dropping the reInvite if the ACK was still pending. This works in UDP since the reInvite then would be resent. Of course the SBC was dialog stateful.
Do you have an idea of the overhead of dialog statefullness ? Would a DB storage of pending ACKs (mean 1 DB write per (re)INVITE callID+Cseq, 1 DB write (delete) per ACK, 1 DB read per reINVITE) have a big impact on performance ? Am I going to butcher my dear openser 1.1 by implementing this ?
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).
Hope this helps T.R.
Well it does :-) It made me think a bit more, I just didn't really worried about timeout and resends, but clearly one MUST take this into consideration, either by leveraging the mechanism to do part of the job or finding a workaround so it doesn't get into the way, depending on the approach. Cleary, if choosing to implement partial dialog statefullness for reINVITE handling, I'll stick to your suggestion, which is much more elegant than delay.
Thanks again for your answer, Best Regards, Jerome Martin