в любом случае, такое пространственно-временное разделение процессоров можент лего привести систему в состояние double main. если между процессорами пропадет линк, каждый из них сочтет себя единственным и оба станут main.

отвечу "от пртивного". у тех, кто не делает такого дубоирования, таких задержек нет. опять же делая свои выводы я основываюсь на вашем описании проблемы. к сожалению, часто у людей бывают субъективные оценки проблем работы оборудования. грешат на одно, фактически оказывается другое.

работают конечно. просто не кто не ставит дублирование через спутниковый линк по IP.

я думаю есть смысл поднять патч до последнего (16с), до 15 есть упоминаяния про проблемы с искажением голоса в СИП транках. если не поможет - трассировки и сервисный запрос в Алкатель.

пока писАл вы уже ответили. опять же имхо, лучше иметь два CS рядом в разных медиагейтвеях, и PCS рядом с периферийными шелфами

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

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

на D8: вход платы стандартный пачкорд! на ЕТАР: входы 1,2 и 4,5 а выходы в сторону D8 1,2 и 7,8. то есть при обжимке разъема D8 не забудьте, что оранжевая пара разбита слева и справа от синей.

я думаю у вас где-то ошибки в программировании что-куда звонит и где абонент, где транк SIP... тонкостей в этом вопросе много. софт я так понимаю перставляли на генезисе.

еще возможно  проблема с тем, что порты RTP генезис предлагает 85хх а алкатель 327хх вообще в алкатель для транспорта голоса используется 256 портов начиная с 32512

что за юзер у вас ALA@193.150.151.110 ?
он на вашем прокси не зарегистрирован.
поставьте режим аутентификации SIP none

это и есть ваш minor sip component alarm

a трассировку SIP с помощью traced не можете показать?

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

Абстрактно рассуждать очень тяжело. Тестовые утилиты для коллцентра adm_acd и pilot2a. Но это сложные инструменты. Вы когда тестируете своими звонками вероятно "делаете все правильно" а вы попробуйте спровоцировать систему, сделать неверный выбор профиля или взаимисключающий вариант. Думаю что эти ваши клиенты просто желают стоил неправильно или в вашей системе назначения профилей есть лазейки, которые вы не учли. Т9 жжет выше было не желают а делают.

Если речь идет о скидл, то вероятнее всего у вас waiting queue. Из этого объекта звонки распределяются не по принципу FIFO а по инициативе так сказать оператора, в зависимости от совпадения его профиля скиллов. У вас видимо или скиллы не те или звонок на входе получает не тот профиль, при котором его можно быстро обоаботать.