far-end NAT traversal

Коллеги,

Не затруднит разъяснить пару вопросов по far-end NAT traversal.

В документации написано: 'If a SIP client sends a request to CommuniGate Pro and the client own network address specified in the request headers is included into the NATed IP Addresses list, while the Server has received this request from a different network address, NOT listed included into the NATed IP Addresses list, the Server decides that this client is behind a NAT.'

Этот момент касается действительно только request headers или также и адресов, передаваемых внутри SDP ? Читаем дальше 'To allow other users to make incoming calls to a client behind a NAT, the CommuniGate Pro server keeps the "communication hole" between the client and server open by periodically sending dummy packets to that client. Use the Ping NATed Clients setting to specify how often the Server should send those packets.'

Каким таким пингом можно заставить NAT device создать в своей таблице запись для трансляции _входящего_ пакета, если на устройстве специально не сконфигурирован static NAT, port mapping и т.п.?

Что мне хочется узнать в результате. Если UA находится за far-end NAT, какой должен/может быть этот NAT ? Будет ли UA работать через тупой NAT, который только умеет транслировать адреса в L3 заголовках? С другой стороны, если CGP определяет наличие NAT по алгоритму, описанному в первой цитате, то "умный" NAT со знанием SIP, видимо, будет только помехой (так как сам попытается подменить адреса в SIP запросе, а возможно и в SDP)? Например "fixup sip" лучше включить или отключить? И как через NAT проходит входящий (в сторону UA) media поток?

Если существует какая-то white paper, разъясняющая все эти дела, с благодарностью приму ссылку.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru