Нет, стоит 7 цифр.

Да, 10.157.5.13 это ОХЕ.
А до ОХО ничего, как мне кажется, доходить и не должно. Это же ограничение по Public Network COS, запрещенные наборы наружу не выходят. Не так разве?

Набор идет всего номера сразу, ибо SIP аппарат.

Вот набор на 9330000, работает запрещающее правило 9330000, 7 знаков, войсгайд играет нормально
https://cloud.mail.ru/public/f8915a57a18e/9330000.txt

Вот набор на 9332222. Работает запрещающее правило 933, 7 знаков. Войсгайд обрывается.
https://cloud.mail.ru/public/8f250c068300/9332222.txt

А что-то я не могу трассы вставить...

Здравствуйте все.
Имеем OXE MG R11.0.1-k1.520-32-b, включенная SIP транком в провайдера (роль провайдера в данном случае исполняет ОХО). Проблема - при попытке запретить через Public Network COS определенные наборы "в город" войс гайд "набранный вами номер не зарегистрирован" играет около секунды и потом прерывается сигналом отбоя.
Подробно: набираем номер 9330000, есть в дискриминаторе правило 933 с разрешенной area, вызов идет.
Меняем в правиле 933 area на запрещенную, получаем пол-войсгада и отбой "Address Incomplete".
Причем если создать в дискриминаторе правило с целым номером 9330000 и его запретить, то при наборе любого номера из десятка 933000x имеем честный полный войсгайд.
Количества цифр в номере не влияет. Тип номера не влияет. Тип префикса не влияет.
Где еще поковырять?

Вот-вот. Поскольку лицензия Accounting for ABCF Calls (или как ее там, забыл) отсутствовала, тарификации не было.

Коллеги, всем спасибо за участие.
Причина оказалась в другом: транк-группа в SIP транке была создана с типом ABCF. Перезоздали как ISDN all Countries, и начал откладываться аккаунтинг.
Еще раз всем спасибо.

Не заработало. Файлы TAXAxxxx.DAT не появляются. Еще идеи?

ПС Команда account on говорит, что аккаунтинг и так был включен.

at the end of call выставили, посмотрим, как это повлияет.

Files for External Accounting = Yes
Internal Accounting = Yes.
И так было с самого начала.

Проверил, Real Time Ticket Output = No, а CDR Ticket Storage все равно не включается.
В общем, я в недоумении. файлы IPxxxxx.DAT копятся, а TAXAxxx.DAT нет ни одного. В фильтры уже внесли вообще все, что можно занести. Звонки только по SIP транку, по идее, это должен быть фильтр Public Outgoing Network Call. В чем может быть засада?
Посмотрели другую аналогичную станцию с таким же включением по SIP транку - так файлы откладываются. Сравнили менеджмент аккаунтинга, все один в один.

Оп... Я всегда думал, что в файлах TAXxxxxxx.DAT хранится обычный аккаунтинг (звонки по потоку и аналоговым транкам), а в IPxxxxx.DAT звонки по VoIP.
Как бы то ни было, файлов TAX...DAT в директории usr4/account нет, и на станции в mgr/Applications/Accounting не дает сделать CDR Ticket Storage = YES.

Да, Дмитрий, все выставлено и файлы присутствуют.

Коллеги, здравствуйте.
Виста не хочет собирать тикеты VoIP звонков. На станции они есть, лицензия Accounting не равна 0, а TicketCollector = 0.
При синхронизации видно, что виста пытается скачать файлы обычного аккаунтинга, выдает ошибку, так как их там нет (только VoIP).
[12/2/2014 5:33:20 PM] Target: XXX,XXX,XXX
New Status : Accounting ticket loading
[12/2/2014 5:33:21 PM] Target: XXX,XXX,XXX
warning : Accounting ticket loading is not supported by the PCX, or no accounting ticket exists in the PBX
[12/2/2014 5:33:21 PM] Target: XXX,XXX,XXX
New Status : Polling Completed
[12/2/2014 5:33:21 PM] Target: XXX,XXX,XXX
New Status : Loading Completed


А VoIP аккаунтинг даже не пытается читать. В чем может быть засада? Не в том дело, что TicketCollector = 0?

ПС Метод сбора тикетов выставлен, само собой, в "Accounting and VoIP".

Undef - такой статус PCS имеет, если он сконфигурирован, но не синхронизирован с основным CS. После выполнения команды pcscopy статус станет INACTIVE (если все настроено правильно, само ообой). Если линк до основного CS порвался и полка перешла на PCS, статус станет ACTIVE.

Да, Андрей, само собой.

VAD, спасибо. Почитал ТС, включил management mode 128, и проблемы вроде бы прекратились.

Была ситуация - в сети три центра, к каждому подключено около 30 узлов. При рестарте одного из центров и, соответственно, вале инцидентов о пропадании подключенной к нему периферии другой центральный узел (дублированный AS) с множеством динамических линков входил в ступор. Все платы виделись в сервисе, но пропадало питание на аппаратах, падал VoIP и потоки. Лечилось баскулом.

Уже третий день тьфу-тьфу-тьфу (стучу по дереву).