Logging and troubleshooting
There are three different logs. Use the one that answers your question:
| Log | Contents | How to turn it on | Where |
|---|---|---|---|
| SIP messages | Every SIP message sent and received, as it is on the wire. | Options/SIP Logging (Ctrl+L), or -log | Logs/<date and time>.log |
| Scenario progress | The progress table of the scenario screen (the Exp and Unexp counters). | Options/Scenario Logging, or -logScen | Logs/<scenario>_<date and time>.log |
| Program log | What the program does: the steps of a run, of every call, warnings and errors. This is the one to send with a bug report. | Always on at DEBUG; change the level with Options/Debugging or -d | SIPInspector.log in the folder the program was started in |
The levels of the program log: ERROR - what stops a call or a feature from working; WARN - something unexpected that the program survived; DEBUG - the steps of a call, a connection or a scenario that are needed to follow what happened (the default); VERBOSE - the detail of every packet. In the Debugging menu they are called Error, Warning, Info, Fine and Off. The log is limited to 20 MB.
When the counters are wrong
- The scenario does not start. Check the local address and port: another program may use the port, or the address is not the one of your network adapter. Run the CLI with
-d DEBUGand read the first lines of SIPInspector.log. - Nothing comes back. Check the remote address and port and any firewall. Turn on SIP Logging: if only outgoing messages are in the log, the other side does not answer.
- Many unexpected messages. Look at the Unexp msgs column to see what came and at which entry. The program log has a line for each one, for example ‘received 401 that the scenario does not expect now; the scenario is at entry 0’. Typical reasons: an optional message is missing in the scenario, the other side repeats messages (retransmissions), or the other side answers with a challenge (401, 407) that the scenario does not handle.
- Messages of one call end up in another. The scenario has several dialogs that interleave: use Options/Don't check Call-ID.
- A call waits forever. A mandatory incoming message does not come, or Wait RTP waits for audio that is not sent. Use the Pause command and Wait video's time limit, and the
-tooption in the CLI. - For a bug report send the diagnostics bundle (Help/Save Diagnostics or
-diag): it has SIPInspector.log, the scenario file, the settings and the call flows.
The diagnostics bundle
Help/Save Diagnostics saves one zip with what is needed to look at a problem, so a support question starts with the facts. Send it to support@sipinspector.com with a few words on what you did and what went wrong.
| File | What it has |
|---|---|
about.txt | The version, the license state and the Machine-ID, Java, the operating system, the memory, the network cards, the log level, the command line |
settings.txt | Every setting of the run |
scenario/, scenario-check.txt | The scenario file, and what Validate Scenario finds in it |
logs/ | SIPInspector.log (its last 8 MB) and the two newest SIP message logs |
reports/ | The three newest reports of the Reports folder |
run/ | The report of the last run (HTML and JSON), what the SIP/SDP checks found with the messages, and the call flows as text |
values/ | The values file, only when it is asked for: it often has the passwords of many users |
Passwords are not in it. The password and the API token of the settings, the serial number, a password= of a scenario and the digest response of the Authorization headers are replaced with *** in every file. Look through the bundle before you send it if your scenario or log has other things that must not leave your network, such as addresses or user names.
On the command line, -diag bundle.zip writes it when the run ended, after the reports; a bundle that cannot be written never changes the exit code. Without -fs and -api, SIPInspDlx -diag bundle.zip writes it at once: it works when the program cannot start a run, even when the license is the problem. The API gives it with GET /diag.