Версия для печати темы

Автор: Astra 28.9.2009, 16:34

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

Автор: All is not what it seems 28.9.2009, 17:31

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

Автор: Astra 28.9.2009, 18:47

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

Автор: All is not what it seems 28.9.2009, 23:21

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

Автор: Astra 29.9.2009, 8:58

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

Автор: All is not what it seems 29.9.2009, 9:59

зачем?

Автор: Astra 29.9.2009, 10:25

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

Автор: All is not what it seems 29.9.2009, 11:13

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

Автор: Astra 29.9.2009, 12:00

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

Автор: All is not what it seems 29.9.2009, 12:39

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

Автор: Astra 29.9.2009, 12:58

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

Автор: All is not what it seems 29.9.2009, 14:06

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

Автор: Astra 29.9.2009, 14:41

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

Автор: All is not what it seems 29.9.2009, 15:19

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

Автор: Astra 29.9.2009, 16:41

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

Автор: harris 29.9.2009, 17:35

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

Автор: All is not what it seems 29.9.2009, 21:07

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

Автор: Astra 30.9.2009, 8:31

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

Автор: Astra 30.9.2009, 8:34

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

Автор: All is not what it seems 30.9.2009, 10:33

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

Автор: Astra 30.9.2009, 11:24

??? Все не так, как кажется.

Автор: All is not what it seems 30.9.2009, 11:34

смотря что вам кажется
я так и не понял что вы не можете понять

Автор: Astra 30.9.2009, 12:10

Как в этой схеме задействованы SLT. Набор чтобы включился LCR транзитной станции должен исходить от SLT транзитной станции. Не могу понять, как с оконечной станции набор пройдет по типу DISA.

Автор: All is not what it seems 30.9.2009, 13:00

с оконечной станции звонок должен выйти через CO, которая подключена к SLT той же станции, при этом звонок из транзитного становится оригенируемым локально и для него начинает работать LCR

Автор: Astra 30.9.2009, 13:21

Спасибо! Понял.

Автор: gmax77 6.5.2015, 0:58

будьте, добры для тупых... и помедленнее, пожалуйста, я записываю.
подразумевается физическое соединение медью пары CO-SLT или можно направить транзитный звонок в сети АТС с оконечной СО на транзитную SLT с донабором номера? или я вообще не попал в тему? :-)