[Users] ACK and re-INVITE ordering

Jerome Martin jmartin at longphone.fr
Thu Nov 30 00:07:30 CET 2006


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





More information about the sr-users mailing list