|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Victor Sudakov 2:5020/400 27 Dec 2006 12:56:33
To : Valentin Nechayev
Subject : Re: SIP phone on FreeBSD
--------------------------------------------------------------------------------
u> <20061226120122.GI865@quarta.carrier.kiev.ua> <emt31o$29rn$1@relay.tomsk.ru>
u> <20061227082238.GJ865@quarta.carrier.kiev.ua>
From: Victor Sudakov <vas@mpeks.tomsk.su>
Valentin Nechayev wrote:
> VS> Я вот про это:
> VS> http://www.stalker.com/CommuniGatePro/NAT.html#FarEnd
> VS> В архивах рассылки эта кухня расписана подробнее, можно поискать.
> Ясно. Как и говорил - Record-Route для случая вхождения _за_ NAT.
А я разве другое утверждал?
Выход _из-за_ NAT IMHO вообще никаких проблем не представляет, если
а) порты симметричны, б) клиент не умничает с попытками определить свой
внешний адрес через STUN etc и в) NAT/Firewall не умничает, пытаясь
менять адреса в протоколе. Т.е. чем меньше специальных телодвижений
при выходе - тем лучше.
> >> И чем rport так принципиален, а received - нет?
> VS> Про received ничего не могу сказать. А rport - это именно UA сообщает,
> VS> что будет ждать на том порту, с которого отправил (и для которого
> VS> есть трансляция в NAT), а не только на том, который в Contact.
> Hет. Contact на этом этапе ещё не действует - он будет
> использоваться для новых запросов (транзакций) в направлении этого
> получателя, а не для данной транзакции. Для данной транзакции
> действует только Via (даже Route ещё не актуален - он будет
> использован для новых запросов, а в пределах транзакции работает
> цепочка заголовков Via).
Уточни пожалуйста понятие "транзакции". BYE в конце разговора - это та
же самая транзакция или уже другая? Вот BYE IMHO должен пойти по
Contact - но если он пойдёт напрямую - там его никто не ждёт. Вот тут
и пригодится Record-Route, чтобы BYE тоже пошёл через прокси. Так?
> VS> До появления rport в чём была загвоздка? UA отправлял с
> VS> 192.168.1.1:1234, а ждал на 192.168.1.1:5060 (и писал это в Contact).
> VS> Естественно, NAT про 5060 знать не знал, а знал только про 1234.
> Если сделать s/Contact/sent-by/ (такое поле в Via, например: "Via:
> SIP/2.0/UDP 192.168.1.1:5060; branch=...") - будет почти правильно.
> "Почти" - потому что картина немного сложнее: в твоём примере нужно,
> чтобы UA реально ждал ответа и обрабатывал принятое на
> 192.168.1.1:1234, а не только на 192.168.1.1:5060, как он же и
> попросил. Иначе NAT без знания SIP ответ не пропустит.
Так вот rport и гарантирует, что UA реально ждёт ответа на
192.168.1.1:1234. И если трансляция в NAT ещё не протухла, ответ он
получит.
> А вот дальше - см. RFC3261:
> ==={{{
> o Otherwise (for unreliable unicast transports), if the top Via
> has a "received" parameter, the response MUST be sent to the
> address in the "received" parameter, using the port indicated
> in the "sent-by" value, or using port 5060 if none is specified
> explicitly. If this fails, for example, elicits an ICMP "port
> unreachable" response, the procedures of Section 5 of [4]
> SHOULD be used to determine where to send the response.
> ===}}}
> что у тебя будет в случае NAT и отсутствия rport? Получится каша:
> Via: SIP/2.0/UDP 192.168.1.1:1234;received=1.2.3.4
> а порт куда делся? В общем, откровенная недоработка - то ли они
> думали, что NAT'ы не будут менять порты, то ли вообще непонятно
> почему.
Мне кажется, они просто не думали про NAT.
Помнится, есть некий checklist при написании RFC: нужно учесть то-то и
то-то. Hе припомнишь, работа через NAT там упомянута?
> Rport всего лишь завершает реализацию, внося в неё
> симметрию.
Отож. Почему я и говорил о важности поддержки rport в клиенте.
--
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
