Module: kamailio
Branch: master
Commit: 93e77d441112ce41042cfd904cc3e7fd8ae78b4a
URL: https://github.com/kamailio/kamailio/commit/93e77d441112ce41042cfd904cc3e7f…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2022-09-07T23:46:23+02:00
modules: readme files regenerated - rtpengine ... [skip ci]
---
Modified: src/modules/rtpengine/README
---
Diff: https://github.com/kamailio/kamailio/commit/93e77d441112ce41042cfd904cc3e7f…
Patch: https://github.com/kamailio/kamailio/commit/93e77d441112ce41042cfd904cc3e7f…
---
diff --git a/src/modules/rtpengine/README b/src/modules/rtpengine/README
index 4944f8abaa..fd1e71dc26 100644
--- a/src/modules/rtpengine/README
+++ b/src/modules/rtpengine/README
@@ -2160,6 +2160,10 @@ rtpengine_offer();
+ SIP-source-address - the opposite of trust-address. Restores
the old default behaviour of ignoring endpoint addresses in
the SDP body.
+ + received-from=IP - Configure the SIP-source-address IP
+ explicitly, which will be useful when two kamailio is cascaded
+ where first kamailio is handling NAT and second kamailio
+ RTPEngine.
+ replace-origin - flags that IP from the origin description
(o=) should be also changed.
+ replace-session-connection - flags to change the session-level
Add receive-from option to flags
receive-from=1.2.3.4
required for managing rtpengine by a kamailio node behind a dispatcher
kamailio node
<!-- Kamailio Pull Request Template -->
UE behind NAT --------------->Dispatcher Kamailio--------> Location & Media managementKamailio ---------------> C5 SoftSwitch
| |
| V
| RTPENGINE
|
|---------------------------->Location & Media management Kamailio ---------------> C5 SoftSwitch
|
V
RTPENGINE
In this scenario when the Kamailio behind the Dispatcher will be getting the $Ri as dispatcher IP and by default that will be passed to RTP Engine for NAT negotiation which will fail.
In this pull merge requst, RTP engine module a new flag is added receive-from=IP which is supposed to be the received IP from the First node through P-Accessnetwork-Info header or the contact recived tag etc..
<!--
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
- [ ] 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 -->
- [ ] 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 -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3230
-- Commit Summary --
* Add receive-from option
-- File Changes --
M src/modules/rtpengine/rtpengine.c (47)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3230.patchhttps://github.com/kamailio/kamailio/pull/3230.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3230
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3230(a)github.com>
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
When handling a `PUBLISH` we call [handle_publish()](https://kamailio.org/docs/modules/5.5.x/modules/presence.… and `NOTIFY`s are sent to all of the corresponding `active_watchers` (as expected). However, when `NOTIFY`s timeout (`408`), we're seeing that the corresponding entries in the `active_watchers` table are _not_ being deleted as expected. Furthermore, we've noticed that `NOTIFY`s are being sent to `active_watchers` which are expired (i.e. `expires < UNIX_TIMESTAMP()`) and when we run `kamcmd presence.cleanup`, no expired entries are removed from the `active_watchers` table.
We suspect that all of these things might be related--the common theme being that records aren't deleted when expected.
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
In our setup, we're using Kamailio as a "presence server" (via the [presence](https://kamailio.org/docs/modules/5.5.x/modules/presence.html), [presence_dialoginfo](https://kamailio.org/docs/modules/5.5.x/modules/presen…, and [presence_xml](https://kamailio.org/docs/modules/5.5.x/modules/presence_xml.… modules). We're using [`subs_db_mode`](https://kamailio.org/docs/modules/5.5.x/modules/presence.html#presence.p.subs_db_mode) `3` (DB-only scheme) and we have multiple Kamailio instances connected to a shared database (MySQL `8.0.27`).
Everything seems to be working as expected. However, as we accumulated stale entries in the `active_watchers` table we're finding that we're wasting more and more time on sending `NOTIFY`s to black holes. We're generating a _lot_ of traffic and waiting for the timeouts to hit is causing memory issues and backups.
Here are the relevant portions of our `kamailio.cfg` file:
```
# ----- presence params -----
modparam("presence", "db_table_lock_type", 0) # Disable locking; MySQL has issues with this is enabled.
modparam("presence", "db_update_period", -1) # Disable synchronization.
modparam("presence", "db_url", PRESENCE_DB_URL)
modparam("presence", "expires_offset", 60) # Force the client to send an UPDATE before the old PUBLISH expires.
modparam("presence", "max_expires", 1800)
modparam("presence", "min_expires", 1700)
modparam("presence", "publ_cache", 0) # Disable the PUBLISH cache since the database is shared.
modparam("presence", "server_address", "sip:$CLUSTER_DOMAIN_NAME:5060") # This becomes the value of the Contact header.
modparam("presence", "sip_uri_match", 1) # Use case insensitive URI matching.
modparam("presence", "subs_db_mode", 3) # Database-only scheme; everything is stored in the database.
modparam("presence", "notifier_processes", 0) # Caution! Under load a race condition can cause CSeq's to be reused.
modparam("presence", "timeout_rm_subs", 1)
# ----- presence_dialoginfo params -----
modparam("presence_dialoginfo", "force_single_dialog", 1) # Maybe not all phones support multiple "dialog" elements?
modparam("presence_dialoginfo", "force_dummy_dialog", 1) # Maybe not all phones support a null body?
# ----- presence_xml params -----
modparam("presence_xml", "db_url", PRESENCE_DB_URL)
modparam("presence_xml", "force_active", 1) # Skip permission/XCAP checks.
modparam("presence_xml", "force_dummy_presence", 1) # Default to a simple "open" status when presentity info is unavailable.
# ...
route[PRESENCE] {
if (!is_method("PUBLISH|SUBSCRIBE")) {
return;
}
if (!t_newtran()) {
sl_reply_error();
exit;
}
if (is_method("PUBLISH")) {
handle_publish();
t_release();
} else if (is_method("SUBSCRIBE")) {
handle_subscribe();
t_release();
}
exit;
}
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
Here's a somewhat sanitized example (the message seems OK to us; however, the `Subscription-State: terminated; reason=timeout` does make us wonder--do we as the sender _know_ that the client is terminated/timed-out?):
```
2022/04/05 21:09:55.209846 10.21.3.12:5060 -> 10.31.0.226:6060
NOTIFY sip:SomeUser@192.168.86.24:54639;alias=123.21.125.232~54639~1 SIP/2.0
Via: SIP/2.0/UDP presence-w.staging.internal:5060;branch=z9hG4bK43ea.648a1952000000000000000000000000.0
To: <sip:SomeOtherUser@9bfadf66-a77b-6a69-25f3-02d96d4aa946>;tag=2607596073
From: <sip:SomeUser@9bfadf66-a77b-6a69-25f3-02d96d4aa946>;tag=69309ea83adcd977af8788878e9f31b3-42e32342
CSeq: 66 NOTIFY
Call-ID: 0_2607659559(a)192.168.86.24
Route: <sip:10.31.0.226:6060;r2=on;lr;ftag=2607596073>, <sip:55.8.122.110;r2=on;lr;ftag=2607596073>
Content-Length: 710
Max-Forwards: 70
Event: dialog
Contact: <sip:presence-w.staging.internal:5060>
Subscription-State: terminated;reason=timeout
Content-Type: application/dialog-info+xml
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="66" state="full" entity="sip:SomeUser@9bfadf66-a77b-6a69-25f3-02d96d4aa946">
<dialog id="0_1364146118(a)192.168.1.244" call-id="0_1364146118(a)192.168.1.244" direction="initiator">
<state>confirmed</state>
<remote>
<identity>sip:4355558565@9bfadf66-a77b-6a69-25f3-02d96d4aa945:5060</identity>
<target uri="sip:4355558565@9bfadf66-a77b-6a69-25f3-02d96d4aa946:5060"/>
</remote>
<local>
<identity>sip:SomeUser@9bfadf66-a77b-6a69-25f3-02d96d4aa946:5060</identity>
<target uri="sip:SomeUser@123.130.50.202:58872"/>
</local>
</dialog>
</dialog-info>
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
We didn't see any functions in the `presence` module that we could call directly to clean things up. One thought we had was to manually run some database commands from `event_route[presence:notify-reply]` (or in a `reply_route`). We've noticed that once the problematic entries are manually removed from the database that we no longer attempt to send `NOTIFY`s to the defunct destinations.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.5.4 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 10.2.1
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
$ uname -a
Linux ip-10-21-3-12 5.10.0-13-cloud-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3074
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3074(a)github.com>
### Description
While a INVITE is been processed the CANCEL of that transaction is been processed in other process almost at the same time
### Troubleshooting
#### Reproduction
Quite difficult to reproduce I would say
#### Debugging Data
```
Reading symbols from /usr/sbin/kamailio...
Reading symbols from /usr/lib/debug/.build-id/e3/9bd8ad0900c980149b00579cce26035c9cb118.debug...
warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing
[New LWP 4136750]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /run/kamailio/kamailio.proxy.pid -f /etc/kamailio/proxy/k'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 atomic_dec_and_test_int (var=0x20) at ../../core/parser/../mem/../atomic/atomic_x86.h:222
222 ../../core/parser/../mem/../atomic/atomic_x86.h: No such file or directory.
(gdb) backtrace
#0 atomic_dec_and_test_int (var=0x20) at ../../core/parser/../mem/../atomic/atomic_x86.h:222
0000001 t_unref (p_msg=<optimized out>) at t_lookup.c:1514
#2 0x000055eee962d69b in exec_post_script_cb (msg=msg@entry=0x7f7e265822c8, type=type@entry=REQUEST_CB_TYPE)
at core/script_cb.c:182
0000003 0x000055eee95dfcbe in receive_msg (
buf=buf@entry=0x55eee9a00740 <buf> "INVITE sip:...@fake.dom:5060;transport=udp SIP/2.0\r\nRecord-
Route: <sip:X.X.X.X;r2=on;lr=on;ftag=1E7F0816-6299BCF10003883E-7FFFF700;ngcplb=yes;socket=udp:Y.Y.Y.Y:5060>\r
\nRe"..., len=<optimized out>, rcv_info=rcv_info@entry=0x7ffc96d12af0) at core/receive.c:520
#4 0x000055eee96d4c40 in udp_rcv_loop () at core/udp_server.c:543
#5 0x000055eee94db634 in main_loop () at main.c:1730
#6 0x000055eee94d2d2c in main (argc=<optimized out>, argv=<optimized out>) at main.c:3053
```
#### Log Messages
Notice that both messages came in the same second ( IPs and numbers have been changed )
```
Jun 3 09:49:05 sipwise2-prx03a proxy[4136750]: NOTICE: DEFAULT_ROUTE <script>: New request on proxy - M=INVITE R=«sip:+49......@X.X.X.X
:5060;transport=udp» F=«sip:+49...@fake.dom» T=«sip:+49...@Y.Y.Y.Z» IP=«Y.Y.Y.Z»:«5060» («Y.Y.Y.Y»:«5060»)
ID=«31668-TN-030322e6-0904f8ba1(a)fake.xn--dom_b2b-1-era UA='Cirpack/v4.88 (gw_sip)' DESTIP=«Y.Y.Y.G»:«5062»
```
```
Jun 3 09:49:05 sipwise2-prx03a proxy[4136755]: NOTICE: DEFAULT_ROUTE <script>: New request on proxy - M=CANCEL R=«sip:+49...@X.X.X.X
:5060;transport=udp» F=«sip:+49...@fake.dom» T=«sip:+49...@Y.Y.Y.Z» IP=«Y.Y.Y.Y»:«5060» («Y.Y.Y.Y»:«5060
») ID=«31668-TN-030322e6-0904f8ba1(a)fake.xn--dom_b2b-1-era UA='<null>' DESTIP=«Z.Z.Z.Z»:«5062»
Jun 3 09:49:05 sipwise2-prx03a proxy[4136755]: NOTICE: DEFAULT_ROUTE <script>: Sending reply S=100 Trying M=CANCEL fs='«Z.Z.Z.Z»:«5062»' du
='«Y.Y.Y.Y»:«5060»' - R=«sip:+49...@X.X.X.X:5060;transport=udp» ID=«31668-TN-030322e6-0904f8ba1(a)fake.xn--dom_b2b-1-era UA='<n
ull>'
```
### Additional Information
This is the Sipwise flavor 5.5.1-1+0~mr9.5.3.2
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3156
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3156(a)github.com>
Module: kamailio
Branch: master
Commit: f5c98a49c98aedcf6e1afec3c42dd862d0eeb9a3
URL: https://github.com/kamailio/kamailio/commit/f5c98a49c98aedcf6e1afec3c42dd86…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2022-09-02T13:15:35+02:00
core: support to specify options for load module
- prototypes:
loadmodule("path", "options")
loadmodulex("path", "options")
- options is a string with characters:
- 'g' or 'G' - open the module shared object file with RTLD_GLOBAL set,
wich can be used for modules related to external scripting languages
to avoid reloading
- example: loadmodule("app_lua", "g")
---
Modified: src/core/cfg.y
Modified: src/core/sr_module.c
Modified: src/core/sr_module.h
Modified: src/main.c
---
Diff: https://github.com/kamailio/kamailio/commit/f5c98a49c98aedcf6e1afec3c42dd86…
Patch: https://github.com/kamailio/kamailio/commit/f5c98a49c98aedcf6e1afec3c42dd86…