23 Aug
2022
23 Aug
'22
6:20 a.m.
### Description
Right now, usrloc keepalive method use a somewhat static call-id, built with the prefix
`ksrulka-` followed by the number of keepalives sent and the contact index of each AoR
pinged.
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.
Basically the following happens:
- user1 registers to proxy
- user2 registers to proxy
- different timer processes handles the keepalives
- call-ids are the same (it start always from `ksrulka-1.1`)
OR
- user1 registers to proxyA
- user2 registers to proxyB
- both proxies start sending keepalives
- call-ids are the same (it start always from `ksrulka-1.1`) from both proxies.
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.
Can be also annoying if logs from all proxies are aggregated, making a bit problematic
filtering by call-id.
### Expected behavior
Call-id should be somewhat random.
#### SIP Traffic
This is an example for same call-id used for pinging two different AoR on same proxy.
```
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
```
and
```
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
```
### Possible Solutions
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.
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.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
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
```
* **Operating System**:
Using official docker images of kamailio 5.6.1.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3225
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3225(a)github.com>