[sr-dev] siptrace inconsistency

[Daniel-Constantin Mierla]

Hello,

I think it is fine to merge those three commits to master as they solve
some of the reported issue. There is also some work planned to be done
for a global enable/disable tracing to database, so it makes sense to
have all the code in master for combined testing.

Regarding the negative ACK, maybe getting the invite transaction and
seeing if it is a failed transaction is an option. Or simply adding in
tm module a callback for negative ACK.

Cheers,
Daniel

On 03.04.20 13:48, Federico Cabiddu wrote:
> 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/b64b3f03a9c6b69587ca360465f091f873f7274b)
> 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/e28f464457eea47cc606c73cbfe4b30fcc8b542a)
> 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/080c6e07708f1964498a43e70c9b6240b5bdebcd)
> 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
> <federico.cabiddu at gmail.com <mailto:federico.cabiddu at 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
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20200405/50c82897/attachment.html>