On Nov 27, 2006 at 19:02, Bogdan-Andrei Iancu bogdan@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 CALL1It 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