Commit graph

2 commits

Author SHA1 Message Date
Richard Mudgett
1dfa11b65c PJPROJECT logging: Made easier to get available logging levels.
Use of the new logging is as simple as issuing the new CLI command or
setting the new pjproject.conf option.

Other options that can affect the logging are how you have the pjproject
log levels mapped to Asterisk log types in pjproject.conf and if you have
configured Asterisk to log the DEBUG type messages.  Altering the
pjproject.conf level mapping shouldn't be necessary for most installations
as the default mapping is sensible.  Configuring Asterisk to log the DEBUG
message type is standard practice for collecting debug information.

* Added CLI "pjproject set log level" command to dynamically adjust the
maximum pjproject log message level.

* Added CLI "pjproject show log level" command to see the currently set
maximum pjproject log message level.

* Added pjproject.conf startup section "log_level" option to set the
initial maximum pjproject log message level so all messages could be
captured from initialization.

* Set PJ_LOG_MAX_LEVEL to 6 to compile in all defined logging levels into
bundled pjproject.  Pjproject will use the currently set run time log
level to determine if a log message is generated just like Asterisk
verbose and debug logging levels.

* In log_forwarder(), made always log enabled and mapped pjproject log
messages.  DEBUG mapped log messages are no longer gated by the current
Asterisk debug logging level.

* Removed RAII_VAR() from res_pjproject.c:get_log_level().

ASTERISK-26630 #close

Change-Id: I6dca12979f482ffb0450aaf58db0fe0f6d2e5389
2016-11-30 13:11:48 -06:00
George Joseph
f8767a8804 res_pjproject: Add ability to map pjproject log levels to Asterisk log levels
Warnings and errors in the pjproject libraries are generally handled by
Asterisk.  In many cases, Asterisk wouldn't even consider them to be warnings
or errors so the messages emitted by pjproject directly are either superfluous
or misleading.  A good exampe of this are the level-0 errors pjproject emits
when it can't open a TCP/TLS socket to a client to send an OPTIONS.  We don't
consider a failure to qualify a UDP client an "ERROR", why should a TCP/TLS
client be treated any differently?

A config file for res_pjproject has bene added (pjproject.conf) and a new
log_mappings object allows mapping pjproject levels to Asterisk levels
(or nothing).  The defaults if no pjproject.conf file is found are the same
as those that were hard-coded into res_pjproject initially: 0,1 = LOG_ERROR,
2 = LOG_WARNING, 3,4,5 = LOG_DEBUG<level>

Change-Id: Iba7bb349c70397586889b8f45b8c3d6c6c8c3898
2016-02-18 16:30:29 -06:00