[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:
>> Maybe not the right time to say this, but honestly, that sounds like a
>> bad design decision. Monolithic applications with all sorts interfaces
>> increases complexity, cost of maintenance, increases exponentially the
>> number of potential bugs etc etc.  Maybe there are things I don't see
>> here, but with the appropriate interfaces, I cannot really see why you
>> would want Diameter built into ser binary?!
>>     
> right, like nobody else uses SER with RADIUS ;-). Well, simply because
> SIP doesn't do AAA and I don't see the point in interleaving another
> communication protocol between SIP and Diameter.
>   
Well, RADIUS in SER is as a client, I assume you have implemented a 
server. That's a big difference.
>>>     
>>>       
>> But if you create Diameter separately, you can even run Diameter on a
>> separate physical server, do load balancing across SER servers (if
>> they replicate), you can create a queue, you can handle DoS attacks on
>> Diamete you can maintain Diameter with a separate team of developers
>> who know nothing of SER, etc etc ...
>>     
> yes, but Diameter, as RADIUS, does AAA. So why, when getting a REGISTER,
> should I send a RPC call to a separate Diameter client, which
> interrogates a Diameter server, which responds back and then I pick up
> somewhere else (where???) in SER and send a 200 OK...
>   
Then I misunderstood. There are already diameter client modules for ser. 
Using SER as diameter client is a no-brainer.
> Same thing for the other direction of requests, from the AAA server
> towards the AAA client (SER)....
>   
No, not the same thing. SER as a Diameter server does not make sense to me.
> It's the same question as: Why would you integrate a db interface into
> SER...
>   
Not at all the same thing. SER uses the database as client. The database 
does not run queries against SER-
> The only difference is that Diameter is more complicated than Radius and
> it is bidirectional. So old approaches for doing Diameter as RADIUS was
> done are flawed, IMO. This is a new thing and anything new that is
> breaking old  assumptions that were taken on the initial design will
> continue to give us headaches.
>   
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...
g-)
> -Dragos
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070129/0636d4eb/attachment.htm