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

[Andrei Pelinescu-Onciul]

On Nov 27, 2006 at 19:02, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
> small typo below...
> 
> Bogdan-Andrei Iancu wrote:
> 
> >Hi Klaus,
> >
> >as the discussion about ser's improvements bounces again to openser, I 
> >had to do a bit of digging to provide a correct answer to openser's 
> >users.
> >
> >yes, there were some improvements did by Andrei to TM, mainly in timer 
> >implementation. As you were wondering, the 0.9.6 SER should be 
> >relatively close to openser 0.9.4 as TM performance and merging the 
> >results from Vaclav with Andrei tests before the timer improvement in 
> >SER 0.9.6, seams to be correct. See:
> >   http://lists.iptel.org/pipermail/serdev/2005-December/006583.html
> >
> >After this improvement, SER's 0.9.6 performances dramatically 
> >increased, but unfortunately, according to our tests it is also 
> >dramatically wrong. TM timers are not working correctly when variable 
> >timeouts are used in SER.
> >
> >With the improvement, the following scenario gets broken - 3 calls 
> >only, no load, default cfg:
> >
> >CALL 1: has 60 secs timeout for Final_response_timeout - nobody 
> >answers, still ringing
> >in less than 2 secs ->
> >CALL 2: has 70 secs timeout  - it is immediately answered.
> >in less than 2 secs ->
> >CALL 3: has 10 secs timeout for Final_response_timeout - nobody 
> >answers, ringing.
> >
> >Of course, everybody expects that CALL3 will timeout before CALL1 
> >(with more than 40 secs), but in SER 0.9.6 (latest stable for the last 
> >2 years), this will not happened - both CALL3 and CALL1 will timeout 
> >simultaneously when the CALL3 timer hits.


Thanks a lot for the bug report.

> 
>                              ^^ it is CALL1                            
>                 
> 
> >
> >It is a simple test that anybody can easily reproduce.
> >
> >A lot of people are saying that OpenSER is a less stable, but dynamic 
> >version of SER. Results say something else here.
> >
> >"performance" should have no penalty over "stability", I would say.
> >
> >This bug was not in the devel tree, but it is in the current SER  
> >0.9.6 stable version for ~ 1 year.
> >
> >In this case I would say it is not relevant how many CPS you have if 
> >you cannot handle them correctly.


This get funny... :-)
Well this is a bug that appears _only_ when _variable_ timers are used
(which should not be used with the old tm code anyway) and only if you
catch a race (rather large, ~ 2 sec) and the worst that will happen is
that you'll have a timer extended to another value (last variable timer
used). Very dangerous :-)


Andrei