Стоит 2000 IPS R6.2, включенный в ТфОП по PRI. Нужно подключить к НЕКу в операторских целях IP-шлюз также по PRI. При этом АОН при транзите с города на шлюз передаваться не будет (сам не пробовал, но говорят, что это так).
Вот я и думаю, чем это может обернуться?
В таком случае, авторизацию нужно проводить не на шлюзе, как это обычно делается, а на НЕКе.

1. В Feature Manual'е описана функция CID Call Routing. Если я правильно понимаю, то с ее помощью можно проводить авторизацию абонентов по АОНу на транзитное соединение со шлюзом.
Оговорюсь, что мне ни разу не приходилось использовать CID Call Routing, поэтому хотелось бы услышать (увидеть) мнения людей, которые пользовали эту фичу или просто знают как она работает.

2. И еще один немаловажный момент: насколько я понял то тут (в этой фиче) используются те же DID таблицы емкость которой 1000 строк, соответственно можно раписать всего 1000 номеров (АОН). Это так?

3. Хочется сделать так: входящие вызовы с Calling Party Number XXXXX проверяются по АОНу, а c Calling Party YYYYY - отправляются на DISA, пароли которой являются пин-кодами карточек.

4. Если подойти к этому вопросу с другой стороны.
Как заставить NEC отдавать входящий АОН при транзите с PRI?
Знаю я один способ, правда дорогой и кривой... но тем не менее рабочий: в НЕК поставить 2 карты 30CCTA, завернуть их друг на друга и транзит пустить через них. Тогда АОН должен пойти транзитом. Но стоят они, млин очень дорого :(

Если подключить шлюз не по PRI, а по R2 или QSIG, то будет ли в таком случае транзит АОНа?
Может еще есть какие идеи по этому поводу?

Кстати, какие IP-шлюзы поддерживают QSIG (если вообще такие существуют)?

Может я не совсем все понял, но тем ни менее.

Я понял, что у тебя звонок приходит из города на DISA, далее происходит авторизация, далее на IP-шлюз. Проблема биллинговать эти звонки?
Если это так , то я это делал. Для биллинга проблем никаких. SMDR может показываеть коды авторизации, пароли. Получается так, вместо внутр. номера показывается 6-значная цифра(номер роута+номер транка). Вопрос только в том, чем вы SMDR обрабатываете, какие данные показываются.

Немного не так.
Сейчас DISA не настроена, потому что IP-шлюзы еще не подключены. Пока это все в проекте.
Поясните, пожалуйста, подробнее откуда берется 6-ти значное число (номер роута - 2 цифры и номер транка - 3 цифры, соответственно вместе - 5 цифр), и в каком случае выдается SMDR в таком виде? Если войти в станцию через DISA и позвонить наружу?
Моя же проблема заключается в следующем: на кого возложить функции по проведению авторизации? Если на НЕК - то как работает CID Call Routing? Если на IP-шлюз - то нужно выдавать наружу номер звонящего с города через НЕК абонента.

mike1 пишет
При этом АОН при транзите с города на шлюз передаваться не будет (сам не пробовал, но говорят, что это так).

Попробуйте на промежуточной станции поставить на транки 21 вместо 18. Типа, обмануть их :-). Тогда, глядишь, и АОН пройдет... :) :rolleyes:

Balzam пишет
Попробуйте на промежуточной станции поставить на транки 21 вместо 18. Типа, обмануть их :-). Тогда, глядишь, и АОН пройдет... :) :rolleyes:
Спасибо за совет, но, к сожалению, не имею возможности попробовать это, т.к. в данный момент никакого транзита нет. Станция работает как оконечная.
Если я правильно понял - вы имели ввиду СМ3002-Trunk-21, что согласно Command Manual'у означает "Dial-in for WCS". Не могли бы вы пояснить логику своих рассуждений, что это означает?
Мне кажется, что в таком случае реальнее попробовать поставить 31 - "DID, Tie Line and the call wich is not handled by the PBX".
Но это все догадки...
Может кто сталкивался с этим???

Специально SMDR я не настраивал. У меня биллингуется только исходящая связь, запись появляется только при установленом соединении.
С DISA тоже самое, в SMDR запись появляется при выходе наружу, при установленом соединении.
6-ти значное число - это 3 цифры роута + 3 цифры транка.
Авторизацию я бы возложил спокойно на НЕК. 1000 одновременных pin-кодов должно хватать. В крайнем случаи карту расширения памяти поставишь и увеличишь до 3000.

DMG пишет
Специально SMDR я не настраивал. У меня биллингуется только исходящая связь, запись появляется только при установленом соединении.
С DISA тоже самое, в SMDR запись появляется при выходе наружу, при установленом соединении.
6-ти значное число - это 3 цифры роута + 3 цифры транка.
Авторизацию я бы возложил спокойно на НЕК. 1000 одновременных pin-кодов должно хватать. В крайнем случаи карту расширения памяти поставишь и увеличишь до 3000.
Запись появляется при установлении соединения??? Насколько я знаю - НЕК этого не умеет, и выдает в SMDR запись ТОЛЬКО по завершению разговора. Соответственно возникает еще проблема с отбоем. Кто и как будет рвать соединение если закончатся деньги на счете?
Сейчас узнал: авторизация по АОНу действительно работает так как надо.
Еще одна проблема: если направлять входящий с города донабор на DISA а не на Automated Attendant для того чтоб можно было дальше выйти наружу, - то не получится вставить голосовое приветствие...
Вопросов становится все больше и больше...

