<p></p>
<h3 dir="auto">Description</h3>
<p dir="auto">Right now, usrloc keepalive method use a somewhat static call-id, built with the prefix <code class="notranslate">ksrulka-</code> followed by the number of keepalives sent and the contact index of each AoR pinged.</p>
<p dir="auto">This means that pings to different contacts from different processes (when using timer_procs in usrloc) or when you have multiple proxies each handling a subset of registrar requests, you can have duplicated call-ids.</p>
<p dir="auto">Basically the following happens:</p>
<ul dir="auto">
<li>user1 registers to proxy</li>
<li>user2 registers to proxy</li>
<li>different timer processes handles the keepalives</li>
<li>call-ids are the same (it start always from  <code class="notranslate">ksrulka-1.1</code>)</li>
</ul>
<p dir="auto">OR</p>
<ul dir="auto">
<li>user1 registers to proxyA</li>
<li>user2 registers to proxyB</li>
<li>both proxies start sending keepalives</li>
<li>call-ids are the same (it start always from  <code class="notranslate">ksrulka-1.1</code>) from both proxies.</li>
</ul>
<p dir="auto">While this is not a routing problem, bug or whatever, it can be annoying if traffic is analyzed with tools like sngrep, which group messages by the Call-ID header, and if you run sngrep on the edge proxy you'll see both keepalive messages under the same call.<br>
Can be also annoying if logs from all proxies are aggregated, making a bit problematic filtering by call-id.</p>
<h3 dir="auto">Expected behavior</h3>
<p dir="auto">Call-id should be somewhat random.</p>
<h4 dir="auto">SIP Traffic</h4>
<p dir="auto">This is an example for same call-id used for pinging two different AoR on same proxy.</p>
<pre class="notranslate"><code class="notranslate">2022/08/23 08:53:35.717668 172.23.42.2:5060 -> 172.23.42.1:5060
OPTIONS sip:user1@192.168.10.123:23045;transport=udp SIP/2.0
Via: SIP/2.0/UDP 172.23.42.2:5060;branch=z9hG4bKx.323.1.0
Route: <sip:172.23.42.1;lr;received=sip:client.public.ip:23045;r2=on>,<sip:kamailio.public.ip;lr;received=sip:client.public.ip:23045;r2=on>
From: <sip:pinger@test.proxy>;tag=uloc-1-6304863f-61-2-8a27955a-6304958f-af2a3-143.1
To: <sip:user1@example.com>
Call-ID: ksrulka-323.1
CSeq: 80 OPTIONS
Content-Length: 0

</code></pre>
<p dir="auto">and</p>
<pre class="notranslate"><code class="notranslate">2022/08/23 08:53:35.897076 172.23.42.2:5060 -> 172.23.42.1:5060
OPTIONS sip:user2@192.168.10.130:5060 SIP/2.0
Via: SIP/2.0/UDP 172.23.42.2:5060;branch=z9hG4bKx.323.1.0
Route: <sip:172.23.42.1;lr;received=sip:client.public.ip:60058;r2=on>,<sip:kamailio.public.ip;lr;received=sip:client.public.ip:60058;r2=on>
From: <sip:pinger@test.proxy>;tag=uloc-1-6304863f-61-1-86c70e53-6304958f-dafc7-143.1
To: <sip:user2@example.com>
Call-ID: ksrulka-323.1
CSeq: 80 OPTIONS
Content-Length: 0
</code></pre>
<h3 dir="auto">Possible Solutions</h3>
<p dir="auto">To be 100% honest I don't get why such method of generating call-ids has been chosen. The only useful thing I see is that you can have a clue of how many keepalives ping have been sent by each process / proxy while inspecting sip traces. I don't see any usage of the fixed call-id in handling responses. But I may be wrong, since I'm new to kamailio.</p>
<p dir="auto">What could be done is to add a random string to the call-id, like nathelper does. If this is acceptable, I can try to create a PR for that.</p>
<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.6.1 (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 9.4.0
</code></pre>
<ul dir="auto">
<li><strong>Operating System</strong>:<br>
Using official docker images of kamailio 5.6.1.</li>
</ul>

<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/3225">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABO7UZPALECNK2VRY7BJYVLV2SQW3ANCNFSM57K4HLXQ">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/ABO7UZOGWW27KWDEAZKCBBLV2SQW3A5CNFSM57K4HLX2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4UCUFX2A.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/3225</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/3225",
"url": "https://github.com/kamailio/kamailio/issues/3225",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>