Service Providers
Polycom, Inc.
36
While maintaining registration with the primary server, the device continually attempts to fall back to one of
the candidate servers that has higher priority than the primary server, if any. The list of candidate servers
that the device is trying to fall back on is known as the
primary fallback list
, which may be empty.
In addition, the device can be configured to maintain a secondary registration with a server that has lower
or equal priority than the primary server. Secondary registration can be enabled by setting the parameter
X_SecondaryRegistration
to YES. If
X_ProxyServerRedundancy
is NO, however,
X_SecondaryRegistration
does not take effect. If this feature is enabled, as soon as a primary server is
found, the device searches for a working secondary server in the same manner from the list of candidate
servers that are of lower or equal priority than the primary server. Similarly, once a secondary server is
found, the device forms a
secondary fallback list
to continually attempt to fall back on if the list is not empty.
The interval for checking the primary fallback list and the secondary fallback list are configured in the
X_CheckPrimaryFallbackInterval
and
X_CheckSecondaryFallbackInterval
parameters. These
parameters are specified in seconds and the default value is 60 for both.
Notes:
●
If a secondary server exists it implies a primary server exists.
●
If the secondary server exists, it immediately becomes the primary server when the current primary
server fails. The device then starts searching for a new secondary server if the candidate set is not
empty.
●
The candidate list can change (be lengthened, shortened, priority changed, etc.) on every DNS
renewal (based on the entry’s TTL). The device rearranges the primary and secondary servers and
fallback lists accordingly.
If the server redundancy feature is disabled, the device resolves only one IP address from the server’s
domain name, and won’t try other IP addresses if the server is not responding.
SIP Privacy
The device observes inbound caller privacy and decodes the caller’s name and number from SIP INVITE
requests by checking the FROM, P-Asserted-Identity (PAID), and Remote-Party-ID (RPID) message
headers. All these headers can carry the caller’s name and number information.
If PAID is present, the device takes the name and number from it. Otherwise, it takes the name and number
from RPID if it is present, or from the FROM header otherwise. RPID, if present, includes the privacy setting
desired by the caller. This privacy can indicate one of the following options:
●
off
= no privacy requested; the device shows name and number.
●
full
= full privacy requested; the device hides both name and number.
●
name
= name privacy requested; the device shows the number but hides the name.
●
uri
= uri privacy requested; the device shows the name but hides the number.
Regardless, if PAID exists or not, the device always takes the privacy setting from the RPID if it is present
in the INVITE request.
If the resulting call name is Anonymous (case-insensitive), the device treats it as if the caller is
requesting full privacy.
