[Users] ACK and re-INVITE ordering

Weiter Leiter bp4mls at googlemail.com
Thu Nov 30 10:24:45 CET 2006


On 11/30/06, Jerome Martin <jmartin at 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 at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20061130/962afa5f/attachment.htm 


More information about the Users mailing list