|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 27 Dec 2006 12:22:45
To : Victor Sudakov
Subject : Re: SIP phone on FreeBSD
--------------------------------------------------------------------------------
u> <20061226120122.GI865@quarta.carrier.kiev.ua> <emt31o$29rn$1@relay.tomsk.ru>
From: Valentin Nechayev <netch@segfault.kiev.ua>
>>> Victor Sudakov wrote:
VS> Я вот про это:
VS> http://www.stalker.com/CommuniGatePro/NAT.html#FarEnd
VS> В архивах рассылки эта кухня расписана подробнее, можно поискать.
Ясно. Как и говорил - Record-Route для случая вхождения _за_ NAT.
>> И чем rport так принципиален, а received - нет?
VS> Про received ничего не могу сказать. А rport - это именно UA сообщает,
VS> что будет ждать на том порту, с которого отправил (и для которого
VS> есть трансляция в NAT), а не только на том, который в Contact.
Hет. Contact на этом этапе ещё не действует - он будет
использоваться для новых запросов (транзакций) в направлении этого
получателя, а не для данной транзакции. Для данной транзакции
действует только Via (даже Route ещё не актуален - он будет
использован для новых запросов, а в пределах транзакции работает
цепочка заголовков Via).
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 ответ не пропустит.
А вот дальше - см. 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'ы не будут менять порты, то ли вообще непонятно
почему. Rport всего лишь завершает реализацию, внося в неё
симметрию.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
