In theory if you set the record-route to a DNS name and not an Ip address, then endpoints should be able to failover within a dialog - but as Alex says - transactions may fail. In many cases there are retry timers to restart transactions that fail. This means that if a call starts with an INVITE transaction on one server, it should in theory be able to find another server for the BYE. Whether this DNS srv based fail over is implemented in end-points is up to testing to prove. If not, then virtual IP failover is your best friend. /O sr-users(a)lists.kamailio.org> wrote: obstacle. However, CANCELs won't work. sr-users(a)lists.kamailio.org> wrote: to let multiple Kamailio servers share their SIP sessions between each other. received and initiated on Kamailio #1, and during any moment of the call (before or while established) if the server #1 goes down or Kamailio stops working for any reason, the call can be processed by Kamailio server #n available in the cluster. but instead need to get a proper way to share SIP sessions between Kamailio servers such that any server could continue the call without issue. the way to go.... to the sender! the sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

Thanks Alex & Olle! I've done some tests with Keepalived for Virtual IP failover, and I found that it works more or less as you mentioned, Olle: if an Invite comes from Server #1, and that server gets offline, the BYE will indeed be correctly processed by Server #2. Isn't DMQ supposed to handle this? as i understand, DMQ sends the SIP messages to other servers, so wouldn't it be enough? (I assume, I haven't tested DMQ yet.... ) * * *Sérgio Charrua* *www.voip.pt <http://www.voip.pt/>* Tel.: +351 <callto:+351+91+104+12+66>91 631 11 44 Email : *sergio.charrua(a)voip.pt* This message and any files or documents attached are strictly confidential or otherwise legally protected. It is intended only for the individual or entity named. If you are not the named addressee or have received this email in error, please inform the sender immediately, delete it from your system and do not copy or disclose it or its contents or use it for any purpose. Please also note that transmission cannot be guaranteed to be secure or error-free. On Tue, Feb 27, 2024 at 2:20 PM Olle E. Johansson via sr-users &lt;sr-users(a)lists.kamailio.org&gt; wrote: In theory if you set the record-route to a DNS name and not an Ip address, then endpoints should be able to failover within a dialog - but as Alex says - transactions may fail. In many cases there are retry timers to restart transactions that fail. This means that if a call starts with an INVITE transaction on one server, it should in theory be able to find another server for the BYE. Whether this DNS srv based fail over is implemented in end-points is up to testing to prove. If not, then virtual IP failover is your best friend. /O &lt;sr-users(a)lists.kamailio.org&gt; wrote: doesn't have. obstacle. However, CANCELs won't work. &lt;sr-users(a)lists.kamailio.org&gt; wrote: approach to let multiple Kamailio servers share their SIP sessions between each other. is received and initiated on Kamailio #1, and during any moment of the call (before or while established) if the server #1 goes down or Kamailio stops working for any reason, the call can be processed by Kamailio server #n available in the cluster. point, but instead need to get a proper way to share SIP sessions between Kamailio servers such that any server could continue the call without issue. that is the way to go.... reply only to the sender! only to the sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email tosr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

Maybe. It's another one of those things where you might spend 99% of your effort for that 0.1% marginal gain... sr-users(a)lists.kamailio.org&gt; wrote: moving virtual IP using master-slave redis -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

If there’s an issue in one node in the cluster and that node goes down, the next node in the cluster will have the same issue and it will go down the same way. I strongly agree with all of that. It's rare that someone truly gets this, and I salute you, sir. -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

On 27 Feb 2024, at 18:50, Richard Edmands &lt;thesirdmz(a)gmail.com&gt; wrote: Then to find out in those 0.1% that Corosync replicates the issue to the node it replaces in 60% of the cases where you would have utilised it.