|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Victor Sudakov 2:5020/400 27 Dec 2006 10:15:56
To : Valentin Nechayev
Subject : Re: SIP phone on FreeBSD
--------------------------------------------------------------------------------
u> <20061226120122.GI865@quarta.carrier.kiev.ua>
From: Victor Sudakov <vas@mpeks.tomsk.su>
Valentin Nechayev wrote:
> >> Шутишь? Record-route не подходит, потому что вставляется тем кто
> >> отправляет запрос дальше, а не тем, кто его принимает. А только
> >> принимающий знает, откуда на самом деле (а не по мнению
> >> отправляющего) пришёл запрос. Далее, как ты вставишь record-route
> >> первым клиентом же, который и сидит собственно за NAT? Он на такое
> >> не рассчитан.
> VS> Почему у тебя тот, кто принимает, и тот кто отправляет дальше - разные
> VS> сущности? Это один и тот же прокси.
> VS> В CGP Record-route работает AFAIK так. Если прокси обнаруживает, что
> VS> UAC пришёл из-за NAT (например по наличию RFC1918 адреса в Contact),
> VS> он не трогает Contact, но вставляет Record-route на себя и запоминает
> VS> реальный src ip, откуда пришёл UAC. Согласно Record-route, все ответы
> VS> на запрос теперь будет получать сам прокси, а уж он согласно
> VS> запомненному ip будет передавать их UA.
> Hу если ты вместо Record-Route будешь писать Route, это будет похоже
> на правду. Record-Route поможет в случае вхождения за NAT, но не
> выхода из-за него.
Я вот про это:
http://www.stalker.com/CommuniGatePro/NAT.html#FarEnd
В архивах рассылки эта кухня расписана подробнее, можно поискать.
> >> Ты всё время циклишься на этом rport. В нём ничего особенно
> >> принципиального, есть всего лишь забытый в стандартизационной
> >> лихорадке атрибут.
> VS> В нём принципиальное то, что без него UA был не обязан ждать ответа на
> VS> том порту, с которого отправил запрос. В этом случае шансы пройти
> VS> через NAT вообще нулевые.
> Hулевые шансы как раз если UA захочет ждать на другом порту. Пакет
> через NAT не вернётся.
Hу а я о чем?
> И чем rport так принципиален, а received - нет?
Про received ничего не могу сказать. А rport - это именно UA сообщает,
что будет ждать на том порту, с которого отправил (и для которого
есть трансляция в NAT), а не только на том, который в Contact.
До появления rport в чём была загвоздка? UA отправлял с
192.168.1.1:1234, а ждал на 192.168.1.1:5060 (и писал это в Contact).
Естественно, NAT про 5060 знать не знал, а знал только про 1234.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
--- ifmail v.2.15dev5.3
* Origin: AO "Svyaztransneft", SibPTUS (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
