[Serdev] So who/what is SER for, anyway?

[Martin Hoffmann]

Salut,

for some reason Greger cut away some parts when splitting up the
message, so I have to go back here.

Dragos Vingarzan wrote:
> 
> I am not sure if I should start this thread or not...

Very much appreciated that you did. That I responded slightly negative
to your issues doesn't mean I don't share them. You just happened to
have identified what I perceive as _the_ advantage of SER as the
ultimate evil.

> Some of you might receive this as SER bashing. But please understand
> that I only want to point out the parts that I, for one, really hate, in
> the hope that the future would bring something good. I think that SER is
> a wonderful piece of software, but it just shows it's age and has some
> cans of worms here and there.

I'd like to innocently comment that the code quality could do with a bit
of improvement. I known that I am a bit anal about coding style, and it is
not as bad as Asterisk, but ...

I think I have headed out to understand tm about six times and every
single attempt failed miserably. Two of them even included the drawing
of pictures and call flow diagrams. Nope. Impossible.
 
> - the tm module
>     - this is standard RFC3261 behavior, yet is this complete now? I for
> one can not keep-up and understand all of it. One has to know very well
> the RFC and then through its code to use it, as it's up to the user to
> ensure conformance.

To me the main problem with tm is that it doesn't follow The
Standard. If you take 3261 you can write a transaction layer and a proxy
core by more or less turning every sentence into a statement or two. Why
does tm go its own way? Why does it merge the transaction layer and the
proxy transaction user into one big messy thing?

Here's a proposal: Re-write the transaction stuff as per 3261. One
module "transaction-layer" (tl?) that implements the transaction layer
with the interface for a transaction user. Implement a statfull proxy
core on top of that ("tproxy"?). For those people who wish SER to be a
UA, implement a UAS and UAC core on top of tl. There even is room for a
B2BUA module.

>     - isn't this core functionality? I just want to have a flag that
> would enable/disable/indicate transactions. Then 90% of the users would
> just enable that and forget about the over complicated scripts and the
> rest would just disable and enable it separately.

It doesn't really matter, if it is in core or in one or two modules. I
would happily part with statless proxying (ie., all the forward stuff). It
doesn't work anyways. However, I do need sl_send_reply(). And I need
the option to call this function before the proxy starts creating a
transaction.

> - the dialogs
>     - again, this should be core. I think everything that is in RFC 3261
> (at least) should be core if we want a "SIP" proxy.

Does 3261 really say that a proxy needs to know about dialogs? I don't
think so. 
 
> - transport
>     - no interface here, so defining new transports or new ways of
> handling messages is impossible.

It may be hard, but it is not impossible. I think the new TCP
implementation in SER 2.0 allows you quite some room here.

Regards,
Martin