Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Purpose of the Asterisk issue tracker

The Asterisk Issue Tracker on GitHub is used to track bugs and miscellaneous (documentation) elements within the Asterisk project. The issue tracker is designed to manage reports on both core and extended components of the Asterisk project.


  • Information Requests: (How does X parameter work?)
    See the forums, mailing lists, IRC channels, or this wiki. For even more information, see
  • Support requests: (My phone doesn't register! My database connectivity doesn't work! How do I get it to work?)
    Search and ask on the forums, mailing lists, and IRC. Again, see for more information.
  • Random wishes and feature requests with no patch: (I want Asterisk to support <insert obscure protocol or gadget>, but I don't know how to code!)
    See the How to request a feature section for more information on requesting a feature.
  • Business development requests (I will pay you to make Asterisk support fancy unicorn protocol!)
    Please head to the asterisk-biz mailing list at If what you want is a specific feature or bug fixed, you may want to consider requesting a bug bounty.
  • and...

Security vulnerability issues must NEVER be reported as regular bugs in the issue tracker. Instead they must be reported at Security Vulnerabilities. You can reach this page by navigating to and clicking the "Security" tab at the top of the page.


Why should you read this?


  • Are you reporting a suspected security vulnerability?
    Please stop! The issue tracker is public, and once a security vulnerability is made public on the issue tracker, all users of Asterisk are made vulnerable. Please see Asterisk Security Vulnerabilities for more information on reporting a suspected security vulnerability.
  • Are you are on a supported version of Asterisk?
    See the Asterisk Versions page for the currently supported versions of Asterisk. Bugs reported against versions of Asterisk that are no longer supported will be closed, and you will be asked to reproduce the issue against a supported version.
  • Are you using the latest version of your Asterisk branch?
    Please check the release notes for newer versions of Asterisk to see if there is a potential fix for your issue. Even if you can't identify a fix in a newer version, it is preferable that you upgrade when reasonable to do so. Release notes are available in the UPGRADE.txt, CHANGES and ChangeLog files within the root directory of your particular release, and are also available at
  • Are you using the latest third party software, firmware, model, etc?
    If the error scenario involves phones, third party databases or other software, be sure it is all up to date and check their documentation.
  • Have you asked for help in the community? (mailing lists, IRC, forums)
    You can locate all these services here:
  • Have you searched the Asterisk documentation in case this behavior is expected?
    Search the Asterisk wiki for the problem or messages you are experiencing.
  • Have you searched the Asterisk bug tracker to see if an issue is already filed for this potential bug?
    Search the Asterisk issue trackerIssue Tracker on GitHub for the issue you are seeing. You can search for issues by selecting Issues -> Search for Issues in the top menu bar.
  • Can you reproduce the problem?
    Problems that can't be reproduced can often be difficult to solve, and your issue may be closed if you or the bug marshals cannot reproduce the problem. If you can't find a way to simulate or reproduce the issue, then it is advisable to configure your system such that it is capturing relevant debug during the times failure occurs. Yes, that could mean running debug for days or weeks if necessary.


You'll report the issue through the tracker (, under the ASTERISK project.asterisk/issues)

  1. Sign up for an account
    Account signup for community services (including JIRA, Confluence and FishEye/Crucible) can be found GitHub account
    If you don't already have a GitHub account, sign up for one now at
  2. Create a new issue in the tracker
    Select the Create Issue button in the top right hand corner of the page. This will prompt you for the project and issue type. Pick the ASTERISK project, and Navigate to and click on the 'New Issue" button at the top right, then choose an appropriate issue type. The following are the supported issue types:

    • Bug

    • New feature

    • Improvement

      TipPlease do not select the Information request issue type. This type is not currently used, and your issue is likely to be closed or redefined.
    • Report a security vulnerability (note, this WILL take you to the secure reporting facility mentioned in the warning above)

  3. Fill out the issue form
    For a bug you must include the following information:

    • Concise and descriptive summary

      • Accurate and descriptive, not prescriptive. Provide the facts of what is happening and leave out assumptions as to what the issue might be.

      • Good example: "Crash occurs when exactly twelve SIP channels hang up at the same time inside of a queue"

      • Bad Examples: "asterisk crashes" , "problem with queue", "asterisk doesn't work", "channel hangups cause crash"

    • Operating System detail (Linux distribution, kernel version, architecture etc)

    • Asterisk version (exact branch and point release, such as

    • Information on any third party software involved in the scenario (database software, libraries, etc)

    • Frequency and timing of the issue (does this occur constantly, is there a trigger? Every 5 minutes? seemingly random?)

    • Symptoms described in specific detail ("No audio in one direction on only inbound calls", "choppy noise on calls where trans-coding takes place")

    • Steps required to reproduce the issue (tell the developer exactly how to reproduce the issue, just imagine you are making steps for a manual)

    • Workarounds in detail with specific steps (if you found a workaround for a serious issue, please include it for others who may be affected)

    • Debugging output - You'll almost always want to include extensions.conf, and config files for any involved component of Asterisk. Depending on the issue you may also need the following:

      • For crashes, provide a backtrace generated from an Asterisk core dump. See Getting a Backtrace for more information.

      • For apparent deadlocks, you may need to enable the compile time option DEBUG_THREADS. A backtrace may also be necessary. See Getting a Backtrace for more information.
      • For memory leaks or memory corruptions, Valgrind may be necessary. Valgrind can detect memory leaks and memory corruptions, although it does result in a substantial performance impact.
      • For debugging most problems, a properly generated debug log file will be needed. See CLI commands useful for debugging and Collecting Debug Information for more information. Note that for issues involving SIP, IAX2, or other channel drivers, you should enable that driver's enhanced debug mode through the CLI before collecting information. A pcap demonstrating the problem may also be needed.


        Be courteous. Do not paste long debug output in the description or a comment, instead please attach any debugging output as text files and reference them by file name.

  4. Submit the Issue
    Once you have created the issue, you can now attach debug as files. You are ready to wait for a response from a bug marshal or post additional information as comments. If you are responding to a request for feedback, be sure to use the workflow actions to "send back" the status to the developers.

How you can speed up bug resolution

Follow the checklist and include all information that bug marshals require. Watch for emails where a bug marshal may ask for additional data and help the developers by testing any patches or possible fixes for the issue. A developer cannot fix your issue until they have sufficient data to reproduce - or at the very least understand - the problem.