Polycom SIP 3.0.2 Manual Do Utilizador

Página de 288
Administrator’s Guide SoundPoint IP / SoundStation IP 
4 - 42
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 any 
of servers. For example, SUBSCRIBE/NOTIFY services (used for features such 
as shared lines, presence, and BLF) will only be established with Server 1.
Upon 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.
Recommended Practices for Fallback Deployments
In situations where server redundancy for fall-back purpose is used, the 
following measures should be taken to optimize the effectiveness of the 
solution:
1.
Deploy an on-site DNS server to avoid long call initiation delays that can 
result if the DNS server records expire.
2.
Do not use OutBoundProxy configurations on the phone if the 
OutBoundProxy could be unreachable when the fallback occurs. 
SoundPoint IP phones can only be configured with one OutBoundProxy 
per registration and all traffic for that registration will be routed through 
this proxy for all servers attached to that registration. If Server 2 is not 
accessible through the configured proxy, call signaling with Server 2 will 
fail.
3.
Avoid using too many servers as part of the redundancy configuration as 
each registration will generate more traffic.
4.
Educate users as to the features that will not be available when in 
“fallback” operating mode.
Note
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 do not become 
excessive. This would be of particularly concern if a phone had multiple 
registrations with multiple servers per registration and it is expected that some of 
these servers will be unavailable.
Note
If reg.x.server.y.register is set to 0, then phone will not register to that server. 
However, the INVITE will fail over to that server if all higher priority servers are 
down.