[Devel] Re: fix for Radius failed query logging

Dan Pascu dan at ag-projects.com
Fri Nov 17 23:32:02 CET 2006


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.

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.

> 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..)
>

-- 
Dan



More information about the Devel mailing list