Hello Björn,

Thanks for the update. This sounds indeed a like a somewhat ugly hack. 😉

It should be probably fixed in the code instead of manually creating KDMQ messages to update the dialog module state in the cfg.

Cheers,

Henning

From: Björn Klasen via sr-users <sr-users@lists.kamailio.org>
Sent: Freitag, 10. Mai 2024 13:27
To: sr-users@lists.kamailio.org
Cc: Björn Klasen <bklasen@tng.de>
Subject: [SR-Users] Re: Failover with dialog dmq while dialog state 2

Hi Henning,

thank you for your reply. I did a lot testings during the past days and I think I found a solution that is working, although it's very dirty...

I found out it is possible to send a manual KDMQ-Message to all Proxy-Nodes including the one that it sending die KDMQ-Message. So I create a dialog state 4 message on ACK and indeed the Dialog on all Peers are Updated correctly to state 4. I also tried this for state 3 on 200 OK, but this does not work. I haven't had a look into the code yet but my experiments shows, that there is never is state 3 update via DMQ, so I think it's not implemented.

Interestingly the TM-Timer still times out after 300 seconds but in normal circumstances this doesn't bother, because either the failed Kamailio will not trigger this, because the Software or the Server crashed, or it tries to send a CANCEL that is denied because we are in dialog state 4.

The only thing is your really have to be careful about your hash tables. You have to delete them at the correct point.

I really need to test a lot at this point, but till now, billing seems to be OK even on failover scenarios.

This is why I really like Kamailio :)

BR, Björn

Am 09.05.24 um 20:57 schrieb Henning Westerholt:

Hello,
 
thanks for the detailed e-mail. As also indicated in the module documentation, the dialog module DMQ replication will not replicate everything, its main use-case is for profile data sharing. https://kamailio.org/docs/modules/5.8.x/modules/dialog.html#dialog.p.enable_dmq
 
In the past months there have been some other discussions on the users lists about similar scenarios (I think related to billing/accounting) and dialog with DMQ, which might be interesting for you in this regard.
 
If you find issues where the DMQ synchronisation is lacking some functionality in the dialog module, you can create a feature request in our issue tracker. There is of course no guarantee that this limitation is also timely addressed.
 
Regarding the INVITE and CANCEL scenario, this is usually not related to dialog but to the tm module. As you also mentioned, there is no replication of transaction state in tm.
 
Cheers,
 
Henning
 

--
Björn Klasen, Senior Specialist (VoIP)
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@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.
______________________________________________________________________