[Serusers] Radius accounting duplicate entries

Sebastian Murray-Roberts sebmurray at gmail.com
Wed Apr 19 15:31:33 CEST 2006


Hi there

I'm using ser v 0.9.6 and Freeradius v 1.1.0 on Ubuntu 5.10. I've set up SER
and implemented the radius accounting and it is working, except that it will
record the start and stop for a call, and then 20 seconds later will create
duplicate entries for the call. The duration is exactly the same, except the
start and stop are offset by 20 secs. Does anyone know why this is
happening? I've spent hours trawling the list and haven't found a solution
for the problem.

I'm pretty new to SER to apologies if there is anything obviously wrong.


My ser.cfg is as follows:

check_via=no    # (cmd. line: -v)
dns=no           # (cmd. line: -r)
rev_dns=no      # (cmd. line: -R)
port=5060
#children=4
fifo="/tmp/ser_fifo"

# ------------------ module loading ----------------------------------

# Uncomment this if you want to use SQL database

loadmodule "/usr/lib/ser/modules/sl.so"
loadmodule "/usr/lib/ser/modules/tm.so"
loadmodule "/usr/lib/ser/modules/rr.so"
loadmodule "/usr/lib/ser/modules/maxfwd.so"
loadmodule "/usr/lib/ser/modules/usrloc.so"
loadmodule "/usr/lib/ser/modules/registrar.so"
loadmodule "/usr/lib/ser/modules/textops.so"

loadmodule "/usr/lib/ser/modules/auth.so"
loadmodule "/usr/lib/ser/modules/auth_radius.so"
loadmodule "/usr/lib/ser/modules/acc_radius.so"
# ----------------- setting module-specific parameters ---------------

# -- usrloc params --

modparam("usrloc", "db_mode",   0)

#set auth_radius exported parameters
modparam("auth_radius","radius_config","/usr/local/etc/radiusclient/radiusclient.conf")
modparam("auth_radius","service_type",12)

# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
#modparam("usrloc", "db_mode", 2)

# accounting stuff
modparam("acc", "log_level", 1)
modparam("acc", "log_flag", 1)
modparam("acc", "log_fmt", "cdfimorstup")
modparam("acc", "radius_config",
"/usr/local/etc/radiusclient/radiusclient.conf")
modparam("acc", "radius_flag", 1)
modparam("acc", "radius_missed_flag", 3)
modparam("acc", "service_type", 15)
modparam("acc", "report_ack", 0)


#random string for authentication
modparam("auth", "secret",
"59t8eu4gnajdfg98qbuoarisdfhgjv-98iuQE[AFJV9M8CRWUPDXIN")

# -- auth params --
# Uncomment if you are using auth module
#
#modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this config),
# uncomment also the following parameter)
#
#modparam("auth_db", "password_column", "password")

# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)


# -------------------------  request routing logic -------------------

# main routing logic

