[asterisk-dev] Regarding Unique Id In Logs

[Richard Mudgett]

On Tue, Jul 3, 2018 at 3:49 AM, Balraj Singh <balraj.singh at zemosolabs.com>
wrote:

> Thank you for your suggestion, We initially considered only using Call-id
> as unique id to grep the logs. But there were several reason for us not to:
> 1) This Call-Identifier variable gets reset after we shut down asterisk
> and starts again from C-00000001.
> 2) We're using CDR and unique-id by default as it is saved in CDR table
> and so we can take unique id from cdr to grep the logs.
> 3) We needed unique-id to be in every log line e.g. executing Dialplan
> applications, sip debug logs, rtp streaming logs, etc. So to achieve this
> customisation, we had to modify logger.c file to easily grep the logs
> related to a call using that id, so that we can trace / debug it if some
> error occurs.
>
> Hence, we had to re-implement this functionality to suffice our needs. So,
> please kindly can you re-verify our approach to this.
>
> On Tue, Jul 3, 2018 at 2:32 AM Richard Mudgett <rmudgett at digium.com>
> wrote:
>
>> You are trying to reimplement callid[1] which has been in Asterisk since
>> v11.  Callid
>> is accessible from dialplan using CHANNEL(callid)[2].  Accessibility from
>> the
>> dialplan has been in Asterisk 13 since 13.15.0 and in Asterisk 15 since
>> it was first
>> released. The callid is created when the incoming channel goes into
>> dialplan not
>> when it is bridged.
>>
>> As to the approach.  You do know that Asterisk is multi-threaded and can
>> handle
>> more than one call at a time?  Using a simple global variable sets the
>> uniqueid
>> for ALL log messages regardless of whether that message has anything to
>> do with
>> the channel of that uniqueid.
>>
>
Nothing has changed.  It is not a good approach.  Your code assumes that
there is one
and only one call happening at a time.  You have to associate the uniqueid
with EVERY
log message when the log message is posted just like callid does.  This was
why the callid
patch was so large.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180703/7664f62b/attachment.html>