посмотрите еще рах внимательно, какая remote network стоит в вашей ТГ, которая подключена к Genesys и SIP subnetwork. С этим могут быть связаны ошибки minor component и отключения юзеров.

на старом форуме:
http://forum.intersyst.ru/read.php?7,7769,7776#msg-7776

Занятый аппарат - это часом не мобильный с городским номером?

начните с того, что дайте команду eqstat 1731 и 1635. увидите какое оборудование имеет эти neqt. в бактрейсах мелькает DND. странно что это приводит к бактрейсам. еще на этом термниале полезно посмотреть termstat d <номер_абонента>

Да уж. Задним пересмотрев заново Ваш traced видно. Что генезис отвечает только предлагая pcma/8000 то есть g711. Чтобтак в корне был поломан сип впатче 16 надо очень постараться. Видимо у французов не только в футболе стало плохо.

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

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

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

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

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

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

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

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

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

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