Hi Denys
I'm testing the logic below, for now, it looks very promising. It seems like there is access to dialog variables.
/* SIP-UA (Snom) <--> Kamailio (w/o topos) <--> FreeSWITCH SIP-UA (Yealink) <--> Kamailio (with topos) <--> FreeSWITCH
Ok I think I know, why this does work for you, but not for me.
We have a very similar situation, where we use kamailio as registrar like you do, but another kamailio (in router role) where you use FreeSwitch.
The situation where we had calls signaling being completely messed up by topos would be...
Call from Switch through Kamailio (with topos) to Yealink. Yealink is busy! Kamailio with topos activated at that moment, engages failure route. Failure route determines YeaLink customer wants call forward on busy to another number. Kamailio routes call to Switch to take care to route to call to the CFW destination. Switch determines, that CFW destination is the number of the Snom UA. Switch routes call to Kamailio (first call leg still present with topos engaged). Switch (in case it is Kamailio, it is a proxy, same CallID, same FromTag from topos point of view)
=> Now things break. (don't ask me about the exact details how they broke, it was just not behaving as expected).
I guess in your situation this works, as FreeSwitch probably works as a B2BUA, therefore when the call is routed to kamailio a 2nd time, it has a different CallID and FromTag and thus does not break the first existing call-leg still known to the kamailio registrar.