Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Ipecs MG300 и E1
АРТКОМ Форум > Форумы для специалистов > Техническая поддержка iPECS-MG & iPECS-eMG800
V.psh
Добрый вечер!
Комрады, помогайте!
Есть MG300, поток поднял, входящие разрулил, но как сделать так что бы например с номера 100 выход на СО шел с определенного номера и только с него?
Как передать АОН провайдеру?
Спасибо!
AXEL
Атрибуты абонентов.
CLI.
ЛыЖник
Цитата(V.psh @ 9.9.2015, 18:21) *
Добрый вечер!
Комрады, помогайте!
Есть MG300, поток поднял, входящие разрулил, но как сделать так что бы например с номера 100 выход на СО шел с определенного номера и только с него?
Как передать АОН провайдеру?
Спасибо!

При работе с потоком предоставляются каналы в потоке, а не определенный номер. Исходящий номер присваивается в атрибутах абонентов. Т.е. для абонента можно назначить один входящий номер, а для исходящего назначить другой. Причем этот номер должен быть из диапазона номеров, которые выделили для работы в потоке. Иначе, ГАТС может не выпустить ваши звонки с чужими номерами или без номера.
V.psh
Спасибо, разобрался. Правда похоже провайдер заменяет исходящий номер, т.к в программе присвоен один номер абоненту, а определяется другой номер.
ЛыЖник
Цитата(V.psh @ 10.9.2015, 8:30) *
Спасибо, разобрался. Правда похоже провайдер заменяет исходящий номер, т.к в программе присвоен один номер абоненту, а определяется другой номер.

Вполне возможно. Они вам для исходящих ставят один пилотный номер. Во избежании umnik2.gif У меня на потоке 300 городских номеров, и каждому номеру на УПАТС нужно присваивать исходящий. Иначе ГАТС звонки с чужими номерами не выпускает. wizard.gif
V.psh
Еще вопросик такой, как сделать так когда 1 абонент занял определенный номер 2 абонент не мог выйти по этому номеру в город и получил отбой?
AXEL
Цитата(V.psh @ 11.9.2015, 12:20) *
Еще вопросик такой, как сделать так когда 1 абонент занял определенный номер 2 абонент не мог выйти по этому номеру в город и получил отбой?

Ага, а потом абоненты скажут, что ваша станция не работает smile.gif
V.psh
Цитата(AXEL @ 12.9.2015, 12:21) *
Ага, а потом абоненты скажут, что ваша станция не работает smile.gif

Так просит сделать заказчик
harris
Цитата(V.psh @ 13.9.2015, 8:42) *
Так просит сделать заказчик

Тогда нужно каждому каналу потока приписать свой номер АОНа (CLI) как на вашей станции, так на и стороне провайдера.
Обычно так не делают, т.к. ИМХО это чушь.
Зачем это нужно заказчику?? Чего именно он хочется добиться?? Может, он просто чего-то не понимает ??
Нужно объяснить заказчику, как работает поток ISDN, и в чем отличия от аналоговых СЛ.
V.psh
Цитата(harris @ 13.9.2015, 9:56) *
Тогда нужно каждому каналу потока приписать свой номер АОНа (CLI) как на вашей станции, так на и стороне провайдера.
Обычно так не делают, т.к. ИМХО это чушь.
Зачем это нужно заказчику?? Чего именно он хочется добиться?? Может, он просто чего-то не понимает ??
Нужно объяснить заказчику, как работает поток ISDN, и в чем отличия от аналоговых СЛ.

Да, этот человек не понимает как работает поток, объяснять ему я запарился уже, не подскажешь в какой pgm это делать?
ЛыЖник
Цитата(V.psh @ 14.9.2015, 7:56) *
Да, этот человек не понимает как работает поток, объяснять ему я запарился уже, не подскажешь в какой pgm это делать?

