2 Jan
2017
2 Jan
'17
7:20 p.m.
On 02 Jan 2017, at 17:15, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
There is acc_radius that offers what acc with radus support enabled
should do. The acc was left with the radius code just for people used
with the old way and be sure that acc_radius is complete. If nobody
complains, the radius part from acc module can be completely removed.
Ok
The diameter support is not depending on any external lib, just that it
was developed long time ago, when diameter specs were a draft.
Meanwhile, they became rfc, but I haven't seen anyone using diameter for
acc in VoIP (well, apart of IMS/VoLTE, but that's different) and it is a
good chance that the code needs a bit of hammering to make it work.
Ok, so if it’s
in that stage, let’s keep it hidden.
Ideally, it should be moved to a dedicated module, acc_diameter, like we
did with acc_radius in the past. At some point I wanted to do it, but I
could find any easy to use open source diameter server. Now no spare
time here, if anyone wants to do it, she/he is welcome to start.
With this reply I don’t see this situation as a problem for distro packaging any more. My
worries are gone.
Any feedback from those actually working with packaging?
/O
Cheers,
Daniel
On 02/01/2017 16:40, Olle E. Johansson wrote:
From the README:
"The SQL backend support is compiled in the module. For RADIUS and DIAMETER you need
to enable it by recompiling the module with properly set defines: uncomment the RAD_ACC or
DDIAM_ACC lines in modules/acc/Makefile. To compile RADIUS support, you need to have
radiusclient-ng (only versions higher or equal to 0.5.0) installed on your system which is
available from http://developer.berlios.de/projects/radiusclient-ng/.”
This compile-time option is one of the few remaining that makes binary distributions hard
- I don’t know how the debian packages handled this one.
Anyone that wants to attempt a way to handle this as modules instead? I don’t fancy
adding diameter and radius support as a requirement
for compiling ACC but there has to be a way to follow the lead of the AUTH modules, with
one generic module and then additional AUTH_RADIUS etc.
(Looking at you Carsten :-) )
/O
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev