I'd like to know how to config Polycom SIP phone (331 or 335) with High Availability (HA) SIP servers. The HA SIP servers are using Virtual IP (VIP). Our SIP phones are registered with VIP. When one of my HA SIP servers fails, the second (in HA group) will be elected. Then our SIP phones can't make a call out, but can receive the call. If I need to dial out, I've to wait 1 hour (default for re-register on Polycom SIP phone, but can be less) or I've to reboot it.
So, I'd like to know how to manipulate a configuration to these SIP phones without rebooting or waiting. If you've a solution, pls share your valuable info to me.
Solved! Go to Solution.
Then our SIP phones can't make a call out, but can receive the call. If I need to dial out, I've to wait 1 hour (default for re-register on Polycom SIP phone, but can be less) or I've to reboot it.
That is interesting...are you sure you aren't having the opposite problem and you just accidentally wrote the description incorrectly (you can make calls out, but can't receive them)?
The SIP registration mechanism really has little-to-nothing to do with outbound calling. It was created so that SIP proxies could be notified where to direct a call for endpoints that have dynamic IP addresses. As long as the client passes a digest authentication challenge, even if that client is not registered to the SIP proxy, it should be able to successfully make an outbound call, just not be sent inbound calls (since the SIP proxy has no idea where to send those calls without an active registration).
I could easily see this kind of problem (outbound works okay, inbound does not) with a high-availability SIP cluster that is not properly engineered. If you have SIP proxies A and B, and the endpoint (phone) registers to proxy A, and proxy A goes down and proxy B picks up the VIP that proxy A was using, proxy B won't necessarily have a SIP registration on file for the endpoint. In that situation, proxy B would gladly accept INVITEs from the endpoint for outbound calls but would have no idea where to send inbound calls destined for that endpoint. In order for this scenario to work, both proxies A and B would have to share a common SIP registration table somehow...not impossible, especially if the SIP stack in use specifically supports being used in an HA environment and is able to sync changes in the registration table between each other in real-time, but it's not necessarily a simple problem to solve, especially if the SIP proxy software was not specifically engineered to do this.
There would certainly not be a setting in the Polycom phone software that makes it "work" in such an environment. The whole point of VIP-based high-availability is to make switching between members of a server cluster completely invisible to the clients/endpoints that are accessing it. The phones should neither need to know nor care if they are all of a sudden talking to a different SIP proxy. If the client specifically has to support seamless access to an HA cluster in a failover scenario, then the design of that HA cluster has failed by definition. So I would suggest that there is something wrong with the design of your HA SIP cluster.
Now, if you really are having the opposite problem, where you can receive calls but cannot make them until the current SIP registration timer runs out, this tells us that the HA cluster is doing its job as far as keeping the SIP registration tables in sync between members of the cluster, because obviously proxy B knows where to send inbound calls to after proxy A goes down. So the question remains: why are outbound calls failing?
Again, it is unlikely there is a setting in the phone that can fix this...from the phone's perspective, it is still talking to the same IP address it was talking to before (the whole point of HA+VIP). This suggests that the problem is perhaps at a lower level somewhere. Does your HA design merely move the VIP to the failover proxy when the primary dies, or does it also allow for the failover proxy to respond to ARP requests for that VIP using the same MAC address that the primary proxy was responding from? If the MAC address being used in ARP replies for that VIP is changing when failover occurs, perhaps there is a problem/bug in the Polycom software that is causing it to cache entries in its ARP table for much longer than it should (perhaps for the duration of the SIP registration!), and which also prevents it from updating the table when a gratuitous ARP bearing a different MAC address is seen from that IP. In that case, the phone might be trying to send INVITEs to the VIP, but if the SIP proxies and the Polycom phone are in the same subnet and on the same ethernet broadcast domain, the phone will be sending them to the wrong MAC address. If the phones and the proxies are *not* on the same subnet and there is a router sitting in between the SIP proxies and the phones, then perhaps the problem is with your router hanging onto ARP entires in its local cache (although, unless your SIP proxies are *only* acting as SIP proxies and not also as media gateways, I would expect you to have problems with one-way audio on inbound calls in a failover scenario if this were true). In either case, the answer is to ensure that the MAC address for the VIP does *not* change in a failover situation.
If you cannot change anything about the way that your HA cluster works or is configured, then I see only two options to work around this problem:
1) Set the SIP registration timer to a ridiculously low value. If you configure the SIP proxies to ask for a SIP REGISTER expiration that is lower than the phone's default (1 hour), the phone will have to honor it. Try setting it to 2 minutes. In a failover scenario, there might be a few seconds, then, where outgoing calls don't work, but the situation will correct itself much more quickly without the need for a reboot of the phone(s).
2) Drop the idea of using VIP-based HA, and instead use DNS with SRV records. Once the phones realize that they can no longer talk to the SIP proxy they originally registered to, they will try to re-register to one of the other SIP proxies they got back in the DNS response.
I hope this gives you some ideas of where to look. Best of luck,
Sorry for my mistake about describing a call and thank you for pointing an error. The correct statements are:I can make a call out but can't receive.
Your suggestions would be important to us. I'll let our team do it.
Noted: The VIP MAC address is still maintained even one of HA fails.