Hello,
I am trying to configure the Topos module and have some questions.
# topos:msg-outgoing vs topos:msg-sending
https://www.kamailio.org/docs/modules/5.8.x/modules/topos.html#topos.e.msg_s...
I am trying to understand the difference between these two event routes(beyond the content of the SIP message ). I notice that both are invoked when OPTIONS are generated by the local Kamailio server but only msg-sending is invoked for messages transiting the Kamailio( ie proxied, not locally generated).
Is there some difference in how these event_routers are invoked beyond the content of the SIP message?
# tops -> requests/replies
When I am in event_route[topos:msg-sending] { and invoke 'drop', does this apply to the current message or does it apply to the transaction?
I have a Kamailio node with devices on either side. Let's call side A untrusted and side B trusted.
I want TOPOS happening against the untrusted device but not the trusted device.
I have found that when I invoke 'drop' on a request coming from A to B, it disables TOPOS not only on that packet, but also the reply comes from B back to A, TOPOS isn't applied when the reply exits Kamailio towards A. So if I call 'drop' on the request coming from A to B, the reply coming from B to A has no TOPOS applied.
How do I get TOPOS applied to all traffic facing a particular device while leaving that traffic un-stripped when the same traffic is interacting with other devices that are trusted?
Thanks,
David
Hi David
I want TOPOS happening against the untrusted device but not the trusted device.
Been exactly there and had to learn - this just is not possible. If topos is used, you need to use it on both legs of the call. You can not drop one side as this breaks how topos works.
So I'm not sure in what the purpose of doping topos on a really message is.
And I also want to make you aware of some known issues:
In some Situations, the Via header are not being correctly removed but passed to the other side, still revealing the topology.
Also, you may need to loop a call to yourself after topos restored the route and via header, to make loose route work.
There is an issue with parallel forking. It happens in parallel forking in situations similar to this:
Two invites are sent to two different destinations but same CallID. Both reply with 200 OK at the same time (different ToTags). Topos does not consider the ToTags but marks the 200 OK as 'processed' after the first 200 OK. So only the ACK to that first 200 OK is being correctly routed because it is expected, the second ACK can not be routed (or was is the other way round - you get the idea). Also applies to other messages, especially PRACK / 200 OK to PRACK as they are prone to happen at the same time.
Thank-you Benoît!
That answer was very complete.
I am using the siptrace module to copy out packets (most of my traffic is TLS) and I wonder if the siptrace module can be coaxed into reporting messages as they appear to the script writer and not as they were sent/received on the wire?
IE transmit on the wire the TOPOS stripped message, but siptrace report with the headers all intact.
Not sure if you've explored the interactions of this module?
Thanks,
David
On Fri, Feb 28, 2025, 11:29 a.m. Benoît Panizzon benoit.panizzon@imp.ch wrote:
Hi David
I want TOPOS happening against the untrusted device but not the trusted device.
Been exactly there and had to learn - this just is not possible. If topos is used, you need to use it on both legs of the call. You can not drop one side as this breaks how topos works.
So I'm not sure in what the purpose of doping topos on a really message is.
And I also want to make you aware of some known issues:
In some Situations, the Via header are not being correctly removed but passed to the other side, still revealing the topology.
Also, you may need to loop a call to yourself after topos restored the route and via header, to make loose route work.
There is an issue with parallel forking. It happens in parallel forking in situations similar to this:
Two invites are sent to two different destinations but same CallID. Both reply with 200 OK at the same time (different ToTags). Topos does not consider the ToTags but marks the 200 OK as 'processed' after the first 200 OK. So only the ACK to that first 200 OK is being correctly routed because it is expected, the second ACK can not be routed (or was is the other way round - you get the idea). Also applies to other messages, especially PRACK / 200 OK to PRACK as they are prone to happen at the same time.
-- 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 ______________________________________________________
-
Benoît Panizzon -
David Tek