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

[Greger V. Teigre]

Dragos Vingarzan wrote:
> Greger V. Teigre wrote:
>   
>> Well, RADIUS in SER is as a client, I assume you have implemented a
>> server. That's a big difference.
>>     
> no, I did a peer (client & server).
>   
>> No, not the same thing. SER as a Diameter server does not make sense
>> to me.
>>     
> well, if you have an AAA, then you want to control things from there.
> And what do you do when you decide to barre a user? You go to the
> reigstrar manually and say "you're out"?
>   
No, but you use a clean management interface. Whether the existing FIFO, 
XMLRPC etc are good enough for you is another thing. My point is that 
once you have a SIP server, a Diameter server, a RADIUS server, an IPDr 
server, etc etc into ser binary, you get all sorts of weird cross-over 
issues, as well as a much higher probability that a bug somewhere will 
crash everything...
> The idea would be to be able to also push event the other way around
> (like the Registration Termination Request) so that you do not need to
> do some crazy subscribe/notify mechanism on the other side.
>   
Yes, I agree on the principle. It's just the software design I don't 
agree with.
> So now with the Open IMS Core registrar, I am able to change the
> expiration period from the global DB for any users, push service profile
> changes, etc. And I can also do 1000 of them at a time, because I have a
> nice architecture in SER too and it can take it and send SIP NOTIFYs
> from the Diameter processes.
>   
Yes, sounds nice, but have you tested all the possible scenarios. Like 
somebody pushing update to 100,000 subscribers in peak hours?
> Also, I haven't read the online charging stuff, but I guess that it
> makes more sense for example for the charging server to push the
> "zero-credit" event to the session controllers than to continuously
> monitor this.
>   
>> I've run RADIUS servers for years and I also know Diameter quite well.
>> Creating a good Diameter server is NOT something you do inside SER.
>> So, instead of having an excellent SIP proxy and and excellent
>> Diameter server communicating with some dedicated, controlled way, you
>> have two mediocre servers...
>>     
> :) could I get some feedback on my CDiameterPeer module? I think that it
> is pretty powerful (performance speaking).
>
> http://svn.berlios.de/wsvn/openimscore/ser_ims/trunk/modules/cdp/?rev=0&sc=0
>
> This is like my 3rd or 4th try at a Diameter integration... I don't see
> much wrong with it (don't look for 100% RFC in there, yet - I for one
> don't need it).
>   
Hehe, I don't think I'm in position to do a code review. I'm a software 
architect, not a developer.  However, what is interesting is that I 
believe we have switched roles: My position is very much a "architect 
for less possible problems", while you argue for simplicity and 
integration. I'm used to standalone RADIUS servers scaling to hundreds 
and thousands of requests per second per server. And we keep them 
standalone in order to keep the uptime.

In fact, I would believe that performace-wise, your implementation is 
good enough in environments where they are used to a) transparent 
failover and b) adding more servers is part of daily business. 
I.e. their cost base is already at that level.  However, the guys that 
SER developers develop for are actually focused on avoiding that kind of 
bloated operations environment because they are concerned about keeping 
the costs down (because they are competing with incumbent telcos with a 
high cost base...)
> (I may be now in Amsterdam ;-), but this is getting off topic or what?)
>   
Well, yes :-)
g-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070130/78a6c11c/attachment.html