Recommended Practices For Fallback Deployments - Polycom CX5500 Administrator's Manual

Polycom CX5500 Unified Conference Station Administrator's Guide
●
Server 2 (the fallback server) will be configured to the address of the router/gateway that provides
the fallback telephony support and is on-site, for example:
reg.1.server.2.address=172.23.0.1 .
Note: Caution When Using Multiple Servers Per Registration
It is possible to configure the phone for more than two servers per registration, but you need to
exercise caution when doing this to ensure that the phone and network load generated by
registration refresh of multiple registrations does not become excessive. This would be of particular
concern if a phone had multiple registrations with multiple servers per registration and it is expected
that some of these servers will be unavailable.
Phone Operation for Registration
After the phone has booted up, it will register to all the servers that are configured.
Server 1 is the primary server and supports greater SIP functionality than other servers. For example,
SUBSCRIBE/NOTIFY services used for features such as shared lines and presence, will be established
only with Server 1.
Upon the registration timer expiry of each server registration, the phone will attempt to re-register. If this is
unsuccessful, normal SIP re-registration behavior (typically at intervals of 30 to 60 seconds) will proceed
and continue until the registration is successful (for example, when the Internet link is once again
operational). While the primary server registration is unavailable, the next highest priority server in the list
will serve as the working server. As soon as the primary server registration succeeds, it will return to
being the working server.
Note: Failover to Servers that are Not Registered
If reg.x.server.y.register is set to 0, the phone will not register to that server. However, the
INVITE will fail over to that server if all higher priority servers are down.

Recommended Practices for Fallback Deployments

In situations where server redundancy for fallback purpose is used, the following measures should be
taken to optimize the solution:
●
Deploy an on-site DNS server to avoid long call initiation delays that can result if the DNS server
records expire.
●
Do not use OutBoundProxy configurations on the phone if the OutBoundProxy could be
unreachable when the fallback occurs. If Server 2 is not accessible through the configured proxy,
call signaling with Server 2 will fail.
●
Avoid using too many servers as part of the redundancy configuration as each registration will
generate more traffic.
●
Educate users as to the features that will not be available when in fallback operating mode.
Polycom, Inc.
1.1.0
145