Hi Federico, were the received ack and cancel captured automatically in the old version when sip trace was set for invite? There were many changes in the past years, but I remember that the flag was mainly for outgoing requests and matching replies of the transaction for which the flag was set. For incoming requests sip_trace() function had to be used. Based on your remark, I think that trace_tm_neg_ack_in() should not check if the trace-is-off(). It should be set when trace-is-on and that's it for the transaction. Feel free to clarify (or propose) the wanted behaviour and then we can work together to have it as expected. I used sip trace lately for tracing all traffic (trace_mode=1), no longer doing any filtering for transactions/dialogs. Cheers, Daniel On 31.03.20 09:09, Federico Cabiddu wrote: Hi all, I've been recently testing 5.3.x/master siptrace module, in particular the new trace mode "t" vs the legacy flag + sip_trace() mode and I've found some issues with the handling of CANCEL. Specifically, I've tested the following scenarios: 1) sip_trace_mode("t") on the initial INVITE only: received ACK for negative replies not captured 2) sip_trace_mode("t") on the initial INVITE and on neg ACK: received ACK captured twice 3) setflag and sip_trace() on the initial INVITE only: received CANCEL and ACK not captured (outgoing yes) 4) setflag and sip_trace() on the initial INVITE and ACK: received CANCEL not captured, received ACK captured twice 5) setflag and sip_trace() for each message (legacy): received CANCEL and 200 captured twice, received ACK captured twice Digging into the module's code the "culprit" looks to be trace_is_off function ( https://github.com/kamailio/kamailio/blob/2768f8ce1cf6da242674e7e40c8e76eb6…) and the places where it is called. E.g.: for the case 1), when a negative reply is received, trace_tm_neg_ack_in is called, which calls inside trace_is_off ( https://github.com/kamailio/kamailio/blob/2768f8ce1cf6da242674e7e40c8e76eb6…), which cannot be true unless the ACK has been marked for capture in the script, in which case it will be capture twice (case 2). The same applies to the CANCEL for case 3), in trace_onreq_out (callback for TMCB_E2ECANCEL_IN) trace_is_off because the incoming message is not flagged. Case 3) should theoretically behave like case 1) according to commit https://github.com/kamailio/kamailio/commit/40e09d8625184f19ff5666a2848cbb8… . I'm not really sure if (and how) modify the trace_is_off function or not calling it in specific cases. E.g.: why calling it in trace_tm_neg_ack_in? This callback is set when we explicity want to trace a transaction, so why checking inside if tracing is on? Maybe I'm missing something, but I think that probably the different behaviors of the modes should be better specified/decided. Best regards, Federico _______________________________________________ Kamailio (SER) - Development Mailing Listsr-dev@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev -- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda

OK, indeed, the previous behaviour should be preserved in this case. Is sip_trace() without params now doing transaction mode capturing?

Hi, Yes and no. Transaction mode is activated but actual behavior is not exactly the same (see case 3) vs case 1)). Cheers, Federico

Federico Cabiddu writes: My feeedback as a K user is this: I would prefer capability to turn on/off tracing of all messages (requests/replies) that enter/leave K via an rpc command rather than by setting the flag and calling sip_trace() in the config.

I could then do transaction/dialog/whatever level post-processing of the traffic based on the records in the database and I don't need any help from K regarding that.

Daniel-Constantin Mierla writes: I would be delighted to test siptrace module RPC on/off capability.

Daniel-Constantin Mierla writes: Thanks for the new feature. I tested and it worked OK. In the config I used modparam("siptrace", "trace_on", 0) so that tracing is by default off when K starts.

Hi all, following the feedback I just pushed a branch (https://github.com/kamailio/kamailio/tree/grumvalski/siptrace_flag_fixes), which tries to address the issues discussed. I've tried to split the commits so that each issue is handled separately. With the first commit (https://github.com/kamailio/kamailio/commit/b64b3f03a9c6b69587ca360465f091f…) I fixed the incoming ACK for negative replies tracing: as discussed it makes no sense to check in the callback if tracing is enabled or not. The second commit (https://github.com/kamailio/kamailio/commit/e28f464457eea47cc606c73cbfe4b30…) refactors the e2e CANCEL handling. With the previous implementation the incoming CANCEL captured would have the ANYADDR set as destination address. This commit also allows to have exactly the same behavior between transaction tracing (sip_trace_mode("t")) and legacy tracing (setflag + sip_trace()) when tracing a specific INVITE. With the third (https://github.com/kamailio/kamailio/commit/080c6e07708f1964498a43e70c9b624…) I've tried as much as possible to restore the legacy behavior when tracing all the requests without having duplicated captures for CANCEL and ACK for negative replies. I could achieve this for the CANCEL checking if the INVITE it refers to is already being traced (meaning that the CANCEL will be captured by the callback) but I couldn't for the ACK. I couldn't find a way to check if the ACK is for a negative reply (and thus it belongs to a transaction), without having the tm callbacks for ACK run, since both t_check and t_check_trans tm calls run the E2ECANCEL_IN callbacks. I've tried different scenarios in both capturing modes (transaction and flag+trace): 1) Successful call (INVITE-200-ACK) 2) Error replied 3) Canceled call 4) locally generated CANCEL (timeout) All looks good (except for the ACK issue) in both modes. I would like to have the developers' feedback before opening a PR, there could be other scenarios/use cases I'm not considering here. Thank you all. Cheers, Federico On Wed, Apr 1, 2020 at 2:45 PM Federico Cabiddu &lt;federico.cabiddu(a)gmail.com <mailto:federico.cabiddu@gmail.com>> wrote: Hi, OK, indeed, the previous behavior should be preserved in this case. Is sip_trace() without params now doing transaction mode capturing? Yes and no. Transaction mode is activated but actual behavior is not exactly the same (see case 3) vs case 1)).  Cheers, Federico