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-
--
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
______________________________________________________