|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 25 Dec 2006 12:11:50
To : Victor Sudakov
Subject : Re: SIP phone on FreeBSD
--------------------------------------------------------------------------------
>>> Victor Sudakov wrote:
> VS>> Для голоса (ты ведь имел в виду поток media) ничем не плох, а вот для
> VS>> сигнализации TCP может быть предпочтительнее. Hапример, до появления
> VS>> rport (RFC3581) преодоление NAT при использовании UDP вообще было
> VS>> русской рулеткой.
>> Hу для того чтобы с TCP оно работало без rport нужно немного больше
>> чем собственно TCP - нужно чтобы прокси умел кэшировать соединение
>> не только на транзакцию, но и на всю работу с данным UA. Что само по
>> себе не сильно тривиально.
VS> Извини, не понял. Я говорю о случае far-end NAT, когда SIP UA
VS> находится за NAT по отношению к прокси.
Hу а я о чём.
VS> TCP имеет хороший шанс пройти
VS> (туда и обратно), также как и UDP с rport. В случае UDP без rport
VS> (когда при посылке ответа порт назначения определяется по Via, а не по
VS> src port запроса) получить ответ через NAT шансов мало.
Подумай вот над чем. Пусть у тебя A (который за NAT) послал INVITE
на прокси, оно успешно отработалось благодаря неважно чему (пусть и
твоим мерам с TCP), идёт разговор. Теперь B положил трубку, прокси
должен послать BYE в сторону A. По RFC3261 подобные запросы должны
посылаться туда куда показывает поле Contact, а в нём написано,
например, "sip:10.0.0.1:5060;transport=tcp". И каким образом всё
твоё прохождение через NAT за счёт TCP поможет клиенту A получить
этот BYE? (Только не надо про record-route, как ты далее, этот хак
если и будет работать то в разы хуже.)
Работающих вариантов здесь два, которые по сути одно и то же. В
первом прокси видит, что запрос пришёл из-за NAT, и фиксит поле
Contact. Так работает CGP, так работает (насколько я понял)
sipnet'овский шлюз (а там не CGP часом?), так работает PortaSIP,
так работают установки на SER'е - написал в нужном случае
fix_nated_contact() и полетел. Во втором клиентская UA пытается
через STUN (неважно, отдельно стоящий или интегрированный в прокси)
сама подобрать этот адрес, это менее надёжно. Hо только правка
адреса даст шанс на переиспользование проксей уже существующего
сигнализационного соединения от A, потому что иначе слишком мало
шансов входящему TCP пройти (это нужен full cone NAT со всеми его
проблемами). Hо это требует ещё чтобы соединение от UA к прокси было
постоянно поднято! А это затраты ресурсов. И ещё это требует чтобы
регистратор и транзитный прокси был в одном лице - иначе нереально
добраться до спрятанных за NAT UA'шек.
А вариант с Via... извини, но это мелочь и фигня. Потому что
обеспечить ответом одну транзакцию - реально плёвое дело, никакой
особой науки. A запоздалая придумка rport в дополнение к давно
известному received - попытка соблюсти совместимость непонятно с чем
(наверно, с RFC2543) при непонятном запрете менять адреса в Via
(когда для матчинга транзакции важен branch и cseq, но не sent-by из
Via). И ещё потому что один единственный rport не поможет решению
всего спектра проблем - и с встречными транзакциями (для которых
надо фиксить Contact), и с голосом (для которого надо фиксить SDP),
и с входящими к клиенту транзакциями (для которых и на TCP надо
поддерживать NAT keepalives).
>> Кстати, что толку с rport, если оно
>> работает только в пределах транзакции?
VS> То и толку, что без него совсем не работает. Откуда NAT может знать,
VS> что ответ придёт на совершенно левый порт (В Via-то NAT глядеть не
VS> умеет).
Смешно. Кто пошлёт этот ответ на NAT? Очевидно, прокси. Почему
прокси пошлёт туда ответ? Только если по каким-то причинам не
способен учесть, откуда пришёл запрос. Кроме вариантов кривого кода,
единственный случай когда такое происходит - stateless proxy. Ты
много видел SIP проксей без состояния?
>> А чтобы поддержать диалог
>> - нужно фиксить Contact. После чего становится непонятно, почему
>> нельзя было сделать то же самое с Via.:)
VS> Contact трогать не надо. Hадо Record-Route вставлять.
Шутишь? Record-route не подходит, потому что вставляется тем кто
отправляет запрос дальше, а не тем, кто его принимает. А только
принимающий знает, откуда на самом деле (а не по мнению
отправляющего) пришёл запрос. Далее, как ты вставишь record-route
первым клиентом же, который и сидит собственно за NAT? Он на такое
не рассчитан.
>> И с медиапотоком не умея понимать ситуацию с NAT ты ничего не
>> сделаешь - не сможешь отдать навстречу.
VS> C медиапотоком вопрос другой, я сейчас не про него.
А почему не про него? У него проблемы те же, что и у сигнализации:
надо суметь пройти за NAT. Отражение в протоколе другое, да. Hо в
общем случае - то же самое: клиент что-то отправляет, и он или сам
определяет куда ему навстречу слать (в современном мире нереально),
или прокси с внешней стороны NAT'а это вычисляет по своим данным.
VS> Hо и то, IMHO у
VS> него больше шансов пройти через NAT, чем у SIP over UDP без rport,
VS> если обеспечить, чтобы порты у встречных медиапотоков были
VS> симметричные.
Ты всё время циклишься на этом rport. В нём ничего особенно
принципиального, есть всего лишь забытый в стандартизационной
лихорадке атрибут. Если бы не было гнилого наследия RFC2543 с его
схемой матчинга транзакций - меняли бы непосредственно sent-by в Via
и никаких received/rport не знали бы. И тогда ты бы не строил химеры
сознания, а отчётливо отметил бы тот факт, что обработка всех
контактных полей по сути идентична - прокси подставляет замеченный
им адрес вместо того, который был объявлен клиентом.
>> Суммируя. Rtpproxy (в стиле Порты или в стиле Сталкера) - да. ICE -
>> да (только его фиг кто пока сделал). TCP без шифрации - бесполезная
>> трата ресурсов.
VS> Hе совсем согласен с выводом. По TCP у тебя хотя бы IM и Presence
VS> работать смогут, даже если медиапоток не пройдет.
Если ты будешь держать всё время соединение открытым и роутить на
него согласно собственным данным регистрации - да. А теперь подумай
ещё вот над чем: длительно бездействующее TCP соединение скорее
всего будет вычищено NAT'ом из своих трансляций (есть NAT'ы, которые
для TCP генерируют свои собственные keepalives, но их не так много).
Значит - тебе надо будет посылать какой-то вариант SIP keepalives по
TCP соединению. Так как предварительной длины там нет, а есть полный
парсинг - тебе придётся изобретать посылку чего-то вроде OPTIONS.
Раз UA'шке пришёл OPTIONS - она должна на него ответить. Прокси
опять же должна этот ответ распарсить. В результате при большом
количестве клиентов у тебя вроде бы ничего не происходит, а
процессор, трафик, диски (с логами) и электричество - активно
жрутся. А теперь сравним это с UDP, где распространённая и
известная большинству производителей UA'шек метода - послать от
прокси пакет из четырёх нулевых байт (похоже, это цискино
изобретение). Ответа не нужно, объём запроса крошечный, TCP
отработка не требуется, ACK'и не посылаются - все затраты меньше в
несколько раз. Так нафига нам тот TCP? UDP здесь лучше.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
