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
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
Hi Jan, thanks for replying
Jan Janak wrote:
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.
I think I found the cause of the problem. my apologise in advance if the following isn't what I think it is. Please be gentle :-)
to try to force a RADIUS start acct packet, I did the following at very beginning of route[0]:
if(method=="INVITE") { setflag(1); rad_acc_request("Start"); }
that finally shows me a packet like this one
rad_recv: Accounting-Request packet from host 127.0.0.1:32781, id=192, length=252 Acct-Status-Type = Failed <-------- Service-Type = Sip-Session Sip-Response-Code = Other Sip-Method = Invite <--------- User-Name = "1234@my.sip.server.com" Calling-Station-Id = "sip:1234@my.sip.server.com" Called-Station-Id = "sip:3034094@my.sip.server.com" Sip-Translated-Req-ID = "sip:34094@fwd.pulver.com:5060" Acct-Session-Id = "79e2c134dce64991@192.168.0.100" Sip-To-Tag = "n/a" Sip-From-Tag = "40305062d9d57506" Sip-Cseq = "23229" NAS-IP-Address = 127.0.0.1 NAS-Port = 5060 Acct-Delay-Time = 0 rlm_radutmp: NAS localhost port 5060 unknown packet type 15) Sending Accounting-Response of id 192 to 127.0.0.1:32781
without the rad_acc_request, no RADIUS packet is sent upon INVITE, no matter how hard I tried or where I put the setflag(1) -- I put LOG(1,"message\n") on every if inside ser.cfg to follow the code and did various tests before caming to that conclusion
while investigating code from ser/modules/acc/, I found that rad_acc_request function will pass its parameter to be processed as, forgive me if I mis-read the code, RADIUS AV-Pairs!!??
that isn't stated at ser/modules/acc/README
after some digging, I came to the following snippet at ser/modules/acc/acc.c that make my point
[...] inline UINT4 rad_status(struct sip_msg *rq, str *phrase) { int code;
code=phrase2code(phrase); if (code==0) return vals[V_STATUS_FAILED].v; if ((rq->REQ_METHOD==METHOD_INVITE || rq->REQ_METHOD==METHOD_ACK) && code>=200 && code<300) return vals[V_STATUS_START].v; if ((rq->REQ_METHOD==METHOD_BYE || rq->REQ_METHOD==METHOD_CANCEL)) return vals[V_STATUS_STOP].v; return vals[V_STATUS_FAILED].v; } [...]
*phrase comes from rad_acc_request("phrase"), so the code tries to interpret the string to decide which Status code to send.
so I put there "200" and got the corresponding Start packet (snippet) using the same ser.cfg INVITE test
if(method=="INVITE") { setflag(1); rad_acc_request("200"); }
Acct-Status-Type = Start <----- Service-Type = Sip-Session Sip-Response-Code = 200 Sip-Method = Invite <-----
Please note the change on Sip-Response-Code to the number I passed to the function
my thought is the following: something is wrong in setflag(radius_flag)'s handling (for RADIUS, at least), as it won't automatically "see" that a Start packet is needed upon INVITEs as it does to Stop packets (CANCEL or BYE) -- a trigger is missing somewhere
if one forces it (as I did), a 2xx response code must be provided as parameter so acc.c's rad_status function will make the correct assumption about acct type and send the correct (Start) packet upon acc_rad_request call
Here is the snippet of a packet of a real failed call (to a non registered UA) - triggered with
if (!lookup("location")) { log(1,"route[0]: not found\n"); setflag(2); # doesn't seem to be needed, problably because sl_send_reply # acc_rad_request("404"); sl_send_reply("404", "Not Found"); break; };
Acct-Status-Type = Failed <---- Service-Type = Sip-Session Sip-Response-Code = Other Sip-Method = Invite <---- [...]
uncommenting the acc_rad_request("404") will bring
Acct-Status-Type = Failed Service-Type = Sip-Session Sip-Response-Code = 404 <---- Sip-Method = Invite [...]
for the sake of completeness, a Sucessfull call with a Stop packet shows as following:
rad_recv: Accounting-Request packet from host 127.0.0.1:32781, id=194, length=259 Acct-Status-Type = Stop Service-Type = Sip-Session Sip-Response-Code = 200 Sip-Method = 8 <----????? User-Name = "1234@my.sip.server.com" Calling-Station-Id = "sip:1234@my.sip.server.com" Called-Station-Id = "sip:3034094@my.sip.server.com" Sip-Translated-Req-ID = "sip:34094@fwd.pulver.com:5060" Acct-Session-Id = "79e2c134dce64991@192.168.0.100" Sip-To-Tag = "1d1a71b7e00b6f84" Sip-From-Tag = "40305062d9d57506" Sip-Cseq = "23230" NAS-IP-Address = 127.0.0.1 NAS-Port = 5060 Acct-Delay-Time = 0 rlm_radutmp: Logout for NAS localhost port 5060, but no Login record Sending Accounting-Response of id 194 to 127.0.0.1:32781
although Calling-Station-Id and Called-Station-Id could be switched between each other depending on which side terminated the call
(I wish to know what Sip-Method=8 means)
comments on what I found?
I'm still thinking on which are the best places to put the setflag's (and acc_rad_requests) to get accurate and non-duplicate RADIUS Start/Stop and Failed packets. Suggestions are more than welcome ;-)
Cheers !3runo from Brazil
P.S. my ser.cfg has (snippets)
loadmodule "/usr/lib/ser/modules/auth.so" loadmodule "/usr/lib/ser/modules/auth_radius.so" loadmodule "/usr/lib/ser/modules/acc.so" loadmodule "/usr/lib/ser/modules/nathelper.so"
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)
and is pretty much nathelper.cfg found in SER distribution
Bruno,
Sorry if I bother you, but I can not make Accounting work with SER and RAIDUS. After reading the following mail ... I can see that, after all, you managed your self to get SER send an Acct-Stop message to RADIUS. How did you do it ?
Regards,
Lucas
Jan Janak wrote:
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.
I think I found the cause of the problem. my apologise in advance if the following isn't what I think it is. Please be gentle :-)
to try to force a RADIUS start acct packet, I did the following at very beginning of route[0]:
if(method=="INVITE") { setflag(1); rad_acc_request("Start"); }
that finally shows me a packet like this one
rad_recv: Accounting-Request packet from host 127.0.0.1:32781, id=192, length=252 Acct-Status-Type = Failed <-------- Service-Type = Sip-Session Sip-Response-Code = Other Sip-Method = Invite <--------- User-Name = "1234@my.sip.server.com" Calling-Station-Id = "sip:1234@my.sip.server.com" Called-Station-Id = "sip:3034094@my.sip.server.com" Sip-Translated-Req-ID = "sip:34094@fwd.pulver.com:5060" Acct-Session-Id = "79e2c134dce64991@192.168.0.100" Sip-To-Tag = "n/a" Sip-From-Tag = "40305062d9d57506" Sip-Cseq = "23229" NAS-IP-Address = 127.0.0.1 NAS-Port = 5060 Acct-Delay-Time = 0 rlm_radutmp: NAS localhost port 5060 unknown packet type 15) Sending Accounting-Response of id 192 to 127.0.0.1:32781
without the rad_acc_request, no RADIUS packet is sent upon INVITE, no matter how hard I tried or where I put the setflag(1) -- I put LOG(1,"message\n") on every if inside ser.cfg to follow the code and did various tests before caming to that conclusion
while investigating code from ser/modules/acc/, I found that rad_acc_request function will pass its parameter to be processed as, forgive me if I mis-read the code, RADIUS AV-Pairs!!??
that isn't stated at ser/modules/acc/README
after some digging, I came to the following snippet at ser/modules/acc/acc.c that make my point
[...] inline UINT4 rad_status(struct sip_msg *rq, str *phrase) { int code;
code=phrase2code(phrase); if (code==0) return vals[V_STATUS_FAILED].v; if ((rq->REQ_METHOD==METHOD_INVITE ||rq->REQ_METHOD==METHOD_ACK) && code>=200 && code<300) return vals[V_STATUS_START].v; if ((rq->REQ_METHOD==METHOD_BYE || rq->REQ_METHOD==METHOD_CANCEL)) return vals[V_STATUS_STOP].v; return vals[V_STATUS_FAILED].v; } [...]
*phrase comes from rad_acc_request("phrase"), so the code tries to interpret the string to decide which Status code to send.
so I put there "200" and got the corresponding Start packet (snippet) using the same ser.cfg INVITE test
if(method=="INVITE") { setflag(1); rad_acc_request("200"); }
Acct-Status-Type = Start <----- Service-Type = Sip-Session Sip-Response-Code = 200 Sip-Method = Invite <-----Please note the change on Sip-Response-Code to the number I passed to the function
my thought is the following: something is wrong in setflag(radius_flag)'s handling (for RADIUS, at least), as it won't automatically "see" that a Start packet is needed upon INVITEs as it does to Stop packets (CANCEL or BYE) -- a trigger is missing somewhere
if one forces it (as I did), a 2xx response code must be provided as parameter so acc.c's rad_status function will make the correct assumption about acct type and send the correct (Start) packet upon acc_rad_request call
Here is the snippet of a packet of a real failed call (to a non registered UA) - triggered with
if (!lookup("location")) { log(1,"route[0]: not found\n"); setflag(2);# doesn't seem to be needed, problably because sl_send_reply # acc_rad_request("404"); sl_send_reply("404", "Not Found"); break; };
Acct-Status-Type = Failed <---- Service-Type = Sip-Session Sip-Response-Code = Other Sip-Method = Invite <----[...]
uncommenting the acc_rad_request("404") will bring
Acct-Status-Type = Failed Service-Type = Sip-Session Sip-Response-Code = 404 <---- Sip-Method = Invite[...]
for the sake of completeness, a Sucessfull call with a Stop packet shows as following:
rad_recv: Accounting-Request packet from host 127.0.0.1:32781, id=194, length=259 Acct-Status-Type = Stop Service-Type = Sip-Session Sip-Response-Code = 200 Sip-Method = 8 <----????? User-Name = "1234@my.sip.server.com" Calling-Station-Id = "sip:1234@my.sip.server.com" Called-Station-Id = "sip:3034094@my.sip.server.com" Sip-Translated-Req-ID = "sip:34094@fwd.pulver.com:5060" Acct-Session-Id = "79e2c134dce64991@192.168.0.100" Sip-To-Tag = "1d1a71b7e00b6f84" Sip-From-Tag = "40305062d9d57506" Sip-Cseq = "23230" NAS-IP-Address = 127.0.0.1 NAS-Port = 5060 Acct-Delay-Time = 0 rlm_radutmp: Logout for NAS localhost port 5060, but no Login record Sending Accounting-Response of id 194 to 127.0.0.1:32781
although Calling-Station-Id and Called-Station-Id could be switched between each other depending on which side terminated the call
(I wish to know what Sip-Method=8 means)
comments on what I found?
I'm still thinking on which are the best places to put the setflag's (and acc_rad_requests) to get accurate and non-duplicate RADIUS Start/Stop and Failed packets. Suggestions are more than welcome ;-)
Cheers !3runo from Brazil
P.S. my ser.cfg has (snippets)
loadmodule "/usr/lib/ser/modules/auth.so" loadmodule "/usr/lib/ser/modules/auth_radius.so" loadmodule "/usr/lib/ser/modules/acc.so" loadmodule "/usr/lib/ser/modules/nathelper.so"
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)
and is pretty much nathelper.cfg found in SER distribution
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.786 / Virus Database: 532 - Release Date: 29/10/2004
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.5.4 - Release Date: 15/12/2004
Bruno,
Sorry if I bother you, but I can not make Accounting work with SER and RAIDUS. After reading the following mail ... I can see that, after all, you managed your self to get SER send an Acct-Stop message to RADIUS. How did you do it ?
Regards,
Lucas
Jan Janak wrote:
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.
I think I found the cause of the problem. my apologise in advance if the following isn't what I think it is. Please be gentle :-)
to try to force a RADIUS start acct packet, I did the following at very beginning of route[0]:
if(method=="INVITE") { setflag(1); rad_acc_request("Start"); }
that finally shows me a packet like this one
rad_recv: Accounting-Request packet from host 127.0.0.1:32781, id=192, length=252 Acct-Status-Type = Failed <-------- Service-Type = Sip-Session Sip-Response-Code = Other Sip-Method = Invite <--------- User-Name = "1234@my.sip.server.com" Calling-Station-Id = "sip:1234@my.sip.server.com" Called-Station-Id = "sip:3034094@my.sip.server.com" Sip-Translated-Req-ID = "sip:34094@fwd.pulver.com:5060" Acct-Session-Id = "79e2c134dce64991@192.168.0.100" Sip-To-Tag = "n/a" Sip-From-Tag = "40305062d9d57506" Sip-Cseq = "23229" NAS-IP-Address = 127.0.0.1 NAS-Port = 5060 Acct-Delay-Time = 0 rlm_radutmp: NAS localhost port 5060 unknown packet type 15) Sending Accounting-Response of id 192 to 127.0.0.1:32781
without the rad_acc_request, no RADIUS packet is sent upon INVITE, no matter how hard I tried or where I put the setflag(1) -- I put LOG(1,"message\n") on every if inside ser.cfg to follow the code and did various tests before caming to that conclusion
while investigating code from ser/modules/acc/, I found that rad_acc_request function will pass its parameter to be processed as, forgive me if I mis-read the code, RADIUS AV-Pairs!!??
that isn't stated at ser/modules/acc/README
after some digging, I came to the following snippet at ser/modules/acc/acc.c that make my point
[...] inline UINT4 rad_status(struct sip_msg *rq, str *phrase) { int code;
code=phrase2code(phrase); if (code==0) return vals[V_STATUS_FAILED].v; if ((rq->REQ_METHOD==METHOD_INVITE ||rq->REQ_METHOD==METHOD_ACK) && code>=200 && code<300) return vals[V_STATUS_START].v; if ((rq->REQ_METHOD==METHOD_BYE || rq->REQ_METHOD==METHOD_CANCEL)) return vals[V_STATUS_STOP].v; return vals[V_STATUS_FAILED].v; } [...]
*phrase comes from rad_acc_request("phrase"), so the code tries to interpret the string to decide which Status code to send.
so I put there "200" and got the corresponding Start packet (snippet) using the same ser.cfg INVITE test
if(method=="INVITE") { setflag(1); rad_acc_request("200"); }
Acct-Status-Type = Start <----- Service-Type = Sip-Session Sip-Response-Code = 200 Sip-Method = Invite <-----Please note the change on Sip-Response-Code to the number I passed to the function
my thought is the following: something is wrong in setflag(radius_flag)'s handling (for RADIUS, at least), as it won't automatically "see" that a Start packet is needed upon INVITEs as it does to Stop packets (CANCEL or BYE) -- a trigger is missing somewhere
if one forces it (as I did), a 2xx response code must be provided as parameter so acc.c's rad_status function will make the correct assumption about acct type and send the correct (Start) packet upon acc_rad_request call
Here is the snippet of a packet of a real failed call (to a non registered UA) - triggered with
if (!lookup("location")) { log(1,"route[0]: not found\n"); setflag(2);# doesn't seem to be needed, problably because sl_send_reply # acc_rad_request("404"); sl_send_reply("404", "Not Found"); break; };
Acct-Status-Type = Failed <---- Service-Type = Sip-Session Sip-Response-Code = Other Sip-Method = Invite <----[...]
uncommenting the acc_rad_request("404") will bring
Acct-Status-Type = Failed Service-Type = Sip-Session Sip-Response-Code = 404 <---- Sip-Method = Invite[...]
for the sake of completeness, a Sucessfull call with a Stop packet shows as following:
rad_recv: Accounting-Request packet from host 127.0.0.1:32781, id=194, length=259 Acct-Status-Type = Stop Service-Type = Sip-Session Sip-Response-Code = 200 Sip-Method = 8 <----????? User-Name = "1234@my.sip.server.com" Calling-Station-Id = "sip:1234@my.sip.server.com" Called-Station-Id = "sip:3034094@my.sip.server.com" Sip-Translated-Req-ID = "sip:34094@fwd.pulver.com:5060" Acct-Session-Id = "79e2c134dce64991@192.168.0.100" Sip-To-Tag = "1d1a71b7e00b6f84" Sip-From-Tag = "40305062d9d57506" Sip-Cseq = "23230" NAS-IP-Address = 127.0.0.1 NAS-Port = 5060 Acct-Delay-Time = 0 rlm_radutmp: Logout for NAS localhost port 5060, but no Login record Sending Accounting-Response of id 194 to 127.0.0.1:32781
although Calling-Station-Id and Called-Station-Id could be switched between each other depending on which side terminated the call
(I wish to know what Sip-Method=8 means)
comments on what I found?
I'm still thinking on which are the best places to put the setflag's (and acc_rad_requests) to get accurate and non-duplicate RADIUS Start/Stop and Failed packets. Suggestions are more than welcome ;-)
Cheers !3runo from Brazil
P.S. my ser.cfg has (snippets)
loadmodule "/usr/lib/ser/modules/auth.so" loadmodule "/usr/lib/ser/modules/auth_radius.so" loadmodule "/usr/lib/ser/modules/acc.so" loadmodule "/usr/lib/ser/modules/nathelper.so"
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)
and is pretty much nathelper.cfg found in SER distribution
-
Bruno Lopes F. Cabral -
Jan Janak -
Lucas Aimaretto