I was testing topos with a mysql backend and all was fine. But since the purpose of this machine doesn't require a complete mysqlserver I tried the redis backend. With redis the calls will drop after some timeout (somewhere < 450 seconds (session timer set to 900)).

Config: # topos modparam("ndb_redis", "server", "name=srv2;addr=127.0.0.1;port=6379;db=2") modparam("topos", "storage", "redis") modparam("topos_redis", "serverid", "srv2")

#modparam("topos", "storage", "db") #modparam("topos", "db_url", DBURL)

modparam("topos", "mask_callid", 0) modparam("topos", "sanity_checks", 0) modparam("topos", "branch_expire", 180) modparam("topos", "dialog_expire", 10800) modparam("topos", "clean_interval", 60)

The call will end on the first session-time firing with a "404 Not here"

Debug contains:

Mar 27 12:20:56 kam kamailio[11649]: DEBUG: topos_redis [topos_redis_storage.c:962]: tps_redis_load_dialog(): loading dialog record for [d:z:atpsh-5aba19b2-2d7f-2] Mar 27 12:20:56 kam kamailio[11649]: DEBUG: ndb_redis [redis_client.c:878]: redisc_exec_argv(): rsrv->ctxRedis = 0x55a7c8da8500 Mar 27 12:20:56 kam kamailio[11649]: DEBUG: topos_redis [topos_redis_storage.c:980]: tps_redis_load_dialog(): hmap with key [d:z:atpsh-5aba19b2-2d7f-2] not found

This records was inserted/updated:

Mar 27 12:17:10 kam kamailio[11647]: DEBUG: topos_redis [topos_redis_storage.c:253]: tps_redis_insert_dialog(): inserted dialog record for [d:z:atpsh-5aba19b2-2d7f-2] with argc 26 Mar 27 12:17:10 kam kamailio[11647]: DEBUG: topos_redis [topos_redis_storage.c:282]: tps_redis_insert_dialog(): expire set on dialog record for [d:z:atpsh-5aba19b2-2d7f-2] with argc 3 Mar 27 12:17:11 kam kamailio[11648]: DEBUG: topos_redis [topos_redis_storage.c:962]: tps_redis_load_dialog(): loading dialog record for [d:z:atpsh-5aba19b2-2d7f-2] Mar 27 12:17:11 kam kamailio[11648]: DEBUG: topos_redis [topos_redis_storage.c:1293]: tps_redis_update_dialog(): updated dialog record for [d:z:atpsh-5aba19b2-2d7f-2] with argc 6 Mar 27 12:17:11 kam kamailio[11648]: DEBUG: topos_redis [topos_redis_storage.c:962]: tps_redis_load_dialog(): loading dialog record for [d:z:atpsh-5aba19b2-2d7f-2] Mar 27 12:17:11 kam kamailio[11648]: DEBUG: topos_redis [topos_redis_storage.c:1293]: tps_redis_update_dialog(): updated dialog record for [d:z:atpsh-5aba19b2-2d7f-2] with argc 6 Mar 27 12:17:11 kam kamailio[11650]: DEBUG: topos_redis [topos_redis_storage.c:962]: tps_redis_load_dialog(): loading dialog record for [d:z:atpsh-5aba19b2-2d7f-2] Mar 27 12:17:11 kam kamailio[11650]: DEBUG: topos_redis [topos_redis_storage.c:962]: tps_redis_load_dialog(): loading dialog record for [d:z:atpsh-5aba19b2-2d7f-2] Mar 27 12:17:11 kam kamailio[11650]: DEBUG: topos_redis [topos_redis_storage.c:1381]: tps_redis_end_dialog(): updated on end the dialog record for [d:z:atpsh-5aba19b2-2d7f-2] with argc 6 Mar 27 12:17:11 kam kamailio[11650]: DEBUG: topos_redis [topos_redis_storage.c:1412]: tps_redis_end_dialog(): expire set on branch record for [d:z:atpsh-5aba19b2-2d7f-2] with argc 3

It looks like the last update/expire sets the timeout to 180s, so the not found is reasonably expected. But why is it that these records aren't deleted in the mysql backend?

0000 00 00 03 04 00 06 00 00 00 00 00 00 00 00 08 00 ................ 0010 45 00 00 6d 0a 52 40 00 40 06 32 37 7f 00 00 01 E..m.R@.@.27.... 0020 7f 00 00 01 b1 0c 18 eb c4 68 f0 3b 93 17 20 b0 .........h.;.. . 0030 80 18 03 d6 fe 61 00 00 01 01 08 0a 00 08 50 67 .....a........Pg 0040 00 08 50 67 2a 33 0d 0a 24 36 0d 0a 45 58 50 49 ..Pg*3..$6..EXPI 0050 52 45 0d 0a 24 32 35 0d 0a 64 3a 7a 3a 61 74 70 RE..$25..d:z:atp 0060 73 68 2d 35 61 62 61 31 39 62 32 2d 32 64 37 66 sh-5aba19b2-2d7f 0070 2d 32 0d 0a 24 33 0d 0a 31 38 30 0d 0a -2..$3..180..