Маршрутизация NET |
Здравствуйте, гость ( Вход | Регистрация )
Маршрутизация NET |
28.9.2009, 16:34
Сообщение
#1
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
Есть следующее пожелание.
Транзитные звонки приходят с оконечных станций на главную по транзитному коду. Назначение транзитных звонков - PSTN. В пгм. 324 выбирается группа линий на которую VOIBE собственно направляет набор. LCR в этом случае не работает и в случае занятости линий, проблемах на линиях и т.д. альтернативный набор возможен только на SPEED ячейку, указанную в пгм. 324. Предложение - предусмотреть в пгм. 324 возможность альтернативного выбора другой группы линий. |
|
|
28.9.2009, 17:31
Сообщение
#2
|
|
Ветеран форума Группа: Участники Сообщений: 912 Регистрация: 10.11.2006 Пользователь №: 114 |
а сделайте так чтоб альтернативные линии имели нумерацию меньше чем основные, тогда после окончания занятия их, начнут заниматся альтернативные
|
|
|
28.9.2009, 18:47
Сообщение
#3
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
а сделайте так чтоб альтернативные линии имели нумерацию меньше чем основные, тогда после окончания занятия их, начнут заниматся альтернативные Не совсем понял. Набор направляется, например, на группу линий 3. Если они все заняты, то будет выбрана группа линий 2. Т.е. это происходит автоматически? Или один и тот же код нужно прописать в таблице NET пгм.324 дважды. Первый индекс на группу 3, а второй на группу 2? |
|
|
28.9.2009, 23:21
Сообщение
#4
|
|
Ветеран форума Группа: Участники Сообщений: 912 Регистрация: 10.11.2006 Пользователь №: 114 |
объедините все нужные линии в одну NEt CO Grp, в которой старшие основные линии, а млдшие резервные
|
|
|
29.9.2009, 8:58
Сообщение
#5
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
объедините все нужные линии в одну NEt CO Grp, в которой старшие основные линии, а млдшие резервные Правильно ли я понял... В пгм. 322 все линии (основные и резервные) объединяю в одну группу. В пгм. 141 ПК1 эта же группа разделена на две группы, из которых основная имеет больший номер, чем резервная. Но это не совсем то, о чем было пожелание. Группа не должна быть одна. Например, создается три сетевых группы линий, выход на которые происходит по трем разным транзитным кодам. Так вот при отказе в одной из групп набор должен уходить на альтернативную группу линий, а не просто перебирать их по порядку! Похожий алгоритм реализует LCR, но к сожалению здесь это не работает. К сожалению, LCR также не работает при наборе SPEED и функции DISA. ИМХО, у корейцев здесь не доработано. Обратите на это их внимание! |
|
|
29.9.2009, 9:59
Сообщение
#6
|
|
Ветеран форума Группа: Участники Сообщений: 912 Регистрация: 10.11.2006 Пользователь №: 114 |
Цитата Группа не должна быть одна. Например, создается три сетевых группы линий, выход на которые происходит по трем разным транзитным кодам. зачем?
|
|
|
29.9.2009, 10:25
Сообщение
#7
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
зачем? На СО портах находятся GSM шлюзы. На шлюзах установлены SIM карты разных операторов (Билайн, МТС и Мегафон) с тарифными планами, когда безлимитные звонки на телефоны данного оператора. Такие тарифы у нас стоят 300-400 рублей в месяц при этом шлюзы не бывают свободными. Сами понимаете выходит очень дешево. Но если два шлюза обеспечивающие, например, выход на Билайн заняты, третий набор будет отбит. Задача, чтобы третий набор был переведен на другую группу, где шлюзы обслуживают безлимитные звонки на всех операторов. Сейчас описанная схема работает через LCR для абонентов главной станции, абоненты оконечных станций при наборе сразу по транзиту попадают на шлюзы с безлимитными тарифами на всех операторов (такие тарифы в 7 раз дороже - 2200-2800 рублей в месяц). Вот такая экономика. |
|
|
29.9.2009, 11:13
Сообщение
#8
|
|
Ветеран форума Группа: Участники Сообщений: 912 Регистрация: 10.11.2006 Пользователь №: 114 |
так поставте по шлюзу на оконечную станцию
|
|
|
29.9.2009, 12:00
Сообщение
#9
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
так поставте по шлюзу на оконечную станцию Это принципиально неверный подход. Должно быть совместное использование общих ресурсов. Иначе нужно ставить не один, а три шлюза на разных операторов, а если будут несколько наборов одновременно? У нас 6 шлюзов на 120 человек. Работа связана с обзвонами. Практически хватает, но хотелось бы еще удешевить связь, если корейцы подправят софт. |
|
|
29.9.2009, 12:39
Сообщение
#10
|
|
Ветеран форума Группа: Участники Сообщений: 912 Регистрация: 10.11.2006 Пользователь №: 114 |
а какое количество абонентов на оконечках?
|
|
|
29.9.2009, 12:58
Сообщение
#11
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
а какое количество абонентов на оконечках? Две LDK-60, человек по 15 на каждой . Мне еще нравится потоковый GSM шлюз 2N. Стоит правда порядка 200000 рублей. Там набор уходит в поток, а шлюз сам разруливает на какую SIM направить набор (LCR). Аналоговые шлюзы конечно дешевле, но нужна маршрутизация на УАТС, иначе экономия не та, разве, что облучения нет от мобильного. |
|
|
29.9.2009, 14:06
Сообщение
#12
|
|
Ветеран форума Группа: Участники Сообщений: 912 Регистрация: 10.11.2006 Пользователь №: 114 |
Цитата Две LDK-60, человек по 15 на каждой . у вас "принципиально неверный подход" вам вместо LDK-60 надо было взять по 15 телефонов LIP в каждый, и всё работало бы так как вы хотите. |
|
|
29.9.2009, 14:41
Сообщение
#13
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
у вас "принципиально неверный подход" вам вместо LDK-60 надо было взять по 15 телефонов LIP в каждый, и всё работало бы так как вы хотите. Согласен. Есть рациональное зерно. Но там есть и свои СО и всякие навороты АТСные. Да и по цене это не особо дешевле. Думаю, что если сделать дополнение к софту с альтернативным выбором СО линий это будет только плюс. |
|
|
29.9.2009, 15:19
Сообщение
#14
|
|
Ветеран форума Группа: Участники Сообщений: 912 Регистрация: 10.11.2006 Пользователь №: 114 |
Свои CO подключаются в RSG, навороты одни и теже, на LIP доступен весь функционал станции. А почему это должно быть особо дешевле, вы потратили больше денег за решение которое не в полной мере вам подходит, и вините в этом станцию
|
|
|
29.9.2009, 16:41
Сообщение
#15
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
Свои CO подключаются в RSG, навороты одни и теже, на LIP доступен весь функционал станции. А почему это должно быть особо дешевле, вы потратили больше денег за решение которое не в полной мере вам подходит, и вините в этом станцию Тема постепенно переходит в дискуссию, может даже спор. Это как выбирать между LG-Nortel и Avaya. Это два решения которые имеют право на жизнь и у обоих есть преимущества и недостатки. Честно скажу, мне не нравится чисто цифровой вариант. Это же Россия. Может старомодно, но это как с китайским товаром, купил за копейки, относил и выбросил. И станцию я не виню - хорошая станция, но еще есть над чем работать. |
|
|
29.9.2009, 17:35
Сообщение
#16
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
Правильно ли я понял... В пгм. 322 все линии (основные и резервные) объединяю в одну группу. В пгм. 141 ПК1 эта же группа разделена на две группы, из которых основная имеет больший номер, чем резервная. Но это не совсем то, о чем было пожелание. Группа не должна быть одна. Например, создается три сетевых группы линий, выход на которые происходит по трем разным транзитным кодам. Так вот при отказе в одной из групп набор должен уходить на альтернативную группу линий, а не просто перебирать их по порядку! Похожий алгоритм реализует LCR, но к сожалению здесь это не работает. К сожалению, LCR также не работает при наборе SPEED и функции DISA. ИМХО, у корейцев здесь не доработано. Обратите на это их внимание! Там много чего не доработано... так, как хотелось бы. Я имею в виду все, что связано с сетевыми таблицами. Подобные запросы мы делали давным давно... Но структура совта такова, что поменять это будет весьма сложно. Корейцы отказываются влезать в такого рода переработку - можно вообще всё поломать. Корейцы в принципе и не рассчитывали на такое применение своих станций, в таких вариантах, как это пытаются реализовать (иногда успешно) у нас. Как пример, это "отсутствие дружбы" между сетевыми таблицами и LCR. Каждая функция предназначась для разных задач. Совместное использование не предусматривалось изначально... А теперь, скорее всего, уже и не имеет смысла переделывать софт - слишком трудоемко и, как я уже говорил, небезопасно... Может на следующих сериях станций можно будет пытаться добиться от них, чтобы они учли наши пожелания сразу при разработке новых станций... -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
29.9.2009, 21:07
Сообщение
#17
|
|
Ветеран форума Группа: Участники Сообщений: 912 Регистрация: 10.11.2006 Пользователь №: 114 |
А задачу можно решить посредством превращения сетевых вызовов в локальные для транзитной станции, посредством пар CO-SLT и тогда на этих вызовах заработает LCR. Так же для этого подойдут порты BRI.
|
|
|
30.9.2009, 8:31
Сообщение
#18
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
Там много чего не доработано... так, как хотелось бы. Я имею в виду все, что связано с сетевыми таблицами. Подобные запросы мы делали давным давно... Но структура совта такова, что поменять это будет весьма сложно. Корейцы отказываются влезать в такого рода переработку - можно вообще всё поломать. Корейцы в принципе и не рассчитывали на такое применение своих станций, в таких вариантах, как это пытаются реализовать (иногда успешно) у нас. Как пример, это "отсутствие дружбы" между сетевыми таблицами и LCR. Каждая функция предназначась для разных задач. Совместное использование не предусматривалось изначально... А теперь, скорее всего, уже и не имеет смысла переделывать софт - слишком трудоемко и, как я уже говорил, небезопасно... Может на следующих сериях станций можно будет пытаться добиться от них, чтобы они учли наши пожелания сразу при разработке новых станций... Жаль конечно, что такая ситуация. Но вот это пожелание сделать альтернативное назначение в пгм. 324 вполне реально. ИМХО LCR в этом случае никак не затрагивается. |
|
|
30.9.2009, 8:34
Сообщение
#19
|
|
Ветеран форума Группа: Участники Сообщений: 823 Регистрация: 12.1.2009 Из: Рязань Пользователь №: 12799 |
А задачу можно решить посредством превращения сетевых вызовов в локальные для транзитной станции, посредством пар CO-SLT и тогда на этих вызовах заработает LCR. Так же для этого подойдут порты BRI. Это интересно. Свободные порты СО на станциях есть. Соединение между станциями через VPN. Как это сделать? |
|
|
30.9.2009, 10:33
Сообщение
#20
|
|
Ветеран форума Группа: Участники Сообщений: 912 Регистрация: 10.11.2006 Пользователь №: 114 |
соедините CO с SLT
|
|
|
Текстовая версия | Сейчас: 31.10.2024, 4:21 |