loose_route false when using topos? At which point in the call flow, does topos restore the Route header?
26 Feb
2024
26 Feb
'24
10:08 a.m.
Hi
https://lists.kamailio.org/pipermail/sr-users/2020-July/109801.html
I have the exact same issue.
When the B side is starting a new transaction (UPDATE to refresh the
session in my case) without topos enabled, that transaction contains
one or multiple route header and a to_tag.
Therefore loose_route() is true and the call is more or less sent to
route(RELAY) immediately without further checks.
If topos is enabled, all record-route header are removed and only one
Via sent to the CPE.
So when the CPE replies, there is no Route header.
Therefore loose_route returns false.
This makes me wonder, at which stage is topos restoring the route
headers? Shouldn't that happen before loose_route is evaluated?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
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
______________________________________________________
26 Feb
26 Feb
1:41 p.m.
Hi,
did you use some kind of db backend for topos like redis or mysql?
Benoit Panizzon via sr-users <sr-users(a)lists.kamailio.org> schrieb am Mo.,
26. Feb. 2024, 16:28:
Hi
https://lists.kamailio.org/pipermail/sr-users/2020-July/109801.html
I have the exact same issue.
When the B side is starting a new transaction (UPDATE to refresh the
session in my case) without topos enabled, that transaction contains
one or multiple route header and a to_tag.
Therefore loose_route() is true and the call is more or less sent to
route(RELAY) immediately without further checks.
If topos is enabled, all record-route header are removed and only one
Via sent to the CPE.
So when the CPE replies, there is no Route header.
Therefore loose_route returns false.
This makes me wonder, at which stage is topos restoring the route
headers? Shouldn't that happen before loose_route is evaluated?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
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:
27 Feb
27 Feb
2:40 a.m.
Hi Karsten
did you use some kind of db backend for topos like
redis or mysql?
Well, you have to, to be able to store the route and via sets :-)
MySQL in use.
We might have figured out a possible cause.
This is the topology:
CPE <=> Kamailio Registrar <=> Kamailio Core <=> Interconnections.
Registrar handles mainly registration, runs rtpengine and this shall be
the place to hide topology towards the CPE.
The core takes care of routing, is dialogue aware and generates CDR for
billing.
So in the situation of CPE A calling CPE B we have:
CPE A => Registrar => Core => Registrar => CPE B
So two legs of the same call running over the same Registrar. It looks
like this breaks topos. I'll further investigate in this situation.
Mit freundlichen Grüssen
-Benoît Panizzon-
--
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
______________________________________________________
5:13 a.m.
Hi
By setting: branch_expire to the same value as dialog_expire which is
12 hours, now my headers get correctly restored on UPDATE and BYE.
But in this UPDATE scenario:
CPE A => Registrar A (topos) => Core => Registrar B (topos) => CPE B
I now have the phenomena that the Contact Header is being removed from
the UPDATE by topos on Registrar B.
Any clue what could cause the issue?
I see that Registrar A is adding a P-SR-XUID hader. Maybe I could
filter that header out on the Core?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
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
______________________________________________________
285
days inactive
309
days old
4 comments
3 participants
participants (3)
-
Benoit Panizzon -
Karsten Horsmann -
Patrick Karton