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

[Dragos Vingarzan]

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, 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".
>
> 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. 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. I don't think that this is such a exotic idea when
you want to run a civilized network. 3GPP also recommends that you check
that the Via headers were not changed so that the answer would go back
on another path. This is also a good thing for a clean traffic.
>
>
> > 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.
>
>
> >    - 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...
>
>
> > - the script
> >    - great thing, but I think that it was designed pre-transactions,
> > pre-dialogs, etc, right?
> >    - lot's of opportunities there, but too many ways of breaking
> > things. If this is designed for normal users, then maybe the range of
> > actions should be restricted and piped through an API that would
> > eliminate most of the conformance issues that might appear.
>
> 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.
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.
>
>
> 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. 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. Eventually things get too complicated to be
handled and then what? A script that generates a script ;-)?

-Dragos