27 Oct
2006
27 Oct
'06
3:18 p.m.
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
28 Oct
28 Oct
2:54 a.m.
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(a)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
30 Oct
30 Oct
11:02 a.m.
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(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
2 Nov
2 Nov
10:21 a.m.
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(a)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(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
14 Nov
14 Nov
1:17 p.m.
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(a)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:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Dimo wrote:
UTC)
or
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
I'm not certain if OpenSER creates adjusted timestamp values (to 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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6583
days inactive
6601
days old
4 comments
3 participants
participants (3)
-
Bogdan-Andrei Iancu -
Dimo -
Tavis P