RadiusNT 2.2 does NOT handle out of order accounting packets
in Manual Calls Update. Therefore, if it receives a stop record
then a start record (both for the same session), it will assume
the user is on-line. I'll add the date check the SQL trigger
does to RadiusNT 2.5's manual calls update to help prevent this.
Make sure the accounting timesouts on the MAX and cisco are
atleast 5-7 seconds. This can cause major issues with
concurrency if not.
There are two possible issues when concurrency is not working.
1. The database was not being updated because if an issue between
the NAS/RadiusNT or RadiusNT/Database. For example, the NAS
was rebooted and the session stops were lost or the NAS did
not send the stop record for the session (some USRs have been
reported to do this when the user just hangs up).
2. The NAS sends accounting data out of order (like a Livinston
will do is accounting gets backed up) and you are using
manual calls update.
-- Dale E. Reed Jr. (daler@iea-software.com)_________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com