General information

Audit log is a subsystem that records events on the Softswitch, with ability to filter by name/type/date.

It provides switch operator a tool to troubleshoot and investigate what changes were done, by whom and when to numerous components of the system, including Accounts, Customers, Tariffs etc.

Location on the Softswitch

The Audit Logs Viewer feature is available only for web users with Administrator privileges under Root Customer and can be accessed from System Management --> Tools --> Audit Logs Viewer

Sippy also has

Elements legend

Filter section:

  • Resource - WHERE the event happened
  • Action - WHAT exactly happened
  • Action by - WHO accessed the page/did the changes
  • Start Date/Time, End Date/Time  - WHEN the event happened


A button with diskette image triggers Download for the filtered data.

A button with looking glass opens detailed report for specified entry, e.g.:

Data section:

  • Resource - WHERE the event happened. Contains the reference to affected subsystem, e.g. accounts or tariffs with corresponding ID of element that was touched.
  • Action - WHAT exactly happened. Hover mouse button to the action to get pop-up hint. List of actions with description and syntax could be found in table below:
Add a record to a tableAtable_name:key1=val1[,key2=val2...]:field1=newval1
Update a recordUtable_name:key1=val1[,key2=val2...]:field1=newval1
Delete recordDtable_name:key1=val1[,key2=val2...]
Restore recordRtable_name:key1=val1[,key2=val2...]
Successful authAUTH_OKcustomer|account|vendor:username|email=value
Bad authAUTH_FAILcustomer|account|vendor:username|email=value
Successful auth using OTPAUTH_OTPcustomer|account|vendor:username|email=value
Reset one time passwordOTP_RSTcustomer|account|vendor|system:
Web Password changePSWD_CHNGi_customer|i_web_user|i_account|i_vendor=id
Add funds/Debit/CreditFUNDSadd|credit|debit|recharge:i_customer|i_account|i_vendor=
Disconnect callCALL_DISCi_call|i_account=id
Billing runBRUNi_account=id
Billing restartBRSTRTi_account=id
Queue an actionQtable_name:key1=val1[,key2=val2...]:field1=newval1
Execute an actionEtable_name:key1=val1[,key2=val2...]:field1=newval1
Clear First Use timestampCLR_FSTUSEaccounts:i_accout=id
Extend LifetimeEXT_LFTMaccounts:i_accout=id
Issue SSL CertificateSSLCRT_ISSi_environment=id
Open TCP 80 portFW_OPEN80i_environment=id
XMLAPI relayed to
another environment
MFA requiredMFA_RQRDcustomer|vendor|web_user:username:MFA_type
MFA pending until setup doneMFA_PENDcustomer|vendor|web_user:username:MFA_type
MFA setup doneMFA_SETUPcustomer|vendor|web_user:username:MFA_type
MFA verification passedMFA_VRFYcustomer|vendor|web_user:username:MFA_type
MFA required, but failedMFA_FAILcustomer|vendor|web_user:username:MFA_type
Reset MFA configs,
tokens and validations
for ALL users
Reset MFA configs,
tokens and validations
for a specific user
  •  Action by - WHO accessed the page/did the changes. Example of syntax:

1. [letter that corresponds to system unit]:

  • u for Web Users
  • a for Accounts
  • c for Customers
  • v for Vendors
  • t for trusted XMLAPI call

2. [id of the entity]

e.g. for Web users it would be i_customer that owns this Web User. For Accounts, Customers, Vendors it would be i_account, i_customer, i_vendor correspondingly. For trusted xmlapi there would be 0.

3. [id of sub entry]

e.g. for Web users it would be i_web_user. For Accounts, Customers, Vendors, trusted xmlapi there would be 0.

4. [name of entry]

e.g. for Web users, Customers and Vendors it would have Web Login of Web User, Customer, Vendor correspondingly. For Accounts - Username, for trusted xmlapi there would be IP address of the Environment.






  • Date - WHEN the event happened. Date is displayed in timezone of web user that checks the Audit log
  • User IP/Node - where the request came from. Normally contains IP address of the user that participated in event, sometimes there could be a node-id of the system