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

Mon Dec 4 10:39:25 CET 2006

Just to make it clear, it is pretty much only possible with Ottendorf if
you are having a reasonably big setup. The previous timer system was not
accurate (you might have noticed, that retransmission timer fired in a range
of +/- 1 sec which is kind of unexact given the timer length 0.5 sec),
variable (all timers were pretty much supposed to be of the same length),
high-resolution (it used to be 1 second).

I concur that migration is alway a painful exercise, but I can only recommend
folks to make themselves busy with it earlier than too late.

-jiri

At 23:05 01/12/2006, sip wrote:
>Well... the TM bug may not be earth-shattering, but it's most decidedly
>important. One of the functions we have that our users LOVE is the ability to
>set their own timeout values for voicemail. We had had a default value that we
>thought would make everyone happy, but soon discovered that many would
>complain that it was too long, and many would complain that it was too short.
>
>Having had many users who came along from asterisk-based services, where
>setting individual timeout values is rather straightforward and easy.
>
>One of the things we've been struggling with has been the timing values. While
>it may not be important in the scheme that it's not ACTUALLY
>service-affecting, I can assure you, if you offer a service, and it doesn't
>work as prescribed, the consequences can be deadly. You shake user-confidence
>-- and that sort of thing travels VERY quickly by word of mouth. It's so very
>hard to gain users, and so very easy to lose them to a competitor -- even if
>that competitor doesn't offer the same options. For what good are options that
>only work sometimes?
>
>SO... in short... yeah... I'm really happy that the timer stuff has been fixed
>in Ottendorf. Of course, it'll be a LONG time before we can migrate the
>production systems to it, but it gives me something to look forward to.
>
>N.
>
>On Thu, 30 Nov 2006 12:19:03 +0100, Andrei Pelinescu-Onciul wrote
>> 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
>> [...]
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>_______________________________________________
>Serusers mailing list
>Serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/ 