[Serdev] SER's core design features(process
model/parser/lumps/script) - was: So who/what is SER for, anyway?
Greger V. Teigre
greger at teigre.com
Tue Jan 30 09:11:31 UTC 2007
Yes, Jiri. And that's where I believe the non-traditional vendors of
software and solution do a fatal mistake. By everybody keeping
everything to themselves, the costs of building it (in terms of
competence like Martin and hist fellow sysops and developers) quite fast
get similar to the costs of buying from a traditional telco-vendor
(well, not really, but too expensive).
I do realize that the immature SIP, non-telco industry needs to find
good business models. However, I only see innovative business models in
the Asterisk world, not the SIP proxy world. The problem is that the
most likely customers of SIP proxy "new-breed" companies are telcos and
the business models adapt. This will give IMS a (small) chance of
succeeding.
g-)
Jiri Kuthan wrote:
> As others have pointed out, the thing is many do pay attention to scalability
> and have working solutions. It is just that they consider it an asset they
> dont wish to give away. The best thing is just for those willing to share
> to go ahead and publish....
>
> -jiri
>
> p.s. -- that's neiter IMS specific nor telco specific.
>
> At 22:01 29/01/2007, Dragos Vingarzan wrote:
>
>> =)) 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...
>> -----------------------------------------------------------------
>>
>> _______________________________________________
>> Serdev mailing list
>> Serdev at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serdev
>>
>
> --
> Jiri Kuthan http://iptel.org/~jiri/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070130/2c697434/attachment.html
More information about the Serdev
mailing list