fix for Radius failed query logging

[Peter Nixon]

On Sat 18 Nov 2006 00:32, Dan Pascu wrote:
> On Friday 17 November 2006 17:51, 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
>
> I don't think this is a good idea, as it will introduce confusion about
> the meaning and the behavior of the Stop record. A typical scenario is to
> generate an SQL insert on a radius Start record and an SQL update on the
> radius Stop record (for a successful call). For a failed call however if
> it generates a Stop record, then in will need to do an SQL insert instead
> of the typical SQL update, since for failed calls there is no start. This
> is not a good idea IMO.

FreeRADIUS handles this fine as reverts to INSERT if it desn't find a record 
to UPDATE on Stop.

> From this point of view, a failed call should rather generate a Start
> record (because it needs the SQL insert), but seen in context, this
> doesn't make much sense, as there is no call starting (it is a failed
> call after all) and there will be no Stop record following later.

Some vendors generate both Start and Stop with 0 session-time on a failed 
call. This is actually something that you could easily make configurable in 
any case. To give all 3 options (Old "Failed" method, "Stop-Only" 
and "Start-Stop") would at most be 15 or 20 lines of extra code...

I understand people wanting to keep backward "compatibility" for existing 
installations, but compatibility with RFCs and other vendor's RADIUS and 
billing systems should also be a priority in my opinion and making it a 
configurable option solves both problems.

Cheers
-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc