Re: far-end NAT traversal

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 подменяет приватные адреса на глобальные?

И на основании чего мой UA принимает решение о том, куда отправлять поток media, чтобы он попал на другой UA, который находится за far-end NAT?

>
> >Читаем дальше '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 и т.п.?
>
> Она не создаётся. Она поддерживается. Дырку пробивает, REGISTER request. А
> сервер в неё суёт CRLF. Периодически. В НАДЕЖДЕ, что дырку не затянет. Но -
> не факт, может и затянуть.

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

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

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

>
> >С другой стороны, если CGP определяет наличие NAT по алгоритму,
> >описанному в первой цитате, то "умный" NAT со знанием SIP, видимо,
> >будет только помехой (так как сам попытается подменить адреса в SIP
> >запросе, а возможно и в SDP)?
>
> Абсолютно точно. То есть - если он такой умный, что и строем ходит, и всё
> правильно меняет - то помехой не будет. Но мы таких пока не видили - во
> всех есть ляпы.
>
> >Например "fixup sip" лучше включить или отключить?
>
> На сегодня - отключить. И включать, когда есть время поэкспериментировать.

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

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

> По этой причине, например, если Вы с такого телефона звоните на систему,
> которая шлёт 183 provision, и потом начинает играть мазурку вместо длинных
> гудков - то Вы, увы, скорее всего ничего не услышите - так как Ваш телефон
> ничего не посылает в это время (обычно), и посему куда играть мазурку,
> CgatePro не знает.
>
> >Если существует какая-то white paper, разъясняющая все эти дела, с
> >благодарностью приму ссылку.
>
> А оно в документации нарисовано. Всё именно так просто, как там. В первом

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

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

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