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
_______________________________________________
Kamailio (SER) - Development Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
