[Serusers] Re: [Users] TM : retransmission timers

[Andrei Pelinescu-Onciul]

On Nov 29, 2006 at 14:05, Kim Il <kim_il_s at yahoo.com> wrote:
> this is getting more and more confusing. The one side says this is a bug, the other says it is a feature. I will try to summarize my understanding till now:

I believe we  better stop this line of discussion at least for now and
instead concentrate on fixing the technical problems that were revealed
on both sides. I wouldn't want it to hinder possible future
collaboration.

> *  openser claims that they improved something and the ser guys say this fix is useless. Daniel, Bogdan could you plesase  explain what is really behind this improvement (Sorry Weiter, but your explanation is far from being sufficient).

I don't know exactly what are you referring to ("something"?), but I don't
remember claiming that an openser fix was useless (at least I haven't, I
might have implied that something, IMHO was not as important as claimed,
 but not that was useless).


> * The ser guys show that openser is inferior to ser but Bogdan replies this is on purpose (because otherwise a strange race situation can occur which Andrei tells us is negligable).

Actually, the claim was along the lines that tm (the statefull part of
the sip stack in ser) and/or the core performance was inferior.

The bug that Bogdan discovered is not negligible. I wanted to point out
that it was not as important as suggested.
This probably deserves a better explanation, so that people without
ser-internals knowledge can understand.
First of all variable timers in this context mean the possibility to
set different values for  the fr_timer and fr_inv_timer at runtime 
(e.g. in function of some user preferences/avps or some special script
logic) as oppossed to having some fixed (but configurable) values.
What really matters here is the fr_inv_timer. The fr_inv_timer is the
time that ser waits for a final response on an INVITE transaction
_after_ a provisional response was received (e.g. 180 Ringing). This 
 roughly corresponds to the Timer C from the sip rfc (rfc3261).
 According to the sip rfc both fr_tiemr and fr_inv_timer should be fixed
and _not_ configurable. However in practice it makes sense to change them
(especially the fr_inv_timer), to implement services such as redirect to
voicemail after x seconds.
The most common use of the variable timers is user (or group)
configurable voicemail redirection. This means that the user is somehow
able to configure the "ringing" interval after which a caller will be
redirected to his voicemail. If variable timers are not used, the
voicemail config option would include only on or off (the ringing time
before voicemail redirection wouldn't be configurable, it would be the
same for all the users).
Now what the bug did, was that it could cause the extension of
fr_inv_timer to the fr_inv_timer of another transaction, if _different_
variable timers were used and some race occured (note that the
probability of hitting the race is quite high if lots of variable
fr_inv_timers with different values are used and the system is very
busy).
This IMHO is not such a big problem since in the case when you are hit
by it, it  really doesn't break anything important (I don't see
sometimes redirecting later to voicemail as such a big problem, OTOH
people might use it for other stuff).


> * I will not get into the history discussion -which I have already touched in previous mails, let alone those mails about respect and the other stuff I could not really see how they relate to this discussion.
> I would really appreciate if these points were clarified -I have the impression the ball is now with Daniel and Bogdan. So plesse Bogdan do not hold to your one mail policy and help clarifying this and provide a bit more of details on the improvements of openser to core and tm.
> 
> I believe Andrei has made a good suggestion that it is in the interest of the entire community to cooperate and divide the areas of interest. By combining the great work the openser guys have done in the area of documentation and featutres with the work of ser in the area of core we will all get an even better ser/openser.

In fact even if we can't reach an agreement in dividing areas, small
cooperation like on fixing/improving code that is the same in both
versions would still be good.
I would say that even a friendly competing approach would be better then
nothing (with comparisons, benchmarks a.s.o), it points out problems in
both versions and serves as a motivation to improve.


Andrei
[...]