On 11/30/06, Jerome Martin jmartin@longphone.fr wrote:
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 ?
You might get away cheaper with a little TM modification and using TCP with the gateway: - you have to enhance TM to allow you to see if a transaction belonging to same dialog is still pending; if it is, either drop the second transaction (as already suggested) or reply with something like 480 or 491 (none of them best suited for the job, but might work); - by using one TCP connection you minimize the chance of packet reordering.
Delaying is not really possible without blocking the process doing it: you could end up with a blocked server.
Hth, WL.
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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users