После всех вышеописанных телодвижений выполнил Daily Job - и появились суточные и месячные счетчики. Начали генериться отчеты по операторам. Какая милая и интуитивно понятная программа!
Всем спасибо за помощь!

PTP процесс галка стоит. Везде.
Вот только что заметил, что у меня в Учет/Сбор данных/Сбор билетов было пустое поле, выставил в Учет и VOIP, после этого в папке Collector появились две поддиректории, но в них пусто. Куда дальше?

Собственно, к изначальному вопросу: для получения статистики по операторам мне PTP нужен или достаточто файлов с тикетами?

Кипит мой разум возмущенный... Что-то я затупил.
На станции DAT файлы с таксацией есть, проверено. Более того, после каждой синхронизации поле "Последний запрошенный файл учета" прилежно меняется на последний DAT файл в станции. Последние 10 вызовов на юзерах тоже обновляются. В файле ACCOUNT.LIS список DAT файлов тоже обновляется. (IP.LIS - пустой)

Но!
В логах синхронизации присутствует
warning: Accounting ticket loading is not supported by the PCX, or no accounting tickets exists in the PBX
В папке 4760_ARC/Accounting/Tickets пусто.
В папке 4760/Data/Collector пусто тоже, хотя мои DAT файлы со станции туда, вроде бы, должны складываться?

А в доке прочел, что надо обьявить сеть PCX
2. Declaring PCXs:
Launch the Directory application, then declare the PCX network in the System tab.
В этой закладке у меня уже и Network, и Subnetwork, и станция присутствуют. Что-то я не догоняю, как сеть надо "обьявлять"...

Добрый день.
Имеем ОХЕ кристалл 8.0.1 и Висту 4.2 (в Актисе на Висту вижу галку Full Pack). Операторская группа из трех операторов (у меня на стенде 4035, у клиента будут 4059IP, думаю, разницы быть не должно). Собственно, задача: по каждому из операторов видеть кол-во принятых/пропущенных вызовов, время в отключке, время звонков в ожидании и т.д. по максимуму).
Виста подключается к станции, синхронизируется без ошибок, я могу генерить отчеты по исходящим вызовам со всех телефонов. В Учет/Траф/VoIP вижу все сделанные вызовы (операторами в том числе). А вот отчеты по операторам или оп. группе пустые. Где копать?
И вообще, я знаю, что информация по исходящим берется из DAT файлов таксации, а откуда берутся данные по операторам?

PS Суточные/месячные счетчики на любом абоненте отсутствуют, при попытке снять контроль по умолчанию идет ругань на недоступность сервера контроля. Может, в этом дело?

Ну... если удастся переключить входящие аналоговые линии ОХО в ОХЕ (которая, кстати, кристалл или common hardware?), и стык между двумя АТС сделан 2МБ потоком, то далее по описанной мной выше схеме. Входящий город абоненты ОХО будут получать транзитом через ОХЕ, и транзитом же выходить через нее в город. Но это уже извращение, по большому счету...

Если абоненты ОХО ходят в город транзитом через потоки ОХЕ, эти вызовы будут откладываться на ОХЕ, вместо номера звонившего будет FS<номер транк-группы>.

А, к примеру, команда config 0 что показывает?

dhs3_init -R maoagent помог, спасибо.
Но... зачем так бывает? В смысле, почему поломалось?

Коллеги! Караул!
R7.0-f4.401-13-ru-c7
При поппытке менеджмента из mgr выдает error:   Got no answer.

Рестартовал. После рестарта обнаруживается невключенный mao. Включаю руками
mao was off -->  mao is on
Не помогает.

В инцидентах необычного, пожалуй, только это:
02/08/11 11:49:48 000010M|--/--/-/---|=0:2663=IPC Chorus err: appli CALLHANDLING oper 6 err -7

На анлишеде был аналогичный случай
http://www.alcatelunleashed.com/viewtopic.php?f=239&t=17190
Так и не решился, похоже.

Ну, и что делать?

Несколько лет назад в Москве было -34, кажется. Никаких жалоб на отказ наружных БС не наблюдалось.

Если речь про исходящие в город, то смотрим Categories/Access category/Public Access Category (есть у каждого юзера). В каждой такой категории есть разрешение/запрещение наборов на определенные номера, определяемые в Translator/External Numbering Plan/Numbering Discriminator

Увела вас дока не в ту сторону...
\OmniPCX 4400\Applications::1\Automated Attendant::1\Automated Attendant Access - это должен быть уникальный номер, никаких совпадений ни сюзером, ни с чем еще. После того, как создадите этот самый AA Access, направляйте на него номер из DID Translator, все должно работать.

Обижаете!.. Такую простую ошибку уж сам бы нашел. Нет, там именно что не создавался 18-й шелф при правильных настройках.

Пока то да се, дело дошло до техсаппорта Алкателя. Только хитрые индусы смогли починить БД. А в чем был косяк - не сказали. А очень интересно.

Да, все так и создавалось, никаких изысков. Просто почему-то не создался 18 шелф. Есть предположение, что это из-за того, что на GD основного кабинета не прописан gateway. Может такое быть?