When **trace_mode** is set to 1, then **send_sock_name** is not used (it uses the unexpected socket listen socket).
However, when **trace_mode** is set to 4, then **send_sock_name** works correctly.
Also, in both cases, **send_sock_addr** works correctly.
```
listen=udp:SIP_IPADDRESS:SIP_PORT
listen=udp:SIPCAPTURE_IPADDRESS:SIP_PORT name "siptrace_socket"
modparam("siptrace", "duplicate_uri", "sip:10.218.31.205:9060")
modparam("siptrace", "hep_mode_on", 1)
modparam("siptrace", "hep_version", 3)
modparam("siptrace", "hep_capture_id", 110)
modparam("siptrace", "send_sock_name", "siptrace_socket")
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_mode", 1)
modparam("siptrace", "trace_to_database", 0)
```
This is tested on Kamailio 5.5.1 and 5.5.3.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3174
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3174(a)github.com>
We have installed Kamailio 5.6.0 from http://deb.kamailio.org/kamailio56, but it is intermittently crashing with a segfault like this:
May 29 04:46:53 ss2 kernel: [26920.901572] kamailio[1416]: segfault at 43a ip 00007f78d1396ab5 sp 00007ffd2487ca10 error 4 in app_perl.so[7f78d1392000+21000]
May 29 04:46:53 ss2 kernel: [26920.901575] Code: 8b 05 8f 34 02 00 48 8b 00 48 89 c7 e8 7b ff ff ff e8 3f e5 ff ff 48 8b 15 78 34 02 00 48 89 02 48 8b 05 6e 34 02 00 48 8b 00 <0f> b6 90 3a 04 00 00 48 8b 05 5d 34 02 00 48 8b 00 83 ca 02 88 90
May 29 04:46:56 ss2 kernel: [26923.737834] kamailio[1409]: segfault at 43a ip 00007f78d1396ab5 sp 00007ffd2487ca10 error 4 in app_perl.so[7f78d1392000+21000]
May 29 04:46:56 ss2 kernel: [26923.737838] Code: 8b 05 8f 34 02 00 48 8b 00 48 89 c7 e8 7b ff ff ff e8 3f e5 ff ff 48 8b 15 78 34 02 00 48 89 02 48 8b 05 6e 34 02 00 48 8b 00 <0f> b6 90 3a 04 00 00 48 8b 05 5d 34 02 00 48 8b 00 83 ca 02 88 90
Perl is version 5.30.0, and the system is running Ubuntu 20.04. A Perl library is loaded using:
modparam( "app_perl", "filename", "/path/to/our/Kamailio.pm" )
We have not found a core file anywhere on the server. Please let us know what other information you need, thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3134
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3134(a)github.com>
The schedule for Kamailio World Conference Online 2022 has been
published on the event website:
- https://www.kamailioworld.com
The event spans over two days, September 7-8, 2022, with presentations
and open discussion sessions during 12:50-17:00UTC. With the main target
to share the knowledge and connect the community, the conference has
presentations covering use of Kamailio for 5G services, NAT traversal
and integration with RTPEngine, TLS with WolfSSL, end to end testing
testing, controlling SIP message content from KEMI and resources
management for scalability. It is a good balance between established and
new speakers at this edition of Kamailio World Conference.
There is no registration required to join the event, the sessions will
be presented in a live video conferencing room streamed to YouTube
KamailioWorld Channel. A text chat room will be made available for
posting questions and background discussions.
Book the dates in your agenda and prepare for another amazing Kamailio
World Conference! Keep the eye on the event website for updates!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
### 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>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Relevant modules and parameters in configuration:
```
loadmodule "presence.so"
loadmodule "dialog.so"
loadmodule "presence_xml.so"
loadmodule "pua.so"
loadmodule "presence_dialoginfo.so"
loadmodule "pua_dialoginfo.so"
modparam("dialog", "db_mode", 1)
modparam("presence", "subs_db_mode", 2)
modparam("presence", "db_table_lock_type", 0)
modparam("pua", "db_mode", 2)
modparam("pua", "db_table_lock_write", 0)
```
Using 2 UDP receiver processes.
User1 is watching (has` SUBSCRIBE`d to) User2, which is called by User3 (call1). User2 doesn't answer, phone is ringing. User1 now also calls User2 (call2), but we don't support receiving a second call so, for this `INVITE`, after 183, almost immediately, a 486 "Busy Here" message is sent and the call is cancelled (call2 finished). The 183 reply generates an "**early**" state on the UDP1 process, while 486 goes to "**terminated**" on the UDP2 process. The `PUBLISH` messages are processed almost concomitantly. The problem is that "**early**" state arrives to the subscriber (User1) after the "**terminated**" one (seen with `sngrep`) so the phone button keeps blinking for a while (... and the state cannot be changed by other call while the "**early**" event is still in the `presentity` table of the database).
I suspect a concurrency problem since I didn't reproduce it with only one UDP receiver process. Even if the "**terminated**" lifetime is much smaller (11s vs minutes), I strongly believe it is still there when the "**early**" state is written. Does the "**early**" event checks the database/memory for a "**terminated**" event for the same call ID? Is it because of the missing locks maybe (`db_table_lock_type`, `db_table_lock_write`) ?
### Troubleshooting
#### Reproduction
Using 2 UDP receiver processes.
User1 is watching (has `SUBSCRIBE`d to) User2, which is called by User3 (call1). User2 doesn't answer, phone is ringing. User1 now also calls User2 (call2), but we don't support receiving a second call so, for this `INVITE`, after 183, almost immediately, a 486 "Busy Here" message is sent and the call is cancelled (call2 finished).
I would not say that it is systematic, but easy enough to reproduce.
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
#### 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).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.5.4 (x86_64/linux)
flags: , EXTRA_DEBUGUSE_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
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 8.3.0
```
* **Operating System**:
Docker image around
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
(paste your output here)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3192
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3192(a)github.com>
I’ve finally got confirmation that the SIP ALPN identifier is registered.
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype…
For Kamailio, this could assist when we multiplex multiple protocols on the same port, like we do for HTTPs and SIP/TLS many times.
ALPN Is part of the TLS handshake, indicating what protocol comes after TLS is done.
For it to help, both phones and servers needs to support it. I do think it would be helpful.
Cheers,
/O