[Serdev] SER's core design features(process model/parser/lumps/script) - was: So who/what is SER for, anyway?

[Martin Hoffmann]

Dragos Vingarzan wrote:
> Martin Hoffmann wrote:
> >
> > Usually, I am much in favour of a multi-processing model as opposed to
> > multi-threading. Apache 1.3 was rock-solid because of this. However, the
> >
> I am for multi-threading,

I thought so ;-)

> but this is not the point. I can live just
> well with multi-process, it's just that the whole thing was initially
> designed like "we know better, you do not need to fork new processes".

You do know of fork(2), right?

> > I can't really see this point but I don't know enough about all this
> > 3GPP stuff to seriously comment on it. Somewhere down the road dialogs
> > where mentioned. Sounds to me that the stuff is overly complex. Not that
> > I am in any way surprised given that this is Telco designed.
> >
> it's not about 3GPP though, but about doing more with SER.

It at least partly is about 3GPP because in a way it perverts the
original ideas behind SIP in order to accomodate an outdated business
model. But this surely goes beyond this thread if not thread.

> About
> dialogs, 3GPP recommends that you should check the Routes that the users
> are using inside dialogs, so that they won't go around the charging
> server for example.

What do I need a charging server for?

> > > SER is no longer "just a SIP proxy".
> >
> > But it is just that. I don't really like all the attempts to make it
> > more than that (which is the main reason why I don't use SEMS). SER is a
> > proxy and a registrar. Everything more fancy shall be done somewhere
> > else.
> >
> Maybe you are right. That's OK with me, but then SER should stop
> claiming that flexibility and that huge list of things that it is good for.

Does SER claim to be a SIP-UA? If it does, it shoudln't because even
with modules such as uac, it is not. 

> > >    - in the end could we have a clear and nice API to work with SIP
> > > messages, headers and URIs? Because not everybody wants to deal with SIP
> > > syntax all the time, yet every module re-implements the hunt for header
> > > values.
> >
> > But that does exist now. It's somewhat miss-leadingly called selects.
> >
> if it is not enforced, it won't get used too soon. we have to get the
> poison out of the fridge...

Pardon? You do know that there is people who are using SER on a
commercial basis? The new data model of SER 2.0 causes us major
headaches and will probably prevent us from switching over for quite
some time. Same with the config. It is a very fine tuned piece grown out
of years of experience. Assuming that those selects just work the same
way as the stuff we have now is dangerous.

> > For me, the script is the main reason as a service provider to use SER.
> > If a customer has a problem with a certain device, I can have a look at
> > a trace, see what's wrong and fix this. As someone running the service,
> > it is essential to be able to do these things merely be changing the
> > config file and not having to re-write part of the source and going
> > through the hoops of release deployment.
> >
> right, but the thing is that this kind of exploitation is actually the
> problem. If there is an issue, a script fix is preferred to a core fix.

We are not talking about problems with SER here. We are talking about
funny implementations in user agents, gateways, you name it. Yes, I can
talk to the suppliers and ask them to fix their stuff. With some this
turns into long discussions about the internal workings of SIP. The next
version then indeed has the problem fixed but a shiny new bug. My job is
to provide customers that happpen to have these devices with a reliable
dial-tone and a working service.

> Then the pile of hacks start to get bigger and bigger, until it is
> overly complicated to do new things, without remembering and using the
> stack of fixes that you did before.

Again, I have all these fixes in one place. I have them commented. If I
know there is no more customers with FooBox version 1.4.2 I can take the
thing out. In code I have to remember which source I have patched to
for the fix. Actually, I first have to remember that I have done that
patch. The config file is looked over quite regularly.

> > Fixing problems already often takes too long. If I were to implement all
> > those little changes "in code", I would loose even more time and, worse,
> > I would eventually loose track of all the changes as they would be
> > scattered all over the place. Now they are in the script with a short
> > comment above.
> >
> My opinion is that fixing problems at the root is always better than
> simple hacks.

I obviuosly agree. But I am in no position to do that.

> But hey, I am in a position which I hope that you won't
> get into: it is faster to replace the whole thing than to write one more
> hack for a minor thing.

I very much doubt that, but sure. If that is the case, go ahead.

> Eventually things get too complicated to be
> handled and then what? A script that generates a script ;-)?

As if that is such a rare thing. Java uses a very similar concept.
Think of the ser.cfg as the machine code of SER and Greger's script as a
high-level language on top.

Regards,
Martin