In this section we collect all the logs about events that has happened. This type of logs are written once the event has finished and do not represent a live photograph of the state of the service or of the appliance. They are mostly useful for debugging user's issues and provide support. Subtitle |
---|
Prefix | figure |
---|
SubtitleText | the static logs menu |
---|
AnchorName | static_logs_menu |
---|
| ![static_logs_menu.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
As you can see in Xref |
---|
AnchorName | static_logs_menu |
---|
| all these logs are grouped under the "LOGGING" label into the main menu.SecuritySince 14.1 version Security Events has been added to logging. This log category lists every event captured by our Security Information and Event Management (SIEM) interface, which has been introduced in that version. Subtitle |
---|
Prefix | figure |
---|
SubtitleText | Security Events list |
---|
AnchorName | security_event_list |
---|
| ![security_event_list.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
SIEM interface catches and rewrites SIEM style events that are currently managed in underlying event log layers such the one described just after present paragraph. This means that each event listed under this section is also present in a specific on but shown in different format, often raw one. SIEM formatted events are instead all present here. Subtitle |
---|
Prefix | figure |
---|
SubtitleText | Security Event detail |
---|
AnchorName | security_event_detail |
---|
| ![security_event_list_detail.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
Just clicking on Timestamp you get single event details as shown in Xref |
---|
AnchorName | security_event_detail |
---|
| .You can tell we're dealing with SIEM formatted log just by reading Details part. Consider that we're talking of a generic SIEM format that can be more refined and adapted for being processed by external systems. can generate events in CEF format, compatible with HP Arcsight product.SystemSystem Events list shows all events occurred to but not directly intercepted by Web appliance because triggered out of its scope. Subtitle |
---|
Prefix | figure |
---|
SubtitleText | System Events list |
---|
AnchorName | system_events_list |
---|
| ![system_event_list.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
Examples are: - Web appliance updates
- Web appliance reboot
- Appliance backup and restores
- Heartbeat
Subtitle |
---|
Prefix | figure |
---|
SubtitleText | System Event details |
---|
AnchorName | system_event_details |
---|
| ![system_event_list_detail.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
Clicking on Timestamp part of the log shows you System Event's details as show in Xref |
---|
AnchorName | system_event_details |
---|
| .Web SessionsIn the web sessions it's possible to read the list of all the access made to the web console. Subtitle |
---|
Prefix | figure |
---|
SubtitleText | List of Web Session Logs |
---|
AnchorName | web_sessions_log |
---|
| ![web_sessions_log.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
Just click on the Web Sessions entry in the main menu and you get a list as in figure Xref |
---|
AnchorName | web_sessions_log |
---|
| . Fields shown are:- Date Created: this is when the event occurred
- Event Type: there are several type of Events (see specifications below)
- Principal: the username used to log in.
- IP Address: the IP address from which the connection has been performed.
Info |
---|
If the user listed is "anonymousUser" then this is an event triggered by the system. This is specifically true for events like the "SESSION_TIMEOUT". |
Event TypesHere follows a list of all the event types logged in this table: - SESSION_TIMEOUT : pretty self explanatory
- LOGOUT : The user performed a logout
- SUCCESS_INTERACTIVE / SUCCESS : these two events always come together and indicates a login has successfully performed. The former one points out the login happened through the web interface ("interactive"), the latter is a generic successful login log.
- FAIL_USER_NOT_FOUND : the login used was not found among the users configured.
- FAIL_CREDENTIALS_EXPIRED : the password or the credentials used are set as expired
- FAIL_BAD_CREDENTIALS : wrong password
Call Details RecordsRecordCDR is a debugging and quality assurance tool: it lists all calls statuses, which is very useful to understand if something went wrong with your Secure Call Service. Note |
---|
Please be aware that CDR can only list past calls. Calls that are currently ongoing are not listed or are partially shown if they are conference rooms. |
To access CDR you must click on Call Detailed Record in main menu. You'll get "Cdr List" page which lists all details of performed calls. Subtitle |
---|
Prefix | figure |
---|
SubtitleText | Call Detailed Record List |
---|
AnchorName | cdr list |
---|
| ![CDR_list.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
Info |
---|
If the table is empty, please perform one phone call between two s and then come back on this page to check that the call has been correctly registered. |
Shown fields are: - Call Date: when the call has been placed.
- Caller Number: The virtual phone number used to place the call.
- Caller: The caller description, if any.
- Caller Group: The caller's group description, if any.
- Callee Number: The virtual phone number called.
- Callee: The callee description, if any.
- Callee Group: The callee's group description, if any.
- Total Duration: how long the call lasted. Time elapsed from the moment the "Call Button" is pressed on the caller's client to the one in which the communication is closed at all.
- Call Duration: how long the call lasted, just the voice.
- Disposition: which result the call had.
- Hangup Cause: how long the call lasted.
- Call id: a unique number that identifies the call.
- Call type: nature of the call performed.
- Call route: if the call transited on a trunk this field would shown the trunk's name.
Relevant fields in CDRThe Disposition field reports the final state of the call, whether it reached the called number or not (eg: callee canceled the call, called was busy, etc...). Possible codes are: - ANSWERED: callee answered
- NO_ANSWER: callee did not answer
- BUSY: callee refused the call
- FAILED: for some reason the call was not able to be placed (eg: User was off-line)
- CANCEL: caller hanged up during ringing
The Hangup Cause describes from Secure Voice Engine's point of view how or why the call ended. Possible causes are: - NOT_DEFINED: No informations received or no information listed in known causes (ie: don't know why)
- NO_ROUTE_DESTINATION: The callee was not known to the system (and there's no trunk to route out).
- NORMAL_CLEARING: Call closed normally.
- USER_BUSY: The user is busy.
- NO_ANSWER: The callee didn't answer and the call was closed for timeout reason.
- CALL_REJECTED: The callee rejected the call, as by pressing the "hold" button.
- BEARERCAPABILITY_NOTAVAIL: The caller and the callee were using different security models that are not compatible.
- NO_USER_RESPONSE: [when call goes out by Trunk] The same as in "NO_ANSWER".
- NORMAL_CIRCUIT_CONGESTION: [when call goes out by Trunk] as in "NO_ROUTE_DESTINATION".
- SUBSCRIBER_ABSENT: [when call goes out by Trunk] calle is temporary not reachable.
Info |
---|
To understand what happened in each call row you should always put together informations shown in Disposition and Hangup Cause. |
The Call Type identifies the nature of the call. Used with the Call id fields this value is useful to trace down complex calls like three-way calls, conferences or transferred calls. Possible values are: - CALL: Regular call between two persons
- 3-WAY: Conference Call, meaning one regular call on which has been invited more participants.
- CONFERENCE: Conference Room, meaning one number to call in order to have more persons talking togethere
- TRANSFER: Regular call that has been transferred to a third person
The Call id is a number that identifies uniquely the call. It can be used to trace a call if it changes its nature (ie becoming a three-way call) or to group all the participants (ie in a conference room). Info |
---|
It's possible to avoid any call record, as a Privacy option. To enable the "No-CDR" option, you just have to set the CDR Period to "DAY" and the duration to '0' (zero). |
Warning |
---|
The above statement about the CDR Privacy option is true only for the DIRECT calls (which are the calls between two users). Conferences and 3-way calls will be logged as ever, though. |
SIP Client ConnectionsThe SIP Sessions page show the activities each Account did with the server. Subtitle |
---|
Prefix | figure |
---|
SubtitleText | List of SIP Session Activities |
---|
AnchorName | sip logs |
---|
| ![sip_sessions_log.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
To get this list just click on the SIP Sessions entry in the main menu. The activities are listed by date and they give you a detailed overview of the SIP status for each one. These logs are very useful for debugging the networking issues on the client side. The Event column lists the SIP events: - CONNECT: client opened a connection to . This usually means the client has been activated
- REGISTER: The Account has been correctly registered and is now on line
- UNREGISTER: The Account has been correctly unregistered and is now off line
- DISCONNECT: client closed the connection. This usually means the client has been stopped.
Each one has its Details column which explains the exact message provided by the . CONNECT/DISCONNECT event are bound to a remote address, not directly related to a specific VoIP account. A periodic background task analyses the SIP session logs and, when possible, reconcile them binding these events to a specific account. Reconciliation is very useful while debugging SIP session for a specific user: clicking on username field will show a filtered list of SIP session events. Secure MessagesThe Messages page lists Secure Messages managed by . Info |
---|
Only transport data are listed in this view: no payload or other data about Secure Messages are showed up |
Subtitle |
---|
Prefix | figure |
---|
SubtitleText | list of Secure Messages |
---|
AnchorName | messages_list |
---|
| ![messages_list.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
The list represent the log of Secure Messages transaction happened, so that it's showed: - Received: when actually received the Secure Message
- From: sender's account name
- To: recipient's account name
- Status: status of the message. Secure Message Statuses are described in next paragraph
Each Secure Message managed by is represented on one single line, as shown in . Secure Message StatusEach Message walks through different statuses, each one representing a milestone towards its delivery: - ENQUEUED: received the request to deliver one Secure Message and put it in its queue to be managed
- DELIVERED: Secure Message has been delivered to recipient's device which sent back a receive confirmation.
There are statuses describing issues raised during the delivery, such as: - EXPIRED: the message has been in queue for more than 72 hours and thus it's no more considered valid.
- INVALID_RECIPIENT: recipient's cannot deal with Secure Messages
- INVALID_DEVICE: recipient's device does not support Secure Messaging
- INVALID_PAYLOAD: message content is empty or bigger than 600 byte (this should never happen)
Anchor |
---|
| install_messages |
---|
| install_messages |
---|
|
Install messages Install messages are one amongst the numerous means for installing on the customers' mobile device. What we accomplish sending an Installation message is to help the customer to find out the correct edition of application and automatically install it. Subtitle |
---|
Prefix | figure |
---|
SubtitleText | list of the install messages sent |
---|
AnchorName | install_msg_list |
---|
| ![install_msg_list.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
main features of the logs of the install messages are: - Timestamp: the exact date & time when the message has been sent
- Account: to who the message has been sent to
- Platform: which mobile platform
- Variant: this could be either:
- ZRTP: this is the end-to-end security model
- SDES: this is the end-to-site security model
- Sent: if the message results to be effectively sent or if there were issues in sending it
- Sent by: the User who sent the Install Message.
- Recipient: the number of mobile device or the email address to whom message has been sent to
- Message Type: this could be either:
- EMAIL: Installation message was sent by email (user's mailbox must be set up)
- SMS: Installation message was sent by Text Message (SMS) using user's virtual phone number
Subtitle |
---|
Prefix | figure |
---|
SubtitleText | details of one install message |
---|
AnchorName | install_msg_detail |
---|
| ![install_msg_detail.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
Clicking on the Timestamp field it becomes possible to reveal details about each message. You can have an example in Xref |
---|
AnchorName | install_msg_detail |
---|
|
. Info |
---|
| Clicking on the Account field brings you straight to the Account's detail. |
Anchor |
---|
| provisioning_messages |
---|
| provisioning_messages |
---|
|
Activation messages Provisioning messages are basically the mean for delivering the download URI of the provisioned configuration. Long story short: whenever you push an automatic activation by sending the provisioning message you're sending a text message that contains the URI to the user's configuration. Part of this configuration is created by the Provisioning Profile, part of it is taken by the Account configuration. Nevertheless, it's always a configuration file to be downloaded and then installed in your . Subtitle |
---|
Prefix | figure |
---|
SubtitleText | Log list of the provisioning messages |
---|
AnchorName | provisioning_messages_logs |
---|
| ![provisioning_messages_logs.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
Clicking on the Provisioning Messages link brings you to the logs list shown in Xref |
---|
AnchorName | provisioning_messages_logs |
---|
|
. Here you have all the primary informations about the automatic activation performed: - Timestamp: when each message has been sent
- Consumed: status of the message, or else either it's been used (consumed) or not. This means if the customer has ever clicked on the link inside the text message/email
- Account: user to whom the message has been sent
- if the text message has been Sent or not, meaning if any problem arose during the delivery and the text never left the server.
- Sent by: the web console user who sent this provisioning message
- Recipient: the number of mobile device or the email address to whom message has been sent to
- Message Type: this could be either:
- EMAIL: Installation message was sent by email (user's mailbox must be set up)
- SMS: Installation message was sent by Text Message (SMS) using user's virtual phone number
Subtitle |
---|
Prefix | figure |
---|
SubtitleText | detail of provisioning message |
---|
AnchorName | show_provisioning_msg |
---|
| ![show_provisioning_msg.png](/docs/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2)
|
Clicking on the Timestamp field it becomes possible to reveal details about each message. You can have an example in Xref |
---|
AnchorName | show_provisioning_msg |
---|
|
. Info |
---|
| Clicking on the Account field brings you straight to the Account's detail. |
Three are the contents shown in the detail form that are not present in the list above: - The Message link
- The Token
- The Validity
|