Hello Dan.<br><br>I think I already understand. You are right.<br><br>So, what do you think whether I change the logic for the other idea I have, implementing a function which performs the tracing base in IP address? I think that feature is not already implemented.<br>
<br>Thanks and regards.<br><br>Sergio Gutierrez.<br><br><div class="gmail_quote">On Mon, Oct 27, 2008 at 2:50 PM, Dan Pascu <span dir="ltr"><<a href="mailto:dan@ag-projects.com">dan@ag-projects.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Monday 27 October 2008, Sergio Gutierrez wrote:<br>
</div><div class="Ih2E3d">> Hello Dan.<br>
><br>
> Thanks a lot for your feedback.<br>
><br>
> If I understand well the code, the approach using the avp is not<br>
> exclusive with the global tracing, so the whole messages get stored<br>
> into the table, at least that a different table be defined, as stated<br>
> in documentation;<br>
<br>
</div>I think there is a misunderstanding. While the AVP can be set even when<br>
global tracing is on, it makes little sense to do so, since all messages<br>
are logged anyway in that case.<br>
<br>
However if you only want to trace certain users, you can turn global<br>
tracing off and set the AVP. In this case only messages for that user<br>
will be traced.<br>
<br>
Maybe is not obvious from the docs, but the trace_on modparam only<br>
controls global tracing. You can set that to 0 and user tracing will<br>
still work if the AVP is set.<br>
<br>
The condition is like:<br>
<br>
if (trace_on || is_set_avp(traced_user_avp) { do_trace(); }<br>
<div><div></div><div class="Wj3C7c"><br>
><br>
> Although my approach does use the same table, it is thought to work in<br>
> an exclusive way, avoiding to trace the whole messages processed, and<br>
> storing only the messages of the users defined as traced.<br>
><br>
> Again thanks in advance for your attention, and I will be awaiting any<br>
> other suggestion you have.<br>
><br>
> Best regards.<br>
><br>
> Sergio Gutierrez.<br>
><br>
> On Mon, Oct 27, 2008 at 1:51 PM, Dan Pascu <<a href="mailto:dan@ag-projects.com">dan@ag-projects.com</a>> wrote:<br>
> > The siptrace module already has the ability to record messages for a<br>
> > given user, by setting an AVP. That avp can be read from a property<br>
> > in the subscriber table (automatically loaded when the subscriber is<br>
> > loaded or by putting a subscriber in a group or by loading it<br>
> > explicitly from a different table). The real problem is not the<br>
> > inability to do this already, is the fact that is difficult to do it<br>
> > for all messages within dialog. By making the siptrace module work on<br>
> > top of the dialog module to automatically trigger tracing all<br>
> > messages within a dialog once the dialog was marked for tracing, this<br>
> > issue should be solved.<br>
> ><br>
> > So what does you approach add in addition to the existing behavior<br>
> > that cannot be done already?<br>
> ><br>
> > On Monday 27 October 2008, Sergio Gutierrez wrote:<br>
> > > Hello to all members in the list.<br>
> > ><br>
> > > I would like to put on your consideration a contribution for the<br>
> > > siptrace module;<br>
> > ><br>
> > > My contribution consists in adding two new functions to module;<br>
> > > this contribution in particular is a new function called<br>
> > > sip_trace_user();<br>
> > ><br>
> > > This function would enable the trace of the sip requests originated<br>
> > > from a particular user, in the same as sip_trace() does it in a<br>
> > > global way. The param trace_user has to be defined as 1 to enable<br>
> > > the feature. The list of traced users would be stored on a table in<br>
> > > database, and this list could be reloaded or cleared at execution<br>
> > > time, by MI commands. sip_trace_user() uses the existing logic<br>
> > > within the module, and it was only necessary implement helper<br>
> > > functions for FROM USER URI manipulation, and the ones required to<br>
> > > handle the list (load , clear and reload).<br>
> > ><br>
> > > In the way that the function is currently implemented, it is<br>
> > > limited to 512 traced users simultaneously; the modification of<br>
> > > this limit would have to be performed at compilation time.<br>
> > ><br>
> > > The feature request has been registered on the tracker with the<br>
> > > number 2200068. Currently, the function is in BETA state, but it is<br>
> > > completely functional, and I have tested it on OpenSIPS trunk<br>
> > > version. It is pending to implement the MI commands to<br>
> > > enable/disable the tracing, and a command to clear the traced users<br>
> > > list.<br>
> > ><br>
> > > I would thank any comments, corrections or suggestions you have<br>
> > > regarding to this contribution. As it is my first one, I think<br>
> > > there must be a lot of things to improve.<br>
> > ><br>
> > > Thanks in advance all for your attention.<br>
> > ><br>
> > > Best regards.<br>
> > ><br>
> > > Sergio Gutierrez<br>
> ><br>
> > --<br>
> > Dan<br>
<br>
<br>
<br>
</div></div>--<br>
<font color="#888888">Dan<br>
</font></blockquote></div><br>