In this case the radius proxy wont work, because you never can anticipate who hangs up the call, thus radius wont know who hung up the call...Besides all other voice applications/hardware (SIP and H323) that use radius do not behave like that, the Called-Station-ID ALWAYS remains the same, as with the Calling-Station-ID.
Can this be added as an acc parameter that can be turn off/on? is it something that can be easily done?
-----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Thursday, November 17, 2005 4:21 AM To: Lenir Cc: 'Jan Janak'; serdev@iptel.org; serusers@iptel.org; devel@openser.org; users@openser.org Subject: Re: [Users] RE: [Serusers] Re: [Serdev] Inaccurate Radius Accounting
Hi!
I think we should leave (open)ser radius as it is. If you need adopt the accounting packets to fit your billing application, I would add a radius proxy, which translates the acounting requests according to your needs and forward it to the billing application.
regards klaus
Lenir wrote:
We could determine who sent the BYE from the value of ftag parameter in Route header field and swap the values, the question is whether this makes sense. The billing system could take all info from start requests
I think it would make sense just from a uniformity stand point.
and use the stop request to calculate the session duration only.
I don't know if that's the case, but this would probably vary from billing system to billing system. I think if we keep it uniform, then it would
never
be a problem. Specially, for billing systems that only support stop-only records and billing systems that authenticate by using PIN prefixes, specially when one of the parties is not a user but a PSTN number. On my billing platform it wont work, it complains about the discrepancy, and the fact that when the callee hangs up it doesn't recognize that the CDR is
for
a PSTN user.
Lenir
-----Original Message----- From: 'Jan Janak' [mailto:jan@iptel.org] Sent: Wednesday, November 16, 2005 3:45 PM To: Lenir Cc: serdev@iptel.org; serusers@iptel.org; users@openser.org; devel@openser.org Subject: Re: [Users] RE: [Serusers] Re: [Serdev] Inaccurate Radius Accounting
Yes, this can happen if the callee sends BYE. In this case the URIs in
From and To header fields are swapped.
The only SIP RADIUS related document (which has expired a long time ago) says that Calling-Station-Id is the URI from From header field of any SIP request. Thus -- according this I-D it is correct. But use of RADIUS with SIP is underspecified so there is no real standard for this.
I don't think it matters that much, because other attributes, namely Acct-Session-Id are used to match start and stop radius requests.
We could determine who sent the BYE from the value of ftag parameter in Route header field and swap the values, the question is whether this makes sense. The billing system could take all info from start requests and use the stop request to calculate the session duration only.
Jan.
On 16-11-2005 15:04, Lenir wrote:
Ok, that put the right things in place. However, here's a twist: Either way, wit switching Sip-Translated-Request-URI and Called-Station-ID around, or not, the CDRs are sent differently depending on who "hands up" the call. For example, notice the User-Name, Calling-Station-ID and Called-Station-ID:
User 1000 calls 15615551212, and user 1000 hangs up:
rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39228, id=206, length=306 Acct-Status-Type = Start Service-Type = Sip-Session Acct-Terminate-Cause = 200 Error-Cause = Invite User-Name = "1000@xx.xx.xx.xx" Calling-Station-Id = "sip:1000@xx.xx.xx.xx" Sip-Translated-Request-URI = "sip:15615551212@xx.xx.xx.xx;user=phone" Called-Station-Id = "sip:949449852150#15615551212@gateway;user=phone" Acct-Session-Id =
"000d2890-d47f01f5-6410e8bd-4baf0435@66.232.8.116"
Sip-To-Tag = "33C5A3C-76A" Sip-From-Tag = "000d2890d47f24f85e6c0b91-0092ab53" Sip-CSeq = "102" NAS-IP-Address = xx.xx.xx.xx NAS-Port = 5060 Acct-Delay-Time = 0rlm_sql (sql): Reserving sql socket id: 15 rlm_sql (sql): Released sql socket id: 15 Sending Accounting-Response of id 206 to xx.xx.xx.xx:39228 rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39228, id=207, length=300 Acct-Status-Type = Stop Service-Type = Sip-Session Acct-Terminate-Cause = 200 Error-Cause = 8 User-Name = "1000@xx.xx.xx.xx" Calling-Station-Id = "sip:1000@xx.xx.xx.xx" Sip-Translated-Request-URI = "sip:15615551212@xx.xx.xx.xx;user=phone" Called-Station-Id = "sip:949449852150#15615551212@gateway:5060" Acct-Session-Id =
"000d2890-d47f01f5-6410e8bd-4baf0435@66.232.8.116"
Sip-To-Tag = "33C5A3C-76A" Sip-From-Tag = "000d2890d47f24f85e6c0b91-0092ab53" Sip-CSeq = "103" NAS-IP-Address = xx.xx.xx.xx NAS-Port = 5060 Acct-Delay-Time = 0User 1000 calls 15615551212, and user 15615551212 hangs up:
rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39227, id=200, length=306 Acct-Status-Type = Start Service-Type = Sip-Session Acct-Terminate-Cause = 200 Error-Cause = Invite User-Name = "1000@xx.xx.xx.xx" Calling-Station-Id = "sip:1000@xx.xx.xx.xx" Sip-Translated-Request-URI = "sip:15615551212@xx.xx.xx.xx;user=phone" Called-Station-Id = "sip:949449852150#15615551212@gateway;user=phone" Acct-Session-Id =
"000d2890-d47f01f4-372dff4b-793d4acc@66.232.8.116"
Sip-To-Tag = "33B37E4-77B" Sip-From-Tag = "000d2890d47f24f639ccef77-4ef08b02" Sip-CSeq = "102" NAS-IP-Address = xx.xx.xx.xx NAS-Port = 5060 Acct-Delay-Time = 0rlm_sql (sql): Reserving sql socket id: 1 rlm_sql (sql): Released sql socket id: 1 Sending Accounting-Response of id 200 to xx.xx.xx.xx:39227 rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39227, id=201, length=286 Acct-Status-Type = Stop Service-Type = Sip-Session Acct-Terminate-Cause = 200 Error-Cause = 8 User-Name = "15615551212@xx.xx.xx.xx" Calling-Station-Id = "sip:15615551212@xx.xx.xx.xx;user=phone" Sip-Translated-Request-URI = "sip:1000@xx.xx.xx.xx" Called-Station-Id = "sip:1000@66.232.8.116:5061" Acct-Session-Id =
"000d2890-d47f01f4-372dff4b-793d4acc@66.232.8.116"
Sip-To-Tag = "000d2890d47f24f639ccef77-4ef08b02" Sip-From-Tag = "33B37E4-77B" Sip-CSeq = "101" NAS-IP-Address = xx.xx.xx.xx NAS-Port = 5060 Acct-Delay-Time = 0Shouldn't it always be that the User-Name attribute is the user who initiated the call?
Lenir
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On
Behalf
Of 'Jan Janak' Sent: Wednesday, November 16, 2005 1:53 PM To: lsantiago@globalgatewaycom.com Cc: serdev@iptel.org; serusers@iptel.org; users@openser.org; devel@openser.org Subject: Re: [Users] RE: [Serusers] Re: [Serdev] Inaccurate Radius Accounting
Either reconfigure the billing application to use Sip-Translated-Request-URI (recommended) or change the ID of the attribute in the radiusclient dictionary as suggested by Bogdan.
In this particular example you should set Called-Station-Id to 107.
Jan.
On 16-11-2005 13:09, 'Lenir' wrote:
Ok, so how do I tell acc.so to send Sip-Translated-Request-URI as the Called-Station-ID instead?
Lenir Santiago, Partner Global Gateway Communications, Inc. 2500 Quantum Lakes Drive, Ste. 203 Boynton Beach, FL 33426 Office: 561-853-2213 Cell: 561-722-0966 Fax: 877-875-0060 http://www.globalgatewaycom.com
-----Original Message----- From: 'Jan Janak' [mailto:jan@iptel.org] Sent: Wednesday, November 16, 2005 11:29 AM To: Bogdan-Andrei Iancu Cc: Lenir; 'Lenir Santiago'; serdev@iptel.org; serusers@iptel.org; devel@openser.org; users@openser.org Subject: Re: [Users] RE: [Serusers] Re: [Serdev] Inaccurate Radius Accounting
Why would you do something like this ? All the info that is needed is in Sip-Translated-Ruquest-ID below. You can see it in the RADIUS dump:
Sip-Translated-Request-URI = "sip:949449852150#15615551212@gateway:5060"
Jan.
On 16-11-2005 16:50, Bogdan-Andrei Iancu wrote:
Hi Lenir,
you can keep the modified To value into an AVP and use the extra accounting feature to log it. See http://www.openser.org/docs/modules/1.1.x/acc.html#AEN115 and http://www.openser.org/docs/modules/1.1.x/acc.html#AEN350
the problem is how to set it as Called-Station-ID attribute in order
to
avoid overlapping. You can do a trick by playing with the radius dictionary (on proxy side) : changed the Called-Station-ID to a different ID attribute set extra accounting with the original attribute ID of
Called-Station-ID
in this way the acc will set de default TO as something else and you
AVP
as Called-Station-ID ;)
regards, bogdan
Lenir wrote:
Well, if userA dials to:30, 30 gets translated to:15615551212 and SER
dials
15615551212, how can I make the acc.so module send the modified to:15615551212 as the Called-Station-ID attribute?
This is important for billing, specially if someone forwards to a
long
distance or international long distance number.
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@iptel.org]
On
Behalf Of Jan Janak Sent: Wednesday, November 16, 2005 3:15 AM To: Lenir Santiago Cc: serdev@iptel.org; serusers@iptel.org; users@openser.org; devel@openser.org Subject: [Serusers] Re: [Serdev] Inaccurate Radius Accounting
Hello,
Called-Station-Id attribute always contains the To URI (not Request-URI). You can find the outbound Request-URI in Sip-Translated-Request-URI attribute.
Even if you rewrite To header field, it will never be accounted in Called-Station-Id.
Jan.
On 15-11-2005 21:59, Lenir Santiago wrote:
Hey guys,
I'm using Radius to do pretty much everything regarding my users,
i.e.
registrations, authorization, features and preferences. I
implemented
my
own
way of doing speeddial by using AVPs provided by radius and AVPOPs
module,
Here is the snippet:
AVP-SIP = speedial:30:15615551212
avp_subst("s:caller_speedial/i:99","/(.*):(.*)/\2/");
#15615551212
avp_printf("i:98","$rU:*"); #30 avp_printf("i:97","sip:$avp($temp2)@$td"); #sip:15615551212@xx.xx.xx.xx
avp_printf("i:96","<sip:$avp($temp2)@$td>\r\n"); #xlog("L_N"," SPEEDIALING: $fU is speed-dialing$hdr(To)->$avp($temp2)\n");
if (avp_check("s:caller_speedial", "fm/$temp1/g")) { #avp_pushto("$To","i:96"); #avp_pushto("$ruri","i:97"); #avp_pushto("$duri","i:97"); #subst('/^To: (.*)@(.*)/To: "$avp($temp2)"<$avp($temp2)@\2/');
#append_hf("To: \"5615551212\"15615551212@xx.xx.xx.xx;user=phone");
#subst_uri('/^sip:(.*)@(.*)$/sip:$avp($temp2)@\2/i');
#subst_user('/(.*)/$avp($temp2)/'); #remove_hf("To"); rewriteuser("15615551212"); xlog("L_N"," SPEEDIALING: $fU is dialing$hdr(To)
$avp($temp2)\n");
avp_delete("$temp1/g"); avp_delete("$temp2/g"); };In this scenario, im forcing it instead of getting the value from
AVPs
just
for ease of showing my point. The problem that I'm having is that no
matter
what I do to change the To header or change the R-URI, radius ALWAYS
sends
the accounting records with the original R-URI, in my case
30@xx.xx.xx.xx,
how can I get acc.so to send the final resulting URI (15615551212@xx.xx.xx.xx) in the Called-Station-Id AVP?
rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39216,
id=97,
length=298
Acct-Status-Type = Start Service-Type = Sip-Session Acct-Terminate-Cause = 200 Error-Cause = Invite User-Name = "1000@xx.xx.xx.xx" Calling-Station-Id = "sip:1000@xx.xx.xx.xx" Called-Station-Id = "sip:30@xx.xx.xx.xx;user=phone" Sip-Translated-Request-URI ="sip:949449852150#15615551212@gateway;user=phone"
Acct-Session-Id ="000d2890-d47f01e8-1dcc30bc-7a49c7a4@yy.yy.yy.yy"
Sip-To-Tag = "230383F4-2AF" Sip-From-Tag = "000d2890d47f20f54576a906-290bdc33" Sip-CSeq = "102" NAS-IP-Address = xx.xx.xx.xx NAS-Port = 5060 Acct-Delay-Time = 0rlm_sql (sql): Reserving sql socket id: 12
rlm_sql (sql): Released sql socket id: 12
Sending Accounting-Response of id 97 to xx.xx.xx.xx:39216
rad_recv: Accounting-Request packet from host xx.xx.xx.xx:39216,
id=98,
length=292
Acct-Status-Type = Stop Service-Type = Sip-Session Acct-Terminate-Cause = 200 Error-Cause = 8 User-Name = "1000@xx.xx.xx.xx" Calling-Station-Id = "sip:1000@xx.xx.xx.xx" Called-Station-Id = "sip:30@xx.xx.xx.xx;user=phone" Sip-Translated-Request-URI ="sip:949449852150#15615551212@gateway:5060"
Acct-Session-Id ="000d2890-d47f01e8-1dcc30bc-7a49c7a4@yy.yy.yy.yy"
Sip-To-Tag = "230383F4-2AF" Sip-From-Tag = "000d2890d47f20f54576a906-290bdc33" Sip-CSeq = "103" NAS-IP-Address = xx.xx.xx.xx NAS-Port = 5060 Acct-Delay-Time = 0Thanks in advance!
Lenir _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users