Никак не сделать. В потоке предоставляется только канал передачи информации по которому выходит абонент со СВОИМ исходящим номером прописанным в ЕГО атрибутах. И в потоке исходящие и входящие номера независимы друг от друга. Можно организовывать с одним входящим номером многоканальный телефон. Внутренние абоненты, принимающие эти звонки, например 6 абонентов, могут иметь одинаковый исходящий номер. А можно, кроме группового номера, присвоить каждому абоненту свой входящий городской номер и, соответственно, свой исходящий номер. Т.е. возможностей очень много. Но, в силу привычки, люди считают, что " у меня прямой номер", "каждому нужен свой городской. А то как же мы будем звонить, один разговаривает, а второй может звонить?" и пр.
mirage
Цитата(harris @ 13.9.2015, 9:56) *
Тогда нужно каждому каналу потока приписать свой номер АОНа (CLI) как на вашей станции, так на и стороне провайдера.
Обычно так не делают, т.к. ИМХО это чушь.
Зачем это нужно заказчику?? Чего именно он хочется добиться?? Может, он просто чего-то не понимает ??
Нужно объяснить заказчику, как работает поток ISDN, и в чем отличия от аналоговых СЛ.

Я не программист АТС, я сисадмин. Ставят нам сейчас станцию IPECS-MG 300, два потока Е1 в них 46 номеров, внутренних 144. Нам тоже надо ограничить количество соединений с городом по группам. Например есть группа *620 в которую входят станции с 123 по 132 (10 шт.). Городской номер +7 (495) 3ХХХХХХ (вместо Х реальные цифры) на вход конвертируется в *620. Входящие звонки на этот номер уходят на группу станций 123-132, свободные из них начинают звонить пока не снимут трубку. Все как нам и надо. Но нам нужно ограничить количество одновременных входящих вызовов на эту группу до 3-х. И количество одновременных исходящих соединений этой группы с городом тоже до 3-х. Тоесть из 10 станций группы одновременно могут занять только 6 тайм/слотов потока Е1, 3 на вход и 3 на выход. Программисты которые запускают АТС мне объясняют, что поток Е1 работает не так, как я думаю и этого не сделать. Я знаю как работает поток Е1 в режиме DID и пытаюсь им объяснить что мы не хотим менять принципы работы потока. Мы хотим что-бы станция вела себя так как нужно нам. В качестве примера привожу следующий алгоритм работы (который реализован):
В потоке есть номер +7 (495) 3ХХХХХ12 который на вход конвертируется в 110 (очередь в ноль) и если станция 110 занята, то звонящий на этот номер абонент слышит сигнал "занято". То есть наша АТС может дать потоку Е1 отбой если условия занятости внутреннего номера куда должен придти вызов соблюдены.
Так почему АТС не может также дать потоку отбой если на отвечающую группу внутренних номеров, куда должен придти вызов уже есть определенное количество входящих городских вызовов??? Информация об этом у станции имеется. И для реализации данного функционала пофиг, как приходят внешние вызовы (по аналогу, потоку или IP).
Так же и на выход на город. Ставим на группу, где нибудь, ограничение на какое-то количество одновременных исходящих на город вызовов и если из группы кто-то пытается выйти на город, а станция видит что из этой группы уже есть максимальное количество исходящих городских вызовов то абонет получает отбой.
Неужеле на такой современной станции нельзя реализовать такой простой алгоритм?
ЛыЖник
Цитата(mirage @ 18.9.2015, 8:54) *
Я не программист АТС, я сисадмин. Ставят нам сейчас станцию IPECS-MG 300, два потока Е1 в них 46 номеров, внутренних 144. Нам тоже надо ограничить количество соединений с городом по группам. Например есть группа *620 в которую входят станции с 123 по 132 (10 шт.). Городской номер +7 (495) 3ХХХХХХ (вместо Х реальные цифры) на вход конвертируется в *620. Входящие звонки на этот номер уходят на группу станций 123-132, свободные из них начинают звонить пока не снимут трубку. Все как нам и надо. Но нам нужно ограничить количество одновременных входящих вызовов на эту группу до 3-х. И количество одновременных исходящих соединений этой группы с городом тоже до 3-х. Тоесть из 10 станций группы одновременно могут занять только 6 тайм/слотов потока Е1, 3 на вход и 3 на выход. Программисты которые запускают АТС мне объясняют, что поток Е1 работает не так, как я думаю и этого не сделать. Я знаю как работает поток Е1 в режиме DID и пытаюсь им объяснить что мы не хотим менять принципы работы потока. Мы хотим что-бы станция вела себя так как нужно нам. В качестве примера привожу следующий алгоритм работы (который реализован):
В потоке есть номер +7 (495) 3ХХХХХ12 который на вход конвертируется в 110 (очередь в ноль) и если станция 110 занята, то звонящий на этот номер абонент слышит сигнал "занято". То есть наша АТС может дать потоку Е1 отбой если условия занятости внутреннего номера куда должен придти вызов соблюдены.
Так почему АТС не может также дать потоку отбой если на отвечающую группу внутренних номеров, куда должен придти вызов уже есть определенное количество входящих городских вызовов??? Информация об этом у станции имеется. И для реализации данного функционала пофиг, как приходят внешние вызовы (по аналогу, потоку или IP).
Так же и на выход на город. Ставим на группу, где нибудь, ограничение на какое-то количество одновременных исходящих на город вызовов и если из группы кто-то пытается выйти на город, а станция видит что из этой группы уже есть максимальное количество исходящих городских вызовов то абонет получает отбой.
Неужеле на такой современной станции нельзя реализовать такой простой алгоритм?