route{

    if (!search("^(f|From):.*192.168.0.36"))
    {
        break;
    };

    # initial sanity checks -- messages with
    # max_forwards==0, or excessively long requests
    if (!mf_process_maxfwd_header("10"))
    {
        sl_send_reply("483","Too Many Hops");
        break;
    };
    if (msg:len >=  2048 ) {
        sl_send_reply("513", "Message too big");
        break;
    };

    #if a UA is attempting a register or invite, authorize him
    if(method == "REGISTER" || method == "INVITE")
    {
        log(1, "Attempting to authenticate user on domain 192.168.0.36");
        if(!radius_www_authorize("192.168.0.36"))
        {
            log(1, "User authentication on domain 192.168.0.36 failed");
            www_challenge("192.168.0.36","1");
            break;
         };
    };


    # we record-route all messages -- to make sure that
    # subsequent messages will go through our proxy; that's
    # particularly good if upstream and downstream entities
    # use different transport protocol
    if (!method=="REGISTER") record_route();

    if (method == "ACK")
    {
        route(2);
        break;
    };

    if (method=="INVITE") {
                log(1, "INVITE MESSAGE RECEIVED - START ACCOUNTING\n");
                setflag(1);
        };
        if (method=="BYE" || method=="CANCEL") {
                log (1, "BYE/CANCEL RECEIVED - STOP ACCOUNTING\n");
                setflag(1);
        route(2);
        break;
        };



    # subsequent messages withing a dialog should take the
    # path determined by record-routing
    if (loose_route())
    {
        # mark routing logic in request
        append_hf("P-hint: rr-enforced\r\n");
    };

    if (!uri==myself)
    {
        # mark routing logic in request
        append_hf("P-hint: outbound\r\n");
    };

    # if the request is for other domain use UsrLoc
    # (in case, it does not work, use the following command
    # with proper names and addresses in it)
    if (uri==myself)
    {

        if (method=="REGISTER")
        {
            log(1, "User registered on domain 192.168.0.36");
            save("location");
            sl_send_reply("200", "ok");
            break;
        }
        else
        {
#            lookup("aliases");
            # native SIP destinations are handled using our USRLOC DB
            if (!lookup("location"))
            {
                log(1, "Unknown user referenced for domain 192.168.0.36,
exiting (404)");
                sl_send_reply("404", "Not Found");
                break;
            };
        };
    };
    append_hf("P-hint: usrloc applied\r\n");

    route(2);

}

route[2]
{
    if (!t_relay()) {
        sl_reply_error();
    };

}


The accounting logs are as follows:

Wed Apr 19 12:20:43 2006
    Acct-Status-Type = Start
    Service-Type = Sip-Session
    Sip-Response-Code = 200
    Sip-Method = 1
    User-Name = "seb at 192.168.0.36"
    Calling-Station-Id = "sip:Seb at 192.168.0.36"
    Called-Station-Id = "sip:0824152727 at 192.168.0.36"
    Sip-Translated-Request-URI = "sip:0824152727 at 192.168.0.37:5070"
    Acct-Session-Id = "xzszxqjpwygwkky at 192.168.0.36"
    Sip-To-Tag = "8004"
    Sip-From-Tag = "lazwk"
    Sip-Cseq = "778"
    NAS-Port = 5060
    Acct-Delay-Time = 0
    NAS-IP-Address = 127.0.0.1
    Client-IP-Address = 127.0.0.1
    Acct-Unique-Session-Id = "1877d2d9ca784853"
    Stripped-User-Name = "seb"
    Realm = "192.168.0.36"
    Freeradius-Proxied-To = 192.168.0.36
    Timestamp = 1145442043

Wed Apr 19 12:20:51 2006
    Acct-Status-Type = Stop
    Service-Type = Sip-Session
    Sip-Response-Code = 200
    Sip-Method = 8
    User-Name = "0824152727 at 192.168.0.36"
    Calling-Station-Id = "sip:0824152727 at 192.168.0.36"
    Called-Station-Id = "sip:Seb at 192.168.0.36"
    Sip-Translated-Request-URI = "sip:Seb_192_168_0_36 at 192.168.0.36:5061"
    Acct-Session-Id = "xzszxqjpwygwkky at 192.168.0.36"
    Sip-To-Tag = "lazwk"
    Sip-From-Tag = "8004"
    Sip-Cseq = "391"
    NAS-Port = 5060
    Acct-Delay-Time = 0
    NAS-IP-Address = 127.0.0.1
    Client-IP-Address = 127.0.0.1
    Acct-Unique-Session-Id = "badf62373eccd795"
    Stripped-User-Name = "0824152727"
    Realm = "192.168.0.36"
    Freeradius-Proxied-To = 192.168.0.36
    Timestamp = 1145442051

As you can see, it seems to be generating another accounting report
corresponding to a call going the other way. The first entry is correct. The
second just seems to appear 20 secs after the call has been disconnected.
There are corresponding stops for both entries as well as entries into the
mysql database. Any ideas?

Thanks in advance
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060419/a30369a1/attachment.htm>


More information about the sr-users mailing list