Polycom CX5500 Unified Conference Station Administrator’s Guide 1.1.0
Polycom, Inc. 143
● Fallback In this mode, a second call server of lesser capability (router or gateway device) takes
over call control to provide basic calling capability without some of the richer features offered by the
primary call server (for example, shared lines, presence, and Message Waiting Indicator). The
CX5500 system supports configuration of multiple servers per SIP registration for this purpose.
In some cases, a combination of the two may be deployed. Consult your SIP server provider for
recommended methods of configuring phones and servers for failover configuration.
Note: Compatibility with Microsoft
®
Lync
The concurrent failover/fallback feature is not compatible with Microsoft Lync.
Caution: Old Failover Behavior Is Not Supported
Prior to SIP 2.1, the reg.x.server.y parameters in <reg/> could be used for failover
configuration. The older behavior is no longer supported. Customers that are using the
reg.x.server.y.* configuration parameters where y>=2 should take care to ensure that their
current deployments are not adversely affected. For example, the phone will only support advanced
SIP features such as shared lines, missed calls, and presence with the primary server (y=1).
Set Up Server Redundancy
Central Provisioning Server
Specify server redundancy options including failback mode,
failback timeout, and failover registration behavior
sip-interop.cfg > voIpProt.server.x.failOver.*
Specify which server to contact if failover occurs
reg-advanced.cfg > reg.x.auth.optimizedInFailover
Override the default server redundancy options for a
specific registration
reg-advanced.cfg > reg.x.outboundProxy.failOver.*
Web Info: Failover Configuration Details
For more information, see Technical Bulletin 5844: SIP Server Fallback Enhancements on Polycom
Phones and Engineering Advisory 66546: Using Optional Geographical Server Redundancy Failover
Behaviors.
DNS SIP Server Name Resolution
If a DNS name is given for a proxy/registrar address, the IP address(es) associated with that name will be
discovered as specified in RFC 3263. If a port is given, the only lookup will be an A record. If no port is
given, NAPTR and SRV records will be tried, before falling back on A records if NAPTR and SRV records
return no results. If no port is given, and none is found through DNS, 5060 will be used. If the registration
type is Transport Layer Security (TLS), 5061 will be used as the port number. See RFC 3263 for an
example.