fix for Radius failed query logging
Peter Nixon
listuser at peternixon.net
Fri Nov 17 21:46:53 CET 2006
On Fri 17 Nov 2006 19:20, Adrian Georgescu wrote:
> Hi Peter,
>
> Failed it is mentioned in RFC2866.
Yes the mention is "15 Reserved for Failed"
Reserved means, basically means currently undefined, but may be defined in a
future RFC... This doesn't mean, go use it how you wish and hope the next RFC
matches what you did....
> 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
Yep. Understood.
> Scenario 2
>
> - Call fails without starting - generates a failed packet, which
> allows you to specify a custom database query different than the
> start query
OK. As I mentioned in my email, this can and should be done with a Stop packet
that contains "Failed" or (some error code that indicates failed) as an
additional attribute.
> 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.
Sure. I didnt say that it didnt make sense, but you are defining undefined
behaviour from the rfc.. I also didnt say that its a bad idea, but that is a
discussion for an RFC working group...
> 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.
Yes. I agree, but in this case the RFC does specify a way for you to do what
you need to do cleanly.
> 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.
I am sorry you feel this way. Standardisation is what makes things
interoperable. I have been involved with VoIP for a long time also (just not
openser), so I am not new to these issues.
> 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.
Well, it MAY break things in future if and when a new RFC defines
how "Acct-Status-Type = Failed" should be used. I agree that given the type
of change we are talking about this is a remote possiblity, however Alan has
the final say in things of this nature. In any case, as Alan also mentioned
in his reply, there are plans to make the sql modules extensible simply by
adding new queries like this to the config file.
In that case no code patch will be required to do what you want to do.. Simply
adding one extra line the the config file will do the trick. This will allow
custom sql queries on basically any attribute type giving people more than
enough rope to hang themselves in weird and wonderfull new ways :-D
Cheers
--
Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
More information about the Freeradius-Devel
mailing list