Failover with dialog dmq while dialog state 2 - sr-users

7 May 2024

Hello @all

as we want to enhance our VoIP-Plattform with DMQ functionalities for
replication of Userlocation, Dialog and Hash Tables I made a lot of
tests durings the last week.

For testing I use two Debian 12 Server with Kamailio 5.7.4 (latest git)

Both server have their own floating IP so in case one server fails the
floating changes to the working server. This is done via keepalived

On both servers Kamailio is active and use ip_free_bind=1 so both
Kamailio instances can listen to all necessary IPs.

So we have following network configuration:

Server1:
static IP: 192.168.253.201
floating IP: 192.168.253.200

Server2:
static IP: 192.168.253.202
floating IP: 192.168.253.210

Now I test some calls while I trigger a failover, so Server1 takes over
192.168.253.10

Message
        Test
        Result
CustomerA -> Proxy -> CustomerB
        Failover while Dialogstate 4
        BYE is relayed correctly. Dialog is changing to state 5
CDR needs to be written manually -> no problem at all
CustomerA -> Proxy -> CustomerB
        Failover while Dialogstate 2
        200 OK is relayed correctly although no transaction exist an therefore
no t_reply route is triggered. This is not a big deal because i can use
default onreply_route so all necessary variables can be used via hash table.
BUT Big Problem: Dialog state stays 2, so a following ACK is a bogus event
and the dialog state is never changed to 4. Even worse: after 300 seconds
the dialog is cleaned away by the timer, so I have no chance to do any kind
of accounting.

Test 2 is a real mess, because for me there is only one solution. I have
to check after a failover on incoming replies to an INVITE that was
handled on Server2 if these current dialog state is < 4 and cancel them.
But I can't see how to do it? Are there other ways than using t_cancel?
Or is it even some kind of a bug that a 200 OK does not trigger state 3
on dialog (although I have in mind that it has to be something to do
with missing transaction data, that are not replicated because of
missing replication capabilities of tm module)?
If none of the above is possible I really asking myself of a real use
case of dialog dmq replication.

--
Björn Klasen, Teamleitung NGN VoIP-Backbone
TNG Stadtnetz GmbH, TNG-Technik
Gerhard-Fröhler-Straße 12
24106 Kiel・Deutschland

T +49 431 7097-10
F +49 431 7097-555
bklasen(a)tng.de
https://www.tng.de

Executive board (Geschäftsführer):
Dr. Sven Willert (CEO/Vorsitz),
Gunnar Peter, Sven Schade,
Carsten Tolkmit, Bernd Sontheimer

Amtsgericht Kiel HRB 6002 KI
USt-ID: DE225201428
Die Information über die Verarbeitung Ihrer Daten
gemäß Artikel 12 DSGVO können Sie unter https://www.tng.de/datenschutz/ abrufen.
______________________________________________________________________