Obihai OBi100 Administration Manual Download

Page: 96 / 220

While maintaining registration with the Primary Server, the OBi will continually attempt to fallback 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
fallback on is known as the

primary fallback list

, which may be empty.

In addition, an OBi 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 any effect. If this feature is
enabled, as soon as a primary server is found, the OBi will search 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. Simarly, once a secondary server is
found, the OBi forms a

secondary fallback list

to continually attempt to fallback on if the list is not empty.

The interval for checking the primary fallback list and the secondary fallback list are configured in the parameter
X_CheckPrimaryFallbackInterval and X_CheckSecondaryFallbackInterval respectively. These parameters are specified in
seconds and the default value is 60 for both.

Notes:

Secondary server exists implies primary server exists.

If the secondary server exists, it immediately becomes the primary server when the current primary server is fails;
device then starts searching for a new secondary server if the candidate set is not empty.

The candidate list may change (lengthened, shortened, priority changed, etc.) on every DNS renewal (based on the
entry’s TTL). Device will rearrange the primary and secondary servers and fallback lists accordingly, whichever
applicable.

If the server redundancy feature is disabled, the device resolves only one IP address from the server’s domain name, and
will not attempt to try other IP addresses if the server is not responding.

SIP Privacy

The OBi device observes inbound caller privacy and decodes caller’s name and number from SIP INVITE requests by
checking the FROM, P-Asserted-Identity (PAID for short), and Remote-Party-ID (RPID for short) message headers. All these
headers may carry caller’s name and number information.

If PAID is present, device takes the name and number from it. Otherwise, it takes name and number from RPID if it is
present, or from the FROM header otherwise. RPID, if present, will include privacy setting desired by the caller. This privacy
may indicate one of the following options:

off

= no privacy requested; the OBi will show name and number.

full

= full privacy requested; the OBi will hide both name and number.

name

= name privacy requested; the OBi will show the number but hide the name.

uri

= uri privacy requested; the OBi will show the name but hide 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. Note that if the resulting caller name is “Anonymous” (case- insensitive), device treats it as if the caller is
requesting full privacy.

For outbound calls, caller’s preferred privacy setting can be stated by the device in a RPID header of the outbound INVITE
request. To enable this behavior, the parameter ITSP Profile

– SIP::X_InsertRemotePartyID must be set to YES or TRUE,

which is the default value of this parameter. OBi only supports two outbound caller privacy setting: privacy=off or
privacy=full. The RPID header generated by the device carries the same name and number as the FROM header. If
outbound caller-ID is blocked, the device sets privacy=full in RPID, and also sets the display name in the FROM and RPID
headers to “Anonymous” for backward compatibility. The device will not insert PAID in outbound INVITE requests.