topos_redis sets TTL on dialogs including presence SUBSCRIPTIONs. Once the TTL expires on those SUBSCRIBEs the topos module fails to route the in-dialog NOTIFYs & subsequent SUBSCRIBEs. That causes presence to break.
loadmodule "topos_redis.so"
modparam("topos_redis", "serverid", "srv1")
loadmodule "topos.so"
modparam("topos", "storage", "redis")
load up topos and topos_redis module, set expiration in topos_redis to 600 (just to reproduce this) create a dialog, either INVITE or SUBSCRIBE anything is fine. Once the TTL is expired the in-dialog routing of packets fail in route[WITHINDLG] with 404 Not here.
The route[WITHINGDLG] is just the standard one for us(can be pasted when needed)
I can set the TTL to few days, but doing that brought the problem back for SUBSCRIBEs since the desk phone stay alive for weeks at a stretch.
I could only think about renewing/refreshing the TTL for dialogs whenever they're loaded, so I modified the topos and topos_redis module for this and tested it. so far it works well and SUBSCRIBEs/NOTIFYs have been getting routed perfectly fine over the course of a week+
kamailio -v
version: kamailio 5.4.3 (x86_64/linux) a96451-dirty
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_BLACKLIST, 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: a96451 -dirty
compiled on 23:44:16 Feb 20 2021 with gcc 8.3.0
Debian GNU/Linux 10 (buster)
Linux sbc-va-2 4.19.0-13-cloud-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.