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, view it on GitHub, or mute the thread.