Do you see route[1] in your log files when the INVITE message is being
processed ? You seem to have the radius_flag configured to 1 and that
flag is set in route(1), so check if that route section really gets
executed when ser forwards the INVITE message.
Jan.
On 17-11 16:20, Bruno Lopes F. Cabral wrote:
Hi there
after slashing my head with a hammer for a little bit,
reading many times the SER RADIUS Howto and acc man
page, I managed to get acc to log some RADIUS accounting
packets (Stop records and Call Failure records) with
FreeRADIUS
unfortunately, I could not discover how to generate
the START records, no matter what I tried!!
as the Stop record doesn't have RADIUS session-time,
I need the Start record so my current billing system
can be used.
I've searched the list archives quite a bit, and
googled on [serusers] and FreeRADIUS lists but
couldn't find a clue.
any help would be gratelly appreciated
snippets of ser.cfg
[...]
loadmodule "/usr/lib/ser/modules/registrar.so"
loadmodule "/usr/lib/ser/modules/auth.so"
loadmodule "/usr/lib/ser/modules/auth_radius.so"
# acc compiled with RADIUS support
loadmodule "/usr/lib/ser/modules/acc.so"
loadmodule "/usr/lib/ser/modules/nathelper.so"
# -- acc params --
modparam("acc", "radius_config",
"/etc/radiusclient/radiusclient.conf")
modparam("acc", "radius_flag", 1)
modparam("acc", "radius_missed_flag", 2)
#modparam("acc", "log_level", 1)
#modparam("acc", "failed_transactions", 1)
#modparam("acc", "report_cancels", 1)
#modparam("acc", "report_ack", 1)
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# -- auth_radius params --
modparam("auth_radius", "radius_config",
"/etc/radiusclient/radiusclient.conf")
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
# !! Nathelper
modparam("registrar", "nat_flag", 6)
modparam("nathelper", "natping_interval", 30) # Ping interval 30 s
modparam("nathelper", "ping_nated_only", 1) # Ping only clients
behind NAT
[...] pretty much nathelper.cfg example [...]
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
log(1,"LOG: not found\n");
setflag(2);
sl_send_reply("404", "Not Found");
break;
};
};
append_hf("P-hint: usrloc applied\r\n");
route(1);
}
route[1]
{
# !! Nathelper
if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)"
&& !search("^Route:")){
sl_send_reply("479", "We don't forward to private IP
addresses");
break;
};
log(1, "LOG: route[1]\n");
setflag(1);
# if client or server know to be behind a NAT, enable relay
if (isflagset(6)) {
force_rtp_proxy();
};
t_on_reply("1");
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
}
onreply_route[1] {
if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
fix_nated_contact();
# CHECK LATER: does this need to be enclosed on
# if(method==BYE || method==CANCEL) ???
force_rtp_proxy();
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
# EOF ---
one thing that I noticed was that, depending on which
side ended the call, the RADIUS Stop packet cames with
that side being the calling-station-id and the peer
being the called-station-id. is it supposed to be that
way?
Cheers
!3runo
P.S. in case it matters:
# ser -V
version: 0.8.14 (i386/linux)
flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK,
SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
@(#) $Id: main.c,v 1.168.4.3 2004/06/28 15:41:21 andrei Exp $
main.c compiled on 07:13:08 Nov 17 2004 with gcc 3.3
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers