In 5.2
setflag(TRACE); sip_trace();
traces both requests and responses. In master, only requests.
Please fix.
-- Juha
It is about storing in database? Or also mirroring?
Cheers, Daniel
On 29.09.19 09:05, Juha Heinanen wrote:
In 5.2
setflag(TRACE); sip_trace();traces both requests and responses. In master, only requests.
Please fix.
-- Juha
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Can you try with latest master? I pushed a commit that hopefully fixes it.
On the other hand, the use of flag looks like no longer necessary if tracing mode parameter is set to 't'. Would it be acceptable to just add a new function sip_trace_mode() that will accept one parameter to specify what to track (message, transaction, dialog)? It would be a short form of sip_trace() with 3 parameters, when the two are not needed. I think it would be more coherent for the future to get rid of using also the message flag for tracking the transaction.
Cheers, Daniel
On 30.09.19 18:00, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It is about storing in database? Or also mirroring?
Storing to db. Don't know about mirroring.
-- Juha
Daniel-Constantin Mierla writes:
Can you try with latest master? I pushed a commit that hopefully fixes it.
It works now.
On the other hand, the use of flag looks like no longer necessary if tracing mode parameter is set to 't'. Would it be acceptable to just add a new function sip_trace_mode() that will accept one parameter to specify what to track (message, transaction, dialog)? It would be a short form of sip_trace() with 3 parameters, when the two are not needed. I think it would be more coherent for the future to get rid of using also the message flag for tracking the transaction.
For me it would be best and simplest if tracing of all request and responses would happen automatically when siptrace module is loaded and suitable parameters are set and when tracing is turned on via an rpc command, i.e., without any function calls in the config.
If that cannot be achived and a function call is needed, one must be enough.
-- Juha
Juha Heinanen writes:
For me it would be best and simplest if tracing of all request and responses would happen automatically when siptrace module is loaded and suitable parameters are set and when tracing is turned on via an rpc command, i.e., without any function calls in the config.
If that cannot be achived and a function call is needed, one must be enough.
So, load siptrace module, set params appropriately, and call a function:
trace_request_or_response_if_tracing_is_enabled_by_rpc_command();
This function should not have any parameters, because they would need to be parsed for vain if tracing is not enabled.
-- Juha
On 30.09.19 21:25, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Can you try with latest master? I pushed a commit that hopefully fixes it.
It works now.
On the other hand, the use of flag looks like no longer necessary if tracing mode parameter is set to 't'. Would it be acceptable to just add a new function sip_trace_mode() that will accept one parameter to specify what to track (message, transaction, dialog)? It would be a short form of sip_trace() with 3 parameters, when the two are not needed. I think it would be more coherent for the future to get rid of using also the message flag for tracking the transaction.
For me it would be best and simplest if tracing of all request and responses would happen automatically when siptrace module is loaded and suitable parameters are set and when tracing is turned on via an rpc command, i.e., without any function calls in the config.
There is a parameter trace_mode which can turn on automatic capture of all sip messages, but is for mirroring the traffic. Probably, for the next major release, it should be extended to do the save in the database as well, if that is wanted via some modparam.
There is also a rpc command to turn tracinf on/off, but it doesn't affect the trace_mode=1. Again, for the next major release we should revise and make those options work for all variants: mirroring or save to db, with control via modparams and rpc...
If that cannot be achived and a function call is needed, one must be enough.
I will add a new function that will have a parameter to specify what to track and remove the flag parameter.
Cheers, Daniel
Daniel-Constantin Mierla writes:
There is a parameter trace_mode which can turn on automatic capture of all sip messages, but is for mirroring the traffic. Probably, for the next major release, it should be extended to do the save in the database as well, if that is wanted via some modparam.
That is what I just asked before reading this. It would make sense that independent of hep, trace_mode=1 would cause tracing of all messages.
There is also a rpc command to turn tracinf on/off, but it doesn't affect the trace_mode=1. Again, for the next major release we should revise and make those options work for all variants: mirroring or save to db, with control via modparams and rpc...
... and rpc command would be effective too.
-- Juha
Actually, if you set the tracing mode and also the flag, you will get duplicated packets! I lived through that a few days ago :)
On Mon, 30 Sep 2019 at 19:22, Daniel-Constantin Mierla miconda@gmail.com wrote:
Can you try with latest master? I pushed a commit that hopefully fixes it.
On the other hand, the use of flag looks like no longer necessary if tracing mode parameter is set to 't'. Would it be acceptable to just add a new function sip_trace_mode() that will accept one parameter to specify what to track (message, transaction, dialog)? It would be a short form of sip_trace() with 3 parameters, when the two are not needed. I think it would be more coherent for the future to get rid of using also the message flag for tracking the transaction.
Cheers, Daniel
On 30.09.19 18:00, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It is about storing in database? Or also mirroring?
Storing to db. Don't know about mirroring.
-- Juha
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training, Oct 21-23, 2019, Berlin, Germany -- https://asipto.com/u/kat
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
When trace_mode is 1, different callbacks are used for catching the sip traffic, so it doesn't disable the tracing based on flags. I will make it more clear in the docs.
Cheers, Daniel
On 30.09.19 23:27, David Villasmil wrote:
Actually, if you set the tracing mode and also the flag, you will get duplicated packets! I lived through that a few days ago :)
On Mon, 30 Sep 2019 at 19:22, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Can you try with latest master? I pushed a commit that hopefully fixes it. On the other hand, the use of flag looks like no longer necessary if tracing mode parameter is set to 't'. Would it be acceptable to just add a new function sip_trace_mode() that will accept one parameter to specify what to track (message, transaction, dialog)? It would be a short form of sip_trace() with 3 parameters, when the two are not needed. I think it would be more coherent for the future to get rid of using also the message flag for tracking the transaction. Cheers, Daniel On 30.09.19 18:00, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > >> It is about storing in database? Or also mirroring? > Storing to db. Don't know about mirroring. > > -- Juha -- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training, Oct 21-23, 2019, Berlin, Germany -- https://asipto.com/u/kat _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org <mailto:sr-dev@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev-- Regards,
David Villasmil email: david.villasmil.work@gmail.com mailto:david.villasmil.work@gmail.com phone: +34669448337
Hi Daniel,
I like your suggestion about replacing the flag option with a function. This duplication is IMHO another potential to confuse users, I see this for the dialog module also frequently (dlg_flag vs. dlg_manage() )
If this change is to late for 5.3.0 - we could consider it for the next development cycle.
Cheers,
Henning
Am 30.09.19 um 20:22 schrieb Daniel-Constantin Mierla:
Can you try with latest master? I pushed a commit that hopefully fixes it.
On the other hand, the use of flag looks like no longer necessary if tracing mode parameter is set to 't'. Would it be acceptable to just add a new function sip_trace_mode() that will accept one parameter to specify what to track (message, transaction, dialog)? It would be a short form of sip_trace() with 3 parameters, when the two are not needed. I think it would be more coherent for the future to get rid of using also the message flag for tracking the transaction.
Cheers, Daniel
On 30.09.19 18:00, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It is about storing in database? Or also mirroring?
Storing to db. Don't know about mirroring.
-- Juha
Hello,
given the changes done in the module to track the message, transaction or dialog, it should be fine to do this right now, because it is the testing period for 5.3, where it is supposed to clean up of issue and make coherent the new changes for this release. It is not like a new brand feature, only how an existing feature can be used in config.
Once there will be a release, removing the flag option won't be ok, because that can break existing configs in a stable release, right now we are still before such milestone.
Cheers, Daniel
On 01.10.19 10:11, Henning Westerholt wrote:
Hi Daniel,
I like your suggestion about replacing the flag option with a function. This duplication is IMHO another potential to confuse users, I see this for the dialog module also frequently (dlg_flag vs. dlg_manage() )
If this change is to late for 5.3.0 - we could consider it for the next development cycle.
Cheers,
Henning
Am 30.09.19 um 20:22 schrieb Daniel-Constantin Mierla:
Can you try with latest master? I pushed a commit that hopefully fixes it.
On the other hand, the use of flag looks like no longer necessary if tracing mode parameter is set to 't'. Would it be acceptable to just add a new function sip_trace_mode() that will accept one parameter to specify what to track (message, transaction, dialog)? It would be a short form of sip_trace() with 3 parameters, when the two are not needed. I think it would be more coherent for the future to get rid of using also the message flag for tracking the transaction.
Cheers, Daniel
On 30.09.19 18:00, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It is about storing in database? Or also mirroring?
Storing to db. Don't know about mirroring.
-- Juha
Hi Daniel,
sure - I was more referring to the timeline (tomorrow) then to the change in its self. ;-)
Cheers,
Henning
Am 01.10.19 um 10:39 schrieb Daniel-Constantin Mierla:
Hello,
given the changes done in the module to track the message, transaction or dialog, it should be fine to do this right now, because it is the testing period for 5.3, where it is supposed to clean up of issue and make coherent the new changes for this release. It is not like a new brand feature, only how an existing feature can be used in config.
Once there will be a release, removing the flag option won't be ok, because that can break existing configs in a stable release, right now we are still before such milestone.
Cheers, Daniel
On 01.10.19 10:11, Henning Westerholt wrote:
Hi Daniel,
I like your suggestion about replacing the flag option with a function. This duplication is IMHO another potential to confuse users, I see this for the dialog module also frequently (dlg_flag vs. dlg_manage() )
If this change is to late for 5.3.0 - we could consider it for the next development cycle.
Cheers,
Henning
Am 30.09.19 um 20:22 schrieb Daniel-Constantin Mierla:
Can you try with latest master? I pushed a commit that hopefully fixes it.
On the other hand, the use of flag looks like no longer necessary if tracing mode parameter is set to 't'. Would it be acceptable to just add a new function sip_trace_mode() that will accept one parameter to specify what to track (message, transaction, dialog)? It would be a short form of sip_trace() with 3 parameters, when the two are not needed. I think it would be more coherent for the future to get rid of using also the message flag for tracking the transaction.
Cheers, Daniel
On 30.09.19 18:00, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It is about storing in database? Or also mirroring?
Storing to db. Don't know about mirroring.
-- Juha
Daniel-Constantin Mierla writes:
given the changes done in the module to track the message, transaction or dialog, it should be fine to do this right now, because it is the testing period for 5.3, where it is supposed to clean up of issue and make coherent the new changes for this release. It is not like a new brand feature, only how an existing feature can be used in config.
Since this is quite a mess now (also RPC Commands section is confusing), it would be great if cleanup could be done before 5.3.
So trace_mode=1 and RPC commands should be effective also when HEP is not in use.
-- Juha
On 01.10.19 10:49, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
given the changes done in the module to track the message, transaction or dialog, it should be fine to do this right now, because it is the testing period for 5.3, where it is supposed to clean up of issue and make coherent the new changes for this release. It is not like a new brand feature, only how an existing feature can be used in config.
Since this is quite a mess now (also RPC Commands section is confusing), it would be great if cleanup could be done before 5.3.
The db storage and hep mirroring were developed independently, not expecting to have them in pair always, but based on this discussion, it seems you would like some of the capabilities from one tracing type to be also in the other.
However, it might be too complex to develop it at this moment, that's why I said it should be for next major release (5.4). Besides coding, it would require a discussion to see how people consider to be the right approach.
Cheers, Daniel
So trace_mode=1 and RPC commands should be effective also when HEP is not in use.
Daniel-Constantin Mierla writes:
The db storage and hep mirroring were developed independently, not expecting to have them in pair always, but based on this discussion, it seems you would like some of the capabilities from one tracing type to be also in the other.
Then also trace_mode should have been called hep_trace_mode.
And if RPC commands don't work when trace_mode == 1, README needs more editing.
-- Juha
-
Daniel-Constantin Mierla -
David Villasmil -
Henning Westerholt -
Juha Heinanen