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, view it on GitHub, or mute the thread.