[sr-dev] [kamailio/kamailio] topos 5.1.1 regression: missing Contact header in in-dialog requests despite record_route() having been executed for initial request (#1421)

[George Diamantopoulos]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180130/b1a17180/attachment.html>