<!-- 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 Kamailio seems to fail to properly route in-dialog SUBSCRIBE with the topos module enabled. In this configuration, SUBSCRIBEs are expected to be delivered to a downstream UAS, an asterisk instance in the internal network.
record_route() is executed for all initial requests, including SUBSCRIBEs. Routing is performed correctly with the topos module disabled, no other modifications were needed. <!-- Explain what you did, what you expected to happen, and what actually happened. -->
### Troubleshooting I haven't been able to work around this issue in any other way other than disabling the topos module. #### Reproduction The configuration used is a heavily modified version of the example configuration file, but the handling of SUBSCRIBEs is generally simple. The initial SUBSCRIBE is subject to some tests, the R-URI is edited and dispatched to a farm of asterisk servers based on some criteria. Record Routing is enforced, so subsequent in-dialog re-SUBSCRIBEs are expected to be routed with loose_route(), which doesn't seem to handle things properly. <!-- If the issue can be reproduced, describe how it can be done. -->
#### Debugging Data I'm attaching kamailio logs with debug=4, cfg_trace <!-- If you got a core dump, use gdb to extract troubleshooting data - full backtrace, local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile bt full info locals list
If you are familiar with gdb, feel free to attach more of what you consider to be relevant. -->
#### Log Messages See attachments <!-- Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
#### SIP Traffic Please see: https://www.cloudshark.org/captures/d2643aae7f2a <!-- If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
### Possible Solutions
Using topoh instead for topos, but unfortunately this will break communication for other reasons (messages too large/UDP fragmentation for some peers).
### Additional Information * **Kamailio Version** Tried with kamailio 5.1.6 and kamailio 5.3.0-dev0 deb.kamailio.org repositories were used to acquire binaries for both versions
* **Operating System**: Debian Stretch <!-- 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`) --> [resubscribe.log](https://github.com/kamailio/kamailio/files/2586440/resubscribe.log)
The module was designed to track voip dialogs (created by INVITE) for interconnected services/servers. It will require some C development to make it work for presence dialogs (created by SUBSCRIBE), which are expected to be handled by local server, not sent to a foreign server.
Do you want to mask the topology for presence dialogs or it just breaks as you want to use it for INVITE? If not, you can skip applying topos for SUBSCRIBE by using the event_route executed by topos in 5.2 or master.
Thanks for the reply. I mostly opened this issue for tracking, and to investigate if a potential fix is trivial or requires substantial work.
We are currently considering the alternatives, that is either wait for 5.2 and use event_route to skip topos processing for subscribes, or deploy a separate kamailio instance with either no topology hiding at all, or topoh-enabled topology hiding instead...
Closing for long time inactivity, all the stable branches offer the possibility to skip handing subscribes. For handling them with topology stripping, a pull request can be made.
Closed #1724.