### Description I noticed an issue regarding loose_route() when using Topos module. My architecture is the following: ``` Client (behind NAT or not) ------> Kamailio (Access SBC) -----------> Kamailio (Interconnect SBC) -----------> Carrier ``` Kamailio Access SBC is listening on 2 interfaces: ``` Public interface : udp:A.A.A.A:5060 Core interface : udp:B.B.B.B:5060 ``` Kamailio Interconnect SBC is listening on 2 interfaces: ``` Core interface : udp:C.C.C.C:5060 Carrier-side interface : udp:D.D.D.D:5060 ``` TOPOS is configured only on second kamailio box (Interconnect SBC). Record routing is used on both kamailios. TOPOS module is configured as follows: ``` modparam("ndb_redis", "server", "name=srv1;addr=127.0.0.1;port=6379") modparam("topos_redis", "serverid", "srv1") modparam("topos", "storage", "redis") modparam("topos", "contact_mode", 1) modparam("topos", "cparam_name", "id") modparam("topos", "rr_update", 1) ``` RR module is configured as follows: ``` modparam("rr", "enable_full_lr", 1) modparam("rr", "append_fromtag", 1) modparam("rr", "enable_double_rr", 1) ``` For an incomoing INVITE (direction: client to carrier) all is fine and topos can strip headers on bleg and insert the cookie on bleg contact as a param. When Callee sends a BYE or re-INVITE, topos inserts route headers in aleg as shown in the next trace: (BYE as received from the carrier on the carrier-side interface D.D.D.D) ``` BYE sip:D.D.D.D:5060 SIP/2.0 Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKrdhsvc001omkvssqvfk0sd0185mt1.1 From: <sip:+33123456789@my-carrier-domain;transport=UDP;user=phone>;tag=SD69ao497-1472568650-1635329820043 To: <sip:+33987654321@my-own-domain;transport=UDP;user=phone>;tag=3ab10616 Call-ID: NjZjMDgyMGMxNzdkN2FhYmJlYzQyYjA5YWIzZThmZmI. CSeq: 547381883 BYE Max-Forwards: 64 Content-Length: 0 Route: <sip:D.D.D.D;r2=on;lr=on;ftag=3ab10616>,<sip:C.C.C.C;r2=on;lr=on;ftag=3ab10616> Route: <sip:B.B.B.B;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2>,<sip:A.A.A.A;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2> P-SR-XUID: atpsh-617925e5-82a5-1 ``` Topos on the kamailio interconnect handles the BYE/re-INVITE and forward it to the second interface C.C.C.C as shown in the following trace: ``` BYE sip:A.A.A.A;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2 SIP/2.0 Via: SIP/2.0/UDP 185.164.213.110;branch=z9hG4bKbd7.ab692eeb60369aa3a5e07f6b63cc9dd7.0 From: <sip:+33123456789@my-carrier-domain;transport=UDP;user=phone>;tag=SD69ao497-1472568650-1635329820043 To: <sip:+33987654321@my-own-domain;transport=UDP;user=phone>;tag=3ab10616 Call-ID: NjZjMDgyMGMxNzdkN2FhYmJlYzQyYjA5YWIzZThmZmI. CSeq: 547381883 BYE Max-Forwards: 63 Content-Length: 0 Route: <sip:C.C.C.C;r2=on;lr=on;ftag=3ab10616> Route: <sip:B.B.B.B;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2> Contact: <sip:+33123456789@10.3.60.45;id=atpsh-617925e5-82a5-1> ``` When the BYE/re-INVITE request reaches the C.C.C.C interface, it is then forwarded directly to the ruri sip:A.A.A.A. Or what I expect to receive in C.C.C.C interface is the following : ``` BYE <HERE SHOULD BE THE CALLER CONTACT URI> SIP/2.0 Via: SIP/2.0/UDP 80.10.231.173:5060;branch=z9hG4bKrdhsvc001omkvssqvfk0sd0185mt1.1 From: <sip:+33123456789@my-carrier-domain;transport=UDP;user=phone>;tag=SD69ao497-1472568650-1635329820043 To: <sip:+33987654321@my-own-domain;transport=UDP;user=phone>;tag=3ab10616 Call-ID: NjZjMDgyMGMxNzdkN2FhYmJlYzQyYjA5YWIzZThmZmI. CSeq: 547381883 BYE Max-Forwards: 64 Content-Length: 0 Route: <sip:D.D.D.D;r2=on;lr=on;ftag=3ab10616> Route: <sip:C.C.C.C;r2=on;lr=on;ftag=3ab10616> Route: <sip:B.B.B.B;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2> Route: <sip:A.A.A.A;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2> Contact: <sip:+33123456789@10.3.60.45;id=atpsh-617925e5-82a5-1> ``` I could work around this issue by doing the following : 1. When receiving the BYE/re-INVITE on interface D.D.D.D, I explode the Route headers, delete old route headers and create new ones in order from the result of explode 2. I update the ru with the contact uri which I stored in a htable when the initial INVITE was received ``` # Manage outgoing branches branch_route[MANAGE_BRANCH] { xdbg("new branch [$T_branch_idx] to $ru\n"); # TOPOS FIX if (is_method("INVITE")) { $sht(tpsindlg=>$ci) = $ci; $sht(tpsindlg=>$ci:ft) = $ft; $sht(tpsindlg=>$ci:ct) = $ct; } } route[WITHINDLG] { if (!has_totag()) return; # Fix bad Route Headers caused by TOPOS module if ($Ri == "D.D.D.D") { $var(rh0) = $(hdr(Route)[0]{s.select,0,,}); $var(rh1) = $(hdr(Route)[0]{s.select,1,,}); $var(rh2) = $(hdr(Route)[1]{s.select,0,,}); $var(rh3) = $(hdr(Route)[1]{s.select,1,,}); remove_hf_re("^Route$"); append_hf("Route: $var(rh0)\r\n"); append_hf("Route: $var(rh1)\r\n"); append_hf("Route: $var(rh2)\r\n"); append_hf("Route: $var(rh3)\r\n"); } # sequential request within a dialog should # take the path determined by record-routing if (loose_route()) { # Fix R-URI caused by TOPOS module if ($Ri == "D.D.D.D") { if ($ci == $sht(tpsindlg=>$ci) && $tt == $sht(tpsindlg=>$ci:ft)) { $ru = $(sht(tpsindlg=>$ci:ct){s.strip,1}{s.striptail,1}); if (is_method("BYE")) { $sht(tpsindlg=>$ci) = $null; $sht(tpsindlg=>$ci:ft) = $null; $sht(tpsindlg=>$ci:ct) = $null; } } } route(RELAY); exit; } if (is_method("ACK")) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server route(RELAY); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); exit; } ``` Could you please tell if this is a normal behavior by TOPOS module or is it a bug? Thank you. -- 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/2905