Main • ReportingBugs

Developers -> Reporting bugs

On this page:

Bugs or missing features are always possible in any software or other branches of engineering. We will try to fix the problems in Yate as soon as possible. Please note that our priorities may be different than yours...

Even if you spent time and accumulated frustration trying to fix a problem you should always make a good report of the problem. Try to make it brief, informative and correct. It never makes sense to just say "It doesn't work!" - that is not going to get problems fixed or even investigated.

You can read a great article by Simon Tatham on How to Report Bugs Effectively. If you want a second opinion please see what Google can find about it.

What to check before reporting?

Before making a bug report you should check if the problem was known before. Someone may be working on it, it may have been fixed or there may be workarounds.

  • Make sure you are running a clean build of Yate, especially if using CVS. Subtle problems may be caused by partial builds. If the compiler crashed at any point you should clean everything and start building from start.
  • Read the Documentation - especially the parts related to your problem.
  • Verify if any other equipment or software you use is compatible with Yate.
  • Check the Bug tracker for open bug reports of the problem. Please look at the closed and resolved bugs too - the problem may have been already fixed in a new release or in CVS.
  • Check the List archive if the problem wasn't reported before.
  • Ask our friend Google

What to include in the report?

Making an usefull bug report is not difficult. You have to provide us maximum of information so we can locate the problem.

  • A brief description of the problem, what you expect to happen and what you actually observe happening.
  • Whether the problem appears always or is intermittent.
  • Details about the hardware you are running Yate on - type, speed and number of processors, size of memory.
  • The version of your operating system and/or distribution.
  • Information on any firewall or NAT you may have on that computer or in the network (for VoIP protocols).
  • Version of Yate, date of latest SVN update if applicable.
  • Logs, preferably with the highest level of debugging. Please enable timestamping (options -Dt, -De or -Df).
  • Backtraces of the stack if Yate crashes and a core dump is available.
  • Ethereal packet captures or at least tcpdump logs (tcpdump -nn is usually enough) if you suspect network related problems.

Please do NOT include large log files. Also never include core files - they are useless without the executable that crashed and all its libraries and modules.

Do not use screen or telnet captures from rmanager. Some scripts and third party libraries write only to the log file and you may be missing important information if you take it from other sources. Only log file or console information is complete.

Crashes caused by memory corruptions leave useless core files (since the damage was caused earlier, typically by a different thread). If you see "glibc detected ... memory corruption" then please do not post such backtraces. The logs may provide some information about what went wrong.

NOTE!!! A backtrace is usefull only if it includes symbol information. You can compile the debug version of Yate, either by "make debug" or choosing the "Win32 Debug" configuration (in Windows).

Where to report bugs?

There are several places you can use to report bugs:

  • For small problems or just to quickly ask a question you can use IRC - the #yate channel on the Freenode network (irc.freenode.net)
  • More complex problems can be asked on the Mail list - the answer may be slower but more people may be able to answer.
  • Finally, there's the Bug tracker where you can report a problem, add notes, logs and patches and track how the report was handled.

How to create a comprehensive backtrace from a core file

Creating an useful backtrace may be tricky. Here is a formula to get plenty of information:

 echo -e 'thread apply all bt\nquit' > gdb-bt-all.txt
 gdb -x gdb-bt-all.txt yate coreFILENAME &> yate-bt-all.log

Replace coreFILENAME with the name of the generated core file. The yate-bt-all.log file will contain a backtrace of all threads. For best results Yate should be compiled with debug symbols. This does not hit the performance or memory usage, just increase the size of the files on disk.

Recent versions of Yate provide a readily made gdb-bt-all.txt in the tools subdirectory of sources.

If you have a core dump but Yate was compiled without symbols you can recompile it and get a proper backtrace - just be sure you don't change the source or configure options. Issuing a "make clean debug" will recreate all binaries with exactly the same addresses but with debugging information. Do not use "make ddebug" or "make xdebug" as these will change the code.

