<div dir="ltr">So guys, I have nice news.<div>I made it working as expected, but with some editions of previous scheme.</div><div><br></div><div>I set NAPTR records for tcp/udp:</div><div><div>dig naptr <a href="http://sipnew.heremydomain.ua">sipnew.heremydomain.ua</a> @ns2 +short</div><div>10 100 "S" "SIP+D2U" "" _sip._<a href="http://udp.sip.heremydomain.ua">udp.sip.heremydomain.ua</a>.</div><div>10 100 "S" "SIP+D2T" "" _sip._<a href="http://tcp.sip.heremydomain.ua">tcp.sip.heremydomain.ua</a>.</div></div><div><br></div><div>I set SRV records for both types of transport:</div><div><div>dig srv _sip._<a href="http://udp.sip.heremydomain.wnet.ua">udp.sip.heremydomain.wnet.ua</a> +short @ns2</div><div>10 100 5060 <a href="http://kamailio1.heremydomain.ua">kamailio1.heremydomain.ua</a>.</div><div>10 100 5060 <a href="http://kamailio2.heremydomain.ua">kamailio2.heremydomain.ua</a>.</div><div><br></div><div>dig srv _sip._<a href="http://tcp.sip.heremydomain.ua">tcp.sip.heremydomain.ua</a> +short @ns2</div><div>10 100 5060 <a href="http://kamailio1.heremydomain.ua">kamailio1.heremydomain.ua</a>.</div><div>10 100 5060 <a href="http://kamailio2.heremydomain.ua">kamailio2.heremydomain.ua</a><br><br>And of course A records for both fqdn names:<br><div>dig <a href="http://kamailio1.heremydomain.ua">kamailio1.heremydomain.ua</a> @ns2 +short<br>10.10.10.1</div><div>dig <a href="http://kamailio2.heremydomain.ua">kamailio2.heremydomain.ua</a> @ns2 +short<br>10.10.10.2<br><br>Here I have to say, that I moved away from idea to set two IP addresses for both fqdns.</div><div>As Sebastian has already said, indeed clients sent half requests to first result of A records and half requests to second one.</div><div><br></div><div>So I decided to record route <a href="http://sip.heremydomain.ua">sip.heremydomain.ua</a>, instead of direct fqdn names of kamailio servers (<a href="http://kamailio1.heremydomain.ua">kamailio1.heremydomain.ua</a> / <a href="http://kamailio2.heremydomain.ua">kamailio2.heremydomain.ua</a>).</div><div>And the result was excellent.</div><div><br></div><div>So the configuration of kamailio proxies was like that:</div><div>1. dialog module working with external database;</div><div>2. registrar module working with external database;</div><div>3. usrloc module working with external database;</div><div>4. both kamailio inserts data to the same db, config files are the same on both kamailio (excepting the listening ifaces);</div><div>5. b2b user agent as routing server and media proxy at the same time;</div><div>6. Location records are visible from both kamailio proxies;</div><div><br></div><div>Here is the sequence of the call process (I used TCP transport to test the environment):</div><div>1. Client sets up dialog through the first kamailio, so three-way-handshake is done, media stream is up.</div><div>2. Then kamailio1 falls down, but dialog doesn't get down.</div><div>2.1 My client noticed, that 5060 port on first kamailio is unreachable and suddenly re-registered itself on second one (he resolves the <a href="http://sip.heremydomain.ua">sip.heremydomain.ua</a> and gets kamailio2 host).</div><div>2.2 Media stream doesn't get down, because of external media-proxy.</div><div>3. Client decides to end up the call and sends BYE request, to kamailio2 host.</div><div>3.1 Kamailio2 knows anything about this client and dialog, so he process this BYE as usual.</div><div>3.2 Session completely (properly) gets down.<br><br>In case of UDP transport, the result was a bit different, because in a few cases srv record couldn't recognize that 5060 is unreachable on first kamailio, so client tried to send BYE to first host.</div><div>But if first host was completely down, it worked in 100 % cases.</div><div><br></div><div>So I can say, that this topology is workable for me.<br><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-27 12:37 GMT+03:00 Donat Zenichev <span dir="ltr"><<a href="mailto:donat.zenichev@gmail.com" target="_blank">donat.zenichev@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Igor.<div>Well, indeed I've already done the solutions with heartbeat, but the main idea now is to minimize the absense of SIP server.</div><div>Heartbeat need time (that depends on your condigurations) to understand that primary is down, e.g. you have dead interval set to 10 seconds, so if no activity has noticed while this period, the node is considered as dead. But, if you will set this interval lower, e.g. 2-3 seconds, you get the risk to obtain flaps (e.g. there is a delay within ip route from slave to primary node, so slave brings up the shared ip and start to process calls, but real master works fine indeed and have possibility to communicate).</div><div><br></div><div>So according to heartbeat, I decided to perform it only inside same physical domain, where ucast/bcast packets will reach other node without any problems.</div><div><br></div><div>According to my actual question, I've moved further and now think following scheme will work fine:</div><div>1. NAPTR records for every transport protocol (e.g. <span style="font-size:12.8px">" _sip._</span><a href="http://udp.domain.org/" style="font-size:12.8px" target="_blank">udp.domain.org</a><span style="font-size:12.8px">").</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">2. SRV records for every NAPTR record (e.g. </span><a href="http://kamailio1.domain.org/" style="font-size:12.8px" target="_blank">kamailio1.domain.org</a><span style="font-size:12.8px">, </span><a href="http://kamailio1.domain.org/" style="font-size:12.8px" target="_blank">ka<wbr>mailio2.domain.org</a><span style="font-size:12.8px">) with same priority/weight for both of them, to balance half invites to first one and half invites to second one.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">3. A records for every domain name (e.g. </span><a href="http://kamailio1.domain.org/" style="font-size:12.8px" target="_blank">kamailio1.domain.org</a> - 10.0.0.1, 10.0.0.2, where actually second one is kamailio2;</div><div>and the same for fqdn <a href="http://kamailio2.domain.org" target="_blank">kamailio2.domain.org</a> - 10.0.0.2, 10.0.0.1).</div><div><br></div><div>So the sequence of dialog actions will be</div><div><br></div><div>1. Invite from uac is balanced to kamailio1;</div><div>2. Dialog is established and media stream is up;</div><div>3. Then kamailio1 goes down;</div><div>4. Bye message tries to achieve host that was set in rr hf (kamailio1), but kamailio1 (10.0.0.1) is down, so bye message will be sent to 10.0.0.2 (kamailio2) and a cause of the behaviour is 10.0.0.2 ip assigned to kamailio1 fqdn as second ip.</div><div>5. The message will be processed by kamailio2, because of common dialog/usrloc db.</div><div><br></div><div>I will make an effort to set up it next week.</div><div>In case of success, I will write a short report here.</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-08-25 17:26 GMT+03:00 Donat Zenichev <span dir="ltr"><<a href="mailto:donat.zenichev@gmail.com" target="_blank">donat.zenichev@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've searched through the sr users list and found a few discussions on this count.<div><br></div><div>So the way (as I think) that is more relevant for kamailio failover, is solution with DNS: NAPTR -> SRV records.</div><div><br></div><div>Like:</div><div><br></div><div>NAPTR record:</div><div>"IN NAPTR 10 10 SIP+D2U "" _sip._<a href="http://udp.domain.org" target="_blank">udp.domain.org</a>"</div><div><br></div><div>SRV records:</div><div>"_sip._<a href="http://udp.domain.org" target="_blank">udp.domain.org</a> SRV 10 1 5060 <a href="http://kamailio1.domain.org" target="_blank">kamailio1.domain.org</a>"<br></div><div>"_sip._<a href="http://udp.domain.org" target="_blank">udp.domain.org</a> SRV 10 1 5060 <a href="http://kamailio2.domain.org" target="_blank">kamailio2.domain.org</a>"<br></div><div><br></div><div>A records:</div><div>"kamailio1 IN A 10.0.0.1"<br></div><div>"kamailio2 IN A 10.0.0.2"<br></div><div><br></div><div>So each kamailio will add rr with own hostname - e.g. <a href="http://kamailio1.domain.org" target="_blank">kamailio1.domain.org</a></div><div>So that, client will send in-dialog requests to route with fqdn <a href="http://kamailio1.domain.org" target="_blank">kamailio1.domain.org</a></div><div>And I can't add to rr <a href="http://sip.domain.org" target="_blank">sip.domain.org</a>, because every new request (whatever it is initial or indialog) will be sent to one of the kamailio servers, but I need to send in-dialog requests to the same kamailio.</div><div><br></div><div>So for the goal of failover, I need to have more A records, like:</div><div><div>"kamailio1 IN A 10.0.0.1"<br></div><div>"kamailio1 IN A 10.0.0.2"<br></div><div>"kamailio2 IN A 10.0.0.2"</div></div><div>"kamailio2 IN A 10.0.0.1"<br></div><div><br></div><div>And in case when kamailio 1 goes down, uac will have two ip dst to send request: 10.0.0.1 and 10.0.0.2 (where indeed second one is kamailio2).</div><div>So as result I will have one database for userlocation and dialog module, and loadbalancing based on SRV priority/weight fields.</div><div><br></div><div>And as failover, A records, that give possibility to send requests first to 10.0.0.1 and second to 10.0.0.2 (if rr was bind to kamailio1).</div><div>And otherwise, if rr was defined as kamailio2, first request tries to achive kamailio1 and then kamailio2.</div><div><br></div><div>Am I right at this point?</div><div><br></div><div><br></div><div><br></div></div><div class="m_2953046257921999426HOEnZb"><div class="m_2953046257921999426h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-08-22 21:57 GMT+03:00 Donat Zenichev <span dir="ltr"><<a href="mailto:donat.zenichev@gmail.com" target="_blank">donat.zenichev@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi.<div><br></div><div>I came up with idea to set up stand with two kamailio and one b2bua server (for routing).</div><div><br></div><div>The idea consists of failover for dialogs, transactions.</div><div>So if one of kamailio nodes is down, another one is able to catch up the dialog and let users to properly end up the session.</div><div><br></div><div>For better realizing of it, I will try to describe the idea step by step:</div><div>1. UAC invites UAS, they've done three-way-handshake, media stream is up.</div><div>2. Kamailio that processed this dialog is down.</div><div>3. Users decided to end the session with BYE method, but proxy that processed their three-way-handshake recently is down, so one of ua sends BYE to the destination route that contains domain name (that both kamailio serve), BYE achieves the second kamailio to let him properly end the dialog.</div><div> But, there is a big but, this second kamailio hasn't ever known about this dialog, he doesn't support any transactions for it and furthermore he doesn't know anything about this call-id.</div><div><br></div><div>So the solution for it, as I think, is hidden in db mode for user location (columns that contain call-ids, branches etc.</div><div>But I need to be sure, if I'm on the right way.</div><div><br></div><div>For purpose, where one ip is served by two nodes, I have two solutions:</div><div><br></div><div>-First one. I want to create heartbeat cluster with two kamailio nodes, they will have one shared ip address, so when one node gets down, another one brings up shared ip interface and implements the same actions that master does.</div><div><br></div><div>-Another method is to assign a few ip addresses to one domain name (ip addresses of different kamailio proxies).</div><div><br></div><div><br></div><div>So the goal looks simple, if someone has ever done something like that, I will be glad to read the ideas.</div><span class="m_2953046257921999426m_-2002245853159942376HOEnZb"><font color="#888888"><div><div><br></div>-- <br><div class="m_2953046257921999426m_-2002245853159942376m_8616329812126089398m_2950283228654730570gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span>-- <br></span>BR, Donat Zenichev
<br>Wnet VoIP team
<br>Tel: +380(44) 5-900-808
<br><a href="http://wnet.ua" target="_blank">http://wnet.ua</a></div></div>
</div></font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_2953046257921999426m_-2002245853159942376gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span>-- <br></span>BR, Donat Zenichev
<br>Wnet VoIP team
<br>Tel: +380(44) 5-900-808
<br><a href="http://wnet.ua" target="_blank">http://wnet.ua</a></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_2953046257921999426gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span>-- <br></span>BR, Donat Zenichev
<br>Wnet VoIP team
<br>Tel: +380(44) 5-900-808
<br><a href="http://wnet.ua" target="_blank">http://wnet.ua</a></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span>-- <br></span>BR, Donat Zenichev
<br>Wnet VoIP team
<br>Tel: +380(44) 5-900-808
<br><a href="http://wnet.ua" target="_blank">http://wnet.ua</a></div></div>
</div>