[sr-dev] [kamailio/kamailio] topos/topos_redis canceled and failed calls not deleted in redis (#2012)

ohammami notifications at github.com
Thu Jul 18 16:29:23 CEST 2019


<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.

If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:

  * http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:

  * http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.

If there is no content to be filled in a section, the entire section can be removed.

You can delete the comments from the template sections when filling.

You can delete next line and everything above before submitting (it is a comment).
-->

### Description

`topos-redis` does not clean entries for failed and canceled calls.

modules are loaded in this order:

```
...
loadmodule "topos.so"
loadmodule "ndb_redis.so"
loadmodule "topos_redis.so"

# ----- ndb_redis params -----
modparam("ndb_redis", "server", "name=srvC;addr=REDIS_HOST;port=REDIS_PORT;db=REDIS_DB_TOPOS")

# ----- topos params -----
modparam("topos", "storage", "redis")
modparam("topos_redis", "serverid", "srvC")
modparam("topos", "mask_callid", 0)
modparam("topos", "sanity_checks", 0)

modparam("topos", "branch_expire", 30)
modparam("topos", "dialog_expire", 14400)
modparam("topos", "clean_interval", 10)
...
```

When a call is answered the timer are working fine and the records are cleaned after branch_expire timer.


1. call established

```
10.0.1.11:6379[9]> KEYS *
1) "b:x:z9hG4bKe33b.1c2d440696a8e6d47f678fcf80962608.0"
2) "d:z:atpsh-5d305fc4-51c0-1"
3) "b:x:INVITE:6cbb3f3c-0470-474a-90e9-1d3f07d42a1a:as32b06c60"
```

2. after 30s

```
10.0.1.11:6379[9]> KEYS *
1) "d:z:atpsh-5d305fc4-51c0-1"
```

4. call ends

```
10.0.1.11:6379[9]> KEYS *
1) "b:x:z9hG4bKa4f4.d283ab69d26e3eadea338bb3cc28860e.0"
2) "d:z:atpsh-5d305fc4-51c0-1"
```

5. after 30s

```
10.0.1.11:6379[9]> KEYS *
(empty list or set)
```

#### Issue description

When the call fails or it's canceled 

```
10.0.1.11:6379[9]> KEYS *
1) "b:x:z9hG4bK6b04.0b594f71aba72f5f7f6f3ca8d7e57f04.0"
2) "d:z:atpsh-5d305fc4-51c3-1"
3) "b:x:INVITE:0319e114-c5b9-4dfc-91f0-392dc4239255:as018c9b6b"
```
after 30s

```
10.0.1.11:6379[9]> KEYS *
1) "d:z:atpsh-5d305fc4-51c3-1"
10.0.1.11:6379[9]> TTL "d:z:atpsh-5d305fc4-51c3-1"
(integer) 14319
```

The record `d:z:atpsh-5d305fc4-51c3-1` is not cleaned by the cancel or busy...it will persist in the redis until it expires.

I upgraded my machine from 5.1.3 to 5.1.8 after finding this fix #1608 which I noticed in the beginning.

### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.1.8 (x86_64/linux) c7a172
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_BLACKLIST, 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: c7a172
compiled on 05:42:57 Jun 19 2019 with gcc 4.8.5
```

* **Operating System**:

```
3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Lin
```

```
CentOS Linux release 7.4.1708 (Core)
```


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2012
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20190718/50813536/attachment.html>


More information about the sr-dev mailing list