В АТС, кроме работы с абонентским номером, используются HUNT-группа. Вот работа внутренних абонентов в группе может несколько отличаться от работы отдельного абонента. В группе из трех абонентов можно указать количество входящих звонков.
А вот исходящие звонки идеализируются по другому. Как правило, канал передачи информации предоставляется каждому внутреннему абоненту при наборе 9 (ну, может за исключением ограничения по COS) не зависимо от организации входящих звонков. Можно линии СО в потоке порезать на группы для исходящих звонков и в прг.117 дать доступ абонентам к соответствующим группам. НО, входящие звонки от ГАТС будут направляться в УПАТС по ЛЮБОЙ линии СО потока. Иначе, надо и в ГАТС поток пилить на транки, что, согласитесь, никто делать не будет. Мне всё-же непонятно, зачем вам нужно ограничение по исходящим звонкам. Вы скатываетесь к использованию аналоговых линий. В одной группе народ не может звонить потому, что линии СО заняты, и в то же время в соседней группе линии СО будут простаивать. Вы нерационально будете использовать трафик связи. Выше дело. Кто-то использует комп для написания докторской, а кто-то для раскладывания пасьянса.
Dron
Цитата(mirage @ 18.9.2015, 8:54) *
Так почему АТС не может также дать потоку отбой если на отвечающую группу внутренних номеров, куда должен придти вызов уже есть определенное количество входящих городских вызовов???

Max Queue Count в атрибутах группы.

Цитата(mirage @ 18.9.2015, 8:54) *
Ставим на группу, где нибудь, ограничение на какое-то количество одновременных исходящих на город вызовов и если из группы кто-то пытается выйти на город, а станция видит что из этой группы уже есть максимальное количество исходящих городских вызовов то абонет получает отбой.
Неужеле на такой современной станции нельзя реализовать такой простой алгоритм?

Понимаете ли, исходящая связь настраивается для абонентов, а не для групп. А эти вот группы(о которых вы пишите)..они для входящей.
В общем то, вам уже написали, что надо разбивать линии потока на CO Group и давать доступ абонентам к нужным группам.
Но, для потока - это бред! Зачем вам поток то тогда, дешевле, по-моему, иметь аналоговые внешние линии.
mirage
Цитата(Dron @ 18.9.2015, 9:50) *
Max Queue Count в атрибутах группы.

