[asterisk-dev] AstriDevCon - PineMango
nir.simionovich at gmail.com
Thu Oct 9 06:49:13 CDT 2008
Agreed, so it must be in the architecture - but as you may have noticed from
previous email, I raised the issue of what is the proper architecture, I'm
sure that having a layer of AA services is the proper way to go.
If the AA services are a mandatory layer, we risk making things more
for standalone application developers. Going to the other side, if I'm a
provider, I would really like to tie that AA layer to an existing AAA
that I may already have deployed, such as RADIUS or DIAMETER.
I think that the best track to take would be to go about and include that
AA mechanism as an API with pluggable modules, allowing for additional AA
mechanisms to be plugged in. If we've already gone the distance to include
no point in not doing in such a way that would appeal to the Big Boys too. I
for fact that carriers in Israel hadn't adopted Asterisk fully due to its
of RADIUS/DIAMETER support.
Please consider the diagram currently posted in the wiki.
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Johansson Olle E
Sent: Thursday, October 09, 2008 11:53 AM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] AstriDevCon - PineMango
9 okt 2008 kl. 11.49 skrev Nir Simionovich:
> While I do agree with oej that security is a must, when allowing such
> core level interconnect, i would also agree with Brian that the toll
> required may be one that we are unable to undertake at this point in
If it's not in the architecture from start - regardless if the actual
code is there-
then the architecture will be wrong and we risk a very high cost of
security as a second thought. If there's no auth* in there, Asterisk
will be even
more open for all kinds of security violations than today, and that's
Authorization is also about being able to implement segmentation, i.e.
hosting within an Asterisk platform.
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
More information about the asterisk-dev