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/2768f8ce1cf6da242674e7e40c8e76eb6c...) 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/2768f8ce1cf6da242674e7e40c8e76eb6c...), 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/40e09d8625184f19ff5666a2848cbb8c... .
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
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:
- 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/2768f8ce1cf6da242674e7e40c8e76eb6c...) 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/2768f8ce1cf6da242674e7e40c8e76eb6c...), 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/40e09d8625184f19ff5666a2848cbb8c....
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 List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Hi Daniel, thanks for the feedback. About your questions: received ACK and CANCEL were not captured in old versions of the module, so no changes from this point of view. But tracing and flagging every request would work without duplicated messages. Something like this
request_route { .... if (!is_method("OPTIONS")) { setflag(CAPTURE_FLAG); sip_trace(); } }
I would expect the legacy behavior preserved, but I need to check better the code to understand how to do. If not possible we should add it to the documentation. I will make some tests removing the trace_is_off check for the negative ACK and make a PR. Finally I think that we also should align case 3) (siptrace + flag) with case 1) (transaction tracing) so that the behavior is the same (as I think was the intention originally). What do you and other devs think?
Cheers,
Federico
On Tue, Mar 31, 2020 at 4:25 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
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:
- 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/2768f8ce1cf6da242674e7e40c8e76eb6c...) 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/2768f8ce1cf6da242674e7e40c8e76eb6c...), 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/40e09d8625184f19ff5666a2848cbb8c... .
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
Hello,
On 01.04.20 10:18, Federico Cabiddu wrote:
Hi Daniel, thanks for the feedback. About your questions: received ACK and CANCEL were not captured in old versions of the module, so no changes from this point of view. But tracing and flagging every request would work without duplicated messages. Something like this
request_route { .... if (!is_method("OPTIONS")) { setflag(CAPTURE_FLAG); sip_trace(); } }
I would expect the legacy behavior preserved, but I need to check better the code to understand how to do. If not possible we should add it to the documentation.
OK, indeed, the previous behaviour should be preserved in this case. Is sip_trace() without params now doing transaction mode capturing?
I will make some tests removing the trace_is_off check for the negative ACK and make a PR.
OK, thanks for digging into it.
Finally I think that we also should align case 3) (siptrace + flag) with case 1) (transaction tracing) so that the behavior is the same (as I think was the intention originally). What do you and other devs think?
I am fine with this.
Cheers, Daniel
Cheers,
Federico
On Tue, Mar 31, 2020 at 4:25 PM Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
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/2768f8ce1cf6da242674e7e40c8e76eb6c630f6b/src/modules/siptrace/siptrace.c#L66) 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/2768f8ce1cf6da242674e7e40c8e76eb6c630f6b/src/modules/siptrace/siptrace.c#L1661), 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/40e09d8625184f19ff5666a2848cbb8c6212db26. 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 List sr-dev@lists.kamailio.org <mailto:sr-dev@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev-- 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>
Daniel-Constantin Mierla writes:
OK, indeed, the previous behaviour should be preserved in this case. Is sip_trace() without params now doing transaction mode capturing?
If I remember correctly, there was discussion about this a few months ago.
Behavior of
modparam("siptrace", "db_url", "MYSQL_SIP_PROXY_USAGE_URL") modparam("siptrace", "trace_flag", TRACE) ... setflag(TRACE); sip_trace();
should be what it has been for many years.
-- Juha
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/b64b3f03a9c6b69587ca360465f091f8...) 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/e28f464457eea47cc606c73cbfe4b30f...) 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/080c6e07708f1964498a43e70c9b6240...) 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@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
Federico Cabiddu writes:
I would like to have the developers' feedback before opening a PR, there could be other scenarios/use cases I'm not considering here.
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.
-- Juha
On 03.04.20 16:41, Juha Heinanen wrote:
Federico Cabiddu writes:
I would like to have the developers' feedback before opening a PR, there could be other scenarios/use cases I'm not considering here.
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.
That might not be that complex to do, right now all traffic can be mirrored via HEP by setting the trace_mode parameter. If someone wants to test it, I can extend it when I get a bit of time during the next few days with an option to write the traffic to database, controlled to turn/on off by the rcp command (already available).
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.
I guess that this kind of filtering is needed for instances with a lot of traffic, where mirroring everything can become a big overhead. Having support for such filtering doesn't exclude to have the above variant (which is simpler -- again, most of it already implemented for HEP mirroring).
Cheers, Daniel
Daniel-Constantin Mierla writes:
That might not be that complex to do, right now all traffic can be mirrored via HEP by setting the trace_mode parameter. If someone wants to test it, I can extend it when I get a bit of time during the next few days with an option to write the traffic to database, controlled to turn/on off by the rcp command (already available).
I would be delighted to test siptrace module RPC on/off capability.
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.
I guess that this kind of filtering is needed for instances with a lot of traffic, where mirroring everything can become a big overhead. Having support for such filtering doesn't exclude to have the above variant (which is simpler -- again, most of it already implemented for HEP mirroring).
Yes, I agree that there are situations where filtering by K is needed.
-- Juha
On 04.04.20 08:46, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
That might not be that complex to do, right now all traffic can be mirrored via HEP by setting the trace_mode parameter. If someone wants to test it, I can extend it when I get a bit of time during the next few days with an option to write the traffic to database, controlled to turn/on off by the rcp command (already available).
I would be delighted to test siptrace module RPC on/off capability.
Can you try the master branch with trace_on=1 and trace_mode=2 for siptrace module? You need to set also the db connection parameters, otherwise no siptrace flag set or function use in routing blocks. See also the docs of trace_mode param.
Cheers, Daniel
Daniel-Constantin Mierla writes:
Can you try the master branch with trace_on=1 and trace_mode=2 for siptrace module? You need to set also the db connection parameters, otherwise no siptrace flag set or function use in routing blocks. See also the docs of trace_mode param.
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.
-- Juha
On 07.04.20 15:15, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Can you try the master branch with trace_on=1 and trace_mode=2 for siptrace module? You need to set also the db connection parameters, otherwise no siptrace flag set or function use in routing blocks. See also the docs of trace_mode param.
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.
Thanks for testing and good to hear is working fine.
As I looked at the code of the module after quite some years, I will try to work a bit on it, it felt like some parts of code are duplicated, maybe I can simplified it to be easier to maintain in the future. I also plan to review a bit how some of the parameters are used, there is one related to db storing allocated to shared memory, not sure it is needed like that right now, because there is no rpc command to change it.
I am saying that so people should be aware and report if something gets broken.
On the other hand, as enhancement, would it make sense to have trace_mode also changeable via rpc? Not sure if someone would want to change from mirroring to hep or uri to storing to database, or the other way around ...
Cheers, Daniel
Daniel-Constantin Mierla writes:
On the other hand, as enhancement, would it make sense to have trace_mode also changeable via rpc? Not sure if someone would want to change from mirroring to hep or uri to storing to database, or the other way around ...
It might be useful to be able to configure via rpc where the trace goes, but I don't have immediate need for that.
When I looked at the code a few months ago, I noticed that the callback is permanently registered. Might save some CPU cycles if the callback would be unregistered when tracing is off.
-- Juha
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/b64b3f03a9c6b69587ca360465f091f8...) 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/e28f464457eea47cc606c73cbfe4b30f...) 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/080c6e07708f1964498a43e70c9b6240...) 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):
- Successful call (INVITE-200-ACK)
- Error replied
- Canceled call
- 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@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
Hi Daniel, thanks for having a look. There is already a callback for negative ACK, my problem was that I was using t_check_trans (tm api) to check if the ACK was a negative ACK, and t_check_trans was calling this callback internally. So, if after the sip_trace() call in the script we had a t_check_trans(), the callback itself was called again, thus giving a duplicated message. I've solved using instead t_lookup_request. I've pushed another commit on the branch and I'm going to open the PR.
Cheers,
Federico
On Sun, Apr 5, 2020 at 9:18 AM Daniel-Constantin Mierla miconda@gmail.com wrote:
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/b64b3f03a9c6b69587ca360465f091f8...) 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/e28f464457eea47cc606c73cbfe4b30f...) 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/080c6e07708f1964498a43e70c9b6240...) 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):
- Successful call (INVITE-200-ACK)
- Error replied
- Canceled call
- 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@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.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
-
Daniel-Constantin Mierla -
Federico Cabiddu -
Juha Heinanen