Re: far-end NAT traversal

От: Vladimir A. Butenko <CGatePro_at_mx_ru>
Дата: Tue 21 Feb 2006 - 13:36:08 MSK

On Tue, 21 Feb 2006 16:04:32 +0600
  "Victor Sudakov" <CGatePro@mx.ru> wrote:
> Vladimir A. Butenko wrote:

>> >
>> >Не затруднит разъяснить пару вопросов по 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 ?
>> 
>> Только headers. Точнее - по верхнему Via.

>
> А в каких конкретно местах SIP-сообщений CGP подменяет приватные
> адреса на глобальные?

А он их не должен менять. Это всякие "умные гейтвеи" их меняют (неправильно). Менять надо только SDP.
> И на основании чего мой UA принимает решение о том, куда отправлять
> поток media, чтобы он попал на другой UA, который находится за far-end
>NAT? На основании того SDP, который ему подсунет CGatePro. А в нем будет порт самого CGatePro - туда оно и будет слать media. А оттуда - релеиться куда-то. В том числе - на другой UA из-за far-end NAT.

>> >не сконфигурирован static NAT, port mapping и т.п.?
>> 
>> Она не создаётся. Она поддерживается. Дырку пробивает, REGISTER request. А 
>> сервер в неё суёт CRLF. Периодически. В НАДЕЖДЕ, что дырку не затянет. Но 
>>- 
>> не факт, может и затянуть. 

>
> А этот CRLF доходит до хоста с UA и тот его тихо дропает со словами
> "что это еще за фигня прилетела, я не просил"?

SIP обязан нормально понимать CRLF на UDP и TCP "пакетах". Да, и он их будет дропать.   

>> >Что мне хочется узнать в результате. Если UA находится за far-end NAT,
>> >какой должен/может быть этот NAT ? Будет ли UA работать через тупой NAT, 
>> >который только умеет транслировать адреса в L3 заголовках?
>> 
>> Да.

>
> Уточню - а если он при этом не просто NAT, а PAT ?
> Т.е. транслирует N локальных адресов в M глобальных, где N>M ?

С Вашего клиента (с его порта 5060, но может быть -и с любого другого) приходят пакеты - на CGatePro. Если "внешний" адрес и порт: а) не будет меняться
б) не будет заростать (то есть можно будет в тот же адрес-порт сувать пакеты, и они будут доходить до Вашего UA) -

  то всё будет работать. Если будет "заростать", а потом - присваивать другие порты - то работать "не будет" (то есть всё равно будет, но ненадежно). Метод топором - это заставлять клиента слать REGISTER каждую минуту - если сайт небольшой (несколько тысяч клиентов активных), то это можно себе позволить.
Метод более "легкий" - это слать те самые CR-LF пакеты от сервера к клиентам.

>> Когда Вы трубку снимаете, Вы туда что-то говорите - хоть кашляете, хоть 
>> вздыхаете. И от телефона начинают идти пакеты на CGatePro. Он видит - 
>> откуда - и начинает пакеты "другой стороны" пихать в образовавшуюся дырку. 

>
> То есть media потоки "туда" и "оттуда" обязаны быть зеркально
> симметричными по портам? А если remote UA, к примеру, отправил в нашу
> сторону поток с порта 3456 на порт 4567 (и создалась соответствующая
> запись в таблице NAT), а входящий поток ждет вовсе на порту 6789 (ну
> вот договорились два UA о таком)? Или так не бывает? Или тут вмешается
> media proxy и не допустит такого безобразия?

Так быть не должно. Хотя это и не прописано четко, но "негласный договор" в том, что порт, прописанный в SDP - это не только порт приема, но и порт передачи, и большинство продуктов (в том числе и CGatePro) просто будут игнорировать пакеты, которые пришли "не с тех" портов и адресов.

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

>
> В том месте, которое я цитировал, или где-то ещё?

Да, на странице RealTime -> SIP.   

>> приближении. А во втором - это никакой белой бумаги не хватит :-(

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

Sincerely,
Vladimir Получено Tue Feb 21 10:35:41 2006