Prepare

First, read the excellent essay How to Report Bugs Effectively. Then read it again. Really.

Make sure that you have searched this wiki for relevant information, and search the tracker if the issue already exists and also search the forum for relevant discussion.

If you don't find the answer to your question, then think hard about how to ask.

Post a Question in the SIPfoundry Forum

You need an account on the SIPfoundry infrastructure to post to the forum.

Remember everything you learned about How To Report Bugs Effectively when writing your email. Be nice. Be patient - everyone who ever posts to those lists has some other job to do - if you want immediate answers, there are commercial versions of sipXecs for which you can buy support. In general, the more carefully and nicely you ask, the quicker and more useful the answer will be.

If you include information from logs, it is best not to reformat them or post the prettier versions output by syslogviewer: instead, attach the log segment to your email. This keeps the email programs from line-wrapping or otherwise modifying the log data, which often interferes with tools developers use to examine and display them.

Use the Issue Tracker

If, after discussion on the list, it seems necessary to create an issue in the project tracker, then you can do that.

You must create an account in the tracker.

Create a New Issue. Be thorough - err on the side of putting in too much information, not too little. Use the sipx-snapshot tool (either through the sipXconfig user interface or as a shell command) to capture your configuration and attach it. If possible, before creating the snapshot:

  1. Reset the log level to at least INFO (this provides message tracing) on the component(s) involved in the problem - always include the sipXproxy and the registrar (since they are involved in just about everything).
  2. Stop the sipXecs services and delete (or move aside) the existing log files (${prefix}/var/log/sipxpbx/*.log)
  3. Start the sipXecs services
  4. Reproduce the problem.
  5. Identify the call(s) that show the problem: the best identification is the call-id value, but the calling and called addresses (phone numbers) and a precise time are OK. (Record the time in UTC, as that is how time is recorded in the log files.)
  6. Create the sipx-snapshot and attach it to your issue.

If your system does not have a large disk, you may want to change your log level back to the default NOTICE level after this; the INFO level logs can get big pretty fast on a busy system.

You can see how your issue is progressing by watching its Status. If you used a valid email address when you created your account (you did, didn't you?), then you'll get email whenever the issue is updated. Because you created the issue, you have special status with respect to it - you are the Reporter.

Special Note if this is a security related issue:

Please also set the 'Security' level in the New Issue to 'Security Issue'.  If this problem affects current users, we want to fix the issue as soon as possible, and not expose existing installations to additional danger until it is fixed.  Please see special information on security at http://wiki.sipxcom.org/display/sipXecs/Security+Team

The workflow is illustrated below. The nodes are Issue States, and the arrows between them are Transitions.

The first couple of states are for issues that are new, or at least have not yet been acted on in some way and implement the community development process:

New

IceBox

Open

Reproduce

Community

Need Information

Patch Pending

 

The next four states reflect the development process:

Backlog

Awaiting Development

 

In Progress

Code Review

 

These two states reflects the QA process:

Awaiting QA

Testing in Progress

Reopened

 

The last two states are the goal states:

Resolved

Closed