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.