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