fix for Radius failed query logging

Peter Nixon listuser at
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



Peter Nixon
PGP Key:

More information about the Freeradius-Devel mailing list