Это ограничивает очередь а не количество одновременных соединений. Тоесть естли на граппу из 10 станций поставить этот параметр в 3, то при 14 входящих соединений на номер группы 10 пройдут на аппараты 3 встанут в очередь а 1 получит отбой. А нам нужно чтоб 3 прошло на аппараты а остальные получили отбой.
harris
Цитата(mirage @ 18.9.2015, 8:54) *
Я не программист АТС, я сисадмин. Ставят нам сейчас станцию IPECS-MG 300, два потока Е1 в них 46 номеров, внутренних 144. Нам тоже надо ограничить количество соединений с городом по группам. Например есть группа *620 в которую входят станции с 123 по 132 (10 шт.). Городской номер +7 (495) 3ХХХХХХ (вместо Х реальные цифры) на вход конвертируется в *620. Входящие звонки на этот номер уходят на группу станций 123-132, свободные из них начинают звонить пока не снимут трубку. Все как нам и надо. Но нам нужно ограничить количество одновременных входящих вызовов на эту группу до 3-х. И количество одновременных исходящих соединений этой группы с городом тоже до 3-х. Тоесть из 10 станций группы одновременно могут занять только 6 тайм/слотов потока Е1, 3 на вход и 3 на выход. Программисты которые запускают АТС мне объясняют, что поток Е1 работает не так, как я думаю и этого не сделать. Я знаю как работает поток Е1 в режиме DID и пытаюсь им объяснить что мы не хотим менять принципы работы потока. Мы хотим что-бы станция вела себя так как нужно нам. В качестве примера привожу следующий алгоритм работы (который реализован):
В потоке есть номер +7 (495) 3ХХХХХ12 который на вход конвертируется в 110 (очередь в ноль) и если станция 110 занята, то звонящий на этот номер абонент слышит сигнал "занято". То есть наша АТС может дать потоку Е1 отбой если условия занятости внутреннего номера куда должен придти вызов соблюдены.
Так почему АТС не может также дать потоку отбой если на отвечающую группу внутренних номеров, куда должен придти вызов уже есть определенное количество входящих городских вызовов??? Информация об этом у станции имеется. И для реализации данного функционала пофиг, как приходят внешние вызовы (по аналогу, потоку или IP).
Так же и на выход на город. Ставим на группу, где нибудь, ограничение на какое-то количество одновременных исходящих на город вызовов и если из группы кто-то пытается выйти на город, а станция видит что из этой группы уже есть максимальное количество исходящих городских вызовов то абонет получает отбой.
Неужеле на такой современной станции нельзя реализовать такой простой алгоритм?

Входящие и исходящие вызовы - разные вещи. Ограничить кол-во входящих вызовов, направленных в группу абонентов (Hunt), можно используя опцию Max Queue в атрибутах Hunt-группы, как уже выше написал уваж. Dron.
Причем ограничивается не кол-во входящих вызовов в принципе, а кол-во вызовов в очереди в группе!!
Но ограничить кол-во исходящих вызовов с одним и тем же номером CLI (АОН), а насколько было понятно из исходного вопроса в этой ветке, требовалось именно это - так это уже совсем другая история, которая решается привязкой номера к каналу.
Как я уже писал выше, чтобы решить вашу задачу в полном объеме, нужно привязывать номера к каналам потока на обоих сторонах линии Е1. А это, Имхо, глупо. Какой в этом смысл??? Чего боитесь, что не хватит каналов, если одна группа абонентов займет больше каналов, чем вы им хотите предписать??
mirage
Цитата(ЛыЖник @ 18.9.2015, 9:35) *
В АТС, кроме работы с абонентским номером, используются HUNT-группа. Вот работа внутренних абонентов в группе может несколько отличаться от работы отдельного абонента. В группе из трех абонентов можно указать количество входящих звонков.
А вот исходящие звонки идеализируются по другому. Как правило, канал передачи информации предоставляется каждому внутреннему абоненту при наборе 9 (ну, может за исключением ограничения по COS) не зависимо от организации входящих звонков. Можно линии СО в потоке порезать на группы для исходящих звонков и в прг.117 дать доступ абонентам к соответствующим группам. НО, входящие звонки от ГАТС будут направляться в УПАТС по ЛЮБОЙ линии СО потока. Иначе, надо и в ГАТС поток пилить на транки, что, согласитесь, никто делать не будет. Мне всё-же непонятно, зачем вам нужно ограничение по исходящим звонкам. Вы скатываетесь к использованию аналоговых линий. В одной группе народ не может звонить потому, что линии СО заняты, и в то же время в соседней группе линии СО будут простаивать. Вы нерационально будете использовать трафик связи. Выше дело. Кто-то использует комп для написания докторской, а кто-то для раскладывания пасьянса.

