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.

On Friday, May 29, 2020, Zhan Bazarov <chiefkeeft@gmail.com> wrote:
> Hello. We faced to an issue with polycom, namely - polycom phones looses
> registration within SRV/DNS based cluster scenario..
> So we have round-robin cluster of SIP-proxy instances behind the same SRV/A
> records(each instance has the same weight). The initial registration works
> fine, but after the polycom sends a SUBSCRIBE request to another one
> sipProxy instance(because of round-robin scenario) - polycom stops sending
> re-register by expires which we are providing in 200Ok message...
>
> So the idea is to keep polycom located on the instance where initial
> register request came to.
>
> But polycom is sending SUBSCRIBE in shuffle(not to the server where
> registration is located)
>
> We can solve this issue by  keeping registration on lines not on main SIP
> configuration itself, otherwise polycom looses registration from cluster at
> all. But it lead to rejecting some calls by polycom with '400 bad request..
> We can solve it by disabling validation. But it leads to additional things
> like: polycom has multiple registrations on the device itself..  I mean, for
> example, first one registration isn’t expired, and polycom has two
> registrations at the same time...
>
>
> any ideas? How we can avoid this issue right?
> Thanks.
>
>
>
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users