Pandi1981 created an issue (kamailio/kamailio#4208)
We are facing an issue while using TOPOS in Kamailio P-CSCF (running under Docker). Kamailio version: 6.0.0 operating system: "10 (buster)"
**Call Flow & Issue Description:** Note: Public IP and Private IP mapping using the below configuration.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ listen=udp:LOCAL_IP:5060 name "internal" listen=udp:LOCAL_IP:6080 advertise PUBLIC_IP:6080 name "external" ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
**Call Flow (INVITE):**
A-Party --> Kamailio P-CSCF (Public IP) --> Kamailio P-CSCF (Private IP) --> Kamailio S-CSCF (Private IP) B-Party <-- Kamailio P-CSCF (Public IP) <-- Kamailio P-CSCF (Private IP) <-- Kamailio S-CSCF (Private IP)
Everything works correctly up to the point where the 200 OK is received by the A-Party. However, when the A-Party sends the ACK, it is received by the Kamailio P-CSCF but is not forwarded to the B-Party.
Upon investigation, we found that when Kamailio receives the ACK from the A-Party, the rr (Record-Route) module fails to recognize its own Route header and thus falls back to strict routing instead of performing loose routing. This results in an incorrect rewrite of the Request-URI of the ACK, causing it to fail to reach the B-Party. Essentially, the Route header is not popped as expected and the ACK routing breaks.
TOPOS module is configured as follows: loadmodule "topos_redis.so" loadmodule "ndb_redis.so" loadmodule "topos.so"
modparam("ndb_redis", "server", "name=tps;addr=127.0.0.1;port=6379;db=0") modparam("topos", "storage", "redis") modparam("topos_redis", "serverid", "tps")
modparam("topos", "rr_update", 1) modparam("topos", "contact_mode", 1) modparam("topos", "xavu_field_a_contact", "a_contact") modparam("topos", "xavu_field_b_contact", "b_contact") modparam("topos", "xavu_cfg", "tps")
Please guide us how to achieve and what we are doing wrong.
linuxmaniac left a comment (kamailio/kamailio#4208)
Upon investigation, we found that when Kamailio receives the ACK from the A-Party, the rr (Record-Route) module fails to recognize its own Route header and thus falls back to strict routing instead of performing loose routing.
could you maybe attach a kamailio log with topos in debug mode for that scenario?
Pandi1981 left a comment (kamailio/kamailio#4208)
[topos_github.log](https://github.com/user-attachments/files/19795756/topos_github.log)
Please find the below details as per the node and IP. PCSCF_IP : 192.168.208.2 ICSCF_IP : 192.168.208.3 SCSCF_IP : 192.168.208.4 AS_IP : 192.168.208.8
Pandi1981 left a comment (kamailio/kamailio#4208)
Any update Please? Please let me know if you need any other information.
Pandi1981 left a comment (kamailio/kamailio#4208)
Please guide us...it's a blocking issue as of now!!
Pandi1981 left a comment (kamailio/kamailio#4208)
@linuxmaniac To understand TOPOS behaviour better, we simulated interconnection between two different providers and its working fine. In Kamailio,We suspected that both the originating and terminating INVITE requests were staying within the same network, which could impact proper ACK/BYE routing to the B-party.