<div dir="ltr">Sorry if I confused you, but I tested my code with concurrent calls happening at the same time and I'm able to get the UniqueId ( associated with a call) in every log line ( associated with that call )  for every call that was happening.<div><br></div><div>What I meant is, I've tested my approach with multiple calls and the unique id that is generated for each call are printed in the logs associated to that call. </div><div>So what do you think? </div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 3, 2018 at 5:49 PM Richard Mudgett <<a href="mailto:rmudgett@digium.com">rmudgett@digium.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 3, 2018 at 3:49 AM, Balraj Singh <span dir="ltr"><<a href="mailto:balraj.singh@zemosolabs.com" target="_blank">balraj.singh@zemosolabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<div>1) This Call-Identifier variable gets reset after we shut down asterisk and starts again from C-00000001.</div><div>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.</div><div>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.</div><div><br></div><div>Hence, we had to re-implement this functionality to suffice our needs. So, please kindly can you re-verify our approach to this.</div></div><div class="m_4475865047697085483HOEnZb"><div class="m_4475865047697085483h5"><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 3, 2018 at 2:32 AM Richard Mudgett <<a href="mailto:rmudgett@digium.com" target="_blank">rmudgett@digium.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>You are trying to reimplement callid[1] which has been in Asterisk since v11.  Callid</div><div> is accessible from dialplan using CHANNEL(callid)[2].  Accessibility from the</div><div> dialplan has been in Asterisk 13 since 13.15.0 and in Asterisk 15 since it was first</div><div> released. The callid is created when the incoming channel goes into dialplan not</div><div> when it is bridged.</div><br><div>As to the approach.  You do know that Asterisk is multi-threaded and can handle</div><div> more than one call at a time?  Using a simple global variable sets the uniqueid</div><div>for ALL log messages regardless of whether that message has anything to do with</div><div> the channel of that uniqueid.<br></div></div></blockquote></div></div></div></blockquote><div><br></div><div>Nothing has changed.  It is not a good approach.  Your code assumes that there is one</div><div>and only one call happening at a time.  You have to associate the uniqueid with EVERY</div><div> log message when the log message is posted just like callid does.  This was why the callid</div><div>patch was so large.<br></div><br><div>Richard</div><br></div></div></div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>