osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: Re: Re: fix for Radius failed query logging -
msg#00069

List: freeradius.devel

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

peter,

you suggested to use accounting stop request for failed sip requests.
that is not a good idea, because what didn't start cannot stop either.

in other words, my stop records contain only a small number of
attributes enough to match the start record that holds many more
attributes. in case of failed request, i don't have a corresponding
start record, but i do need all the same attributes in failed request
that i have in start request.

-- juha


Thread at a glance:

Previous Message by Date:

Automatic report from sources (radiusd) between 16.11.2006 - 17.11.2006 GMT

CVS log entries from 16.11.2006 (Thu) 09:00:01 - 17.11.2006 (Fri) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/modcall.c; Revisions: 1.58 File: radiusd/share/dictionary.cisco.vpn3000; Revisions: 1.13, 1.7.4.3 ===================================================== Combined list of identical log entries ===================================================== Description: Corrected typo Modified files: File: radiusd/share/dictionary.cisco.vpn3000; Revision: 1.13; Date: 2006/11/17 00:01:43; Author: aland; Lines: (+2 -2) File: radiusd/share/dictionary.cisco.vpn3000; Revision: 1.7.4.3; Date: 2006/11/17 00:01:18; Author: aland; Lines: (+2 -2) ===================================================== Log entries ===================================================== Description: Move action2str to where it needs to be. Add comment at the start of modcall(), saying what it does. If we have a module action of RETURN or REJECT at "unroll" in modcall(), don't fall through to the next check. Instead, jump forward to do_return, which stops processing this group Modified files: File: radiusd/src/main/modcall.c; Revision: 1.58; Date: 2006/11/16 23:59:32; Author: aland; Lines: (+19 -15) ===================================================== Summary of modified files ===================================================== File: radiusd/share/dictionary.cisco.vpn3000 Revisions: 1.13, 1.7.4.3 Authors: aland (+2 -2), aland (+2 -2) ------------------------------- File: radiusd/src/main/modcall.c Revisions: 1.58 Authors: aland (+19 -15) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

Next Message by Date:

Re: fix for Radius failed query logging

