11 Jul
2024
11 Jul
'24
10:48 a.m.
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
3:57 p.m.
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(a)hotmail.com>om>:
You have to use topos:receiving instead of
topos:incoming.
Le 11 juil. 2024 08:48, Denys Pozniak via sr-users <
sr-users(a)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
4:35 p.m.
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(a)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(a)hotmail.com>om>:
You have to use topos:receiving instead of
topos:incoming.
Le 11 juil. 2024 08:48, Denys Pozniak via sr-users <
sr-users(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
12 Jul
12 Jul
12:28 p.m.
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
5 Sep
5 Sep
5:47 p.m.
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(a)lists.kamailio.org>gt;:
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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
--
BR,
Denys Pozniak
6:48 p.m.
Hello,
there are two types of event_route that can be executed by topos, one
gives access to headers as well -- see the readme.
Cheers,
Daniel
On 05.09.24 16:47, Denys Pozniak via sr-users wrote:
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(a)lists.kamailio.org>rg>:
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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply
only to the sender!
Edit mailing list options or unsubscribe:
--
BR,
Denys Pozniak
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Advanced Training, October 8-10, 2024 -- asipto.com
6 Sep
6 Sep
9:36 a.m.
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.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
12:24 p.m.
Hey!
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
2 - execute event_route[topos:msg-sending]
8 - execute event_route[topos:msg-receiving]
*/
modparam("topos", "event_mode", 10)
request_route {
...
if ( is_method("INVITE") && !has_totag() && $ua =~
"snom" ) {
$dlg_var(no_topos) = "true";
}
...
}
event_route[topos:msg-receiving] {
if ( $dlg_var(no_topos) == "true" ) {
drop;
}
}
event_route[topos:msg-sending] {
if ( $dlg_var(no_topos) == "true" ) {
drop;
}
}
пт, 6 сент. 2024 г. в 09:08, Benoît Panizzon via sr-users <
sr-users(a)lists.kamailio.org>gt;:
Hey!
--
BR,
Denys Pozniak
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.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
12:50 p.m.
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.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
63
days inactive
120
days old
9 comments
6 participants
participants (6)
-
Benoît Panizzon -
Daniel-Constantin Mierla -
Denys Pozniak -
Ilie Soltanici -
Maria Jonas -
Patrick Karton