[Serusers] radius acc: where are the start records?
Lucas Aimaretto
lucas at cyneric.com
Thu Dec 30 22:06:12 CET 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 at my.sip.server.com"
> Calling-Station-Id = "sip:1234 at my.sip.server.com"
> Called-Station-Id = "sip:3034094 at my.sip.server.com"
> Sip-Translated-Req-ID = "sip:34094 at fwd.pulver.com:5060"
> Acct-Session-Id = "79e2c134dce64991 at 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 at my.sip.server.com"
> Calling-Station-Id = "sip:1234 at my.sip.server.com"
> Called-Station-Id = "sip:3034094 at my.sip.server.com"
> Sip-Translated-Req-ID = "sip:34094 at fwd.pulver.com:5060"
> Acct-Session-Id = "79e2c134dce64991 at 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 at 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
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.6 - Release Date: 28/12/2004
More information about the sr-users
mailing list