On Fri 17 Nov 2006 15:00, Juha Heinanen wrote: > peter, > > you suggested to use accounting stop request for failed sip requests. > that is not a good idea, because what didn't start cannot stop either. > > in other words, my stop records contain only a small number of > attributes enough to match the start record that holds many more > attributes. in case of failed request, i don't have a corresponding > start record, but i do need all the same attributes in failed request > that i have in start request. Hi Juha The amount of attributes that your (I guess you mean openser) stop records _currently_ contain have nothing to do with the issue at all. (Most NAS infact put much MORE info into the Stop records than the Start ones as that is typically the record you use for billing) My suggestion was to simply have the Failed records be of Acct-Status-Type "Stop". The RFC does not state that there has to be a Start record in order for there to be a Stop record and this is how most vendors do it. (If you wish to add an extra attribute that includes the word "Failed" then by all means do so..) Here is an example Start and Stop record from a Cisco 53XX series running H.323 (Sorry don't have any production SIP installations at present) Please take note of "Cisco-AVPair" attributes which may contain arbitary data (according the Cisco's dictionary) and the length of the records Sat Oct 16 06:38:54 2006 Acct-Session-Id = "00BA5EC6" h323-setup-time = "16:36:05.023 GMT+2 Sat Oct 16 2006" h323-gw-id = "gw1-5300." h323-conf-id = "A6C16E86 205211D9 87870003 BA6B5AFA" h323-call-origin = "originate" h323-call-type = "Telephony" Cisco-AVPair = "h323-incoming-conf-id=A6C16E86 205211D9 87870003 BA6B5AFA" Cisco-AVPair = "subscriber=Unknown" Cisco-AVPair = "out-intrfc-desc=" Cisco-AVPair = "gw-rxd-cdn=ton:0,npi:0,#:696990535792987" User-Name = "195.2.2.1" Acct-Status-Type = Start NAS-Port-Type = Async Cisco-NAS-Port = "ISDN 1:D:1" NAS-Port = 0 Called-Station-Id = "696990535792987" Service-Type = Login-User NAS-IP-Address = 212.1.1.1 Acct-Delay-Time = 5 Client-IP-Address = 212.1.1.1 Acct-Unique-Session-Id = "0657b177760ba193" Sat Oct 16 06:38:55 2006 Acct-Session-Id = "00BA5EC6" h323-setup-time = "16:36:05.023 GMT+2 Sat Oct 16 2006" h323-gw-id = "gw1-5300." h323-conf-id = "A6C16E86 205211D9 87870003 BA6B5AFA" h323-call-origin = "originate" h323-call-type = "Telephony" Cisco-AVPair = "h323-incoming-conf-id=A6C16E86 205211D9 87870003 BA6B5AFA" Cisco-AVPair = "subscriber=Unknown" Cisco-AVPair = "out-intrfc-desc=" Cisco-AVPair = "gw-rxd-cdn=ton:0,npi:0,#:696990535792213" Acct-Input-Octets = 440 Acct-Output-Octets = 0 Acct-Input-Packets = 22 Acct-Output-Packets = 0 Acct-Session-Time = 0 h323-connect-time = "16:36:05.675 GMT+2 Sat Oct 16 2006" h323-disconnect-time = "16:36:05.675 GMT+2 Sat Oct 16 2006" h323-disconnect-cause = "1C" Cisco-AVPair = "h323-ivr-out=Tariff:Unknown" Cisco-AVPair = "release-source=3" h323-voice-quality = "0" Cisco-AVPair = "gw-final-xlated-cdn=ton:0,npi:0,#:05357111111" Cisco-AVPair = "charged-units=0" Cisco-AVPair = "disconnect-text=invalid number (28)" Cisco-AVPair = "peer-address=696990535792987" Cisco-AVPair = "info-type=speech" Cisco-AVPair = "peer-id=69691" Cisco-AVPair = "peer-if-index=280" Cisco-AVPair = "logical-if-index=105" Cisco-AVPair = "acom-level=20" Cisco-AVPair = "coder-type-rate=g729r8" Cisco-AVPair = "noise-level=0" Cisco-AVPair = "voice-tx-duration=0 ms" Cisco-AVPair = "tx-duration=0 ms" User-Name = "195.2.2.2" Acct-Status-Type = Stop NAS-Port-Type = Async Cisco-NAS-Port = "ISDN 1:D:1" NAS-Port = 0 Called-Station-Id = "696990535792987" Service-Type = Login-User NAS-IP-Address = 212.1.1.1 Acct-Delay-Time = 5 Client-IP-Address = 212.1.1.1 Acct-Unique-Session-Id = "0657b177760ba193" Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

Previous Message by Thread:

Re: [Devel] Re: fix for Radius failed query logging

Peter Nixon <listuser@xxxxxxxxxxxxxx> wrote: > OK. This _looks_ like a RADIUS accounting packet, and the patch doesn't look > horrible, but with the exception of the following in RFC 2866 I can't find > anything mentioning "Acct-Status-Type = Failed" as being valid: "Failed" looks to be implementation-specific. The patch isn't too bad, but hacking FreeRADIUS to add vendor-specific workarounds is something we try to avoid. On the good side, we plan on making some changes to the SQL module that make the patch unnecessary, but will still have the functionality you want. > Based on which RFC does SER generate RADIUS accounting packets > with "Acct-Status-Type = Failed"? My suggestion for OpenSER is to avoid "Failed", if at all possible. The standards don't say what it means, so it doesn't mean much... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog

Next Message by Thread:

Re: fix for Radius failed query logging

