History of occurred events.
This information is for advanced users and support matters.
To send these logs to a syslog server configure it on the Log Configuration page.
Read more online:
System log
Refresh... - The webpage shows a static view of the log. To see the latest information, click "Refresh".
Shows firewall events: packets processed and the actions taken for them.
This information is for advanced users and support matters.
NOTE: Firewall logging is by default disabled to maximize firewall performance. It can be enabled on the Log Configuration page, where the verbosity of the log can also be configured.
Certain traffic on the inside have been filtered out and is never visible in the log: trafic to/from this unit's internal web server, and Syslog and NetBIOS packets. Advanced users can change this behaviour using Additional rules on the Security Profile page.
During heavy load performance is prioritized before logging, which can result in some packets not being logged.
If you want to send the log to a syslog server configure it on the Log Configuration page.
Read more online:
Firewall log
Refresh... - The webpage shows a static view of the log. To see the latest information, click "Refresh".
Shows SIP calls traversing this box. Can even show call quality related metrics.
NOTE: Call logging is by default disabled. It can be enabled on the Log Configuration page, where you also can decide if you additionally want to collect call quality related metrics.
A SIP call will usually generate the following call records in the call log:
Ringing start for [sip:1234@domainx.com 111.111.111.111] -> [sip:5678@domainy 222.222.222.222]
1234@domainx.com is the calling parties SIP address, 111.111.111.111 is the calling clients IP address.
5678@domainy.com is the called parties SIP address, 222.222.222.222 is the called clients IP address.
There is only one Ringing start record for a call, even if this call rings several parallel because of call forking.
Start of session M2Qyg67bYjIm: [sip:1234@domainx.com 111.111.111.111] -> [sip:5678@domainy 222.222.222.222]
The Start of session record is created when the call is answered by the called party. M2Qyg67bYjIm is a unique session ID for this call. It is composed of the beginning of the incoming call ID, of the end of the outgoing call ID, and of a hash value of the remaining part of the involved call IDs. The incoming and outgoing call ID will usually be the same, except for special scenarios, e.g. when a back-to-back SIP user agent is involved.
End of session M2Qyg67bYjIm: [sip:1234@domainx.com 111.111.111.111] -> [sip:5678@domainy 222.222.222.222]
Duration: 2 sec, Terminate reason: User Request
The End of session record is created when the call is finished. Terminate reason User Request is the regular case, Timeout is an exceptional case if one party of the call does not respond any more.
-> Bytes: 11200, Pkts: 56, missing: 0 (max 0), reo.: 0, Jitter avg: 0 ms (max: 7 ms), last PT: 0 (PCMU), CN: no, MOS: 4.40
<- Bytes: 13400, Pkts: 67, missing: 0 (max 0), reo.: 0, Jitter avg: 0 ms (max: 0 ms), last PT: 0 (PCMU), CN: no, MOS: 4.40
These two records follow immediately after the End of session record in the log. They are only generated when "including Media statistics" is set up on the Log Configuration page for call logging.
They contain results of the RTP packet monitoring which is performed for the RTP streams belonging to this call.
The first line contains information about the RTP packet stream from the calling to the called party, the second line contains information about the opposite direction.
Bytes is the number of bytes (including IP header);
Pkts. is the number of RTP packets.
missing tells the number of missing (lost) packets.
max is the number of continuously missing packets, so e.g. a value of 3 means that e.g. the packets with sequence numbers 3001,3002 and 3003 were missing.
reo is the number of reordered packets, so packets which were not received in the normal order.
Jitter avg. is the average Jitter value in milliseconds over the total call duration.
max is the maximum jitter value during the call.
Last PT is the last packet's payload type value from its RTP header.
PCMU here tells that the used codec in the last RTP packet was PCMU in this example.
CN is either yes or no and tells if Comfort Noise packets (used for silence compression) were present during the call.
MOS means "Mean opinion score"; it is a value between 1 and 5 and gives an estimation how listeners might experience this call, with 1 being "bad" and 5 being "excellent". This value is calculated mostly based on the used codec, and on the packet loss distribution during the call. Note that this value does not take into account possible packet loss or other problems happening to the packet stream after it has traversed this box.
If you want to send the call log to a syslog server configure it on the Log Configuration page.
Read more online:
Call log
Refresh... - The webpage shows a static view of the log. To see the latest information, click "Refresh".