[kamailio/kamailio] topos module may not be able to transparently transmit the update message (#2659)
**Description** We use below config to test the topology hiding function，when kamailio receive “update” message，doesn't send out，it will send to itself with destination port 5060； Sorry for raising this question again，I really don’t know what parameters need to be configured。And after I modified some codes, it could succeed probabilistically... Sorry again, excuse me
**Troubleshooting** ``` loadmodule "ndb_redis.so" loadmodule "topos_redis.so" loadmodule "topos.so" modparam("ndb_redis", "server", "name=srv8;addr=127.0.0.1;port=6381;db=2") modparam("topos", "storage", "redis") modparam("topos", "db_url", "redis://127.0.0.1:6381/2") modparam("topos_redis", "serverid", "srv8")
...Omit the configuration in the middle...
route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing xlog("L_INFO","yang yangyang testin to not here"); if (loose_route()){ if(is_method("INFO")){ route("INFO_SELF"); }
route(BYE); route(REINVITE); route(ACK); route(RELAY); } else { 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 $var(obj) = $sht(call_objects=>$ci); xlog("L_INFO","Call $ci: ACK received in A-Leg, $fU@$si:$sp -----> $rU@$Ri:$Rp relaying downstreamrouteWITHINDLG\n"); t_relay(); exit; } else { exit; } } xlog("L_INFO","yang in to not here"); sl_send_reply("404","Not here"); } exit; } }
``` -------- Call flow
``` UE-----------------PROXY-------------B2bua invite-------------->|------------------>invite 183<----------------|<------------------183 Prack------------ ->|------------------>Prack 200ok<-------------|<-----------------200ok update1---------->| |update2<-----------| | 404 not here-------> | ````
**Additional Information**
``` version: kamailio master (x86_64/linux)
```
### Possible Solutions
I set the log level to debug, and the comparison found that the logic of prack and update is different。After checking the code of topos, it is found that kamailio/src/modules/topos/tps_msg.c has a separate processing for prack.according to commit [37830f5](https://github.com/kamailio/kamailio/commit/37830f53b1f21fba5beef5d8e22913c4...) So I added update to the prack processing method，Later I found that when the B-side update message comes, it should follow the original logic。 So I distinguish whether to follow the modified logic according to ONREPLY_ROUTE。 But after probabilistic success，The problem is that the value returned by get_route_type（） is sometimes 1 and sometimes 4 Call flow after modification：
``` UE-----------------PROXY-------------B2bua invite-------------->|------------------>invite 183<----------------|<------------------183 Prack------------ ->|------------------>Prack 200ok<-------------|<-----------------200ok update1---------->|----------------->|update 200ok<-------------|<-----------------200ok |<-----------------|update2 | 404 not here---------> | ````
Here is the code I modified： /src/modules/topos/tps_msg.c 
I found something I think that is similar with UPDATEs and was able to handle in-dialog UPDATEs with TOPOS by adding `UPDATE` to the list of methods that get `record_route()` in `route[WITHINDLG]`, along with `NOTIFY` and `REFER`:
``` ... # sequential request withing a dialog should # take the path determined by record-routing if(loose_route()) { route(DLGURI); if(is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } else if(is_method("ACK")) { # ACK is forwarded statelessy route(NATMANAGE); route(RTPENGINE_MANAGE); } else if(is_method("NOTIFY|REFER|UPDATE")) { # Add Record-Route for in-dialog NOTIFY as per RFC 6665. record_route(); } route(RELAY); exit; }
... ```
I think this module should be insensitive to users after loading。I have found some ways to solve this problem, but I don’t know if the idea is correct。  i ues tps_dlg_detect_direction() to get diretion,This method always gets the correct result。 But now it seems that INFO and BYE have already mentioned REFER and NOTIFY and there should be problems, I still need to test。 @amessina ，Thank you for your reply。
The module requires record routing, so if the UPDATE requires to re-enforce Record-Route, then you have to do it. The `404 not here` is sent typically when a request within dialog comes without Route header.
I was aware that only NOTIFY requires to re-enforce Record-Route, but can be also a matter of UA implementation to want it for other requests. Without Record-Route/Route headers in the SIP requests, the topos module does not work.
@buzhaodi - try what @amessina suggested, and if works then we can add to the docs of the module to highlight this case.
I tried it many times, just to use the precondition (RFC3312) process. Upgrade from audio to video. No matter whether record_route() is added or not, it will not succeed. I modified it according to my screenshot above and it took effect. This may be a problem with my usage. I will close this question first, if there is a problem, I will give you feedback
Closed #2659.
-
Anthony Messina -
Daniel-Constantin Mierla
-
zhangyang