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

[Dragos Vingarzan]

Martin Hoffmann wrote:
>
> You do know of fork(2), right?
>
the point was that there are more things to do than just a simple fork.
Processes need to be managed somehow, mainly due to the TCP stuff.
>
>
> > > 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.
>
Call it 3GPP, TISPAN or RFC 4740, you are right, it's out of scope now.
But the thing is that once you want to do more, you need to abstract
from lower layers. And you need a solid base to be able to do a good
abstraction.
>
>
> > 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?
>
it was just an example, replace with whatever you have there.
>
>
> Does SER claim to be a SIP-UA? If it does, it shoudln't because even
> with modules such as uac, it is not.
>
some of the features imply SIP-UA. It is great as UAS, yet basic at UAC.
>
> 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.
>
You are right. So say what bothers you the most and let's see how we can
improve that. I know that your interest is mainly to keep your business
running smoothly. This is why old versions should be maintained. But if
we would freeze there we're stuck with that.
>
>
> > 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.
>
well, but service providers should be the ones that should force this
wacky manufacturers to be compliant.So fix the problem at the root and
you will be overall more happy.

Again, I am not for cutting out SER's flexibility, I am just for
splitting it and making it manageable.
>
> > 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.
>
I will just troll around a little bit more, see if maybe things would
get better for me ;-). I mean, I would rather invest time in SER than in
a completely new thing because I have no interest in building a SER like
thing...
>
> > 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.
>
it's pretty dirty though :). I don't think of it that way because when I
want something done, I do it in a module and I export the normal
functionality that an administrator might need in the script and tie it
there.

-Dragos