Polycom Video Game Sound System Version 2.0.3B User Manual

Page of 42
<January, 2007>
3725-17472-001/A
Technical Bulletin 5844
SIP Server Fallback Enhancements on SoundPoint
®
 IP Phones
This technical bulletin provides detailed information on how the SIP 
application has been enhanced to support SIP server fallback.
This information applies to SoundPoint IP phones running SIP application 
version 2.1 or later.
Introduction
Server redundancy is often required in VoIP deployments to ensure continuity 
of phone service for events where the call server needs to be taken offline for 
maintenance, the server fails, or the connection from the phone to the server 
fails.
Two types of redundancy are possible:
• Fail-over: In this mode, the full phone system functionality is preserved by 
having a second equivalent capability call server take over from the one 
that has gone down/off-line. This mode of operation should be done 
using DNS mechanisms or “IP Address Moving” from the primary to the 
back-up server. 
• Fallback: In this mode, a second less featured call server (router or 
gateway device) with SIP capability takes over call control to provide basic 
calling capability, but without some of the richer features offered by the 
primary call server (for example, shared lines, presence, and Message 
Waiting Indicator). Polycom phones support configuration of multiple 
servers per SIP registration for this purpose.
In some cases, a combination of the two may be deployed.
In SIP 2.1, the fallback behavior has been enhanced and this behavior is 
described in this document. 
Note
Your SIP server provider should be consulted for recommended methods of 
configuring phones and servers for fail-over configuration.
Warning
The server redundancy behavior in SIP2.1 has changed from that implemented in 
prior releases. Prior to SIP 2.1, the reg.x.server.y  parameters (see section 
4.6.2.1 of the SIP 2.0 Administrator's Guide) could be used for fail-over 
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, 
presence with the primary server (y=1).