Маршрутизация NET Опции

[Astra]

Есть следующее пожелание.
Транзитные звонки приходят с оконечных станций на главную по транзитному коду. Назначение транзитных звонков - PSTN. В пгм. 324 выбирается группа линий на которую VOIBE собственно направляет набор. LCR в этом случае не работает и в случае занятости линий, проблемах на линиях и т.д. альтернативный набор возможен только на SPEED ячейку, указанную в пгм. 324.
Предложение - предусмотреть в пгм. 324 возможность альтернативного выбора другой группы линий.

[All is not what ...]

а сделайте так чтоб альтернативные линии имели нумерацию меньше чем основные, тогда после окончания занятия их, начнут заниматся альтернативные

[Astra]

а сделайте так чтоб альтернативные линии имели нумерацию меньше чем основные, тогда после окончания занятия их, начнут заниматся альтернативные

Не совсем понял. Набор направляется, например, на группу линий 3. Если они все заняты, то будет выбрана группа линий 2. Т.е. это происходит автоматически?
Или один и тот же код нужно прописать в таблице NET пгм.324 дважды. Первый индекс на группу 3, а второй на группу 2?

[All is not what ...]

объедините все нужные линии в одну NEt CO Grp, в которой старшие основные линии, а млдшие резервные

[Astra]

объедините все нужные линии в одну NEt CO Grp, в которой старшие основные линии, а млдшие резервные

Правильно ли я понял... В пгм. 322 все линии (основные и резервные) объединяю в одну группу. В пгм. 141 ПК1 эта же группа разделена на две группы, из которых основная имеет больший номер, чем резервная.
Но это не совсем то, о чем было пожелание. Группа не должна быть одна. Например, создается три сетевых группы линий, выход на которые происходит по трем разным транзитным кодам. Так вот при отказе в одной из групп набор должен уходить на альтернативную группу линий, а не просто перебирать их по порядку! Похожий алгоритм реализует LCR, но к сожалению здесь это не работает.
К сожалению, LCR также не работает при наборе SPEED и функции DISA. ИМХО, у корейцев здесь не доработано. Обратите на это их внимание!

[All is not what ...]

Группа не должна быть одна. Например, создается три сетевых группы линий, выход на которые происходит по трем разным транзитным кодам.

зачем?

[Astra]

зачем?

На СО портах находятся GSM шлюзы. На шлюзах установлены SIM карты разных операторов (Билайн, МТС и Мегафон) с тарифными планами, когда безлимитные звонки на телефоны данного оператора. Такие тарифы у нас стоят 300-400 рублей в месяц при этом шлюзы не бывают свободными. Сами понимаете выходит очень дешево. Но если два шлюза обеспечивающие, например, выход на Билайн заняты, третий набор будет отбит.
Задача, чтобы третий набор был переведен на другую группу, где шлюзы обслуживают безлимитные звонки на всех операторов.
Сейчас описанная схема работает через LCR для абонентов главной станции, абоненты оконечных станций при наборе сразу по транзиту попадают на шлюзы с безлимитными тарифами на всех операторов (такие тарифы в 7 раз дороже - 2200-2800 рублей в месяц). Вот такая экономика.

[All is not what ...]

так поставте по шлюзу на оконечную станцию

[Astra]

так поставте по шлюзу на оконечную станцию

Это принципиально неверный подход. Должно быть совместное использование общих ресурсов. Иначе нужно ставить не один, а три шлюза на разных операторов, а если будут несколько наборов одновременно? У нас 6 шлюзов на 120 человек. Работа связана с обзвонами. Практически хватает, но хотелось бы еще удешевить связь, если корейцы подправят софт.

[All is not what ...]

а какое количество абонентов на оконечках?

[Astra]

а какое количество абонентов на оконечках?

Две LDK-60, человек по 15 на каждой . Мне еще нравится потоковый GSM шлюз 2N. Стоит правда порядка 200000 рублей. Там набор уходит в поток, а шлюз сам разруливает на какую SIM направить набор (LCR). Аналоговые шлюзы конечно дешевле, но нужна маршрутизация на УАТС, иначе экономия не та, разве, что облучения нет от мобильного.

[All is not what ...]

Две LDK-60, человек по 15 на каждой .

у вас "принципиально неверный подход" вам вместо LDK-60 надо было взять по 15 телефонов LIP в каждый, и всё работало бы так как вы хотите.

[Astra]