On Fri 17 Nov 2006 15:00, Juha Heinanen wrote: > peter, > > you suggested to use accounting stop request for failed sip requests. > that is not a good idea, because what didn't start cannot stop either. > > in other words, my stop records contain only a small number of > attributes enough to match the start record that holds many more > attributes. in case of failed request, i don't have a corresponding > start record, but i do need all the same attributes in failed request > that i have in start request. Hi Juha The amount of attributes that your (I guess you mean openser) stop records _currently_ contain have nothing to do with the issue at all. (Most NAS infact put much MORE info into the Stop records than the Start ones as that is typically the record you use for billing) My suggestion was to simply have the Failed records be of Acct-Status-Type "Stop". The RFC does not state that there has to be a Start record in order for there to be a Stop record and this is how most vendors do it. (If you wish to add an extra attribute that includes the word "Failed" then by all means do so..) Here is an example Start and Stop record from a Cisco 53XX series running H.323 (Sorry don't have any production SIP installations at present) Please take note of "Cisco-AVPair" attributes which may contain arbitary data (according the Cisco's dictionary) and the length of the records Sat Oct 16 06:38:54 2006 Acct-Session-Id = "00BA5EC6" h323-setup-time = "16:36:05.023 GMT+2 Sat Oct 16 2006" h323-gw-id = "gw1-5300." h323-conf-id = "A6C16E86 205211D9 87870003 BA6B5AFA" h323-call-origin = "originate" h323-call-type = "Telephony" Cisco-AVPair = "h323-incoming-conf-id=A6C16E86 205211D9 87870003 BA6B5AFA" Cisco-AVPair = "subscriber=Unknown" Cisco-AVPair = "out-intrfc-desc=" Cisco-AVPair = "gw-rxd-cdn=ton:0,npi:0,#:696990535792987" User-Name = "195.2.2.1" Acct-Status-Type = Start NAS-Port-Type = Async Cisco-NAS-Port = "ISDN 1:D:1" NAS-Port = 0 Called-Station-Id = "696990535792987" Service-Type = Login-User NAS-IP-Address = 212.1.1.1 Acct-Delay-Time = 5 Client-IP-Address = 212.1.1.1 Acct-Unique-Session-Id = "0657b177760ba193" Sat Oct 16 06:38:55 2006 Acct-Session-Id = "00BA5EC6" h323-setup-time = "16:36:05.023 GMT+2 Sat Oct 16 2006" h323-gw-id = "gw1-5300." h323-conf-id = "A6C16E86 205211D9 87870003 BA6B5AFA" h323-call-origin = "originate" h323-call-type = "Telephony" Cisco-AVPair = "h323-incoming-conf-id=A6C16E86 205211D9 87870003 BA6B5AFA" Cisco-AVPair = "subscriber=Unknown" Cisco-AVPair = "out-intrfc-desc=" Cisco-AVPair = "gw-rxd-cdn=ton:0,npi:0,#:696990535792213" Acct-Input-Octets = 440 Acct-Output-Octets = 0 Acct-Input-Packets = 22 Acct-Output-Packets = 0 Acct-Session-Time = 0 h323-connect-time = "16:36:05.675 GMT+2 Sat Oct 16 2006" h323-disconnect-time = "16:36:05.675 GMT+2 Sat Oct 16 2006" h323-disconnect-cause = "1C" Cisco-AVPair = "h323-ivr-out=Tariff:Unknown" Cisco-AVPair = "release-source=3" h323-voice-quality = "0" Cisco-AVPair = "gw-final-xlated-cdn=ton:0,npi:0,#:05357111111" Cisco-AVPair = "charged-units=0" Cisco-AVPair = "disconnect-text=invalid number (28)" Cisco-AVPair = "peer-address=696990535792987" Cisco-AVPair = "info-type=speech" Cisco-AVPair = "peer-id=69691" Cisco-AVPair = "peer-if-index=280" Cisco-AVPair = "logical-if-index=105" Cisco-AVPair = "acom-level=20" Cisco-AVPair = "coder-type-rate=g729r8" Cisco-AVPair = "noise-level=0" Cisco-AVPair = "voice-tx-duration=0 ms" Cisco-AVPair = "tx-duration=0 ms" User-Name = "195.2.2.2" Acct-Status-Type = Stop NAS-Port-Type = Async Cisco-NAS-Port = "ISDN 1:D:1" NAS-Port = 0 Called-Station-Id = "696990535792987" Service-Type = Login-User NAS-IP-Address = 212.1.1.1 Acct-Delay-Time = 5 Client-IP-Address = 212.1.1.1 Acct-Unique-Session-Id = "0657b177760ba193" Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!