Hi Stefan, >> We're using sippy b2bua in some deployments, where we currently >> implement transaction and dialog persistence using redis as a backend, >> since it's simple, fast, easy-to-use and offers replication. Thus, you >> can replicate states to a standby server and from there continue >> processing active transactions and dialogs after a fail-over. Are there >> any plans for such a thing on the road-map for sems? Do you see any >> show-stoppers implementing this? Either way, I'll definitely have a look > we have implemented replication to and failover from a backup server (in > a private branch). so, no, no real show-stoppers there. we are using > sems' internal in-mem db (monitoring), so only active-passive is
How do you handle restarts on the active side and down-times on the backup-side then, if it's all in-memory? Let's say I want to restart the sems process for some reason without tearing down active calls, will it load the states from disk to continue? Or if the fail-over side is down for some minutes, will it catch up with the active side to have a consistent state? That were mainly the reasons for choosing redis, since it writes changes also to disk (handy for restarts of sippy on the active side), and with its replication, the backup side catches up with changes automatically after down-times, so I can load the current states when sippy starts up during fail-over. I'm currently just assuming a signaling-only b2bua, so no RTP is involved in the scenarios described above. Andreas
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
