Hello, I haven't worked on the dmq replication for dialogs, so not sure why that state is not replicated, but I think that would be the right solution if the lack of replication creates issues.
Cheers, Daniel
On Mon, Jul 1, 2019 at 12:34 PM Mathieu Bodjikian < mathieu.bodjikian@corp.ovh.com> wrote:
Hello,
We are using DMQ module to sync dialogs between 3 Kamailio boxes.
We are using last Kamailio version (5.2.3).
From our understanding, the state DLG_STATE_CONFIRMED_NA is not synced over DMQ ( https://github.com/kamailio/kamailio/blob/a84a3ea618f0e602a8892c37fce7f4e72a... )
With containerized environement, the ACK's can go to any Kamailio instance, which lead to :
On first box : -> INVITE received -> Dialog created + KDMQ sent (state DLG_STATE_UNCONFIRMED) -> 180 | 183 received -> Dialog updated + KDMQ sent (state DLG_STATE_EARLY) -> 200 received -> Dialog updated + KDMQ NOT sent (DLG_STATE_CONFIRMED_NA)
On second box : -> ACK received : - next_state_dlg(): bogus event 6 in state 2 for dlg - dialog not updated - KDMQ with state DLG_STATE_CONFIRMED not sent
On first box, after timeout : -> After timeout : - dialg with incorrect timeouts (since box2 didn't send dialog update) - tm sends BYE in both ways - bye_reply_cb(): inconsitent dlg timer data on dlg
We see two solutions : - We add DLG_STATE_CONFIRMED_NA to states we sync on dlg_dmq_replicate_action
- We manage to route the ACK on the same instance that received firstINVITE (could be tricky)
Which one is preferable ?
Kind regards, Mathieu Bodjikian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users