siptrace: add methods_blacklist_auto modparam

[nferreyra]

Pre-Submission Checklist

• Commit message has the format required by CONTRIBUTING guide
• Commits are split per component (core, individual modules, libs, utils, ...)
• Each component has a single commit (if not, squash them into one commit)
• No commits to README files for modules (changes must be done to docbook files
  in doc/ subfolder, the README file is autogenerated)

Type Of Change

• Small bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds new functionality)
• Breaking change (fix or feature that would change existing functionality)

Checklist:

• PR should be backported to stable branches
• Tested changes locally
• Related to issue #XXXX (replace XXXX with an open issue number)

Description

• Adds a new methods_blacklist_auto modparam that allows to
  ignore SIP method ids before mirroring traffic to a SIP capture
  server when trace_mode=1.

[miconda]

First: this came after code freeze for 5.4.x release, so it has to wait a bit until branch 5.4 is created, unless there is a different decision on this.

Second: README should not be regenerated, it is done automatically by a cron job.

Then, I think the modparam should use the value format as for is_method() function, because it is more intuitive to have something like "OPTIONS|REGISTER|KDMQ".

However, I am thinking that it may be more flexible to add an event_route, because the sip message is parsed in such case and if drop is used, then do not mirror the sip message. Then other type of conditions can be used. I can eventually take care of implementing it after branching the 5.4, but it would be even better if someone makes a PR meanwhile.

[nferreyra]

Hi @miconda. Tks for looking at this.
Regarding the README it was my bad, I just noticed that I had included it after the PR creation.
Initially, I was implementing the modparam with the "is_method" approach but then I found the methods_filter that seems more performant. Since it's static the string could be converted at the module initialization to the decimal representation allowing to keep the bitwise comparison.

About your event_route propose, I really like that approach because it also gives the script writer full control. I guess between native or script approaches the performance difference will be negligible.

[miconda]

I just pushed an alternative implementation with event_route[siptrace:msg] - by using drop(), the message should not be mirrored. At this moment, only conditions over the sip message content should be done (e.g., method check, headers check), because source/destination addresses are not set (some message are generated locally) -- I will work on this soon. But it should offer all what this patch was offering.

No testing done yet, so assistance with that and feedback are appreciated.

[nferreyra]

Hi @miconda thank you. I will test and let you know the result soon.

[miconda]

OK, thanks! I will close this PR, if there are problems, open an item on issues tracker.