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 _______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
