<p></p>

<h3 dir="auto">Description</h3>
<p dir="auto">Relevant modules and parameters in configuration:</p>
<pre class="notranslate"><code class="notranslate">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)
</code></pre>
<p dir="auto">Using 2 UDP receiver processes.</p>
<p dir="auto">User1 is watching (has<code class="notranslate"> SUBSCRIBE</code>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 <code class="notranslate">INVITE</code>, after 183, almost immediately, a 486 "Busy Here" message is sent and the call is cancelled (call2 finished). The 183 reply generates an "<strong>early</strong>" state on the UDP1 process, while 486 goes to "<strong>terminated</strong>" on the UDP2 process. The <code class="notranslate">PUBLISH</code> messages are processed almost concomitantly. The problem is that "<strong>early</strong>" state arrives to the subscriber (User1) after the "<strong>terminated</strong>" one (seen with <code class="notranslate">sngrep</code>) so the phone button keeps blinking for a while (... and the state cannot be changed by other call while the "<strong>early</strong>" event is still in the <code class="notranslate">presentity</code> table of the database).<br>
I suspect a concurrency problem since I didn't reproduce it with only one UDP receiver process. Even if the "<strong>terminated</strong>" lifetime is much smaller (11s vs minutes), I strongly believe it is still there when the "<strong>early</strong>" state is written. Does the "<strong>early</strong>" event checks the database/memory for a "<strong>terminated</strong>" event for the same call ID? Is it because of the missing locks maybe (<code class="notranslate">db_table_lock_type</code>, <code class="notranslate">db_table_lock_write</code>) ?</p>
<h3 dir="auto">Troubleshooting</h3>
<h4 dir="auto">Reproduction</h4>
<p dir="auto">Using 2 UDP receiver processes.</p>
<p dir="auto">User1 is watching (has <code class="notranslate">SUBSCRIBE</code>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 <code class="notranslate">INVITE</code>, after 183, almost immediately, a 486 "Busy Here" message is sent and the call is cancelled (call2 finished).</p>
<p dir="auto">I would not say that it is systematic, but easy enough to reproduce.</p>
<h4 dir="auto">Debugging Data</h4>

<h4 dir="auto">Log Messages</h4>

<h4 dir="auto">SIP Traffic</h4>

<pre class="notranslate"><code class="notranslate">(paste your sip traffic here)
</code></pre>
<h3 dir="auto">Possible Solutions</h3>

<h3 dir="auto">Additional Information</h3>
<ul dir="auto">
<li><strong>Kamailio Version</strong> - output of <code class="notranslate">kamailio -v</code></li>
</ul>
<pre class="notranslate"><code class="notranslate">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
</code></pre>
<ul dir="auto">
<li><strong>Operating System</strong>:<br>
Docker image around</li>
</ul>
<pre class="notranslate"><code class="notranslate">$ 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)
</code></pre>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/kamailio/kamailio/issues/3192">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABO7UZIAQZQQLW5JEHBUFTLVU77GHANCNFSM54DXH33Q">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/ABO7UZJW3SF4QJCWHUEGEO3VU77GHA5CNFSM54DXH332YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4TRGMTMA.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><kamailio/kamailio/issues/3192</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/kamailio/kamailio/issues/3192",
"url": "https://github.com/kamailio/kamailio/issues/3192",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>