forum.technoforward.ru

Ситуация следующая - есть несколько станций, повязанных CCIS over IP. Для простоты рассмотрим лишь две, но проблема глобальная.
Restriction Class (RC), прописанный внутреннему абоненту в 1201 нормально транслируется по всей сети - тут проблем нет.
Абонент входит в первую станцию по ISDN PRI, по CID call routing получает отдельный тенант, отправляется на DISA, где авторизуется по АОН, получает свой RC и гудок для дальнейшего набора. Если дальнейший набор отправляется наружу из локальной станции (первой), то класс нормально отрабатывается и абоненту разрешается звонить только туда, куда разрешается, согласно RC.
Но в случае, если его набор отправляется в удалённую (вторую) станцию, то уже во второй станции он может выйти на любое направление, даже на запрещённые для его RC, чего быть, по сути, не должно.
Вопрос - это глюк, недоработка НЭКа, или попросту где-то затаилась ошибка?

_________________
Если нет дождя и грязи...

На глюк это не очень похоже, а от ошибок - никто не застрахован. Впрочем, оба эти утверждения - чистая схоластика...
Что касается недоработки NECа, то тут всё несколько сложнее. Можно относиться ко всему, что нам не нравится, как к недоработке. В то же время, часто бывает, что одним пользователям хочется видеть фичу одним образом, а другим - совершенно противоположным, противоречащим первому. Поэтому недоработкой, пожалуй, следует считать те из наших неудовлетворенных хотелок, которые не оговорены должным образом в документации.
В данном случае и этот критерий трудно признать абсолютным, поскольку речь идет не об отдельной фиче (Remote Access to System), а о ее работе в сочетании с CCIS, для которого эта фича, как и сходная Automated Attendant вообще не оговорена по причинам, на мой взгляд, достаточно весомым: протокол CCIS на то и служит, чтобы обеспечить прямой доступ к абонентам и ресурсам сети, тогда как AutoAttendant и в значительной степени DISA предлагают сходные удобства внешним абонентам. Упомянутое сочетание, полагаю, усугублено ещё и LCR в каждом из узлов. Это - гемучая смесь.
Тем не менее в Feature Programming Manual --> Chapter 1 BUSINESS FEATURES --> APPENDIX D FEATURES AND SPECIFICATIONS --> BUSINESS F&S --> REMOTE ACCESS TO SYSTEM имеется условие Что это за "dedicated trunk" и "dedicated number to access this capability" - прокомментировать не смогу, но это очень похоже на некое ограничение.

Там же, несколькими строками ранее:


Но в то же время, для внутренних-то абонентов весь этот "limiting access" отлично работает, а вот для абонентов внешних, прошедших тернистый путь дизы, а следом не менее тернистый путь CCIS over IP - нет. По поводу каких-то определённостей транков - слабо верится. Налицо лишь факт наличия дырки.

_________________
Если нет дождя и грязи...

Ещё раз повторюсь - прямых возражений у меня нет, только мнение.
По поводу п. 4 могу заметить (опять же в качестве всего лишь мнения): подразумевает как раз SYSTEM, а не NETWORK. Т.е. действие CLASS OF SERVICE, полученных, фактически, для данного конкретного вызова, можно считать рабочим в пределах узла. А вот в пределах всей сети - об этом никаких прямых утверждений нет...
Впрочем, такая дискуссия вряд ли принесет практические плоды. Я бы предложил Вам попытаться найти что-нибудь материальное для решения проблемы, либо для того, чтобы убедиться в ее нерешаемости. В первую очередь я бы постарался понять, как именно желательно решить проблему частично, если она окажется нерешаемой полностью: запретить прохождение таких вызовов через CCIS, либо наоборот, разрешить это всем, раздавая пароли как можно меньшему кругу лиц.
Если количество уже используемых RSC достаточно невелико, то можно попытаться добавить для внешних DISA-вызовов новую группу RSC, отличную от такой же для внутренних абонентов, и учесть эту новую группу RSC в LCR.