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

[Jan Janak]

Martin Hoffmann wrote:
> 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 ...

  Any particular recommendations?

> 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?

  Performance reasons. RFC3261 goes a long way in suggesting
  implementation details but it does not mean you have to follow them,
  as long as the behavior of the proxy is correct.

> 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.

    Jan.