ДОбрый день.
Схема cisco5350 -ISDN PRI -протон -ОКС 7 - город.
Возможно ли в протоне настроить переадресацию по занятости для звонищих из города и внутренних абонентов ?
т.е допустим звонок от абонента или из города приходит на протон и тот его отправляет в PRI на циску. Если циска отбивает по занято (дает дисконнект с 17 кодом) возможно ли перенаправить вызов а)на другого абонента; б) в город; в) в тот же поток но на другой номер?
П.С Протон-ССС Алмаз 1.

Я думаю логичней и правильней данную переадресацию в Cisco настраивать. Протон какой в наличии - Вектор или Алмаз, если Алмаз, то-1, -2 или -4?

Я думаю логичней и правильней данную переадресацию в Cisco настраивать. Протон какой в наличии - Вектор или Алмаз, если Алмаз, то-1, -2 или -4?

Представте себе что циска по сути - конвертор sip в PRI. т.е сип-абоненты за ней по сути являются "виртуальными PRI абонентами". тогда с точки зрения общей маршрутизации не разумно выносить логику обслуживания вызовов за пределы атс. К тому же это бы означало что для каждого переадресованого вызова нужно было бы попусту задействовать 2 таймслота в PRI.
Возможно ли вообще такая переадресация ? Станция : Протон-ссс Алмаз 1, вроде бы :)

Представте себе что циска по сути - конвертор sip в PRI. т.е сип-абоненты за ней по сути являются "виртуальными PRI абонентами". тогда с точки зрения общей маршрутизации не разумно выносить логику обслуживания вызовов за пределы атс...
Тогда и вы представьте, что ЦАТС Алмаз по сути в данном случае конвертор ОКС-7 в PRI и, продолжая ваш логический ряд, переадресовывать городские звонки должна сама городская АТС. :) Хотя и она по сути конвертор... пусть тогда сам телефон переадресовывает :D Хотя, пожалуй, я много требую от простого конвертора тактильных воздействий в абонентскую сигнализацию. Короче, переадресовывать при занятости обязан сам абонент, тем более, что с этой задачей большинство абонов (из тех, что со свежими прошивками и патчами) успешно справляются: занят у Мани городской, звонят на сотовый, ежели она занята Ваней, ну и фиг с ней, набирают Таню
Во я нафлудил, всего-то с двух рюмок:D
А если серьёзно и по делу:
1. Cisco где-то в душе ешё и маршрутизатор, но данную конкретную железяку не настраивал, врать не буду.
2. Есть в Алмазе такой тег - "Таблица наведения". Имхо должен помочь. Полистаю доку, освежу память, а вы всё же убедитесь, что за версия Алмаза

ДОбрый день.
Схема cisco5350 -ISDN PRI -протон -ОКС 7 - город.
Возможно ли в протоне настроить переадресацию по занятости для звонищих из города и внутренних абонентов ?
т.е допустим звонок от абонента или из города приходит на протон и тот его отправляет в PRI на циску. Если циска отбивает по занято (дает дисконнект с 17 кодом) возможно ли перенаправить вызов а)на другого абонента; б) в город; в) в тот же поток но на другой номер?

Делал подобную схему ровно десять лет назад. Сisco-ISDN PRI - Алмаз -ОКС 7 - SI2000.
Реализовано было на одном из первых Алмазов (БИКМ заводской № 12 был). Работало по занято или отвалу всего PRI. Подставлял прификс и уходил обратно в SI2000 на ТЧ каналы. Помню, можно было бы и номер абонента подставить, но только если весь PRI занят/отвалился.

Тогда и вы представьте, что ЦАТС Алмаз по сути в данном случае конвертор ОКС-7 в PRI и, продолжая ваш логический ряд, переадресовывать городские звонки должна сама городская АТС. :) ...
Разумеется представить такое не трудно однако все дело упирается корректность биения на уровни абстракций, А нам между тем помимо конверторов необходимо еще и где-то расположить реализацию плоскостей контоля вызовов и управления. Циска в роли маршрутизатора звонков крайне неудачное решение, когда на алмазе заведено порядка 2000 абоненских комплекта:). Но даже если дилегировать циске некоторое количество функций управления общей маршрутизацией, с точки зрения ресурсов получится крайне не оптимально. Итак звонок уходит на циску - заняли тс в потоке; скрипт на циске обратился к базе (которую к слову придется вести и интегрировать циску в систему учета и управления) и увидел что надо переадресовывать номер - звонок уходит в тот же поток, занимается еще один тс. Итого два тс просто так выкинуто. Теперь представим что у абонента 3 сип телефона и настроена переадресация последовательно с одного на другой. Итого звонок на 1 занятый номер "сожрет" 2+2+1 если и второй будет занят, поскольку придется пулять туда сюда этот звонок. Написание же логики отсеивания лишних легов - фактически написание сервиса на циске - задача нетривиальная, хотя проблему можно решить префиксной маршрутизацией- но в случае нескольких цисок - это гемор ибо тогда уже точно придется звонок выпускать в протон или копировать на все циски планы маршрутизации.. значительно усложняется задача отслеживание рекурсивных вызовов которые могут вообще забить поток (у А преадр на Б у Б на А и оба заняты или недоступны- в сипе такое бывает:D опять надо городить префиксы и учитывать возмоность прихода звонка из города назад) . А представте что циска не одна - и замкнуть на ней сип нумерацию не удастся ? На фоне вышесказаного скрыть сип за PRI и пользоватся единой маршрутизацией и услугами в рамках одной абстрактной модели согласитесь выглядит красивее. Но это так флуд за флуд, прошу прощения. по поводу Таблицы наведения - буду посмотреть, спасибо за наводку , я сегодня просто первый раз открыл доку по Алмазу - дело в том что я то как раз и есть тот администратор циско на которого хотят "спихнуть" фактически машрутизацию абонентов алмаза:D:D:D. Извините великодушно за много букав.
ПО уточненным данным Алмаз вроде первый.

