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

[Greger V. Teigre]

I would say that we could learn something from the "telco perspective". 
However, we are too busy bashing their corruption of the SIP protocol to 
notice...  Not to say that they do a good thing for SIP, on the 
contrary, their monolithic and top-to-bottom stack control of everything 
prevents a lot of innovation and causes the much-touted and (very 
future) IMS applications to be so expensive that non-IMS applications 
are more likely to (already) have won...
    But, on the stuff that Martin writes about, operations, change 
management, scalability, failover, etc, we have lots to learn. I'm 
ashamed that there are no standardized way to monitor SER proxies, even 
a simple SNMP module would do. I would guess that there are 20-30 SER 
SNMP module implementations out there, all proprietary...
g-)

Dragos Vingarzan wrote:
> 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
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070129/885a5eec/attachment.htm