You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

 

The 

Unable to show "metadata-from": No such page "_space_variables"
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,

Unable to show "metadata-from": No such page "_space_variables"
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).

Note
The SBC Core does not support NAT traversal for IPv6 calls. Ensure NAT is disabled in pure IPv6 call scenarios.

Signaling Traversal

For the signaling aspect, the

Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
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

Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
; after the initial registration, the
Unable to show "metadata-from": No such page "_space_variables"
relays only a subset of subsequent REGISTER messages to the SIP Registrar based on a longer internal refresh interval.

Secure Media Host Traversal

The

Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
must actually send the RTP to the NAT'd public address/port. Since the RTP stream is generally symmetric, the
Unable to show "metadata-from": No such page "_space_variables"
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

Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
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.
Once a valid RTP packet is found against the signaling IP and the RTP stream is established, no further validation is required.
To use this feature, the Media NAT Traversal flag "mediaNat" must first be enabled.

Secure Media Hosted Traversal CLI Syntax

% 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. 

Media NAT Traversal CLI Syntax

% 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 

Unable to show "metadata-from": No such page "_space_variables"
 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 
Unable to show "metadata-from": No such page "_space_variables"
 is controlled by the 
Unable to show "metadata-from": No such page "_space_variables"
 which supports NAT traversal of INVITE messages (call setup) towards SIP UA.

The 

Unable to show "metadata-from": No such page "_space_variables"
 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.

  • No labels