Hello all, It seems there has been a regression between kamailio 5.1.0 and 5.1.1 with the topos module. ### Description Kamailio acts as a proxy for asterisk instances residing in a private IP range and other entities (subscribers, peers) residing on other networks. This is a multihomed installation, with 4 interfaces total (but mhomed is set to no). Just by upgrading to 5.1.1, topos will complain with: `tps_storage_record(): no local address - do record routing for all initial requests` for re-INVITEs within an established dialog. This warning is also printed for other in-dialog requests (BYE, ACK). Also common behaviour with all those in-dialog requests is that if the request received by kamailio had a Contact header, topos will strip it before relaying (true for re-INVITE and ACK). For ACK there seem to be no obvious side-effects, because there's no response to it. For BYE, its 200 OK response is routed properly, in contrast with the 200 OK to the re-INVITE. During the processing of 200 OK to re-INVITE, the following relevant lines are printed in the logs: ``` DEBUG: topos [tps_msg.c:1031]: tps_response_sent(): handling outgoing response DEBUG: topos [tps_msg.c:1038]: tps_response_sent(): no x-branch header - nothing to do ``` During the processing of 200 OK to BYE, the following relevant lines are printed in the logs: ``` DEBUG: topos [tps_msg.c:1031]: tps_response_sent(): handling outgoing response DEBUG: topos [tps_msg.c:376]: tps_pack_message(): compacted headers - x_via1: [SIP/2.0/UDP 192.168.1.1:5060;rport=5060;received=2.2.2.2;branch=z9hG4bK-c1a29abe](86) - x_via2: [](0) - x_vbranch1: [z9hG4bK-c1a29abe](16) DEBUG: topos [tps_msg.c:485]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [](0) - s_rr: [](0) DEBUG: topos [tps_msg.c:490]: tps_pack_message(): compacted headers - as_contact: [](0) - bs_contact: [](0) DEBUG: topos [tps_storage.c:124]: tps_storage_lock_get(): tps lock get: 436 ``` ### Troubleshooting Downgrading to 5.1.0 fixes the issue, with no changes in configuration. #### Reproduction Most SIP logic adheres to the sample configuration file, one difference being that record_route() is performed regardless of request method, as required for topos (although to reproduce this issue this change is not needed, as record_route() is performed for INVITEs anyway with the sample configuration file). To reproduce on my setup, I initiate a call which kamailio will forward to asterisk, making sure topos is loaded. I then put the call on hold to generate a re-INVITE and watch as a) outgoing INVITE lacks a Contact header and b) Final reply to re-INVITE won't be routed, instead causing several retransmissions from asterisk. #### SIP Traffic I'm not sure SIP Traffic is relevant here, as only the Contact header missing is what strikes me as most odd. I can share pcaps and logs privately if needed. ### Additional Information * **Kamailio Version** Kamailio 5.1.1 on debian stretch from sipwise's repo * **Operating System**: ``` Debian 9.1 ``` * **Other pertinent configuration information**: * The following issues might be relevant: #1356, #1350 * This kamailio box has several network interfaces. mhomed is not used, instead force_send_socket is called where necessary. -- 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/1421