Re: _outboundsip._udp

От: German Myzovsky <CGatePro_at_mx_ru>
Дата: Wed 22 Feb 2006 - 14:28:12 MSK

> "Упаднические настроения" только в отношении использования CGP :),

> и дело даже не в поддержке только "глупых" NAT, там не понятно как
> на боевой системе логи разбирать, и что при SIP Ddos делать :(

Обоснованные предложения есть? Касательно NAT, по моему опыту, лучше, чем сейчас, сделать невозможно. Остались два неудобства, которые по моему мнению не стоит трогать.

I. Траверс firewall без NAT. Получается классическая схема ftp с его двумя портами. Отправил с порта 1054, в Contact'e стоит 5060, NAT'а нет, на firewall'е 5060 закрыт, а 1054 открылся ненадолго, но туда никто ничего не пишет. Схема ftp passive применительно к SIP была бы актуальна. Но с другой стороны, потом все равно пойдет медия, HOLD/Transfer и где-нибудь firewall это дело зарежет. Лучше сразу честно признаться, что firewall -- нельзя.

II. NATed IPs. Пространство RFC1918 известно не всем. Внутренних сетей 192.167.x.x и 127.x.x.x -- достаточно. Что будет, если прописать 0.0.0.0-255.255.255.255, я не знаю. Опция Detect Always [v] была бы кстати. Т.е. три Via, якобы белый адрес в top Via, но адрес источника другой -- всё, сохраняем Path и поехали пинговать. Как это отразится на честных Via -- неизвестно. Поэтому лучше не трогать.

По остальным функциям затруднений пока не возникает. Логи пишутся 300 Mb в mfs, потом gzip'уются. Тулза парсит log.gz на диске за 10 сек., log в mfs за 5 сек. Кластерной версии пока нет :).

> Про PBX я молчу, может в 5.1 там чего лучше будет. Да, применений не нашлось. Только войсмэйл минуто-мегабайтный. Пока не будет кодеков, [в России] дело не пойдет. Непосредственно CG/PL нареканий не вызывает: садись и пиши. Не хватает функциональности -- обоснуй и получи.

Никакого другого пути нет, CG/PL уже сейчас повторяет некоторые зигзаги Cisco TCL. Рано или поздно будет синтаксис CG/PL 2.0, весь SIGNAL будет приниматься стоковым приложением, любая строка в header'е будет доступна на чтение и запись, появятся persistent tasks в глобальном контексте. На боевой системе логи можно будет дублировать в юзер/директорию... Или дальше стоковых spp* дело не двинется.

С кодеками сложно будет. Производительность нужна конкретная, это уже не релей из сокета в сокет. Значит кластер. SIP Farm дорогой, Catalyst с DSP на борту дешевле получится. Идеально было бы внешним плагином подключить к CGatePro PBX груду железа под Win/Linux с кодеками на Intel IPP под ответственность лицензиата (схема добавления G.729 в WM5). Если же делать внутри, то логично не раздувать стоимость лицензии на кодеки до полутора млн., а ограничить количеством каналов под ответственность CommuniGate Systems.

Впрочем, ни то, ни другое не ляжет на архитектуру и споткнется либо на том же SIP Farm, либо на системе лицензирования.

-- 

Герман Мызовский,
Tario Communications.

Получено Wed Feb 22 11:28:23 2006