On Tue, Mar 2, 2010 at 5:29 PM, Scott Lawrence <[email protected]> wrote: > On Tue, 2010-03-02 at 17:11 -0500, Mardy Marshall wrote: >> >> On Mar 2, 2010, at 4:45 PM, Scott Lawrence wrote: >> >> > I've added a wiki page on Logging: >> > >> > http://wiki.sipfoundry.org/display/xecsdev/Logging+Guidelines >> > >> > One thing I'd like to emphasize: >> > >> > We should do our logging so that INFO level is sufficient for >> > any user or support person to diagnose a configuration or >> > interoperability problem. >> > >> > The DEBUG level should be reserved for developer-level >> > information only - it is for finding bugs in the code, not >> > for >> > finding bugs in configuration or other vendors messages. >> > >> > Following the guidelines allows us to be very verbose (and we >> > already >> > are) at DEBUG level without creating logs that so big that they are >> > hard >> > to work with. >> > >> > Not all existing sipXecs code conforms to the above rules - if you >> > notice exceptions, then fix them or check with others to see if they >> > think that a change is needed. Don't raise an issue on every >> > instance - >> > we don't need that - just consult or post here and get on with it. >> > >> > I would like to have the configuration UI pop up a confirmation >> > dialog >> > when DEBUG is selected along the lines of: >> > >> > This level is intended only for developer use and is not >> > normally needed to diagnose a production release problem. It >> > will produce very large log files. Do you really want to do >> > this? >> > >> > Thoughts? >> > >> >> >> Keeping log file sizes to a minimum is a must. And since SIP trace >> messages can account for as much as 60% of log file content and are >> not used by support personnel, I would urge you to move them from INFO >> level back to DEBUG. > > There's no way to diagnose many configuration and especially > interoperability problems without the SIP messages. They most > emphatically are used by support people - note the fact that one of the > most common requests in our recent poll for simplification features was > an easier way to get SIP traces and display them with sipviewer.
An approach that used tcpdump and converted them to readable traces may be considered but that is not as good as the sip logs because tcpdump does not record auxiliary information that is often of interest. I'd say keep the message logging IN (the way it is) at INFO level loggng at least until we have developed a tool as good as sipviewer that can view traces based on tcpdump. Besides, tcpdump is probably more verbose unless the traces are carefully filtered. ( Still working on a regression test tool that can run off tcpdump but that's a long way into the future. ) > > > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
