palich

Понятно. А зачем она Вам так нужна? Что-то не работает без нее?

Вы в принципе излагаете задачу понятно. Но мне кажется, не до конца понимаете принципы работы АТС определенного вендора с их телефонами (чаще всего по проприетарным протоколам). Суть в том, что АТС с телефонами с таком случае образуют единую инфраструктуру. Отсюда следует, что если ввести в эту инфраструктуру инородный ( производства другого вендора) объект, то единство теряется. В Вашем случае телефоны остались, а АТС поменялась. Для CISCO АТС телефоны Avaya "чужие", и скорее всего никаких настроек она им не отдаст.

Так получается, что это функция телефона - он сначала собирает все цифры номера, что Вы набрали, а потом отправляет их блоком на АТС. CCM 5.0 тут ни при чем.

Где можно было переключать? Enblock - это метод передачи цифр номера в сигнализации DSS1, причем тут телефоны? Мануал для чего? Что куда надо enblock'ом передавать?

Скорее всего коллега SoftSwitch рассказывал об этом. В соседней теме он писал про РТУ на виртуальных машинах. Он же и в БД пишет своими скриптами.

Друзья, есть информация от МФИ, что в ESXi бывают сбои с чтением ключа. Так что - на свой страх и риск...

как можно взять на тестирование G100F в Санкт-Петербурге?

На семинарах рассказывали про РТУ на KVM. У людей работало. Но самых лучший и надежный способ - это спросить у технической поддержки бывшей МФИ-СОФТ, ныне Swithray.

Надо выяснять почему "все это время UCCX естественно OUT_OF_SERVICE" - это первопричина. Потому что, пока не поднимется UCCX, CTI порты и не подумают регистрироваться. Смотрите логи и алармы UCCX. Можно долго смотреть что к чему, а можно сделать лайфхак аля: Сделать delay по-больше добавить в файл 2 секунды тишины

Думаю, что надо перенести тему в соответствующий раздел Продажа телекоммуникационного оборудования

mAccess.MTU (48FXS) или mAccess.MAK (от 30 до нескольких сотен FXS) производства НТЦ Протей

Добрый день, коллега. Если Вы РТУ не советуете, ECSS не используете, то что Вы рекомендуете? Что стоит у вас на сети? Было бы интересно послушать.

+1 к ответу от Aven Никаких внешних линий через FXO. Ну а абонентам или IP-телефоны или FXS шлюзы.

По идее Вам достаточно забить в гугл запрос "session border controller" и увидите возможные варианты. Я написал про те, про которые слышал или с которыми работал. Этот класс устройств очень специфичный. По-моему, еще многие инженеры и не задумываются об использовании SBC, поэтому, думаю, что каждый смотрит на моменты сугубо индивидуальные... так сказать - со своей колокольни. Из того, с чем мы сталкивались это: - система резервирования (особенности реализации) - link layer redundancy (есть или нет) - количество MAC адресов на интерфейс - количество VLAN на интерфейс - особенности лицензирования - максимальное количество сессий - поддерживаемые протоколы и кодеки и многое-многое другое ...

Да, именно такая схема.

Что сразу приходит в голову: AudioCodes’ Mediant family of Session Border Controllers (SBCs) GENBAND’s QUANTiX™ family of SBCs Oracle Communications Session Border Controller с частности Acme Packet 3820

Добрый день. В голову приходит использование PLAR соединения. Для реализации можно взять 1 Addpac FXS и 1 Addpac FXO. Но не могу сказать, что это будет дешевое решение. Скорее всего есть FXS и FXO шлюзы по-дешевле... но суть от этого не изменится. Схема: ССОП --[2-проводная абонентская линия]--> FXO шлюз --[iP сеть (SIP,H323)]--> FXS шлюз --> [Телефонный аппарат]

ну получаетсЯ, что простой коммутатор потоков тут уже не подойдет, ведь он как-то должен получать этот список должников. выходит, что надо принять на транковый шлюз вызов через поток, отправить на ssw (астер или что-то еще), который как раз и определит, что делать с вызовом, и потом отправить обратно на транковый шлюз уже в нужное направление.

Что вы подразумеваете под "фильтровать"? Какие действия надо осуществлять с вызовами? - что-то пропускать, что-то дропать? Какой-нибудь программный коммутатор (softswitch) у Вас есть на сети?

По оборудованию SNR есть же отдельный форум, как я понимаю как раз для технической поддержки: IP-телефония SNR Может попробовать туда написать?

Присоединяюсь. Вот варианты: Mediant 800 E-SBC Mediant Software E-SBC

Как нам рассказывали, SMG умеет быть SBC. В качестве SBC на границе своей сети могу посоветовать Acme Packet Session Director.

Честно говоря, мы используем Addpac с FXS портами, но думаю, что разница не велика. Мы никогда не сталкивались с проблемами эха, к тому же Addpac поддерживает рекомендацию G.168

У Eltex есть MSAN для большого кол-ва абонентов, это чтобы не плодить кучу 72-портовых шлюзов. Как альтернативный вариант - mAccess.MAK от ПРОТЕЙ, хорошая штука. проверяли. В остальном схема видится мне жизнеспособной. Только под Астер нормальный сервак прикупить и все. Это решение тоже хорошо, но если у вас есть много денег. И Avaya, и Cisco, и даже, думаю, Samsung, выйдем вам в огромную сумму. Один из плюсов - у вас будет законченное и удобное в обслуживании решение.

Хорошие шлюзы у Addpac. Например, VoIP шлюз VoiceFinder AP1002 Высокопроизводительный VoIP шлюз для компаний