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:
export SOFIA_DEBUG=9 export NUA_DEBUG=9 export NTA_DEBUG=9 export TPORT_DEBUG=9 export TPORT_LOG=1
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:
set SOFIA_DEBUG=9 set NUA_DEBUG=9 set SOA_DEBUG=9 set NEA_DEBUG=9 set IPTSEC_DEBUG=9 set NTA_DEBUG=9 set TPORT_DEBUG=9 set TPORT_LOG=1 set TPORT_DUMP=tport_sip.log set SU_DEBUG=9
Then run freeswitch.exe in the same process.
Increase Debug Output
<param name="log_event" value="DEBUG"/> <param name="all" value="DEBUG"/>
Edit switch.conf.xml (especially if you have lots of calls, reduce logging)
<param name="loglevel" value="debug"/>
The possible values for value are (use only the text value in ""):
0 "CONSOLE", 1 "ALERT", 2 "CRIT", 3 "ERR", 4 "WARNING", 5 "NOTICE", 6 "INFO", 7 "DEBUG"
[what are the possible name values?]
You may also use the console API to set debug level on FS console.
freeswitch@de> console loglevel [0-7] (numerical value as above)
And you can also set the levels of fsctl.
freeswitch@de> fsctl loglevel [0-7] (numerical value as above)
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!