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