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">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">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">sr-users@lists.kamailio.org</a><br>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>>