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

Thu Jan 25 13:29:27 UTC 2007

IMHO, auto-generating scripts is too hard a problem. Code
auto-generation might work for very precise tasks, e.g. parsers, but
given the complexity of the problem...

-Dragos

Greger V. Teigre wrote:
>
> Klaus and Dragos,
> I also agree on your statements/suggestions regarding the script,
> however, I realize that there is too much history (and hours and days of
> work) invested in ser.cfg. At least to radically strip ser.cfg.  That
> could quickly render ser useless for many setups where implementation
> errors have been corrected by "fixes" and where one has adapted to all
> the non-standard approaches...
>
>  >We could start with a script which generates the ser config from a
> template file and a user configuration file as starting point for users
> (like >the exim4 configuration in debian)
>
> This is exactly what I have spent a considerable amount of my time on
> the last months. I use m4 and set of template files + "hooks" in the
> template files where you can add your own code. Using this build system,
> you can manage a set of servers with common features, as well as be able
> to manage differences between servers.
> It is built on the SER - Getting Started configuration files and I'm
> getting closer to releasing a first version. It will be commited to SER
> 2.0 CVS as this has no code impact.
>
> My goal is that ser.cfg should ALWAYS be auto-generated and that you can
> use switches in the configuration file together with code pieces for
> each hook (ex. detecting NAT) to modify the configuration.
> g-)
>
> Klaus Darilion wrote:
> > Regarding the script I fully agree with Dragos!
> >
> > IMO there are several things which should be hided from configuration.
> > E.g. the terrible if(method!=REGISTER) record_route();
> >
> > IMO we should have an option record_route=yes and we are done.
> >
> > Also the whole NAT traversal. This should be handled globally too, e.g.
> >
> > perform_nat_traversal=no/always/ifneeded (this of course automatically
> > activates the rtp proxy - no need to check for replies with 183/200 -
> > no need to check for reINVITEs, ...)
> >
> > rtp_proxy=mediaproxy/rtpproxy
> >
> > allow_preloaded_routesets=no/yes
> >
> > And so on. I suspect there is no ser/openser installation out there
> > (included mine) which is 100% RFC conform regarding or has a total
> > bugfree NAT traversal (e.g. doing fix_nated_contact only for local SIP
> > users) ...
> >
> > Thus, there is lots of potential to make ser more user friendly. The
> > above examples do not have any performance impact, but prevents users
> > from having lots of bugs in their message handling and NAT traversal).
> >
> > I already can year you crying that we will loose all the flexibility
> > when doing this - but in the end we will have a very flexible SIP
> > proxy which will be used by geeks and there will be not so flexible
> > SIP proxies (asterisk, repro ...) which will be used by admins without
> > a PhD in SIP.
> >
> > regards
> > klaus
> >
> > PS: We could start with a script which generates the ser config from a
> > template file and a user configuration file as starting point for
> > users (like the exim4 configuration in debian)
> >
> >
> > Greger V. Teigre wrote:
> >> Greger's comment: Dragos have several observations related to the
> >> core design of SER, namely the process model, the parser, the lumps
> >> and the script. Thus, the thread name: SER's core design
> >> features(process model/parser/lumps/script).
> >> --------------------------------------
> >>
> >> So let me be specific:
> >> - the process model
> >>    - believe it or not, I might want to write a module that needs more
> >> processes to be efficient. SER is no longer "just a SIP proxy".
> >>    - yes, I know about the FIFO, RPC and whatever other interfaces, but
> >> is anyone fully satisfied with that?
> >>
> >> - the parser
> >>    - if SIP is an extensible protocol regarding the headers, why don't
> >> we have an equally easy to extend parser? For example, the header name
> >> parser could be auto-generated from a list of configurable header
> names.
> >>    - and do we really need it that fast anyway? I have seen some
> >> changes that push code clarity instead of insane performance, just keep
> >> them coming.
> >>    - 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.
> >>
> >> - the lumps
> >>    - performance + memory concerns, ok, but the mechanism is a little
> >> perverse. First you do not (and can not) enforce even the RFC
> compliance
> >> of messages. Then if I do a change, another module can't see it and you
> >> just hope all will be fine.
> >>    - this goes then back to the point above - lack of an API, as an API
> >> would hide the internal structures in the core and let you modify and
> >> view modifications easily and transparently.
> >>
> >> - 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.
> >>    - Someone needs to step in and set some boundaries here. It's great
> >> for people without programming experience, that do not want to write a
> >> module to do something new, but it is often abused by the same people
> >> and then hacks propagate into the modules and core. Too much
> flexibility
> >> from my point of view. You want to do something complex, then write a
> >> module and interface it to the script, then have a small and clean
> >> linking script.
> >>
> >> _______________________________________________
> >> Serdev mailing list
> >> Serdev at lists.iptel.org
> >> http://lists.iptel.org/mailman/listinfo/serdev
> >
> >
>

-- 
-----------------------------------------
Dipl. Eng. Dragos Vingarzan
FOKUS/NGNI
Kaiserin-Augusta-Allee 31
10589 Berlin,Germany
Phone +49 (0)30 - 3463 - 7385
Mobile +49 (0)163 - 159 - 5221
eMail vingarzan at fokus.fraunhofer.de
Web www.fokus.fraunhofer.de
We could change the world if God would give us the source code...
-----------------------------------------------------------------