Denis,

You probably need to specify the full address, including the mask, like: 1.1.1.1/32

Regards, Ilie

On Thu, 11 Jul 2024 at 14:19, Denys Pozniak via sr-users < sr-users@lists.kamailio.org> wrote:

I tested - no changes, plus an error appeared in the syslog:

*CRITICAL: <core> [core/ip_addr.c:234]: ip_addr2sbuf(): unknown address family 0CRITICAL: <core> [core/ip_addr.c:234]: ip_addr2sbuf(): unknown address family 0*

modparam("topos", "event_mode", 9)

event_route[topos:msg-outgoing] { if ( $sndto(ip) == "1.1.1.1" ) { xlog("L_WARN","[msg-outgoing] $rm/$rU/$sndto(ip) \n"); drop; } }

event_route[topos:msg-receiving] { if ( $si == "1.1.1.1" ) { xlog("L_WARN","[msg-receiving] $rm/$rU/$si \n"); drop; } }

чт, 11 июл. 2024 г. в 14:20, Patrick Karton patrickarton@hotmail.com:

...

You have to use topos:receiving instead of topos:incoming.

Le 11 juil. 2024 08:48, Denys Pozniak via sr-users < sr-users@lists.kamailio.org> a écrit :

Hello! I need to disable topos for one specific SIP trunk (in-out), it looks like it’s enough to use event_route with IP address filtering. But for some reason, the incoming INVITE from the peer still gets processed by topos and I also don’t see a mention of [msg-incoming] in the logs, only this:

WARNING: <script>: [msg-outgoing] OPTIONS/you/1.1.1.1

Code snippet:

loadmodule "topos.so" modparam("topos", "db_url", DBURL) modparam("topos", "contact_mode", 1) modparam("topos", "header_mode", 1) modparam("topos", "methods_noinitial", "OPTIONS,SUBSCRIBE,PUBLISH") modparam("topos", "dialog_expire", 7210) modparam("topos", "rr_update", 1) modparam("topos", "event_mode", 5) /* 1 - execute event_route[topos:msg-outgoing] 2 - execute event_route[topos:msg-sending] 4 - execute event_route[topos:msg-incoming] 8 - execute event_route[topos:msg-receiving] */

request_route { .... event_route[topos:msg-outgoing] { if ( $sndto(ip) == "1.1.1.1" ) { xlog("L_WARN","[msg-outgoing] $rm/$rU/$sndto(ip) \n"); drop; } } }

event_route[topos:msg-incoming] { if ( $si == "1.1.1.1" ) { xlog("L_WARN","[msg-incoming] $rm/$rU/$si \n"); drop; } }

# kamailio -v version: kamailio 5.7.1 (x86_64/linux) 1cf389-dirty

--

BR, Denys Pozniak

--

BR, Denys Pozniak

---

Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

Hey! I'm still trying to figure out how to implement an exception from topos processing for a specific type of SIP device (IP is not fixed) based on User-Agent. If anyone has any ideas, I'd appreciate some help!

пт, 12 июл. 2024 г. в 11:58, Maria Jonas via sr-users < sr-users@lists.kamailio.org>:

Hi, To disable topos for a specific SIP trunk, you can use event routes with IP address filtering. It seems your configuration doesn't trigger event_route[topos:msg-incoming] as expected. Ensure you have set event_mode to 5 to enable the necessary events and verify that the IP address comparison is accurate. Here's a revised snippet: modparam("topos", "event_mode", 5)

request_route { ... }

event_route[topos:msg-outgoing] { if ($sndto(ip) == "1.1.1.1") { xlog("L_WARN", "[msg-outgoing] $rm/$rU/$sndto(ip)\n"); drop; } }

event_route[topos:msg-incoming] { if ($si == "1.1.1.1") { xlog("L_WARN", "[msg-incoming] $rm/$rU/$si\n"); drop; } }

Ensure the IP address 1.1.1.1 is correctly matched, and check if the event routes are correctly configured.

Thanks __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

Hey!

I'm still trying to figure out how to implement an exception from topos processing for a specific type of SIP device (IP is not fixed) based on User-Agent. If anyone has any ideas, I'd appreciate some help!

I have been in the same situation. I have a registrar that handles UAs and has a connection to our core routing instance. It also handles call forwarding.

So when a call is directed to a registered UAs I want to engage topos, but when the UAs times out or is unreachable and CFW is engaged (sending the call back to the core to route to the CFW destination), I wanted to revert engaged topos.

=> I found no way to do that. Further more, if the call is looped back from the core to another customer on the same registrar, topos is getting confused and breaks.

If you find a solution, I would be very happy to hear how you solved reverting topos for a specific ip or for specific situations after it was engaged.

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.