Filter
Top Products
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.