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