<!-- 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 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. <!-- Explain what you did, what you expected to happen, and what actually happened. -->
### Troubleshooting ``` loadmodule "topos_redis.so" modparam("topos_redis", "serverid", "srv1")
loadmodule "topos.so" modparam("topos", "storage", "redis") ```
#### Reproduction 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. <!-- If the issue can be reproduced, describe how it can be done. -->
### Possible Solutions 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+
<!-- If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix. -->
### Additional Information
* **Kamailio Version** - output of `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
```
* **Operating System**:
<!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `uname -a`) -->
``` 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 ```
* **Suggested Fix/Patch**: https://github.com/kamailio/kamailio/compare/master...goharahmed:master
As written in the readme of the topos module, it is not (yet) designed for presence dialogs.
I would not expect that only increasing the expire value for SUBSCRIBE records is going to make it work, because then the NOTIFY requests sent for that subscription need to be updated. With some scenarios, attributes from another dialogs maybe in the xml body of presence messages. What kind of presence dialogs you tested with? Dialog info (blf) or user presence?
Thank you so much @miconda for your review. I definitely missed the note in topos module. However, the patch that I have applied goes for all sort of dialogs and not just subscribes.
https://github.com/kamailio/kamailio/compare/master...goharahmed:master
We've tested it against BLF subscribes of Event: dialog and message-summary , but any other dialog benefits alike. I can test for 'reg'/'reginfo' events too. Our network topology is:
``` phones<====> [Kamailio:topos+topos_redis] ~~~~~subscribes~~~>[Presence-Kamailio] ||~~~invites~~~>[MediaServers] ```
The TTL expiration renewal is not set on branches, I don't know what could be the implications.
How can I help to test this change thoroughly?. Over the course of 1.5 week now we've not seen any problematic reports from support thus far, still keeping this under observation.
I am going to review the changes in your branch and try to integrate them somehow.
Thanks Daniel, The codes worked very well for about 3+weeks now. Based on your last comment I reviewed the topos module and bypassed the whole SUSBCRIBE/presence method from topos event route and thats working fine as well. The reason why I moved back to basics was because redis is still a cache and we noticed Hits vs Misses in redis and did not want to take any chances with random spotty complaints from customers about presence.
@goharahmed - a PR related more or less to the same topic was just merged earlier today:
* https://github.com/kamailio/kamailio/pull/2662
Can you try to see if it brings what you need?
I may still try to push the changes to update the lifetime of dialogs, but the PR had code targeting SUBSCRIBE and can be the proper way to have support for presence.
Closing it, support for SUBSCRIBE handling was added by #2662. If there is any problem with that approach, open an issue with details about what is not working with the current version of the module in master branch.
Closed #2652.
-
Daniel-Constantin Mierla -
goharahmed