Hi
Having this situation while elaborating topos in lab.
* Kamailio Registration Instance with topos enabled where customers are registered.
* Kamailio Core Instance with Dialogue enabled and handling interconnections.
Calls in transit from customer to IC work flawlessly, topos does what it should, hides and restores headers needed on the core.
But I have run into an issue with customer calling another customer on same registrar instance. To generate a CDR with diaglogue and for decision where to route the calls to (registrar is kept simple and only handles registrations and locations), those calls are also routed via core.
This works as long as PRACK is disabled.
When PRACK is enabled and CPE B is requesting 100rel, the PRACK send from CPE A has no route set (it was removed by topos). Therefore the PRACK only makes it to the core who then does not know where to route that PRACK. It looks like topos on the REG only restores ONE Route pointing to the core (maybe because the 2nd one pointed to itself?) header when restoring them.
I have attempted to spam more record_route() here and there in the config of the core and the registrar to try to force creation of route headers, but failed.
Is this a known limitation of using topos?
Hi
I might have figured out how to do it... I have to suppress topoligy hiding when not talking to a CPE.
branch_route[BR_TO_CORE] { $var(droptopos) = 1; }
event_route[topos:msg-outgoing] { if ($var(droptopos) == 1) { drop; } }
Trace looks promising, now getting full route set being passed on.
Hello,
you've seems to have already found a workaround, as posted later.
Generally, topos should work for PRACK, there were several enhancements/fixes committed in the last year.
Cheers,
Henning
Hi Henning
you've seems to have already found a workaround, as posted later.
Generally, topos should work for PRACK, there were several enhancements/fixes committed in the last year.
Unfortunately, I didn't get it working as I anticipated.
CPE - REGISTRAR - CORE
I would like to hide topology towards the CPE so it does not have to deal with recorded routes or via headers and also to hide those ip addresses from the customer.
But I need those header between REGISTRAR and CORE kamailio instances.
For call from registrar to core I use a branch route trigger.
Within that trigger I do:
branch_route[BR_TO_CORE] { if ($avp(debug) > 0) { xlog("L_INFO", "$cfg(route): Branching to Core\n"); } $avp(droptopos) = 1; }
event_route[topos:msg-outgoing] { # Drop topology hiding towards core. We need those route header! if ($avp(droptopos) == 1) { xlog("L_INFO", "$cfg(route): **************** DROP TOPOS\n"); drop; } $avp(droptopos) = 0; }
Unfortunately this does not only affect the INVITE to the core, but also drops topos on the other leg (replies like ringing and 200 OK from core via registrar to customer) which then disclose all via information.
Is there a way to drop topos selectively only in one direction?
Mit freundlichen Grüssen
-Benoît Panizzon-
Some update after more testing...
not droping topos to the core and setting
modparam("topos", "rr_update", 1)
solves some situations but has caused at least a new one.
Situation:
Two CPE on same Registrar.
A CPE => + + REGISTRAR <=> CORE B CPE <= +
A is calling B.
Call route: A CPE => Registrar => Core => Registrar => B CPE
In this example, there are four contacts registered B CPE. Each replies with 180 ringing and requiring 100rel.
I see, topos is enumerating the 180 ringing contact user with
atpsh-someid-1 atpsh-someid-2 atpsh-someid-3 atpsh-someid-4
But on the second leg, towards A CPE, all 180 ringing have the SAME contact username:
atpsh-63f39a4f-c0aa8-2
The CPE A replies PRACK to the first one and that PRACK is correctly routed to CPE B
PRACK sip:atpsh-63f39a4f-c0aa8-2@IP SIP/2.0
That username is being translated to that first one from the first leg.
But with that PRACK routed and username translated AND the other side acknowleding that PRACK with 200 OK. I fear topos discards all information regarding that mapping as it considers the PRACK transaction has ended.
The subsequent 180 RINGING which the CPE confirms with PRACK containing the same contact userid again, is being rejectec with 404 and the whole call is ending here with tangling ringing endpoints.
If I manage to pick up the call real quickly on the first CPE that rings and the 200 OK to the INVITE is getting to the origin before the 404 occurs, the call is established.
So I fear, there is an issue with topos handling replies from various contacts of the same AOR.
Mit freundlichen Grüssen
-Benoît Panizzon-
-
Benoît Panizzon -
Henning Westerholt