Как правило ничего не мешает. Особенно если менеджмента не много. Были станции - годами работавшие.
А вообще по жизни:
- ошибки софта
- неаккуратное обслуживание
- осознанно вредные действия персонала.

Я считаю - надо анализировать инциденты и избавляться от ненужных (зачем вы вставили плату в 0-13 не прописав ее в менеджмент?)
Поднимите время по NTP (на обоих процессорах).
Процессора рекомендуется включить в отдельный VLAN, чтоб всякие броадкасты в сети не мешали им жить
и т.п.
На тему последнего (вредные действия) - была софтинка 4730i, там был хороший tool для просмотра сети. Написано - что им нельзя пользоваться в обычной жизни, он отъедает память, он для инсталлятора при запуске сети - но кого это останавливало.

для начала - надо разобраться с проблемой.
Тикеты (в нормальных станциях) хранятся до 99 дней (задается в менеджменте, по дефолту 31 день). Далее автоматом убираются.
Проблемы а'ля ваши - возникают при рестартах, когда разные времена на процессорах, расхождении баз.
Команда accreset позволяет поудалять лишнее.
Сохраните базу
Остановите stand-by
Разберитесь с main
Поднимите второй процессор через клонирование.

данный инцидент говорит - что на на stand-by и main - разошлось представление о железе.
дайте команду listerm 0 15
потом зайдите на stand-by и дайте ее же - сравните.
Как-то не так клонирование сделали.

Данную команду (переиндексацию) рекомендуют делать перед сохранением базы при разных апгрейдах.
Никогда на моей памяти не удавалось таким образом исправить "испорченную" базу, кроме отдельных крайне экзотических проблемах.

данный инцидент не имеет никакого отношения к клонированию. Он говорит что в 0-13 вставлена плата, а в менеджменте ее нет.
Выдерните платы, которые не прописаны или пропишите вставленные.
Клонирование полезно делать при рестарте (останавливаем stand-by, рестартуем main, после запуска поднимает второй процессор в дубль через клонирование). Предполагая что рестарты редки (например 1 раз в год).
Ну и естественно делаем клонирование, когда пойдут инциденты со stand-by - про неизвестный терминал и т.п.

RTP и количество ресурсов - это разные вещи. RTP - это протокол договоренности о выделении ресурсов и определенный способ формирования пакетов. Сколько товарищей поучаствует в соединении - вопрос не однозначный.
Например - если два IP устройства совместимы по кодекам - они работают напрямую, если нет - могут быть задействованы ресурсы INTIP3 (IP аппарат по G711 говорит со станцией, а она по G729 общается с внешним устройством - SIP). (это что у нас написано - компрессия внутри/за пределы домена, какая компрессия по дефолту, стоит ли галка на мультиалгоритм)

А что мешает фильтровать входящие звонки по initial dialed number?
Все относящиеся к ней получили.
Дальше звонки с duration=0 и waiting time не 0 - не отвеченные.
Звонки с duration не 0 - отвеченные. Как долго звонок висел до ответа - waiting time.

Всем спасибо! Мне приятно, но лучше давайте дождемся следующего 20 Марта!!! Всем удачи!

В любом случае - использование громкой связи требует культуры разговора.
Сразу, негромко, одновременно - это не правильно.
Говорить надо по очереди, говорить надо правильно "э-э-э скажите....", "э-э-э предлагаю ..."

а вы сделали что-то, чтоб в 4760 звонки появились?
1) они должны быть на станции - "accview -tf" - смотрите содержимое файлов тарификации на станции.
Если их нет - настраиваете тарификацию
Если есть - но нет по данному направлению - смотрите что за проблема (например в accounting duration для данной TG осталось "не тарифицировать".
Ели она private, и т.п.

2) если есть на станции - тогда сказано ли у вас в ОХЕ что тикеты надо собирать.
Кроме того - их нет в 4760 (в аккаунтинге стоите на абоненте - видите последние 10 тикетов, нужных нет) или их нет в отчетах (т.е. просто репорт не правильно формируете)

Если будет показывать нечестное время сообщений - это уже плохо.

Куда смотреть? Показываете t3 трассу и спрашиваете, что не хватает.

У вас - здоровая сеть.
Инцидентов - хватает (мне всегда казалось, что при наличии инцидентов - количество начинает переходить в качество).

Разберитесь с сетью (работает или нет) - suproutage вам в руки.
Далее - разберитесь с броадкастом. Включен или нет на узлах. Что разрешено рассылать/принимать, что нет. Т.е. или выключить везде (или по зонам) или включить везде, настроив что вас интересует.
После чего рестартуйте броадкаст - cleanbroad по всей сети (если он включен)

Повторю вопрос - т.е. были рабочие инциденты и все - никаких слов - что shutdown вызван и т.п.?
команда last  что показывает (она в 5-м есть?) - есть коннекты, кто вызвал рестарт

Был VH. Не помню чем с ним сердце успокоилось:
- при работе от 220 - практически сразу уходил в ребут (причем инцидентов не было)
- при работе от АКБ - работал!!!
- поменялись корпусами с учебным - т.е. переставив платы из одного в другой - оба VH продолжили работу.

А инцидентов - точно никаких нет? Т.е. были обычные - и бац? Никаких - что система пошла на перезагрузку и т.п.?