Поток резать не вариант ... Мы не скатываемся к использованию аналоговых линий, просто хочется иметь возможность гибко управлять имеющимися ресурсами. Вот например для чего нам нужно ограничить количество исходящих на группу. Раньше у нас (Завод) стояла АТС от провайдера связи (мы не имели доступа к программированию) и было выделено 104 внутренних номера (46 с выходом на город, с четкоей привязкой "номер внутр."-"номер городской"-1СО) и 58 без выхода в город. Сейчас мы купили станцию IPECS-MG300 и взяли два потока Е1 (46 номеров-60тс) от другого провайдера. Провайдер дает безлимит на город и область. Руководство хочет дать возможность звонить по этому направлению тем абонентам которые раньше выхода в город не имели, но не в ущерб работе тех абонентов которым связь нужна для работы. Да и в отделах которые работают в основном на телефонах раньше было так: на отдел давали 2-3 городских номера(линии) и ставили паралельные аппараты. Сейчас есть возможность паралельные убрать, но нужно ограничить занимаемые внешние ресурсы. Если по статистике за месяц-два мы увидим простой линий может что и изменим, но на стартовом этапе нам надо обезопасить себя и не допустить ситуации, что два отдела забили все слоты и в другие отделы не могут прозвониться. Не имея доступа к статистике занятия линий в предыдущие переоды делать прогнозы не получится. Со слов самих сотрудников у них постоянная очередь на позвонить в город (достоверность под вопросом, но начальникам отделов были поставлены отдельные внутренние телефоны (без выхода в город) запитаных от старой маленькой АТС Сименс, для прямой связи руководителей с ними по причине невозможности дозвониться до них по основной внутренней связи).
Про HUNT-группы и ограничения которое там можно выставить можно поподробнее... А то в доке что-то не могу найти установку ограничения на кол-во входящих соединений на группу...
mirage
Цитата(harris @ 18.9.2015, 10:10) *
Входящие и исходящие вызовы - разные вещи. Ограничить кол-во входящих вызовов, направленных в группу абонентов (Hunt), можно используя опцию Max Queue в атрибутах Hunt-группы, как уже выше написал уваж. Dron.
Причем ограничивается не кол-во входящих вызовов в принципе, а кол-во вызовов в очереди в группе!!
Но ограничить кол-во исходящих вызовов с одним и тем же номером CLI (АОН), а насколько было понятно из исходного вопроса в этой ветке, требовалось именно это - так это уже совсем другая история, которая решается привязкой номера к каналу.
Как я уже писал выше, чтобы решить вашу задачу в полном объеме, нужно привязывать номера к каналам потока на обоих сторонах линии Е1. А это, Имхо, глупо. Какой в этом смысл??? Чего боитесь, что не хватит каналов, если одна группа абонентов займет больше каналов, чем вы им хотите предписать??

Не количество исходящих вызовов с одним CLI, а количество исходящих вызовов из группы (CLI могут быть разными).
Мы боимся что без ограничений на группы абоненттов, каналов не хватит и отделы не смогут сбалансированно работать (по крайней мере пока мы не соберем реальную статистику использования канала). Ведь по принципу "Кто первый встал, того и тапки" ситуация, что будут заняты все каналы двумя отделами и остальные отделы не смогут получать и совершать вызовы имеет теоретическую возможность.
AXEL
Цитата(mirage @ 18.9.2015, 10:35) *
Не количество исходящих вызовов с одним CLI, а количество исходящих вызовов из группы (CLI могут быть разными).
Мы боимся что без ограничений на группы абоненттов, каналов не хватит и отделы не смогут сбалансированно работать (по крайней мере пока мы не соберем реальную статистику использования канала). Ведь по принципу "Кто первый встал, того и тапки" ситуация, что будут заняты все каналы двумя отделами и остальные отделы не смогут получать и совершать вызовы имеет теоретическую возможность.


У вас 60 транков на 144 внутренних номера, если ваша фирма работает не на постоянный обзвон клиентов, то вероятность занятия всех потоков очень мала. Я сомневаюсь, что у вас единовременное занятие будет больше 15 каналов. Просто откройте 101 программу и увидете все занятые транки.
harris
Цитата(mirage @ 18.9.2015, 10:35) *
Не количество исходящих вызовов с одним CLI, а количество исходящих вызовов из группы (CLI могут быть разными).
Мы боимся что без ограничений на группы абоненттов, каналов не хватит и отделы не смогут сбалансированно работать (по крайней мере пока мы не соберем реальную статистику использования канала). Ведь по принципу "Кто первый встал, того и тапки" ситуация, что будут заняты все каналы двумя отделами и остальные отделы не смогут получать и совершать вызовы имеет теоретическую возможность.

На практике, поток в 30 каналов обеспечивает нормальную связь для 200 абонентов. У вас 2 потока, т.е. 60 каналов, и абонентов всего 144.
Врядли все сотрудники завода работают постоянно только с телефоном, занимаясь обзвоном клиентов, чтобы одновременно загрузить 2 потока. Имхо, ваши опасения напрасны.
mirage
Цитата(AXEL @ 18.9.2015, 10:48) *
У вас 60 транков на 144 внутренних номера, если ваша фирма работает не на постоянный обзвон клиентов, то вероятность занятия всех потоков очень мала. Я сомневаюсь, что у вас единовременное занятие будет больше 15 каналов. Просто откройте 101 программу и увидете все занятые транки.