Creating core files

If Yate doesn't create core files when it crashes:

  • Check that the directory Yate is started in is writable, there's where the core files are dumped
  • Make sure you set something like ulimit -c unlimited or start Yate with the -C command line option
  • Check if core size limits aren't restricted by the superuser, system policy or filesystem quota

July 2014:
Yate 5.4 and YateBTS 4 launched. Added JSON and DNS support in Javascript, Handover support in YateBTS.

March 2014:
YateBTS 2.0 launched. Added authentication and WebGUI. Added USSD support in commercial version.

March 2014:
Yate 5.2 launched. Better JavaScript support and a fixed memory leak.

Jan 2014:
YateBTS 1.0 launched. The first GSM Basestation which works with an IMS/VoLTE core network.

Jan 2014:
Yate 5.1 launched. Better JavaScript support and added libygsm. Elisa chatbot added in RManager

Oct 2013:
OpenHSS is the Yate based HLR/HSS solution for MVNO and LTE carriers.

Oct 2013:
Yate 5 released. Added IPv6 support in SIP for LTE. Improved JavaScript support. Download NOW

Jan 2013:
Yate 4.3 released: Added XML support in Javascript. SCCP - GTT routing between different networks. Stability improvements.
Download NOW

Aug 2012:
Yate 4.2 released: SIP flood protection. Better Jabber/Google Voice support. Usable Javascript. Fixed SIGTRAN links fluctuations.
Download NOW

Apr 2012:
YateClient was accepted in the Mac Store.

Yate 4.1 released: better Gvoice support, iSAC codec, support for new Wanpipe drivers. Fixes T.38 and Mac client issues.

Mar 2012:
SS7Cloud is launched today, 1st March, 2012, by NullTeam, Yate creators. Having all you need to be a US CLEC, it brings SS7 services in a cloud.

Feb 2012:
Yate 4.0 released.
SCCP, TCAP, MAP and CAMEL, TCP and TLS in SIP, Javascript fast prototyping of telephony applications and brand new face for YateClient.

Nov 2011:
Here is a video that, quote "demonstrates the truly awesome power of the YATE engine, as it easily handles 3 simultaneous calls to an audio player application including dtmf (button press) handling "(from PaintedRockComm).

Nov 2011:
Yate will attend ORR - OPENRHEINRUHR (November 12 - 13).

04 May 2011:
sipgate chooses open source project Yate for core infrastructure.

12 Apr 2011:
Yate 3.3.2 released.
Fix for Jingle calls to Google Voice dropping after 5 minutes.
4 Apr 2011:
Yate 3.3 released.
Support for GMail chat conference, fixes for internal microphone in MacOS. Minor fixes in SS7 M2PA and ANSI. Fixes in H.323, SIP and RTP.

9 Mar 2011:
Yate 3.2 released.
Bug fixes in SIGTRAN/MGCP/SS7 and added support for CNAM/LNP lookup by SIP INVITE/3xx.

Feb 2011:
Yate will attend FOSDEM and XMPP summit.

31 Jan 2011:
Yate 3.1 released.
Yate client support for Google Voice. Support for any country tones in tonegen.

20 Dec 2010:
Yate 3.0 released.
SS7 ITU certified. SS7 STP added. Client supports Jabber IM (Google Talk + Facebook).

3 May 2010:
Yate 3.0.0 alpha 3 released. Featuring the new Jabber server and wideband audio.

8 March 2010:
Yate 2.2 released. Mostly bug fixes. Dahdi compatible. Latest 2 release before 3.0.

6-7 February 2010:
Yate booth at FOSDEM 2010. Free CD with Freesentral available.

2 Nov 2009:
Yate 2.1 launched. Can replace a Cisco PGW2200 to control a Cisco AS54xx.

6 Aug 2008:
Yate and OpenSIPS (former OpenSER) join to build IP based clusters.

4 Aug 2008:
Yate 2 launched.

EditHistoryBacklinksRecent ChangesSearch