Re: fix for Radius failed query logging
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
Our message is that OpenSER has an opportunity to behave in a standardized way. Other vendors have been using 'Acct-Status-Type = Stop' this way for about a decade. Your choice to use 'Failed' was a gratuituous change to existing RADIUS practices that has zero benefit for anyone. Instead of responding to that feedback positively, you're flaming us for not implementing yet another vendor-specific workaround, even AFTER we said that FreeRADIUS will support the functionality you want. More detailed responses are below. Please CC me on any responses. Alan DeKok. ....
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.
I understand that... see the FreeRADIUS source code for any number of vendor-specific workarounds, fixes to bugs in the RFC's, etc. In fact, I'm co-author of what will become a RADIUS RFC that documents what's wrong in the other RFC's, and what people should really do. But that isn't the issue. For us, the issue is that we have to add another work-around for a particular vendor, who has chosen to do something non-standard. We try to encourage standardized ways of solving problems, and to discourage vendor-specific hacks. There are already enough vendor-specific patches in FreeRADIUS.
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.
Again, that response is missing the point entirely.
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.
Yes. We may even add a default "Failed" query to the sql configuration. But we WILL note that it's only used by one vendor, and that it SHOULD NOT be used for anything else, because it has no real meaning.
participants (2)
-
Alan DeKok -
Peter Nixon