Troubleshooting

Since version 0.1.67 (2019.05) "Troubleshooting" function is part of "Help" menu and contains simple checks for many of the problems listed below. This would be recommended first step in case of any problems or for any new installation - reminding of trivial things like missing microphone or missing audio devices with remote desktop (forcing to switch audio modules to "Null" or wave file).

No registration?

make sure register expires is set to non-zero; zero value as registration expiration serves as special value to work without registration
if there are multiple network interfaces or adresses try binding to single one, using either its IP address if it's fixed or device GUID (as displayed in log); changing NIC priorities from control panel is another option
check log

Call interrupted immediately after connecting?

missing audio input or output device (e.g. no microphone plugged to jack with autosensing)
if using wave file as source: incompatible file format (required wave, mono, S16_LE or wave file is missing
for Windows 10: check/modify microphone privacy settings (this affects also other applications like Discord)

Call dropped immediately after being initialized

see log to check if disconnection cause is local (e.g. second party answered but audio device is missing, no microphone connected) or related to both call parties (e.g. SIP/488 reply received = no compatible codecs selected, SIP/403 = probably wrong user/password)

Call confirmed but no audio in one or both directions

Often caused by ACK message not being received or RTP stream being directed to wrong address.
In general tSIP is not well equipped for NAT traversing (e.g. ICE is not available) as this kind of problems is not expected with commercial VoIP operators (as their devices are supposed to be accessible from public addresses, be correctly configured and most of the times are prepared for situations when second party advertises local or incorrect public adresses) or for communication withing single network.
In not too rare cases router - in particular ALG = Application Level Gateway feature - may be responsible. It is supposed to help with NAT traversing but oversimplified (e.g. based on text substitution) or plainly incorrect implementations may often block communication. If setting related to this function cannot be found in router configuration but its presence is suspected then changing SIP listen port(s) to other than 5060 and 5061 might help.

Bad audio quality after attended transfer on FreePBX

I have not confirmed it yet, but there might be audio issue related to switching audio codecs during the call (call started with PCMA, switched to G.722 later). It looks like limiting softphone codec number to single one (e.g. only G.722) might be a workaround.

Other audio issues

I've received few reports of problems with audio. I wasn't able to reproduce it, but switching from default "winwave" audio module to "Portaudio/DirectSound" was helpful.

Failed to init application

bind port for SIP is busy, i.e. other application if listening on the same port as tSIP tries to
- change tSIP bind port (or remove binding thus using automatic port)
- or: change bind port in other application - netstat command may help

Possible crash related to AGC / audio preprocessor

Rare crash (sqrt domain error) was reported when using Speex AGC on Linux/Wine. I don't know if this is specific to Wine or rather some audio signal pattern and I wasn't able to reproduce this. While I haven't removed AGC from application (leaving it for test purposes) I'm not recommending using this option as it's usability is very debatable (Windows 7 has built-in AGC enabled by default anyway, also AGC can often degrade audio quality by amplifying noise).

Echo heard by second party

first of all: there should be no echo unless your microphone is picking up your speaker; if you are using headset then echo is not expected and you should try looking into audio mixer settings first for any loops like "Stereo Out" not muted in audio sources
in Settings/Audio Processing set AEC (acoustic echo cancellation) to WebRTC (by default no AEC is used and I was not able to get good results with Speex AEC, so WebRTC is basically only option worth trying)
if echo is still present - look at your audio devices settings and try to disable all the audio enhancements; I've found that multiple audio processing blocks often don't well together (basically breaking AEC adaptation state)
cheap $1 USB sound card might be worth trying if you have spare one - they might be missing fancy audio processing and this is a plus

Echo heard by you

If you hear the echo of your own voice and it is not caused by looping on local audio mixer, then you probably won't be able to do anything with it locally, you just have to ask second party for troubleshooting. This is sometimes called "far echo" and AFAIR there are only few commercial solutions that are claimihg they can fix it. Near/local echo cancellation is the norm (everyone tries to limit their own, locally generated echo, but almost no one can remove echo that is generated by others).

Zenitel TKIV+ crashes

Zenitel TKIV+ module crashes due to improper SIP header parsing and NULL dereference (visible in its logs) upon receiving call from tSIP. This can be actually triggered with many different header lines. I've reported it back to Zenitel few months ago but I think it was ignored - I've received the reply that these systems are working in closed networks, so it is not important. Maybe it would get fixed someday. While I could remove the header line that is crashing TKIV I feel like it might create bad precedence if the only reason for it would be adapting to one buggy product.

Other

2018.01. [OBSOLETE - default behavior is changed to increase interoperability] I've received report with problem with one (German?) cloud-based virtual PABX operator. This operator allows to register multiple phones/softphones to single account but apparently after tSIP was registering other devices from same account were losing registration / not received incoming calls. Seemingly this was fixed by filling "Contact" in tSIP account settings with same value as user name (if not filled tSIP fills Contact with semi-random value which may look weird but shouldn't cause problems) and setting local port (binding) to 5060 (despite that softphone was behind NAT that was changing source port anyway).

Reporting an issue

While I'm trying to reply within a day, keep in mind it is quite likely that we are living in different time zones and I might only have few hours window of available time (not sleeping, not working). Including log from tSIP, trace from Wireshark or a description how to reproduce issue might save few mail roundtrips.

Back to howto list.