[Serdev] Radius stop record delay

[Maxim Sobolev]

Dan Pascu wrote:

> On Thursday 19 August 2004 18:21, Jiri Kuthan wrote:
> 
>>>Anyway, regarding the accounting stuff I don't think we disagree. I'm not
>>>locked on the idea that accounting should be sent when BYE arrives, but
>>>only that I would like to know when BYE has arrived. Sending an absolute
>>>timestamp is problematic (depends on ser and radius being in the same
>>>timezone and being time synchronized). But we can send the time
>>>difference between the BYE request and the moment the stop accounting
>>>message is sent and use that to compute the real time of the BYE request
>>>arrival.
>>
>>That's a possible design option. We can send also both timestamp for
>>receipt of request and reply. I don't have any strong preferences on these.
>>Maybe I like timestamps generated by SER on receipt of SIP message better
>>than timestamps generated by RADIUS server on receipt of RADIUS message --
>>it is yet another communication link which can affect accuracy.
> 
> 
> The issue I see with absolute timestamp is that they require extra care to be 
> kept in sync. What you propose is fine as long as ser is the only entity 
> talking with the radius server, but if the radius server collects data from 
> more entities (some of which are not ser), syncing the timestamps each 
> generate may become an issue. However if we let the entity that collects the 
> accounting (radius) to generate the timestamps, there is no syncing timestamp 
> issue at all.

Actually, in real-world VoIP billing systems usually the only method is 
to stick to gateway-generated timestamps. Of course this requires 
providing Radius with information about timezone each gateway is in and 
enabling mandatory ntpd synchronisation of each gateway that sends 
accounting information. The reason for this is that network delays for 
Radius packets propagation can not be accurately accounted for, thereby 
in the case of timestamps generated by Radius it will provide persistent 
random skew, which can be significant you are trafficing hundreds of 
thousand or millions minutes per months.

-Maxim