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-