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

Jan Janak wrote: message is being 1 and that 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 = &quot;1234(a)my.sip.server.com&quot; 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 = &quot;79e2c134dce64991(a)192.168.0.100&quot; 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 = &quot;1234(a)my.sip.server.com&quot; 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 = &quot;79e2c134dce64991(a)192.168.0.100&quot; 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(a)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