Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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 SUBSCRIBEd 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) ?
Using 2 UDP receiver processes.
User1 is watching (has SUBSCRIBEd 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.
(paste your sip traffic here)
kamailio -vversion: 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
$ 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, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.