Service Providers
47
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”. The keep-alive
messages are sent to the same server where a REGISTER request would be sent.
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 with from among a list of candidates.
● Switch to another server once the server that it currently registers with becomes unresponsive. In
other words, device registration must be enabled 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 register with. This is known as
the Primary Server. Subsequently, the device maintains registration with the primary server the usual way.
However, if no working server is found after traversing the entire list, 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 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 doesn’t 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 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 isn’t empty.
To Next Page
Loading...
Need help?
General
