В менеджменте - User/dynamic state user - Busy camp-on

Человек на аппарате во время разговора нечаянно нажал кнопку camp-on, соответственно и с аппарата ее снова можно нажать. Как на русском подписана клавиша - не помню.

Или (если проблема только с внешними звонками) поменяли категорию Public Network COS (Access COS) - Incoming DID hold on busy set (верните 1).

Точно Padlock. Спрошу насчет существования подсказок.

у товарищей 10-й, спасибо за инфу по 10.1, если чего - есть путь куда идти.

Не сталкивались с проблемой (45-й патч):
- аппарат заблокирован (префиксом lock/unlock).
- если префикс и пароль набирать быстро - то он разблокируется, если не торопясь - то нет.

А с ABC-F мне кажется в SIP будут проблемы. Если supervised by routing - не доступен, не будет создан Х.25 кластер под эти ресурсы, и система подумает что нет доступных ресурсов для VPN звонка.
Хотя, с другой стороны, для организации ABC-F вам понадобится сигналинг (возможность общения между процессорами по IP), а если есть хождение по IP - остается плюнуть на SIP, а поднять и использовать H.323 для сетевых звонков.

Все равно не понятно - зачем вам делать разную регистрацию для разных абонентов станции (вернее не вам, а провайдеру). Что мешает - с точки зрения "не левых" соединений - аутентифицироваться станцией на шлюзе (иметь один external gateway), а отдавая правильный АОН - разруливать тарификацию у провайдера для разных организаций внутри вашей АТС.
Просто похоже - схему с одной маленькой станцией/отдельным аппаратом - распространили на станцию с несколькими организациями, при этом ни чего не меняя.

а у вас чего - абонентам звонят с 10-ти разных гейтвеев? Офигеть.

Господа - брейк. Бодаться - в личку.

Покажите строчку с error (Дим, это не инцидент, это не когерентность базы).
Тогда можно будет ПОПЫТАТЬСЯ подумать что с этим делать. Чаще всего через cuser править напрямую базы и рестартовать станцию (откатиться по базе если появилось недавно, или забить если не мешает - возможностей много).

Вопрос сигналинга - это где ПРОЦЕССОРА будут обмениваться МЕЖДУ   СОБОЙ в процессе работы (поэтому и интересно только для 0-го кристалла). N64 - это по C1 линку, IO2 - общение будет через платы IO2N, Ethernet - соответственно по Ethernet. Проблема с N64 - иногда процессора не успевают все обновлять.

Т.е. возможность с компа достучаться до процессоров и где происходит межпроцессорный обмен (N64, IO2, Ethernet) - это не связанные вещи.

А по сути - да ставите IO2 и 8 каналов или Ethernet в 0-м ящике и рестартуете станцию.

Потерял нить рассуждений. на данный момент в чем по сути проблема? На тему кодеков - всегда не забываем смотреть System/other/compr. param - Обычно бывает интересно иметь галку в поле multi alg for compression.
И второе  -  не взирая на то, что прописано в VoIP транковых группах (например G711) - на самом деле будет использоваться то, что прописано в IP/IP domain. Для SIP в дефолте - ехтра кодинг алгоритм (для 711 надо поставить - без компрессии).
Для IP аппаратов - интра домен алгоритм.
Для VPN звонков - что сказано на тему колеков в VPN overflow.

Сигналинг в 0-м (только он интересует) шелфе - IO2 c 8-мью каналами (или Ethernet).
Включать процы в сеть - на мой взгляд лучше втыкать оба (только перемычкой на плате запретить on-board ethernet).

А 7-й релиз на CPU7 стоял? Не меняли процессора и пр.? В 0-м шелфе - сигналинг стоит IO2 на 8 каналах (или Ethernet) надеюсь. Не Nx64 c 4-мя?
А вообще хороший инцидент. веселее - когда на тестовые сообщения IO2 не отвечает - тогда отпадет (после 3-го не ответа) IO2. а с ней и процессор.

Выравнивать по жизни надо все - через клонирование  - базу, через netadmin -m  - копировать настройки Линукса.

Раз в доке на совместимость написали - скорее всего будер работать. Специфичных фич не будет (типа Calling Party Control).