forum.technoforward.ru

3002, 3003, 3040 и 3041 по Д-каналу (116) выставил на 31.
3593>02 исправил на 00. Попробуем получить логи потока у оператора - как получу прикреплю в сообщении.

А вроде ж как для роута D-канала было принято значение по умолчанию оставлять? Т.е. "15" или "NONE" в новых релизах?

Судя по этой выдержке, начиная с релиза 12.2, действительно, допустимо не указывать номер D-хэндлера для D-рута. Но с другой стороны, и указывать этот номер никто не запрещает. В такой ситуации я бы предпочел указать его явно. Тем более, что релизов IPS выше 14-го (для которого приведена выдержка) в обозримом будущем не ожидается, а в более далеком - и подавно, а значит - нет повода менять привычки...

Засомневался... Проверил на выборочных станциях 7400 M100ES/ED, M100MX, 2000IPS 6-го и 10-го релизов. Везде:

3593 > D-channel trunk route: 15

Иными словами, я никогда не привязывал его к номеру канала EDSS


Тут нельзя не согласиться...
Но, думаю, в данном случае это ни на что не влияет.

Обзвонил несколько городских номеров, с которых часто звонят к нам - выяснил этот глюк имеет место последние 1-2 месяца. Понял, после всех наших манипуляций глюк не исчез. Последний раз был вчера. Просто информация об этих несостоявшихся входящих вызовах нам не доходили.
В связи с этим:
1. Есть файл *.ofd, который я снял со станции в июле этого года посредством MatWorX>Maintenance>Save, тогда станция скорее всего еще не глючила. Можно было бы загрузить этот файл обратно. Проблема: Это еще мы на практике не проходили, боязно.
2.Не уходит ли входящий вызов каким то образом в ночной/А/В режимы? А не находя маршрут - теряется в недрах станции? Как бы настроить эти маршруты чтобы вызовы дошли хоть до любого абонента (или настроить эти режимы как дневной режим) или явно стереть фрагменты этих несостоявшихся маршрутов?

По п. 1: Это было бы целесообразно, если предположить, что с момента снятия .ofd Вы что-либо меняли в программе именно на Вашей АТС.
Процедура при корректном исполнении и при условии невыключения до полного окончания - достаточно безопасна. Перед выполнением можно рекомендовать на всякий случай снять ещё и текущий дамп. Нужно иметь ввиду, что в конце загрузки по идее должна произойти автоматическая запись загруженных данных во флэш, и, вероятно, - рестарт. Если Вы этого не заметили, имеет смысл сделать это в ручную после завершения процедуры (именно в таком порядке!).
По п. 2: "теряться в недрах станции", да еще и с выдачей restrict инициатору, вызовы не могут. Идея о переключении режимов D\N\A\B имеет право на рассмотрение, хотя для этого кто-то или что-то должно переключить Систему в соответствующий режим, а затем - вернуть обратно. Чтобы отмести эту идею как причину, достаточно прописать команды 7602, 7603 и 7604 идентично команде 7601.

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

Здравствуйте. Вот уже три месяца на входящую связь нареканий нет. Исправилось после манипуляций с настройками АТС или самой PRI-платы. Конкретно не понял после каких изменений исправилось. На всякий случай снял еще раз .ofd через прямое подключение СОМ-портом. После этого стараюсь лишний раз без особой нужды не трогать настройки. Спасибо.