20 Nov
2004
20 Nov
'04
7:01 p.m.
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(a)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(a)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(a)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(a)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