1. Я имел ввиду время считается с момента установления соединения. Если соединение не установлено (абонент занят, не отвечает) запись в SMDR не попадает.
2. Чтоб деньжки с карточки считывались, нужна отдельная софтина. Во-Всяком случаи, нам для "гостинечного сервиса" пишут сейчас прогу , которая будет считать денежки и управлять станцией. Подозреваю, что для IP-шлюза считалка денежков тоже нужна.
3. Я вообще имеею ввиду REMOTE ACCESS TO SYSTEM, а не AUTOMATED ATTENDAT. В Feature Programming Manual на стр. 410-411, по-моему написано о голосовых сообщениях. Или я ошибаюсь.

DMG пишет
1. Я имел ввиду время считается с момента установления соединения. Если соединение не установлено (абонент занят, не отвечает) запись в SMDR не попадает.
2. Чтоб деньжки с карточки считывались, нужна отдельная софтина. Во-Всяком случаи, нам для "гостинечного сервиса" пишут сейчас прогу , которая будет считать денежки и управлять станцией. Подозреваю, что для IP-шлюза считалка денежков тоже нужна.
3. Я вообще имеею ввиду REMOTE ACCESS TO SYSTEM, а не AUTOMATED ATTENDAT. В Feature Programming Manual на стр. 410-411, по-моему написано о голосовых сообщениях. Или я ошибаюсь.
1. Это понятно, что АТС начинает отсчитывать время после получения сообщения Connect.
2. У вас случай проще. Вам не нужно извращаться с транзитом. Вам нужно всего лишь тарифицировать СВОИХ абонентов. Хотя об одном тонком месте в этом моменте я уже писал.
3. В Feature Programming Manual на стр. 410-411 не нашел никакого упоминания о голосовых сообщениях. Вы смотрите мануал какого релиза? Если по R6.2 - то у меня на этих страницах Message Reminder-Dterm.

Какая разница кого тарифицировать, внутренних или приходящих по DISA. Для отключения абонента нужна управляющая софтина. У НЕКа (думаю и у шлюза) таковой нет.
И что значит извращатся с транзитом? Почему не тарифицировать просто по паролю?
Что касается голосового сообщения, посмотри REMOTE ACCESS TO SYSTEM, может быть страница не совпадает.

Для того чтоб разрывать соединение можно воспользоваться PMS. Команда разрыва соединения у НЕКа есть:
EB0 - disconnect trunk
EB2 - disconnect EXT.
Тарификация на НЕКе при таком режиме работы станции, как стоит в моей задаче, затруднительна по ряду причин: например мало 3000 кодов DISA, реально карт в обороте ходит примерно 20000. Начал я задумываться о возложении функций авторизации на некий внешний сервер, на котором бы крутилась БД с пин-кодами. Вопрос в том как ее интегрировать с АТС?
REMOTE ACCESS TO SYSTEM посмотрел. Ничего про голосовое сообщение там не нашел. Назови, пожалуйста, номер команды где ты это видел. И все таки, мануалом какого релиза ты пользуешься?

To All:
Может быть на какой-нибудь другой УАТС возможно реализовать данную схему?
Есть варианты?

Да , согласен с голосовыми сообщениями немного напутал. Сообщения можно записывать от внешнего источника.
Мануал на диске с надписью R41 (наследство)

PMS - это правильно. Но мне объясняли, что это немного железок + софт.

Я работал в компании по предоставлению услуг междугородки по пин-кодам. Более 500 абонентов одновременно у нас не получалось. Правда, мы карточки не использовали. Пин-коды прописывали на оборудовании клиента.
Кстати, станцию ребята сейчас стали использовать Definity. Говорят возможностей побольше.

DMG пишет
Я работал в компании по предоставлению услуг междугородки по пин-кодам. Более 500 абонентов одновременно у нас не получалось. Правда, мы карточки не использовали. Пин-коды прописывали на оборудовании клиента.
Кстати, станцию ребята сейчас стали использовать Definity. Говорят возможностей побольше.
Очень интересно! Расскажи, пожалуйста, подробнее! Как понимать "Пин-коды прописывали на оборудовании клиента.", а проверку правильности пин-кода кто осуществлял???
Как вообще была реализована схема. Я правильно понял, что работали на NEC'e? Если да - то какая модель?

Мы работали только с юридическими лицами. По-началу, работали на чужой станции. "Арендовали" пин-коды, и раздовали их своим клиентам. Прописывали - значит записывали их в скоростной набор миниатс, или кнопки памяти аппаратов. Пин-коды у клиентов были постоянные, звонки они делали в кредит.
Недавно я созванивался с ребятами. Сейчас они поставили свою станцию Definity. За авторизацию отвечает станция. Звонки также делаются в кредит. Биллинговая прога обрабатывает стандартный SMDR.
Компании работающие на карточной платформе обычно используют сервера и маршрутизаторы типы Cisco AS5300, Vanguard можно использовать.

На самом деле карточная система не совсем удобна.
Во-первых, клиенту удобнее запомнить постоянный набор цифирик и не заботится о постоянном пополнении своего счета.
Во-вторых, карточка ассоциируется с IP-телефонией, о качестве которой до сих пор не добрая слава. Оно и понятно, "последняя миля" в российской глубинке может испортить все представление о качестве связи.
И третье, выпуск 20000 карточек. Экономический риск адекватен, если не больше, звонкам в кредит.