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
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
Funny, encountered this exact problem just the other day.
@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? _sip._udp.proxy.mydomain.net. 1800 IN SRV 100 50 5060 proxy1.mydomain.net. _sip._udp.proxy.mydomain.net. 1800 IN SRV 100 50 5060 proxy2.mydomain.net.
P.S. Clearly this topic is not Kamailio related
On Sun, May 31, 2020 at 12:16 PM Brian : brians@iptel.co wrote:
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
Hi. How did you deal with that?
From my side I've tried to use path and outbound on the polycom side.. Now
polycom is not jumbing between proxies but still loosing registration...
-- Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
Actually I've fixed the issue by adding this: fix_nated_register(); add_contact_alias(); istead of fix_nated_contact();
and then On the second kam(if request coming from another kam) I'm doing this: handle_ruri_alias();
-- Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
-
Brian : -
Sergiu Pojoga -
Zhan Bazarov