<div dir="ltr">Funny, encountered this exact problem just the other day.<div><br></div><div>@Brian - not to use equal priorities or weights? Say in a 2 node cluster like below, what do you suggest as priority/weight values, if load-balancing AND failover is desired?<br></div><div>_sip._<a href="http://udp.proxy.mydomain.net">udp.proxy.mydomain.net</a>. 1800    IN      SRV     100 50 5060 <a href="http://proxy1.mydomain.net">proxy1.mydomain.net</a>.<br>_sip._<a href="http://udp.proxy.mydomain.net">udp.proxy.mydomain.net</a>. 1800    IN      SRV     100 50 5060 <a href="http://proxy2.mydomain.net">proxy2.mydomain.net</a>.<br></div><div><br></div><div>P.S. Clearly this topic is not Kamailio related</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 31, 2020 at 12:16 PM Brian : <<a href="mailto:brians@iptel.co">brians@iptel.co</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The easy way to deal with it is not to use equal weights in SRV. It will nearly always lead to this type of issue with some user agents. <br><br>On Friday, May 29, 2020, Zhan Bazarov <<a href="mailto:chiefkeeft@gmail.com" target="_blank">chiefkeeft@gmail.com</a>> wrote:<br>> Hello. We faced to an issue with polycom, namely - polycom phones looses<br>> registration within SRV/DNS based cluster scenario..<br>> So we have round-robin cluster of SIP-proxy instances behind the same SRV/A<br>> records(each instance has the same weight). The initial registration works<br>> fine, but after the polycom sends a SUBSCRIBE request to another one<br>> sipProxy instance(because of round-robin scenario) - polycom stops sending<br>> re-register by expires which we are providing in 200Ok message...<br>><br>> So the idea is to keep polycom located on the instance where initial<br>> register request came to.<br>><br>> But polycom is sending SUBSCRIBE in shuffle(not to the server where<br>> registration is located)<br>><br>> We can solve this issue by  keeping registration on lines not on main SIP<br>> configuration itself, otherwise polycom looses registration from cluster at<br>> all. But it lead to rejecting some calls by polycom with '400 bad request..<br>> We can solve it by disabling validation. But it leads to additional things<br>> like: polycom has multiple registrations on the device itself..  I mean, for<br>> example, first one registration isn’t expired, and polycom has two<br>> registrations at the same time...<br>><br>><br>> any ideas? How we can avoid this issue right?<br>> Thanks.<br>><br>><br>><br>> --<br>> Sent from: <a href="http://sip-router.1086192.n5.nabble.com/Users-f3.html" target="_blank">http://sip-router.1086192.n5.nabble.com/Users-f3.html</a><br>><br>> _______________________________________________<br>> Kamailio (SER) - Users Mailing List<br>> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>