This is a set of hints on how to more effectively report bugs in sipXecs/SCS. It is more oriented toward problems with call handling than problems with the configuration system, but many of the hints are good for both.
First, there is a great essay on writing bug reports: "How to Report Bugs Effectively" by Simon Tatham http://www.chiark.greenend.org.uk/~sgtatham/bugs.html More specifically for sipXecs/SCS: - Identify and describe a specific instance of the failure. Naturally, you think that figuring out the exact extent of the problem and describing it is the best sort of bug report. E.g., "Every time I call from extension 1234 to 100 the call doesn't go through." Unfortunately this is not so; the best report is a report of a *specific failure instance*. E.g., "At 19:43:24Z, I called from extension 1234 to 100 and the call didn't go through." The reason for this is that the way we determine the cause of the failure is to look through the log files to see how a specific failure happened, and the more closely you identify a specific failure instance, the less work we have to do to locate one. Of course, you should describe as concretely as possible what you did, what you expected to happened, and what did happen. If you think you understand the exact extent of the problem, please include that, but only as *additional* information. - Include a snapshot of sipXecs. Naturally, you provide the log of the component that is responsible for the feature that is failing. Unfortunately, that is usually not the component that is causing the failure. Since we can't determine the logs that we will need to examine before we examine the logs, the only efficient method is to include all the logs. And the sipx-snapshot program is designed to do exactly that, along with a lot of other information that might be necessary for the diagnosis. - Include all the logs if you can. Naturally, you take advantage of sipXconfig's offer to trim the logs to the minute or two around the point of failure. Unfortunately, the time when the problem started may be well before the time of the failure. If it doesn't generate a snapshot file that is too large to handle, it's best to give sipx-snapshot no time restriction, that is, to include the entire day's logs. If that isn't possible, including the last 2 hours of logs is usually sufficient. - Set all the logs to DEBUG level. The more information in the logs, the easier to determine exactly what has gone wrong. The default logging level is WARNING, which is insufficient for debugging most problems. If the logs do not become unmanageably large, use DEBUG level, and use it on *all* the logs. If that is a problem, use INFO level, which at least includes all of the SIP message traffic, and will at least allow us to determine which component is malfunctioning. - Identify phones by extension number or IP address. There is a tendency for people to identify phones by their make and model, especially in testing situations where the phone's assigned extension number may change frequently. Unfortunately, SIP doesn't carry phone make/model information effectively. But it does carry extension numbers and IP addresses effectively. So describe phones by their extension numbers, or if multiple phones have the same extension number, describe them by their IP addresses. - Identify calls by when they happened, and their origin and destination. It is easiest to locate calls in log files by knowing the time the call happened and its origin phone. So providing an accurate time when the call happened and the phone from which it originated is most helpful. And your description should always include the number that was dialed, which also helps us confirm that we've identified the correct call. Alternatively, you can identify calls by their Call-Id values, preferably in conjunction with the time of the call, but for most people, that is more difficult to do. Note that the logs are kept in Universal Time Coordinated (UTC, also known as Greenwich Mean Time, GMT), which is a 24-hour clock. UTC times are often marked by a suffix "Z". So "19:43:24Z" means 7:43pm and 24 seconds, UTC. If you provide times in your local time, we have to figure out what time zone you are in, which is not always easy, and then translate the time into UTC. You can always get the UTC time by executing the command "date -u" on your sipXecs system. Please use the server's time, or the time on another system you *know* is kept correct by NTP. It is tempting to use the time reported on a phone's display or by your watch, but those are often incorrect, and rarely give time down to the second. Also, please report times to the second, as one can make a number of phone calls within a single minute. Dale _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