у вас "принципиально неверный подход" вам вместо LDK-60 надо было взять по 15 телефонов LIP в каждый, и всё работало бы так как вы хотите.

Согласен. Есть рациональное зерно. Но там есть и свои СО и всякие навороты АТСные. Да и по цене это не особо дешевле. Думаю, что если сделать дополнение к софту с альтернативным выбором СО линий это будет только плюс.

[All is not what ...]

Свои CO подключаются в RSG, навороты одни и теже, на LIP доступен весь функционал станции. А почему это должно быть особо дешевле, вы потратили больше денег за решение которое не в полной мере вам подходит, и вините в этом станцию

[Astra]

Свои CO подключаются в RSG, навороты одни и теже, на LIP доступен весь функционал станции. А почему это должно быть особо дешевле, вы потратили больше денег за решение которое не в полной мере вам подходит, и вините в этом станцию

Тема постепенно переходит в дискуссию, может даже спор. Это как выбирать между LG-Nortel и Avaya. Это два решения которые имеют право на жизнь и у обоих есть преимущества и недостатки. Честно скажу, мне не нравится чисто цифровой вариант. Это же Россия. Может старомодно, но это как с китайским товаром, купил за копейки, относил и выбросил. И станцию я не виню - хорошая станция, но еще есть над чем работать.

[harris]

Правильно ли я понял... В пгм. 322 все линии (основные и резервные) объединяю в одну группу. В пгм. 141 ПК1 эта же группа разделена на две группы, из которых основная имеет больший номер, чем резервная.
Но это не совсем то, о чем было пожелание. Группа не должна быть одна. Например, создается три сетевых группы линий, выход на которые происходит по трем разным транзитным кодам. Так вот при отказе в одной из групп набор должен уходить на альтернативную группу линий, а не просто перебирать их по порядку! Похожий алгоритм реализует LCR, но к сожалению здесь это не работает.
К сожалению, LCR также не работает при наборе SPEED и функции DISA. ИМХО, у корейцев здесь не доработано. Обратите на это их внимание!

Там много чего не доработано... так, как хотелось бы. Я имею в виду все, что связано с сетевыми таблицами.
Подобные запросы мы делали давным давно... Но структура совта такова, что поменять это будет весьма сложно. Корейцы отказываются влезать в такого рода переработку - можно вообще всё поломать.
Корейцы в принципе и не рассчитывали на такое применение своих станций, в таких вариантах, как это пытаются реализовать (иногда успешно) у нас.
Как пример, это "отсутствие дружбы" между сетевыми таблицами и LCR. Каждая функция предназначась для разных задач. Совместное использование не предусматривалось изначально... А теперь, скорее всего, уже и не имеет смысла переделывать софт - слишком трудоемко и, как я уже говорил, небезопасно...
Может на следующих сериях станций можно будет пытаться добиться от них, чтобы они учли наши пожелания сразу при разработке новых станций...

[All is not what ...]

А задачу можно решить посредством превращения сетевых вызовов в локальные для транзитной станции, посредством пар CO-SLT и тогда на этих вызовах заработает LCR. Так же для этого подойдут порты BRI.

[Astra]

Там много чего не доработано... так, как хотелось бы. Я имею в виду все, что связано с сетевыми таблицами.
Подобные запросы мы делали давным давно... Но структура совта такова, что поменять это будет весьма сложно. Корейцы отказываются влезать в такого рода переработку - можно вообще всё поломать.
Корейцы в принципе и не рассчитывали на такое применение своих станций, в таких вариантах, как это пытаются реализовать (иногда успешно) у нас.
Как пример, это "отсутствие дружбы" между сетевыми таблицами и LCR. Каждая функция предназначась для разных задач. Совместное использование не предусматривалось изначально... А теперь, скорее всего, уже и не имеет смысла переделывать софт - слишком трудоемко и, как я уже говорил, небезопасно...
Может на следующих сериях станций можно будет пытаться добиться от них, чтобы они учли наши пожелания сразу при разработке новых станций...

Жаль конечно, что такая ситуация. Но вот это пожелание сделать альтернативное назначение в пгм. 324 вполне реально. ИМХО LCR в этом случае никак не затрагивается.

[Astra]

А задачу можно решить посредством превращения сетевых вызовов в локальные для транзитной станции, посредством пар CO-SLT и тогда на этих вызовах заработает LCR. Так же для этого подойдут порты BRI.

Это интересно. Свободные порты СО на станциях есть. Соединение между станциями через VPN. Как это сделать?

[All is not what ...]

соедините CO с SLT