view contrib/app_acct_tools/README @ 1515:8430dabbc637

Add 3GPP TS 29.109 V15.0.0 (2017-06) Add AVPs: - GBA-UserSecSettings, OctetString, code 400, section 6.3.1.1 - Transaction-Identifier, OctetString, code 401, section 6.3.1.2 - NAF-Id, OctetString, code 402, section 6.3.1.3 - GAA-Service-Identifier, OctetString, code 403, section 6.3.1.4 - Key-ExpiryTime, Time, code 404, section 6.3.1.5 - ME-Key-Material, OctetString, code 405, section 6.3.1.6 - UICC-Key-Material, OctetString, code 406, section 6.3.1.7 - GBA-U-Awareness-Indicator, Enumerated, code 407, section 6.3.1.8 - BootstrapInfoCreationTime, Time, code 408, section 6.3.1.9 - GUSS-Timestamp, Time, code 409, section 6.3.1.10 - GBA-Type, Enumerated, code 410, section 6.3.1.11 - UE-Id, OctetString, code 411, section 6.3.1.12 - UE-Id-Type, Enumerated, code 412, section 6.3.1.13 - UICC-App-Label, OctetString, code 413, section 6.3.1.14 - UICC-ME, Enumerated, code 414, section 6.3.1.15 - Requested-Key-Lifetime, Time, code 415, section 6.3.1.16 - Private-Identity-Request, Enumerated, code 416, section 6.3.1.17 - GBA-Push-Info, OctetString, code 417, section 6.3.1.18 - NAF-SA-Identifier, OctetString, code 418, section 6.3.1.19 - Security-Feature-Request, OctetString, code 419, section 6.3.1.20 - Security-Feature-Response, OctetString, code 420, section 6.3.1.21 Note: 3GPP TS 29.109 table 6.1 row GBA_U-Awareness-Indicator (407) has an underscore in the name (contrary to RFC 6733 section 4.1). Fix: GBA_U-Awareness-Indicator (407) renamed to GBA-U-Awareness-Indicator (407).
author Luke Mewburn <luke@mewburn.net>
date Thu, 09 Apr 2020 00:34:15 +1000
parents e5010975da35
children
line wrap: on
line source

This folder contains several tools to use and parse the data from the app_acct.fdx extension.

- database.sql :
    An example database format for use with the scripts in this folder.
    
- app_acct.conf :
    The part of app_acct.conf that is relevant to this database schema.

- purge_to_file.php : 
    This PHP script is used to take the records from the incoming table (stored by app_acct.fdx 
  extension) and save these records in a file in SQL format. This is similar to pg_dump 
  command, except that all the records that have been saved in the file are removed from 
  the table. This can be used in cron jobs for example to maintain a reasonable size of 
  the incoming table and move the data to another host for off-line processing. It can 
  also be useful to aggregate the data from different hosts, if you are load-balancing your
  accounting servers for example (granted that all app_acct.fdx use identical table format
  on all the servers). See the top of the file for configuration parameters.
    
- process_records.php :
    This PHP script processes the records pertaining to users sessions, as follow:
  * when a session is complete (STOP record received), it stores a session summary
  into the processed records table (see process_database.sql file for format). 
  * It optionally archives the processed records into a different table, before deleting them.
  * It can also move records of unterminated sessions that are older than a configurable time 
  to an orphan_records table, so that they are not re-processed every time. 
  This orphans table must have the same structure as the "incoming" table.
  
- display_results.php, display_self.php, display_stats.php :
   These scripts give a few examples of how to display the processed data.
  
USAGE:
 *) Initial: create your database using database.sql file
 *) Configure the app_acct.fdx extension using tips from app_acct.conf

  The following processing can be run for example as cron jobs.
 1) On each accounting server for the realm, configure the app_acct.fdx extension to
   dump the records in a local database (all servers must use the same database format).
   The table would typically be "incoming".
 2) Run the purge_to_file.php script on each server regularly, then move the generated
   files onto a single server for processing. This server only needs the other tables.
 3) Add the data from the files into the database in this server by running:
   psql < file.sql
    Each file that has been added should then be archived and removed so that it is not 
   re-added later.
 4) Run the process_records.php script on this processing server. Now, the database
   contains the aggregated data that can be visualized with display_*.php scripts.
   
"Welcome to our mercurial repository"