Juha Heinanen wrote:
Dragos Vingarzan writes:
Then we could just take 90% of these IMS modules and brand them as "Diameter SIP Application". It's practically the same thing and you get a nice network architecture with great scalability properties.
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-12.txt
what scalability advantages does diameter give you over radius?
I was referring to SIP application level scalability, not to diameter/radius. The CSCF architecture solves the problem of the big home registrar being hard to replicate once one single machine can no longer handle all your subscribers. Of course there are other solutions, but this is a standardized one so that you can use different components and get out of the provider lock.
But you would miss the Application Server thing, with the possibility of easily enabling per-user functionality. Sure that you can do this now from the SER script, but the effort of maintaining it dynamic, per user and with the AS having access to the subscriber data is just huge. In my opinion SER's script is great for managing things at the SIP level, but once you build applications on top, you just want to abstract from that. And let's not forget the standardization aspect - any IMS core network should be able to use and standard IMS Application Servers.
what are those applications that ASes handle? why can't i put users' application info into radius raply table?
of course you can. But again, the standard is not there for what you say. Also radius has drawbacks, like the fact that it is not bi-directional so that you can not push updates back and forth.
-- juha