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

[Dragos Vingarzan]

=)) SNMP got on my list recently - so I threw the list away :-P.

I am more amazed that nobody pays attention to how IMS deals with
scalability issues. Everybody here bashes IMS, yet I see lot's of
"IMS-like" features being requested and implemented when nobody notices
the context.

I am not saying that this is the way to go, but to me it seems more
clean approach than the current one. For example, is there a civilized
mechanism to move users between registrars so that you could take one
offline and upgrade the hardware or something? A telco would NEVER
accept a node that is not capable of offloading itself. Downtimes for
maintenance are a big no-no.

Oh, and btw: any pure SIP app server that does loose routing can be used
as an IMS App Server with Open IMS Core.... so it shouldn't be
expensive... or? Yes, they did screw it here and there instead of
cleaning and innovating into SIP, but hey, there is also quite some
resistance on the other side too.

-Dragos

Greger V. Teigre wrote:
> 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
>>
>>
>>   


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