The
supports SIP peers located behind remote Network Address/Port Translation (NAPT) devices. NAPT is the most common type of Network Address Translation (NAT) The most common is a residential IAD behind a home NAPT device.
NAPT traversal is enabled on an individual IP Trunk Group basis. When configuring NAPT traversal, the Qualified Prefix table (qualifiedPrefix) is defined, which is a set of one or more IP network media and signaling prefixes that an IP address must match to be considered for NAT handling. If no entry is present in qualifiedPrefix table, the endpoint is automatically treated as existing behind a NAT device. As a result,
considers requests from all IP addresses to be behind a NAT device.
Two general issues apply to the problem where NAPT devices rewrite IP header addresses and ports for both signaling and media but do not modify embedded addressing information (i.e., NAPT devices exist that are SIP/SDP unaware):
- The "private" addressing local to the SIP peer is different from the "public" addressing uses to reach the peer through the NAPT device. Consequently, addressing information that SIP peer embeds within signaling messages is insufficient for routing purposes and the needs an alternate means of determining the appropriate destination IP address/port.
- Pinholes must be open in the NAPT device to exchange signaling and media between the and the SIP peer. Otherwise, any "unsolicited" packets the sends towards the SIP peer are dropped by the NAPT device. The implication for both signaling and media is that the must first receive packets from a SIP peer located behind a NAPT device before it can send packets to such a peer. (refer to See Adaptive NAT Pinhole Timer below).
| Include Page |
|---|
| No_NAT_for_IPv6 |
|---|
| No_NAT_for_IPv6 |
|---|
|
Signaling Traversal
For the signaling aspect, the
supports a SIP registration relay service. No special support from the user endpoint/IAD is required for this method of NAPT traversal. REGISTER messages provide the
with a means for learning the destination IP address/port for signaling to the peer - the NAPT'd public source address/port in the IP header becomes the nexthop to reach the SIP peer's registered contact address. The
can then learn the addressing information embedded in SIP signaling messages accordingly.
REGISTER messages also keep the signaling traffic pinhole open. When the SIP peer registers, the
specifies an expiration interval that is comfortably less than the NAPT device's idle timeouts (typically a few minutes); the SIP peer is thus forced to send a refresh registration before the NAPT signaling pinhole closes. The majority of these relatively frequent external refreshes are handled locally by the
; after the initial registration, the
relays only a subset of subsequent REGISTER messages to the SIP Registrar based on a longer internal refresh interval.
Secure Media Host Traversal
The
also supports hosted NAT traversal for media, and exhibits similar behavior for sending media as it does for signaling. More specifically, the addresses embedded in the SDP specification are, in terms of the SIP peer's private addressing, behind the NAPT device; whereas the
must actually send the RTP to the NAT'd public address/port. Since the RTP stream is generally symmetric, the
waits for RTP from the peer and then uses the source IP address/port from the received RTP packet as its destination IP address/port for the return direction. Similarly, destination addressing for RTCP requires additional steps when the peer is behind a NAPT device. The approach is the same: the SBC does not send RTCP packets until it has learned the peer source IP address/port from a received RTCP packet.
The
includes a
secureMediaNatPrefix configurable parameter to specify the prefix length in the network IPv4 address obtained from signaling to match against. When set to a value other than "0", the
validates the source network IP (IPv4 only) of RTP packet against the source network IP/mask obtained from signaling before allowing media to flow. Once validated, the
only accepts packets from the signaling/masked IP address, and drops any RTP packets where network source IP does not match the source network IP/mask obtained from signaling. When
secureMediaNatPrefix is set to "0", this feature is disabled.
Secure media NAT validation applies to any one of the following scenarios:
- at initial call setup using network IP address obtained from INVITE message.
- using network IP address obtain from re-INVITE, UPDATE and REFER messages.
- with a HOLD followed by RETRIEVE.
- for video calls.
| Note |
|---|
| Once a valid RTP packet is found against the signaling IP and the RTP stream is established, no further validation is required. |
| Note |
|---|
To use this feature, the Media NAT Traversal flag "mediaNat" must first be enabled. |
| Code Block |
|---|
|
% set addressContext <address context name> zone <zone name> sipTrunkGroup <TG name> services natTraversal secureMediaNatPrefix <0-32> |
To use this feature, the Media NAT Traversal flag "mediaNat" must first be enabled.
| Code Block |
|---|
|
% set addressContext <name> zone <name> sipTrunkGroup <name> services natTraversal mediaNat <disable | enable> |
Refer to Zone - SIP Trunk Group - CLI for CLI command details for these two flags.
Adaptive NAT Pinhole Timer
For situations where SIP UA is behind NAT which does not support standard NAT traversal mechanism, the
can act as Registrar proxy by forwarding REGISTER messages to Registrar on behalf of SIP UA, refreshing REGISTER messages according to the expiry timer received from Registrar. The expiry timer between SIP UA and
is controlled by the
which supports NAT traversal of INVITE messages (call setup) towards SIP UA.
The
determines the expiry timer value which must be slightly less than NAT pinhole timer in SIP UA side. NAT pinhole closing timer is identified using SIP OPTIONS out-of-dialog mechanism mentioned in RFC 3261 and expires timer in 200 OK for REGISTER message is adjusted to ensure the pinhole remains open.