NAT Traversal Considerations
If the device sits behind a NAT router (typically the case), it can discover the mapped external
address corresponding to its local SIP contact address as seen by the server in one of the following
ways:
● From the “received=” and “rport=” parameters of the VIA header of the REGISTER response sent
by the server. These two parameters tell the device its mapped IP address and port number. This
method is used if periodic registration is enabled on the device.
● From the response to a STUN binding request the device sent to a STUN server. This method
is used by enabling X_KeepAliveEnable and setting X_KeepAliveMsgType to “stun”. In that case,
the STUN server is taken from X_KeepAliveServer, if it is specified. Otherwise, the keep-alive
messages are sent to the same server where a REGISTER request would be sent to. The latter is
the most effective way of using STUN to discover the mapped external contact address.
The device always uses the mapped external contact address in all outbound SIP requests instead of
its local contact address if one is discovered by either method discovered above.
SIP Proxy Server Redundancy and Dual Registration
Server Redundancy specifically refers to the device's capability to look for a working server to
REGISTER to from a list of candidates, and switch to another server once the server that it currently
registers to becomes unresponsive.
Device registration must be enabled in order to use the server redundancy feature. Other SIP
requests, such as INVITE or SUBSCRIBE, are sent to the same server that the device currently
registers with.
If Outbound Proxy Server is provided, server redundancy is applied to the Outbound Proxy Server
instead of the registration server. Server redundancy behavior is enabled by enabling the
ITSP Profile
X - SIP::
X_ProxyServerRedundancy parameter, which is disabled by default.
Another requirement for using the server redundancy feature is that the underlying server must be
configured in the device as a domain name instead of an IP address. This allows the device to collect
a list of candidate servers based on DNS query.
The domain name can be looked up as DNS A record or DNS SRV record. For A records, all the IP
addresses returned by the DNS server are considered to have the same priority. For SRV records,
the hosts returned by the DNS server can be each assigned a different priority.
After a list of candidate servers are obtained, the device first looks for a working server according to
the stated priority. A
working server
means one that the device can successfully registers to. This is
known as the
Primary Server
. Subsequently, the device maintains registration to the primary server
the usual way. However, if no working server is found after traversing the entire list, the device takes
a short break and repeats the search in the same order.
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 to 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 device searches for a working secondary server in the same manner from the
74
Chapter 12Service Providers
To Next Page
Loading...
Need help?
General