Пока проверить реалную загрузку не выйдет (станция еще не подключена, переход на новую станцию запланирован на 1 ноября).
ЛыЖник
Цитата(mirage @ 18.9.2015, 11:04) *
Пока проверить реалную загрузку не выйдет (станция еще не подключена, переход на новую станцию запланирован на 1 ноября).

У меня в АТС при 400 внутренних абонентах из 60 каналов в двух потоках занималось в лучшем случае каналов 20. Загрузку каналов проверял WinTariff. Там можно смотреть статистику. Опыт работы показал, что использование 2-х потоков это перебор. От второго потока отказались. Теперь у нас 300 городских номеров на одном потоке. Среднее время разговоров до 5-ти минут. При ваших несчастных 144 абонентах два потока это даже выше крыши... victory.gif
mirage
Цитата(harris @ 18.9.2015, 10:56) *
На практике, поток в 30 каналов обеспечивает нормальную связь для 200 абонентов. У вас 2 потока, т.е. 60 каналов, и абонентов всего 144.
Врядли все сотрудники завода работают постоянно только с телефоном, занимаясь обзвоном клиентов, чтобы одновременно загрузить 2 потока. Имхо, ваши опасения напрасны.

Вот практике мне и не хватает ... Точнее практической статистики... У нас на заводе есть отделы снабжения, логистики, реализации и т.д. манагеры которых (по словам рукуводителей отделов) выстраиваются в очередь позвонить (при распределении 2-3 линии на 8-15 человек). И у нас не 144 абонента, а 144 порта внутренних (купить больше портов пока бюджет не позволил) и придется часть портов паралелить по сотрудникам (процентов 20-30).
Спасибо за оптимистическую статистику про 30тс на 200аб. Может и правда я зря паникую, но все равно странно что современные АТС не могут того, что доисторический Панас 1232(сдвоенный) с потоком на входе, легко делал (там где я работал лет семь назад).
mirage
Цитата(ЛыЖник @ 18.9.2015, 11:14) *
У меня в АТС при 400 внутренних абонентах из 60 каналов в двух потоках занималось в лучшем случае каналов 20. Загрузку каналов проверял WinTariff. Там можно смотреть статистику. Опыт работы показал, что использование 2-х потоков это перебор. От второго потока отказались. Теперь у нас 300 городских номеров на одном потоке. Среднее время разговоров до 5-ти минут. При ваших несчастных 144 абонентах два потока это даже выше крыши... victory.gif

У меня есть статистика за прошлые переоды (сметрел за 10 мес), но не по городским звонкам а только по тем что тарифицируются поминутно (МГ, МН, и сотовая). Вот судя по ним среднее время разговора наших абонентов 20-25 минут sad.gif
ЛыЖник
Цитата(mirage @ 18.9.2015, 11:19) *
У меня есть статистика за прошлые переоды (сметрел за 10 мес), но не по городским звонкам а только по тем что тарифицируются поминутно (МГ, МН, и сотовая). Вот судя по ним среднее время разговора наших абонентов 20-25 минут sad.gif

Тогда ищете в гугле "Расчет нагрузки на линии СО" или расчет линий СО по Эрлангу. Коли у вас есть статистика по звонкам то выносите себе моск superstition.gif и считает примерное количество линий для данной нагрузке. Вот из расчетов по этой методике и берется такая цифра как 30 каналов в потоке на 200 абонентов.
mirage
Цитата(ЛыЖник @ 18.9.2015, 11:27) *
Тогда ищете в гугле "Расчет нагрузки на линии СО" или расчет линий СО по Эрлангу. Коли у вас есть статистика по звонкам то выносите себе моск superstition.gif и считает примерное количество линий для данной нагрузке. Вот из расчетов по этой методике и берется такая цифра как 30 каналов в потоке на 200 абонентов.

Спасибо! Попробую. Но у меня есть статистика только на тарифицируемые звонки ... Статистики местных городских вызовов нет. И все равно вопрос про возможность ограничения городских вызовов на группу абонентов остается открытым. Может в следующую версию ПО корейцы добавят если их попросить?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.