[usrloc] Make usrloc keepalive call-id more random

[xadhoom]

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.

[miconda]

I didn't care much about randomness of call-id thinking that also from-tag changes (which has internal unique id of the record) and that has to be also used for dialog matching.

But makes sense to make it more random from the point of view of analysing the sip traffic and aggregations on call-id. I will look at the code soon and see what can be done.

[xadhoom]

If for you is ok to modify the call-id generation in usrloc, I can try to setup a PR. I think that appending a cryptorand() value to the keeepalive call-id is sufficient.

[henningw]

crytorand() will produce cryptographic secure numbers, which might be a bit overkill. Using fastrand() is probably enough, this is ISAAC with a really long period.

[miconda]

I pushed a commit to add a random and the pid to the call id. Maybe in long term will be replaces with a random string, but for the moment should be fine. Feel free to make PRs with other enhancement there and they will be reviewed.

The commit will be backported soon.

Closing this one.