[Devel] Re: fix for Radius failed query logging
Adrian Georgescu
ag at ag-projects.com
Fri Nov 17 18:20:42 CET 2006
Hi Peter,
Failed it is mentioned in RFC2866. To explain to you a bit how SER/
OpenSER typically works and it is in service for may years.
Scenario 1
- Call starts - generates a start packet
- Cals stops - generates a stop packet
Scenario 2
- Call fails without starting - generates a failed packet, which
allows you to specify a custom database query different than the
start query
This behaviour is typically used by SER/OpenSER community for years.
It has nothing to do with Cisco and vendors specific attributes. It
is a situation where Accounting type Failed simply make sense and
there are countless numbers of VoIP deployments out there making good
use of it.
Now, as many things in SIP, RFCs are not always the place to look for
real life problems and their solutions. Many RFCs have been written
before decent field experience existed in the field and did not cover
the out-of-the lab requirements. By obeying blindly to what some RFC
mentions or lacks to mention it would mean that the progress of
mankind will be at the hand of some people with time and interest to
write RFCs.
Once a technology gets adopted nobody has time anymore for
standardisation as it did before adoption. Radius was once an AAA
tool for dial-up networks. SIP and VoIP came later and this mailing
lists gives you feedback about it.
Changing 10 lines of code will make many people praise Freeradius for
its good work for the fast growing VoIP/SIP community and will not
break anything else. Otherwise it should be no wonder why some switch
to radiator who seem to care more about what people really need in
place of what is missing from the RFCs.
Adrian
On Nov 17, 2006, at 4:51 PM, Peter Nixon wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openser.org/pipermail/devel/attachments/20061117/6bc90e47/attachment.html
More information about the Devel
mailing list