Network Hosted NAPT/NAT Traversal

 

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
  Unable to show "metadata-from": No such page "_space_variables"
  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
  Unable to show "metadata-from": No such page "_space_variables"
  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
  Unable to show "metadata-from": No such page "_space_variables"
  and the SIP peer. Otherwise, any "unsolicited" packets the
  Unable to show "metadata-from": No such page "_space_variables"
  sends towards the SIP peer are dropped by the NAPT device. The implication for both signaling and media is that the
  Unable to show "metadata-from": No such page "_space_variables"
  must first receive packets from a SIP peer located behind a NAPT device before it can send packets to such a peer. (refer to Adaptive NAT Pinhole Timer).

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.

Secure Media Hosted Traversal CLI Syntax

To use this feature, the Media NAT Traversal flag "mediaNat" must first be enabled. 

Media NAT Traversal CLI Syntax

Refer to Zone - SIP Trunk Group - CLI for CLI command details for these two flags.