When records are replicated, is expected to be same kind of config, so both proxies should have same dialog lifetime/expire value, otherwise they are not like a single node behaviour. Replication is mainly for redundancy, not scalability. Dialog is not working with database only, it has the records in memory and works with those. There are functions that you can load the dialog records from database if they are not found in memory when processing a specific SIP message. Now, given the purpose of redundancy/high-availability, the proxy 2 should expire the dialog, because it doesn't know if the proxy 1 is still alive. If the replication is for another purpose, like active calls limit, then it might be good to set a flag for it to say do not send BYEs on expiration or other operations that can be a conflict. There are also options to replicate only profiles, not all dialogs, so by that one can have distributed calls limit. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2080#issuecomment-536427638

Maybe this is irrelevant, but I'd like to add another scenario (not sure if you have contemplated this one @henningw): replicating dialogs exclusively via DMQ (with no database at all). * Proxy1 creates a dialog (let's call it **dialogA**) and replicates it via DMQ to Proxy2. * Proxy1 is restarted/crashes/something. * Proxy1 comes back up before **dialogA** has expired. * Proxy1 receives all dialogs from Proxy2 via DMQ (including **dialogA**). What would happen when expiration for the **dialogA** is due? 1- Would Proxy1 send the BYE and then "tell" via DMQ to Proxy2 to remove it from its memory? 2- What if Proxy1 never came back up in time, would Proxy2 know that **it** should take care of sending out a BYE for that expired dialog? 3- Would both Proxy1 and Proxy2 send a BYE and then tell the other proxy via DMQ to remove it? (this would be a race-condition I believe, and one would end up logging a *non-existent dialog* on syslog?) I know the subject of this issue clearly talks about scenarios **with** a database, so if you believe this database-less scenario shouldn't be discussed here let me know and I can create a new issue. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2080#issuecomment-537294709

This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2080#issuecomment-1801299913 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/2080/1801299913(a)github.com>

I also came across that issue, but the other way round. I started with a short session timer, intending to extend it on every re-invite according to the timer values in the sip message and reply. This turned out not to work, as the peer nodes would not get an update on re-invites and thus fire the timeout and expiring the dialog from memory, and also sync state 5 (delete) back to the node handling the dialog causing the next in-dialog sip message hitting a 481 dialog not found. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2080#issuecomment-1825263391 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/2080/1825263391(a)github.com>

Closed #2080 as not planned. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2080#event-11544232848 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issue/2080/issue_event/11544232848(a)github.com>