<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I'm trying to figure out how people use SER in order to get a picture
of what the needs really are. My goal is to be able to group various
usage patterns and create "best practice" areas at iptel.org, where
people also can add comments and describe their experiences. <br>
<br>
Would you mind sharing a bit about the "mixture of SER and OpenSER
modules" you are using, as well as why you opted to change the database
model? <br>
g-)<br>
<br>
sip wrote:
<blockquote cite="mid20061204153630.M30086@infinideas.com" type="cite">
<pre wrap="">Indeed. No fears there. We've already got a dedicated server on order to test
it with. Won't likely be here until the beginning of the year, but we won't
have time to muck with it before then anyway with the usual end-of-year
madness going on.
Very much looking forward to testing Ottendorf and trying to figure out the
best way to migrate. As is, it will be slightly complex as we've spent a good
portion of time redoing the SER database to our particular specifications and
needs... and many of the tables we use have been removed or redone for
Ottendorf, and many of the features we rely upon have been completely done
away with.
Also, since we use a mixture of SER and OpenSER modules in our code, as well
as in-house modules to handle several things, migrating to Ottendorf is going
to be an exercise in frustration and pain. :) I'm not eager to start even
looking at that until after the holidays.
N.
On Mon, 04 Dec 2006 10:39:25 +0100, Jiri Kuthan wrote
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">On Nov 29, 2006 at 14:05, Kim Il <a class="moz-txt-link-rfc2396E" href="mailto:kim_il_s@yahoo.com"><kim_il_s@yahoo.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">this is getting more and more confusing. The one side says this is a bug,
</pre>
</blockquote>
</blockquote>
<pre wrap="">the other says it is a feature. I will try to summarize my understanding
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->till now:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">* openser claims that they improved something and the ser guys say this
</pre>
</blockquote>
</blockquote>
<pre wrap="">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).
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
<blockquote type="cite">
<pre wrap="">* The ser guys show that openser is inferior to ser but Bogdan replies
</pre>
</blockquote>
</blockquote>
<pre wrap="">this is on purpose (because otherwise a strange race situation can occur which
Andrei tells us is negligable).
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
<blockquote type="cite">
<pre wrap="">* I will not get into the history discussion -which I have already touched
</pre>
</blockquote>
</blockquote>
<pre wrap="">in previous mails, let alone those mails about respect and the other stuff I
could not really see how they relate to this discussion.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I would really appreciate if these points were clarified -I have the
</pre>
</blockquote>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I believe Andrei has made a good suggestion that it is in the interest of
</pre>
</blockquote>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a class="moz-txt-link-freetext" href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Serusers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a class="moz-txt-link-freetext" href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>
</pre>
</blockquote>
<pre wrap="">--
Jiri Kuthan <a class="moz-txt-link-freetext" href="http://iptel.org/~jiri/">http://iptel.org/~jiri/</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Serusers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a class="moz-txt-link-freetext" href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>
</pre>
</blockquote>
</body>
</html>