(RADIATOR) radius accounting timestamp

[Hugh Irvine]

Hello Martin -

It is Radiator itself that adds the "Timestamp" attribute to accounting 
requests as described in section 6.28.14 of the Radiator 3.9 reference 
manual ("doc/ref.html").


  The attribute Timestamp is always available for insertion, and is set 
to the time the packet was received, adjusted by Acct-Delay-Time (if 
present), as an integer number of seconds since Midnight Jan 1 1970 
UTC. The Timestamp atttribute is added by Radiator to all received 
Accounting requests, and is set to the current time according to the 
host on which the Radiator is running.


There is a more recent "Event-Timestamp" radius attribute that has now 
been defined for the NAS to add to requests, but it is not universally 
supported. Note that NAS equipment historically has not had any idea 
about "clock" or "wall" time, which is why the radius protocol itself 
is specified in elapsed time (number of seconds) instead.

regards

Hugh


On 12 Aug 2004, at 22:37, Martin Koenig wrote:

> Hi List,
>
> I have a problem here with a VoIP gateway and it's radius accounting 
> logs on a radiator.
>
> Sample-Log:
>
> Mon Aug  9 17:17:22 2004
> 	User-Name = "tpl-sip-gw1"
> 	Acct-Session-Id = "0"
> 	NAS-IP-Address = 195.2.12.82
> 	NAS-Port-Type = Async
> 	Acct-Status-Type = Start
> 	cisco-h323-gw-id = "h323-gw-id="
> 	cisco-avpair = 
> "h323-incoming-conf-id=1669600617-432910a9 at 192.168.120.254"
> 	cisco-h323-call-type = "h323-call-type=VOIP"
> 	cisco-h323-call-origin = "h323-call-origin=Answer"
> 	Called-Station-Id = "01777354741"
> 	Calling-Station-Id = "451"
> 	cisco-h323-conf-id = 
> "h323-conf-id=1669600617-432910a9 at 192.168.120.254"
> 	Timestamp = 1092064642
>
> Mon Aug  9 17:17:27 2004
> 	User-Name = "tpl-sip-gw1"
> 	Acct-Session-Id = "0"
> 	NAS-IP-Address = 195.2.12.82
> 	NAS-Port-Type = Async
> 	Acct-Status-Type = Start
> 	cisco-h323-gw-id = "h323-gw-id="
> 	cisco-avpair = 
> "h323-incoming-conf-id=1669600617-432910a9 at 192.168.120.254"
> 	cisco-h323-call-type = "h323-call-type=VOIP"
> 	cisco-h323-call-origin = "h323-call-origin=Answer"
> 	Called-Station-Id = "01777354741"
> 	Calling-Station-Id = "451"
> 	cisco-h323-conf-id = 
> "h323-conf-id=1669600617-432910a9 at 192.168.120.254"
> 	Timestamp = 1092064647
> 	
> Mon Aug  9 17:17:31 2004
> 	User-Name = "tpl-sip-gw1"
> 	Acct-Session-Id = "0"
> 	NAS-IP-Address = 195.2.12.82
> 	NAS-Port-Type = Async
> 	Acct-Status-Type = Stop
> 	Acct-Input-Octets = 67840
> 	Acct-Output-Octets = 81280
> 	Acct-Session-Time = 9
> 	Acct-Input-Packets = 424
> 	Acct-Output-Packets = 508
> 	Acct-Terminate-Cause = 0
> 	cisco-h323-gw-id = "h323-gw-id="
> 	cisco-h323-remote-address = "h323-remote-address=192.168.120.254"
> 	cisco-avpair = 
> "h323-incoming-conf-id=1669600617-432910a9 at 192.168.120.254"
> 	cisco-h323-disconnect-cause = "h323-disconnect-cause=300"
> 	cisco-h323-call-type = "h323-call-type=VOIP"
> 	cisco-h323-call-origin = "h323-call-origin=Answer"
> 	Called-Station-Id = "01777354741"
> 	Calling-Station-Id = "451"
> 	cisco-h323-conf-id = 
> "h323-conf-id=1669600617-432910a9 at 192.168.120.254"
> 	Timestamp = 1092064651
> 	
> Mon Aug  9 17:17:36 2004
> 	User-Name = "tpl-sip-gw1"
> 	Acct-Session-Id = "0"
> 	NAS-IP-Address = 195.2.12.82
> 	NAS-Port-Type = Async
> 	Acct-Status-Type = Stop
> 	Acct-Input-Octets = 67840
> 	Acct-Output-Octets = 81280
> 	Acct-Session-Time = 9
> 	Acct-Input-Packets = 424
> 	Acct-Output-Packets = 508
> 	Acct-Terminate-Cause = 0
> 	cisco-h323-gw-id = "h323-gw-id="
> 	cisco-h323-remote-address = "h323-remote-address=192.168.120.254"
> 	cisco-avpair = 
> "h323-incoming-conf-id=1669600617-432910a9 at 192.168.120.254"
> 	cisco-h323-disconnect-cause = "h323-disconnect-cause=300"
> 	cisco-h323-call-type = "h323-call-type=VOIP"
> 	cisco-h323-call-origin = "h323-call-origin=Answer"
> 	Called-Station-Id = "01777354741"
> 	Calling-Station-Id = "451"
> 	cisco-h323-conf-id = 
> "h323-conf-id=1669600617-432910a9 at 192.168.120.254"
> 	Timestamp = 1092064656
>
> As you can see, there is one retransmit per log entry. This is 
> configured to be that way atm. The bigger problem is that the 
> timestamp is also changed on every re-transmit. I don't find any hint 
> on this timestamp field in rfc2866 (radius accounting).
>
> If it is default behaviour, also other hardware, that the timestamp 
> changes on every retransmit, then shouldn't be there a Acct-Delay-Time 
> field also to compensate the later timestamp?
>
> The main questions are: How should this piece of hardware behave? 
> Should the timestamp not be changed on every retransmit? Should 
> retransmit be disabled because accounting logs are sure to be written 
> to the server because there is also an accounting-response issued by 
> the server? What records at all are set by the  radiator? My guess is 
> that only the header "Mon Aug  9 17:17:36 2004" is generated by 
> radiator, the rest comes from the gateway. Is that correct?
>
> Thank you very much,
>
> regards,
> Martin Koenig
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.