You need not recompile with debug symbols or use a debugger to take these steps (for that, see Debugging Freeswitch)
Debug for the Impatient
From a bash/shell:
Start FreeSWITCH (e.g. /usr/local/freeswitch/bin/freeswitch)
This will produce quite of logs ready to be pasted into freeswitch pastebin http://pastebin.freeswitch.org/
To turn this logging off, exit freeswitch and:
Enabling SIP/Sofia Tracing
Stop FreeSWITCH. At the bash shell prompt enter any subset of the following:
NOTE: If you only want to see the SIP messages then use the TPORT_LOG export only.
For the full set of environment variables, see http://sofia-sip.sourceforge.net/refdocs/debug_logs.html
You don't have to rebuild sofia for these to work.
Enabling SIP/Sofia Tracing on Windows
- From mailing list post by UV.
In Windows, you need to set those environment variables using "set" instead of "export". Like this:
Then run freeswitch.exe in the same process.
Increase Debug Output
Edit switch.conf.xml (especially if you have lots of calls, reduce logging)
The possible values for value are (use only the text value in ""):
[what are the possible name values?]
You may also use the console API to set debug level on FS console.
And you can also set the levels of fsctl.
In console.conf.xml uncomment the color mode.
The colors are:
- ALER - Red
- CRIT - Red
- ERROR - Red
- WARNING - Magenta
- NOTICE - Cyan
- INFO - Green
- DEBUG - Yellow
Whatever libedit is, enable it via --enable-core-libedit-support argument to configure script.
Debugging problematic calls, such as clicks
- Check to see what the encoding is, so you know what needs to be debugged. 'show channels' on the fs_cli.
- Make a call to the same endpoint, to see if it is related to a short, or long call.
- Check for any error or warning output in the fs_cli during the calls, to see if there is something obvious that FS already knows about.
- If with the same endpoint you always experience the problem, try to isolate where the issue is.
- Call 9198 and listen to Tetris to see if the problem is present there.
- Call 9197 and listen to the mw tone.
- Call 9196 and test the echo.
- If steps 5-7 don't show the issue, then the connection between phone to FS is fine.
- Try other endpoints to see whether it is experienced in all cases.
- Call 5000, and call the 888 conference to see whether the issue is present there.
- Call the endpoint (if it is PSTN) with a POTS or mobile phone, to see whether it is VoIP related or endpoint related.
You should know where the issue lies after these steps!