Re: [Serusers] radius acc: where are the start records?

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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers