Hello, you can also check out by commit id to a version before the update of siptrace, it should be possible to do it for the files of siptrace, all the rest be the latest master. This will be fixed, just a time when a lot of devs are traveling to Berlin. It's a regression by a large enhancement of the module, there are many commits there, so reverting is not the easiest option here, because the enhancement has to stay, only the regression needs to be fixed. There is also the alternative of using sipdump module if your only purpose is to look at tls traffic -- it has also more context information and some metadata. Cheers, Daniel On 07.05.19 17:12, Juha Heinanen wrote: -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com

On 07.05.19 18:34, Juha Heinanen wrote: You can also do that on your local clone Because the review was done, reverting means doing again a lot of work which was done already. Reverting is for the cases when something was pushed without wanting that at all (like a backport of a new feature in a stable branch, or code that should not be accepted at all). In this case it is a regression/a bug introduced with couple of new features that stay -- there were many such cases in the past and they will be in the future. That is the purpose of master branch -- to add new features and fix their bugs till next stable release. It may happen that some issue stays a bit unresolved in the master branch, due to certain conditions our of the willingness of the developer. If a developer says that "a bug" won't be fixed because he doesn't want, then it can also be the case for a revert, but if a developer (does not have to be the initial author of the commits) says it is going to take care of it but it is in holidays/traveling/etc... for few days, it is not a critical case with a master branch. Reverting is messing up the commit history as well, which we use for release notes of major versions. Anyhow, with Kamailio World finished, I just got a bit of time and pushed a commit -- no time to test right now, but maybe you can give it a try and then report if works. If not, I will dig further soon, just give the new error messages/details/... Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com

Hello, I just got back from Kamailio World today. I didn't have any way to fix this while in Berlin. The week before I've been busy fixing some issues for our internal projects. Thanks Daniel for the fix. I'll test it with the sipp scenarios that I've used for testing the main feature. This will be fixed as soon as possible. Regards, Ionut ________________________________________ From: sr-dev <sr-dev-bounces(a)lists.kamailio.org> on behalf of Juha Heinanen <jh(a)tutpro.com> Sent: Thursday, May 9, 2019 1:10 PM To: miconda(a)gmail.com Cc: Kamailio (SER) - Development Mailing List Subject: Re: [sr-dev] still no fix to siptrace Daniel-Constantin Mierla writes: There is no error messages anymore, but from a test call only ACK appeared in db table: modparam("siptrace", "db_url", "MYSQL_SIP_PROXY_USAGE_URL") modparam("siptrace", "trace_flag", TRACE) if (isflagset(TRACE)) { INFO(Tracing $rm); sip_trace(); }; May 9 13:03:49 host /usr/bin/sip-proxy[16575]: INFO: Tracing INVITE May 9 13:03:51 host /usr/bin/sip-proxy[16575]: INFO: Tracing ACK May 9 13:03:55 host /usr/bin/sip-proxy[16575]: INFO: Tracing BYE You don't need to spend your time on this, since your commits didn't break the module. Just go back to 5.2 level and let the person who implemented the new features to fix the code. -- Juha _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev