Элтекс

Мы производим транковые VoIP шлюзы уже более 7 лет! Если у Вас есть пожелания по новым моделям, доработкам софта или железа, оставляйте комментарии. Мы обязательно рассмотрим все предложения!

Шлюзы настольного исполнения:
SMG-2 – до 2 портов Е1 (RJ-48), 64 VoIP-канала, 1 порт 10/100/1000Base-T (RJ-45), 1 порт USB 2.0
SMG-4 - 4 порта Е1 (RJ-48), 128 VoIP-каналов, 1 порт 10/100/1000Base-T (RJ-45), 1 порт USB 2.0

Транковые шлюзы с поддержкой IP-АТС:
SMG-1016M – до 16хЕ1 (CENTRONICS-36), до 768 VoIP каналов, до 2000 SIP абонентов, IVR, ДВО, СОРМ, RADIUS-маршрутизация, запись разговоров, SIP/SIP-T/SIP-I/H.323/SIGTRAN
SMG-2016 - до 16хЕ1 (RJ-48), до 768 VoIP каналов, до 3000 SIP абонентов, до 2хHDD SATA 2.5”, IVR, ДВО, СОРМ, RADIUS-маршрутизация, запись разговоров, SIP/SIP-T/SIP-I/H.323/SIGTRAN

Предложения участников форума:

Просьба к участникам дискуссии высказываться строго по делу и воздержаться от лишнего флуда в этой теме.

Ну, собственно говоря, как я уже и писал. То, что на мой взгляд не хватает SMG:
1) Исходящих модификаторов на PBX профилях
2) Мониторинга текущих активных звонков. То есть просто тот же CDR но в онлайне: вх_транк вх_номер вх_модиф исх_транк исх_номер исх_модиф состояние_звонка
3) Возможности прямо в SMG посмотреть последние скажем 50-100 CDR. А лучше возможность фильтрации. То есть мы задаем A/B номер или имя транка и система выводит относящиеся к ним CDR
4) Крайне не хватает онлайновой отладки. Были в процессе запуска транка с Мегафоном, инженер на том конце вживую проговаривал мне что происходит с моим звонком, а мне приходилось: запустить отладку, сделать звонок, остановить отладку, скачать файл, разбираться в файле. При чем здесь тоже желательно сделать фильтр по A/B номеру, чтобы в отладку попадал именно наш звонок, а не все в куче валились.
5) Возможность вывода в CDR всех полей номеров: оригинальный с транка, после транк модификатора, после биллинг модификатора и возможность указывать порядок полей в CDR
6) Господа, а почему так мало категорий АОН? Шлюз поддерживает ОКС7, SIP-T. Где поддержка категорий ISUP/ISUP-R? То, что в "Категории ОКС-7" этого недостаточно. Желателен именно полноценный выбор и назначение этих категорий в модификаторах.

P.S. Это всего лишь за месяц эксплуатации. Дальше думаю еще что-то понадобится

Хотелось бы видеть логи с возможностью их скачивания и дальнейшего хранения по изменениям параметров SIP-абонентов, например:
17.02.2016;09:05:00;admin;Абонент 555-55-55;изменена категория доступа....с такой-то на такую-то

Хотелось бы получить возможность отключать ECM при использовании T.38 на SMG-1016M.

Анвар писал(а):Хотелось бы видеть логи с возможностью их скачивания и дальнейшего хранения по изменениям параметров SIP-абонентов, например:
17.02.2016;09:05:00;admin;Абонент 555-55-55;изменена категория доступа....с такой-то на такую-то

Анвар, а разве SYSLOG - Вывод истории изменения конфигурации не то что Вам надо?

rubicon писал(а):Хотелось бы получить возможность отключать ECM при использовании T.38 на SMG-1016M.

Поясните, пожалуйста, зачем?

Да, и просьба ко всем аргументировать свои пожелания.

Возможность отключать SIP порт для приема в SIP интерфейсах. То есть если мы указываем 0 для порта приема, чтобы в этом профиле система не слушала входящий SIP трафик. Это нужно для того, чтобы можно было более безопасно использовать систему в Интернет без применения SBC и fail2ban. Обходясь простыми правилами файрвола только для интерфейсов, принимающих трафик. А про инициирующие интерфейсы можно не беспокоиться.

Женя писал(а):

rubicon писал(а):Хотелось бы получить возможность отключать ECM при использовании T.38 на SMG-1016M.

Поясните, пожалуйста, зачем?
Да, и просьба ко всем аргументировать свои пожелания.

Для того, чтобы было меньше проблем с прохождением факса по Т.38
Неоднократно сталкивался с ситуацией, когда оба факса поддерживали/использовали ECM и при обнаружении каких-то ошибок при передаче они до бесконечности запрашивали повторную передачу страницы. При блокировке информации о поддержке ECM страница по-крайней мере пройдёт. На других шлюзах это возможность часто поддерживается, даже на древних цисках.

Есть ли возможность рассмотреть вопрос об источниках синхронизации для каждого потока отдельно?

Господа, было бы неплохо добавить кодеки OPUS и Speex

Randomize писал(а):Есть ли возможность рассмотреть вопрос об источниках синхронизации для каждого потока отдельно?

С точки зрения возможности сращивания сетей с разными по характеристикам полями коммутации это конечно прям фишка была бы... с другой стороны хочется сказать "какого хрена?" )) неужели кто то ещё от кварца внутри оборудования работает и неоткуда взять хоть сколько нибудь годный синхросигнал? сейчас все вроде уже от ростелека, или других крупняков берут...

а если подумать, то это вроде как технический аттракцион какой то получится... как вы видите выравнивание синхронизации на своей сети дальше или на сети другого оператора, у которого существенно ниже частота отсчётов?

bravo писал(а):

Randomize писал(а):Есть ли возможность рассмотреть вопрос об источниках синхронизации для каждого потока отдельно?

С точки зрения возможности сращивания сетей с разными по характеристикам полями коммутации это конечно прям фишка была бы... с другой стороны хочется сказать "какого хрена?" )) неужели кто то ещё от кварца внутри оборудования работает и неоткуда взять хоть сколько нибудь годный синхросигнал? сейчас все вроде уже от ростелека, или других крупняков берут...

а если подумать, то это вроде как технический аттракцион какой то получится... как вы видите выравнивание синхронизации на своей сети дальше или на сети другого оператора, у которого существенно ниже частота отсчётов?

А если, например, есть необходимость использовать на одном шлюзе потоки Е1 разных "крупняков", у которых своя синхронизация. Как быть в этом случае?

тут опасная ситуация, о которой я сам в какой то момент переживал, но ростелек и мгтс благополучно присоединились к моей БКП и поля синхронизации совпали, судя по всему... в общем я думаю в 99% случае эти крупняки используют примерно одинаковое оборудование с одинаковой точностью отсчётов, так как им самим между собой надо стыковаться)

Господа, а еще мне одному кажется, что система групп как-то уж искусственно раздута? В плане создания некой "общей" группы. Мне кажется, что более логичным была бы такая система:
Есть N групп доступа, скажем 64. Мы больше не создаем для пользователя некую "общую" группу вроде МС + ЗВ + МГ. А просто в профиле пользователя выбираем, что он принадлежит к группам: МС, ЗВ, МГ.