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?

Call interrupted immediately after connecting?

Call dropped immediately after being initialized

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

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

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.


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.

 "Cookie monsters": 7741461    Parse time: 0.001 s