<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [ ] 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
- [X] 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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [X] PR should be backported to stable branches
- [ ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
192.0.0.0/29 is a reserved subnet for NATtin IPv4 across an IPv6 netwerk. For example Dual Stack Lite carrier grade NAT.
This is small change and updates the subnets used for NAT according to https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-speci…
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1488
-- Commit Summary --
* Support for
-- File Changes --
M src/modules/ipops/detailed_ip_type.c (1)
M src/modules/ipops/detailed_ip_type.h (2)
M src/modules/nat_traversal/nat_traversal.c (3)
M src/modules/nathelper/nathelper.c (1)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1488.patchhttps://github.com/kamailio/kamailio/pull/1488.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1488
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
Module: kamailio
Branch: master
Commit: 2dde938c188839c71a1551866de20e39d73d28f6
URL: https://github.com/kamailio/kamailio/commit/2dde938c188839c71a1551866de20e3…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2020-04-07T12:46:16+02:00
modules: readme files regenerated - siptrace ... [skip ci]
---
Modified: src/modules/siptrace/README
---
Diff: https://github.com/kamailio/kamailio/commit/2dde938c188839c71a1551866de20e3…
Patch: https://github.com/kamailio/kamailio/commit/2dde938c188839c71a1551866de20e3…
---
diff --git a/src/modules/siptrace/README b/src/modules/siptrace/README
index f7fcd2eded..ea4eae3b19 100644
--- a/src/modules/siptrace/README
+++ b/src/modules/siptrace/README
@@ -156,7 +156,7 @@ Chapter 1. Admin Guide
configuration file. In this case the original message is processed
along with it's corresponding transaction/dialog if certain flags
are used.
- * by setting “trace_mode” to mirror all traffic.
+ * by setting “trace_mode” to mirror or store to db all traffic.
The tracing can be turned on/off using Kamailio RPC commands.
@@ -435,13 +435,19 @@ modparam("siptrace", "force_send_sock", "sip:10.1.1.2:5000")
3.18. trace_mode (integer)
- If set to 1, the module uses core events triggered when receiving or
- sending SIP traffic to mirror traffic to a SIP capture server using
- HEP. It will automatically do the mirroring of all SIP traffic. It is
- no longer needed to set the siptrace flag per request or execute
- sip_trace(), if it is done, then there mirroring is duplicated.
+ If not set to 0, the module uses core events triggered when receiving
+ or sending SIP traffic to store it to database or mirror it to a SIP
+ capture server using HEP or UDP forwarding. It will automatically do
+ the handling of all SIP traffic. It is no longer needed to set the
+ siptrace flag per request or execute sip_trace(), if it is done, then
+ the storing and mirroring is duplicated.
- If set to 0, no automatic mirroring of SIP traffic via HEP.
+ The value of the parameter can be a combination of next values:
+ * 0 - no automatic mirroring or storing of SIP traffic.
+ * 1 (1st bit set) - mirror the traffic to HEP server.
+ * 2 (2nd bit set) - store the traffic to database server.
+ * 4 (3rd bit set) - mirro the traffic to the SIP URI specified by
+ duplicate_uri.
The trace_on parameter still has to be set, allowing also to control
this mode of mirroring via RPC commands.
@@ -453,6 +459,8 @@ modparam("siptrace", "force_send_sock", "sip:10.1.1.2:5000")
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_mode", 1)
...
+modparam("siptrace", "trace_mode", 3)
+...
3.19. auth_key (integer)
Module: kamailio
Branch: master
Commit: 87b8c506f0dc77f0d39eb662df24fbe500bef9bb
URL: https://github.com/kamailio/kamailio/commit/87b8c506f0dc77f0d39eb662df24fbe…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2020-04-07T12:33:47+02:00
siptrace: docs updates for trace_mode parameter
---
Modified: src/modules/siptrace/doc/siptrace_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/87b8c506f0dc77f0d39eb662df24fbe…
Patch: https://github.com/kamailio/kamailio/commit/87b8c506f0dc77f0d39eb662df24fbe…
---
diff --git a/src/modules/siptrace/doc/siptrace_admin.xml b/src/modules/siptrace/doc/siptrace_admin.xml
index 9a33b36456..511dda3a98 100644
--- a/src/modules/siptrace/doc/siptrace_admin.xml
+++ b/src/modules/siptrace/doc/siptrace_admin.xml
@@ -33,7 +33,7 @@
</listitem>
<listitem>
<para>
- by setting <quote>trace_mode</quote> to mirror all traffic.
+ by setting <quote>trace_mode</quote> to mirror or store to db all traffic.
</para>
</listitem>
</itemizedlist>
@@ -468,16 +468,40 @@ modparam("siptrace", "force_send_sock", "sip:10.1.1.2:5000")
<section id="siptrace.p.trace_mode">
<title><varname>trace_mode</varname> (integer)</title>
<para>
- If set to 1, the module uses core events triggered when receiving
- or sending SIP traffic to mirror traffic to a SIP capture server
- using HEP. It will automatically do the mirroring of all SIP traffic.
+ If not set to 0, the module uses core events triggered when receiving
+ or sending SIP traffic to store it to database or mirror it to a SIP
+ capture server using HEP or UDP forwarding.
+ It will automatically do the handling of all SIP traffic.
It is no longer needed to set the siptrace flag per request or
- execute sip_trace(), if it is done, then there mirroring is
+ execute sip_trace(), if it is done, then the storing and mirroring is
duplicated.
</para>
+ <para>
+ The value of the parameter can be a combination of next values:
+ <itemizedlist>
+ <listitem>
<para>
- If set to 0, no automatic mirroring of SIP traffic via HEP.
+ 0 - no automatic mirroring or storing of SIP traffic.
</para>
+ </listitem>
+ <listitem>
+ <para>
+ 1 (1st bit set) - mirror the traffic to HEP server.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 2 (2nd bit set) - store the traffic to database server.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 4 (3rd bit set) - mirro the traffic to the SIP URI specified by
+ duplicate_uri.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
<para>
The trace_on parameter still has to be set, allowing also to control
this mode of mirroring via RPC commands.
@@ -493,6 +517,8 @@ modparam("siptrace", "force_send_sock", "sip:10.1.1.2:5000")
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_mode", 1)
...
+modparam("siptrace", "trace_mode", 3)
+...
</programlisting>
</example>
</section>
Module: kamailio
Branch: master
Commit: fd5a0b890028887b4cb1cd7ac2be2cf37d27956f
URL: https://github.com/kamailio/kamailio/commit/fd5a0b890028887b4cb1cd7ac2be2cf…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2020-04-07T10:04:54+02:00
rr: docs for loose_route_preloaded()
---
Modified: src/modules/rr/doc/rr_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/fd5a0b890028887b4cb1cd7ac2be2cf…
Patch: https://github.com/kamailio/kamailio/commit/fd5a0b890028887b4cb1cd7ac2be2cf…
---
diff --git a/src/modules/rr/doc/rr_admin.xml b/src/modules/rr/doc/rr_admin.xml
index bdb78291b6..bce2042d05 100644
--- a/src/modules/rr/doc/rr_admin.xml
+++ b/src/modules/rr/doc/rr_admin.xml
@@ -416,6 +416,33 @@ loose_route();
</example>
</section>
+ <section id="rr.f.loose_route_preloaded">
+ <title><function moreinfo="none">loose_route_preloaded()</function></title>
+
+ <para>The function is similar to `loose_route()`, but it returns 1 (true)
+ when the Route header is preloaded (is in an initial request) and -1
+ (false) if processing of the Route header failed or it is for requests
+ within dialog.</para>
+ <para>It is a convenient function to use for routing initial requests on
+ an edge proxy that adds Path header to REGISTER requests.
+ </para>
+ <para>This function can be used from REQUEST_ROUTE.</para>
+
+ <example>
+ <title><function>loose_route_preloaded</function> usage</title>
+
+ <programlisting format="linespecific">
+...
+if(!loose_route_preloaded()) {
+ sl_send_reply("404" "Preloaded route expected");
+ exit;
+}
+...
+</programlisting>
+ </example>
+ </section>
+
+
<section id="rr.f.record_route">
<title><function moreinfo="none">record_route([sparams])</function></title>