Делал подобную схему ровно десять лет назад. Сisco-ISDN PRI - Алмаз -ОКС 7 - SI2000.
Реализовано было на одном из первых Алмазов (БИКМ заводской № 12 был). Работало по занято или отвалу всего PRI. Подставлял прификс и уходил обратно в SI2000 на ТЧ каналы. Помню, можно было бы и номер абонента подставить, но только если весь PRI занят/отвалился.

А не подскажите в общем плане схему, как это было сделано и что из настроек Алмаза использовали ? Ткните плз, я можно сказать супер новичок в этой АТС.

Приоритеты и модификация где-то в таблицах наведения. Не помню. С Алмазом последний раз работал в 2002 году.

Добавьте в свою схему какой-нибудь softswitch (например, Asterisk (http://ru.wikipedia.org/wiki/Asterisk)), на котором реализуйте недостающий функционал.

Добавьте в свою схему какой-нибудь softswitch (например, Asterisk (http://ru.wikipedia.org/wiki/Asterisk)), на котором реализуйте недостающий функционал.
я вверху писал о недостатках децентрализации управления вызовами. Идея то как раз состояла в том чтобы не делать различий между абонентами а обслуживать всех одинаково, повышая по сути мобильность и универсальность выданых абоненту номеров. А так придется дробить нумерацию итд итп. Предполагаете что подобный, в общем то довольно примитивный, функционал ,описаный в subj ,в Алмазе не реализован ?

Лет пять назад задавался аналогичными Вашим задачами. Пришлось задействовать Астериск. Первоначально был Алмаз и всего три задачи, которые протон+войп шлюз+GSM шлюзы не осилили до конца:
1. Одних абонентов автоматически рулить на дешевых войп операторов. При этом то один то другой оператор иногда отказывали в сервисе, да интернет отваливался частенько. Для этого система должна следить за доступностью сервисов, и если что - перенаправлять звонок то на одного оператора, то на другого, то на традиционного МТТ.
2. Других абонентов надо было автоматически рулить через пул (донабор) другого оператора. Астериск "узнавал этих абонентов в толпе", набирал городской номер пула, набирал в пул DTMFом номер назначения, и соединял.
3. Еще было десятка четыре корпоративных сотовых плюс 164 направления сотовых номеров региона, звонки на которые выгодно было пропускать через GSM шлюзы.
я вверху писал о недостатках децентрализации управления вызовами. Идея то как раз состояла в том чтобы не делать различий между абонентами а обслуживать всех одинаково, повышая по сути мобильность и универсальность выданых абоненту номеров.
Идеи надо бы закладывать в ТЗ на телефонизацию.

Лет пять назад задавался аналогичными Вашим задачами. Пришлось задействовать Астериск. Первоначально был Алмаз и всего три задачи, которые протон+войп шлюз+GSM шлюзы не осилили до конца:
1. Одних абонентов автоматически рулить на дешевых войп операторов. При этом то один то другой оператор иногда отказывали в сервисе, да интернет отваливался частенько. Для этого система должна следить за доступностью сервисов, и если что - перенаправлять звонок то на одного оператора, то на другого, то на традиционного МТТ.
2. Других абонентов надо было автоматически рулить через пул (донабор) другого оператора. Астериск "узнавал этих абонентов в толпе", набирал городской номер пула, набирал в пул DTMFом номер назначения, и соединял.
3. Еще было десятка четыре корпоративных сотовых плюс 164 направления сотовых номеров региона, звонки на которые выгодно было пропускать через GSM шлюзы.

Идеи надо бы закладывать в ТЗ на телефонизацию.
т.е вы плогаете что переадресовывать с исдн на алмазе не получится ?

Можно сделать как говорил Mike_K, но это - пародия на то, что Вам нужно :)

Таблица наведения оказалась не совсем то, что нужна. Работает только для внутренних абонентов. Есть ещё пара мыслей, завтра опробую на железе.

Таблица наведения оказалась не совсем то, что нужна. Работает только для внутренних абонентов. Есть ещё пара мыслей, завтра опробую на железе.
очень обяжете.

В Протоне как раз и реализован механизм представления внешних абонентов как "своих", в частности подключенных и по PRI. Для этго в Алмазе надо создать концентратор и прописать в нем номера SIP-овских абонентов.
Подробную информацию можете получить в тех поддержке. Обращайтесь, Вам расскажут как это сделать.

Да-а, век живи, век учись - дураком помрёшь:) О концентраторе я и не подумал. Извращался совсем в другую сторону. А мысль с концентратором самая правильная - это ж Алмаз-1