1. Question:
   I understand from your documentation that part of the NATPASS Firewall Controllers function is discovering the type of NAT the UA is behind independent of UA STUN, TURN, ICE, capability.. I would like to confirm this point.
   
   Answer:
   It's completely independent, It has it's own mechanism to figure out type of Firewall (FW).
   Later versions of NATPass can take advantage of having second public IP address (should be specified in config file), to recognize type of FW more accurate.
   
   
2. Question:
   What cases require media relay traversal? Can you provide a table similar to the following of two SIP UAs behind their own NAT and using NATPASS define which cases support media release and which require relay traversal?
   
   Answer:
   Well. That is not so trivial.
   
   First of all. NATPass has startup option "-f" or configuration option "full_mode = ON". If any of those is set, NATPass would always translate RTP trough itself and would not even try to figure out type of FW or release RTP.
   
   Otherwise there are a few different scenarios and they treated differently.
   
   A. If UA1 is calling to UA2 (most likely using one or more proxies)
      and they both are behind the same FW, and they both use the same
      NATPass,RTP would be released regardless of FW type.
   
   In all other scenarios to NATPAss there are two independent calls. First part is call from UA behind FW to Public Service (Proxy) and second part is call from Public Service (Proxy) to UA behind FW. They are completely separated from each other. Any part could be missing. For example call from UA behind FW to UA located in Public IP or vice versa (most likely call from/to PSTN)
   
   It's important to understand that even if call is going from one UA behind FW to another UA behind FW those calls are independent, and it's possible that one of them would be released and another not.
   
   If it's clear, it would be obvious that it doesn't make sense to build table as "UA1/UA2 NAT Type"
   
   
   Now let's consider other scenarios.
   
   B. UA located on Public IP (not behind FW) but still pointed to NATPass.
      In this case RTP will be always released.
      (BTW Registration from those type of client not cached, and
      does not decrease licensed number of allowed devices)
   
   C. UA behind Symmetric FW.
      RTP can't be release even in theory and will always be translated
      by NATPass, except for scenario 1.
   
   D. UA behind Cone FW.
      Type of cone is irrelevant here. Ability to release RTP not depend
      on type of cone. Type of cone only affect on provisional SIP responses
      and behavior of NATPass before call is setup. Depend on type of
      Cone NATPass could bypass 'Early media' or emulate 'ring' itself.
   
      As soon as NATPass realized that FW is Cone it's trying to figure out
      external port for RTP.
   
      If this process is successful RTP is released.
   
   Every call placed from/to UA through NATPass has two time critical
   processes: Determine type of FW and Determine External address of RTP.
   
   If any of this process is time out NATPass automatic roll over this particular call to FULL mode and start translate RTP itself.
   
   Current statistics shows that more then 90% of calls from/to devices behind any type of Cone FW are released.
   
   The reason why less then 10% of calls from/to UA behind Cone FW are not released is timeout. In most cases UA located far enough from NATPass or there is some network congestion.
   

©ABP International, Inc    - 06/22/2004 - SDS

All information in this FAQ is supplied as best effort only.
ABP does not guarantee suitability of products or provide any guarantees or warranties on our vendors products.