|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 13 Jan 2007 22:22:12
To : Victor Sudakov
Subject : Re: SIP phone on FreeBSD
--------------------------------------------------------------------------------
>>> Victor Sudakov wrote:
> VS>> Я вот про это:
> VS>> http://www.stalker.com/CommuniGatePro/NAT.html#FarEnd
> VS>> В архивах рассылки эта кухня расписана подробнее, можно поискать.
>> Ясно. Как и говорил - Record-Route для случая вхождения _за_ NAT.
VS> А я разве другое утверждал?
Ты слишком неясно описал.
VS> Выход _из-за_ NAT IMHO вообще никаких проблем не представляет,
Представляет. Потому что всегда надо входить обратно.:)
>> Hет. Contact на этом этапе ещё не действует - он будет
>> использоваться для новых запросов (транзакций) в направлении этого
>> получателя, а не для данной транзакции. Для данной транзакции
>> действует только Via (даже Route ещё не актуален - он будет
>> использован для новых запросов, а в пределах транзакции работает
>> цепочка заголовков Via).
VS> Уточни пожалуйста понятие "транзакции". BYE в конце разговора - это та
VS> же самая транзакция или уже другая?
Другая. В пределах того же диалога. Ты бы RFC почитал, что ли. А то
потом появляются такие вот объяснения, которые надо разбирать
начиная с определений терминов.
VS> Вот BYE IMHO должен пойти по
VS> Contact - но если он пойдёт напрямую - там его никто не ждёт. Вот тут
VS> и пригодится Record-Route, чтобы BYE тоже пошёл через прокси. Так?
Да.
>> Если сделать 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 ответ не пропустит.
VS> Так вот rport и гарантирует, что UA реально ждёт ответа на
VS> 192.168.1.1:1234. И если трансляция в NAT ещё не протухла, ответ он
VS> получит.
Hу гарантирует, и что с того? Я всё время пытаюсь понять, почему ты
ему какую-то особую роль, чуть ли не мистическую, назначаешь. Хотя
он используется всего лишь для уточнения направления посылки ответа
на запрос в пределах транзакции.
>> а порт куда делся? В общем, откровенная недоработка - то ли они
>> думали, что NAT'ы не будут менять порты, то ли вообще непонятно
>> почему.
VS> Мне кажется, они просто не думали про NAT.
Тогда откуда и зачем у них взялся received?
VS> Помнится, есть некий checklist при написании RFC: нужно учесть то-то и
VS> то-то. Hе припомнишь, работа через NAT там упомянута?
Да.
>> Rport всего лишь завершает реализацию, внося в неё
>> симметрию.
VS> Отож. Почему я и говорил о важности поддержки rport в клиенте.
В том с чем я работаю - если обнаруживается, что клиент за NAT,
rport вставляется независимо от того, был ли он в запросе. Пока что
ни одного плача по этому поводу не слышал.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
