<!-- 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
<!-- 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 -->
- [X] Commit message has the format required by CONTRIBUTING guide
- [X] Commits are split per component (core, individual modules, libs, utils, ...)
- [X] Each component has a single commit (if not, squash them into one commit)
- [X] 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
- [X] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
Added secfilter module scheme to dbtext, as per using `kamdbctl create` with DBTEXT, was getting following error
```
cp: cannot stat '/usr/share/kamailio//dbtext/kamailio/secfilter': No such file or directory
```
With this patch error is gone. Secfilter DBTEXT scheme is taken from SQLite scheme.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2261
-- Commit Summary --
* kamctl: added secfilter to dbtext
-- File Changes --
A utils/kamctl/dbtext/kamailio/secfilter (1)
M utils/kamctl/dbtext/kamailio/version (1)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2261.patchhttps://github.com/kamailio/kamailio/pull/2261.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/2261
Module: kamailio
Branch: master
Commit: 5a16612493f9d6622f2c22fa83864295c7b55c9b
URL: https://github.com/kamailio/kamailio/commit/5a16612493f9d6622f2c22fa8386429…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2020-03-31T11:31:21+02:00
modules: readme files regenerated - tcpops ... [skip ci]
---
Modified: src/modules/tcpops/README
---
Diff: https://github.com/kamailio/kamailio/commit/5a16612493f9d6622f2c22fa8386429…
Patch: https://github.com/kamailio/kamailio/commit/5a16612493f9d6622f2c22fa8386429…
---
diff --git a/src/modules/tcpops/README b/src/modules/tcpops/README
index 4c08b3624b..70209686f0 100644
--- a/src/modules/tcpops/README
+++ b/src/modules/tcpops/README
@@ -32,6 +32,8 @@ Olle E. Johansson
3.5. tcp_set_connection_lifetime([conid], lifetime)
3.6. tcp_enable_closed_event([conid])
3.7. tcp_get_conid(hostport, pvname)
+ 3.8. tcp_set_otcpid(conid)
+ 3.9. tcp_set_otcpid_flag(mode)
4. Event routes
@@ -51,6 +53,8 @@ Olle E. Johansson
1.7. tcp_set_connection_lifetime usage
1.8. tcp_set_closed_event usage
1.9. tcp_get_conid usage
+ 1.10. tcp_set_otcpid usage
+ 1.11. tcp_set_otcpid_flag usage
Chapter 1. Admin Guide
@@ -71,6 +75,8 @@ Chapter 1. Admin Guide
3.5. tcp_set_connection_lifetime([conid], lifetime)
3.6. tcp_enable_closed_event([conid])
3.7. tcp_get_conid(hostport, pvname)
+ 3.8. tcp_set_otcpid(conid)
+ 3.9. tcp_set_otcpid_flag(mode)
4. Event routes
@@ -144,6 +150,8 @@ end
3.5. tcp_set_connection_lifetime([conid], lifetime)
3.6. tcp_enable_closed_event([conid])
3.7. tcp_get_conid(hostport, pvname)
+ 3.8. tcp_set_otcpid(conid)
+ 3.9. tcp_set_otcpid_flag(mode)
3.1. tcp_conid_alive(conid)
@@ -345,6 +353,53 @@ event_route[tcp:closed] {
}
...
+3.8. tcp_set_otcpid(conid)
+
+ Set the value for outbound tcp connection id.
+
+ Meaning of the parameters is as follows:
+ * conid - the value of tcp connection id. It can be an integer number
+ or a variable holding an interver value.
+
+ Return values:
+ * 1: success
+ * -1: failure
+
+ Example 1.10. tcp_set_otcpid usage
+...
+ $var(conid) = 10;
+ tcp_set_otcpid("$var(conid)");
+...
+
+3.9. tcp_set_otcpid_flag(mode)
+
+ Set or reset the internal flag for using or not the outbound tcp
+ connection id for sending out. The outbound connection id can be set by
+ module or by config using tcp_set_otcpid(...) function. An example of a
+ module setting the otcpid is register via lookup location function,
+ which sets the filed to the connection id used to receive the
+ registration request.
+
+ Meaning of the parameters is as follows:
+ * mode - if 0, then the flag is reset, otherwise it is set.
+
+ Return values:
+ * 1: success
+ * -1: failure
+
+ Note: if you set the flag to use the outbound tcp connection id, then
+ custom config changes to the destination address, like updating the
+ r-uri ($ru) or dst uri ($du) are not resetting it, so the same already
+ set connection id is used and the SIP request might be sent to the
+ unexpected destination. Reset the flag in such case, if you set it
+ previously.
+
+ Example 1.11. tcp_set_otcpid_flag usage
+...
+ $var(cmode) = 1;
+ tcp_set_otcpid_flag("$var(cmode)");
+...
+
4. Event routes
4.1. tcp:closed
Module: kamailio
Branch: master
Commit: d6e94d074a2a1f1af2964f1ed7f24602a8dd295a
URL: https://github.com/kamailio/kamailio/commit/d6e94d074a2a1f1af2964f1ed7f2460…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2020-03-31T11:23:20+02:00
tcpops: docs for tcp_set_otcpid() and tcp_set_otcpid_flag() functions
---
Modified: src/modules/tcpops/doc/functions.xml
---
Diff: https://github.com/kamailio/kamailio/commit/d6e94d074a2a1f1af2964f1ed7f2460…
Patch: https://github.com/kamailio/kamailio/commit/d6e94d074a2a1f1af2964f1ed7f2460…
---
diff --git a/src/modules/tcpops/doc/functions.xml b/src/modules/tcpops/doc/functions.xml
index 9c6409c4e6..94cefaa776 100644
--- a/src/modules/tcpops/doc/functions.xml
+++ b/src/modules/tcpops/doc/functions.xml
@@ -290,6 +290,87 @@ event_route[tcp:closed] {
if(tcp_get_conid("127.0.0.1:5060", "$var(conid)")) {
xlog("connection id is: $var(conid)\n");
}
+...
+ ]]></programlisting>
+ </example>
+ </section>
+ <section id="tcpops.f.tcp_set_otcpid">
+ <title>
+ <function>tcp_set_otcpid(conid)</function>
+ </title>
+ <para>
+ Set the value for outbound tcp connection id.
+ </para>
+ <para>Meaning of the parameters is as follows:</para>
+ <itemizedlist>
+ <listitem>
+ <para><emphasis>conid</emphasis> - the value of tcp connection id.
+ It can be an integer number or a variable holding an interver value.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>Return values:</para>
+ <itemizedlist>
+ <listitem>
+ <para>1: success</para>
+ </listitem>
+ <listitem>
+ <para>-1: failure</para>
+ </listitem>
+ </itemizedlist>
+ <example>
+ <title><function>tcp_set_otcpid</function> usage</title>
+ <programlisting><![CDATA[
+...
+ $var(conid) = 10;
+ tcp_set_otcpid("$var(conid)");
+...
+ ]]></programlisting>
+ </example>
+ </section>
+ <section id="tcpops.f.tcp_set_otcpid_flag">
+ <title>
+ <function>tcp_set_otcpid_flag(mode)</function>
+ </title>
+ <para>
+ Set or reset the internal flag for using or not the outbound tcp
+ connection id for sending out. The outbound connection id can be
+ set by module or by config using tcp_set_otcpid(...) function. An
+ example of a module setting the otcpid is register via lookup location
+ function, which sets the filed to the connection id used to receive
+ the registration request.
+ </para>
+ <para>Meaning of the parameters is as follows:</para>
+ <itemizedlist>
+ <listitem>
+ <para><emphasis>mode</emphasis> - if 0, then the flag is reset,
+ otherwise it is set.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>Return values:</para>
+ <itemizedlist>
+ <listitem>
+ <para>1: success</para>
+ </listitem>
+ <listitem>
+ <para>-1: failure</para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Note: if you set the flag to use the outbound tcp connection id,
+ then custom config changes to the destination address, like
+ updating the r-uri ($ru) or dst uri ($du) are not resetting it, so
+ the same already set connection id is used and the SIP request
+ might be sent to the unexpected destination. Reset the flag in such
+ case, if you set it previously.
+ </para>
+ <example>
+ <title><function>tcp_set_otcpid_flag</function> usage</title>
+ <programlisting><![CDATA[
+...
+ $var(cmode) = 1;
+ tcp_set_otcpid_flag("$var(cmode)");
...
]]></programlisting>
</example>