[Users] DST and accounting

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Nov 14 12:17:05 CET 2006


Hi Dimo,

wouldn't be more simpler to make this conversion (UTC->local time) on 
the RADIUS server? or in the billing engine?

the idea is to avoid complicating the SIP proxy with thinks that are not 
really related to the SIP part.

Regards,
Bogdan

Dimo wrote:

> Hi Bogdan,
> That is great. As far as i have seen UNIX timestamp is UTC based.
> But wouldn't it be even better to have some kind of pseudo variable
> which gives the system offset according to the utc? In this way I will
> be able to send both the UNIX timestamp and the offset to my radius
> server and it will be able to both account the calls in local time and
> take in consideration the change in offset once the time changes from
> DST.
> Having the DST logic in the radius server will not work for me,
> because we have the same radius server accounting openser servers from
> different time zones where potentially the DST changes at different
> times of the year.
>
> Best,
> Dimo
>
>
> On 10/30/06, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
>
>> Hi Dimo, Hi Tavis,
>>
>> up to devel version, openser did not sent any timestamp via RADIUS- what
>> you were getting was the timestamp set by the RADIUS server when
>> receiving the radius package; so it is about configuring RADIUS 
>> server / OS.
>>
>> in devel version, a UNIX timestamp of the SIP package is sent via all
>> backends and you can use it as it is more reliable. Also UNIX time is
>> not affected by DST.
>>
>> regards,
>> bogdan
>>
>> Tavis P wrote:
>>
>> >Dimo wrote:
>> >
>> >
>> >>Hello,
>> >>I have sent this a while ago but it did not come, so if you are
>> >>getting the mail for the second time sorry.
>> >>
>> >>You may be aware of the accounting problem with Daylight Savings Time.
>> >>Currently in Radius accounting we have a timestamp of the event
>> >>acoording to system clock (i think). So if a call starts soon before a
>> >>daylight saving change and ends soon after it, it may have too big or
>> >>negative duration, depending on whethere the clock moved forward or
>> >>backward.
>> >>
>> >>Is there a way to make accounting take notice of that (maybe
>> >>accounting in gmt+offset or something?)
>> >>
>> >>Any ideas appreciated, as you know DST is comming soon for europe at
>> >>least.
>> >>
>> >>Dimitar
>> >>
>> >>_______________________________________________
>> >>Users mailing list
>> >>Users at openser.org
>> >>http://openser.org/cgi-bin/mailman/listinfo/users
>> >>
>> >>
>> >>
>> >>
>> >I'm not certain if OpenSER creates adjusted timestamp values (to 
>> UTC) or
>> >uses the localtime, however i would recommend that you set the local
>> >timezone of your OpenSER server to "UTC", that will cleanly work around
>> >the problem (err, if it is even a problem ;)
>> >
>> >tavis
>> >
>> >
>> >
>> >_______________________________________________
>> >Users mailing list
>> >Users at openser.org
>> >http://openser.org/cgi-bin/mailman/listinfo/users
>> >
>> >
>> >
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>





More information about the sr-users mailing list