How to report a problem with sipXecs

From SIPfoundry sipXecs IP PBX, The Open Source SIP PBX for Linux - Calivia

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

Contents 1 Prepare 2 Ask on the list 3 Use the Issue Tracker

Prepare

Make sure that you have searched this wiki for relevant information, and search the mailing list archives. Some people find it easier to do this using the gmane archives.

Ask on the list

Try asking about your problem on one of the mailing lists:

• If your problem is with how to use the system, ask on the sipx-users list.

• If your problem is with how to write code for the system, ask on the sipx-dev list.

For either list, you must be subscribed to the list and send from the subscribed address. There are limits on the size of postings, so don't post multi-megabyte images or logs because your mail will be automatically rejected.

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 wanted immediate answers you should have paid someone to get them. In general, the more carefully and nicely you ask, the quicker and more useful the answer will be.

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 createing 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 GMT, 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.

The workflow is illustrated below. Things in green are usually the Reporter, things in blue are usually the project coordinator, and things in orange are usually some developer .

The first two states are for issues that are new, or at least have not yet been acted on in some way:

New

This is the initial state for all issues. An issue in this state has not yet be reviewed. Someone (usually the project coordinator, but it can be any developer), will review it and either assign it back to the Reporter to ask for more information (which moves it to Need Information state), Resolve it (if the right answer can be determined right away), or Accept it (which moves it to Open state).

Accepted

This state means that the issue appears to be described well enough that it is possible to start work on it. It does not necessarily mean that anyone is doing that work yet - for that, watch the Assigned To field and the Fix For Release field. Those fields cannot be set when the issue is Created - that can happen only during the review and acceptance process.

The next three states indicate that there is some kind of activity:

Need Information

This state means that something more is needed before any further progress can be made on the issue. Often, the issue has been assigned back to the Reporter when it is moved to this state, but it might be someone else who has essential input. If an issue assigned to you is in this state, you can Reopen it when you provide the information, which will move it back to New state (where it will once again go through the review process).

In Progress

This state means that some developer is actively working on the issue. Again - it may not represent a commitment to fix it (see above).

Patch Pending

This state means that someone other than a developer (maybe even you) has attached a proposed fix to the issue. This is similar to the New state in that it indicates that review by a developer is needed. If it stays in this state too long, send email to the project coordinator or the sipx-dev list to call attention to it, but please be patient. The reviewer may apply the patch and move the issue to Resolved state, or may request that the submitter change it in some way (which moves the issue back to Accepted state).

The last two states are the goal states:

Resolved

This state indicates that the reviewer or developer believes that the issue has been adequately addressed. Normally, the issue is Assigned back to the Reporter when moved to this state to see if the Reporter agrees; if so, the Reporter should Close the issue - if not, Reopen it.

Closed

The final state - the issue is done and nothing further need happen.