Услуга "виртуальная АТС"

[Антон Никифоров]

Приветствую Вас, многоуважаемый All!

Моя задача. Есть компания, получающая у меня некоторое количество поротов. 10 АКшек и 5 IPшек. У них есть городской номер (понятное дело, его прописать надо в АОН каждого из 15 абонентов шоп в город выходили под выданным им номером).

Но вот незадачи:
1. Надо этим 15ти ограничить выход на другие локальные номера. Чтобы они через город им звонили и не имели права набрать внутренний номер другого абонента и позвонить, скажем, прямо генеральному диретороу соседней по территории конторы.
2. Внутренние номера могут и пересекаться. Т.е. в двух подобных компаниях будут встречаться внутренние номера, скажем, 100.
3. Каждая компания покупает городской номер серийный с числом одновременных разговоров - 5. Как их ограничить? Причем в одном случае, чтобы было 5 входящих и 5 исходящих (в пределе 10 соединений, но определенного типа), а в другом - 5 всего, хоть входящих, хоть исходящих.

Посоветуйте, где почитать про подобные настройки?

Прочитал на Вашем сайте, что МС240 умеет создавать виртуальные АТС. Но это все, что касалось виртуальных АТС - одна фраза.

[Алексей Сергеев]

1.Вам необходимо для каждой такой компании создать индивидуальный план нумерации, в котором будут находиться только номера этих портов и порты выхода в город. Причем, можно сделать как индивидуальные порты, так и общие. Единственно что должна явно указываться транковая группа для входящих в этот план.
Обратите внимание, что номер порта может принадлежать одному плану, а входящи набор от этого порта может пойти в другой. В Вашем случае лучше чтобы номерной план и план входящего набора совпадали (есть такой режим в конфигурации).

2.Номера в разных планах могут совпадать.

3. первый случай. два транка по 5 портов, один указывается как входящий, второй как исходящий (выход по префиксам на него)
второй случай - 10 портов в транке который используется и как входящий, и как исходящий.

[Антон Никифоров]

Приветствую Вас, Сергей!
Спасибо за ответы, буду пытатся реализовать сказанное
Хотя понял только поверхностно, нужны опыты.

[Антон Никифоров]

1.Вам необходимо для каждой такой компании создать индивидуальный план нумерации, в котором будут находиться только номера этих портов и порты выхода в город. Причем, можно сделать как индивидуальные порты, так и общие. Единственно что должна явно указываться транковая группа для входящих в этот план.
Обратите внимание, что номер порта может принадлежать одному плану, а входящи набор от этого порта может пойти в другой. В Вашем случае лучше чтобы номерной план и план входящего набора совпадали (есть такой режим в конфигурации).

Не совсем понятен термин "порт". Если речь о АК - ясно, ему указывается план нумерации явно, а если это ТМ.IP порт?
И, в случае если транковый порт принимает все возможные входящие звонки для разных компаний и разных номеров, то не проще ли принять их все в 0ой план нумерации и оттуда функцуией смена плана перенаправить в другой план?
Правда, у меня тут загвоздка, попытка добавить входящий номер 74956416413 приводит к его сокращению до 56416413, ну и соответственно происхожит с 74956410013.

2.Номера в разных планах могут совпадать.

Да, могут, но тогда не получится звонить из одного плана в другой путем добавления "смена плана нумерации" в таблицу внешних линков. Только через город, а это не всегда удобно.

3. первый случай. два транка по 5 портов, один указывается как входящий, второй как исходящий (выход по префиксам на него)
второй случай - 10 портов в транке который используется и как входящий, и как исходящий.

Вот тут совсем не понял.
Есть транковая группа, включающая в себя 1 PRI интерфейс со всеми его 30 таймслотами. Провайдер на этот транк присылает звонки, входящие на разные номера (71234567890 и 70987654321) последовательно их занимая и освобождая. Какждый из номеров привязан к своей компании и должен быть ограничен по числу одновременных соединений. Однако, выделение конкретных тайм слотов не приветствуется, поскольку в случае, если закрепить 1,2 и 3ий тайм слоты за первым номером, а 4,5 и 6 за вторым, то боле никто не сможет эти тайм слоты использовать. А задача, как раз-таки в том, чтобы максимально эффективно использовать поток к провайдеру и иметь возможность по любому тайм слоту выпустить или впустить любой номер. А уже получив соединени (или перед тем как его выпустить) проверить не превышен ли лимит соединений по конкретному номеру.

[Алексей Сергеев]

Не совсем понятен термин "порт". Если речь о АК - ясно, ему указывается план нумерации явно, а если это ТМ.IP порт?
И, в случае если транковый порт принимает все возможные входящие звонки для разных компаний и разных номеров, то не проще ли принять их все в 0ой план нумерации и оттуда функцуией смена плана перенаправить в другой план?

TM.IP в этой системе позиционируется как СЛ. Соответственно для транковой группы, в которой канал TM.IP, надо задать план входящего набора. Разделить транк от TM.IP на несколько планов действительно не получится. Вы правы, лучше сделать через 0 план с последующим переходом.

Правда, у меня тут загвоздка, попытка добавить входящий номер 74956416413 приводит к его сокращению до 56416413, ну и соответственно происхожит с 74956410013.

Внутренние ограничения на 8 знаков. Есть версия под большее количество знаков, но она в стадии разработки (проект под 10-тизначку).

Да, могут, но тогда не получится звонить из одного плана в другой путем добавления "смена плана нумерации" в таблицу внешних линков. Только через город, а это не всегда удобно.

Что-то вы через раз "через город" заворачиваете. Если АТС не сможет разрулить на внутренних абонентов номера, то и "город" не справится. Номера же будут совпадать. Я имел в виду что внутри разных планов можно звонить по одинаковым номерам не выходя из плана. Естественно как только мы покидаем план мы должны подчиняться правилам общей нумерации.

Есть транковая группа, включающая в себя 1 PRI интерфейс со всеми его 30 таймслотами. Провайдер на этот транк присылает звонки, входящие на разные номера (71234567890 и 70987654321) последовательно их занимая и освобождая. Какждый из номеров привязан к своей компании и должен быть ограничен по числу одновременных соединений. Однако, выделение конкретных тайм слотов не приветствуется, поскольку в случае, если закрепить 1,2 и 3ий тайм слоты за первым номером, а 4,5 и 6 за вторым, то боле никто не сможет эти тайм слоты использовать. А задача, как раз-таки в том, чтобы максимально эффективно использовать поток к провайдеру и иметь возможность по любому тайм слоту выпустить или впустить любой номер. А уже получив соединени (или перед тем как его выпустить) проверить не превышен ли лимит соединений по конкретному номеру.

Мой взгляд на такой конфиг:
Делаем 3 плана нумерации 0 основной, 1 для компании 1, 2 для компании 2.
- транк группу помещаем в 0 план.
- делаем префикс перехода 71234567 в план 1
- делаем префикс перехода 70987654 в план 2
- в планах делаем группы вызова (наверняка там нескольких абонентов надо вызывать)
- всем абонентам прописываем АОН: 71234567890 для плана 1 и 70987654321 для плана 2.
- если часть номеров не на портах АК, то по нужным префиксам выводим на общую группу на TM.IP (если SIP абоненты)

Ограничение на количество одновременно занятых каналов по PRI для каждого номера нет возможности сделать. Можно только ограничить общее количество используемых таймслотов на потоке.

[Антон Никифоров]

Внутренние ограничения на 8 знаков. Есть версия под большее количество знаков, но она в стадии разработки (проект под 10-тизначку).

А какие будут советы относительно "разруливания" этого ограничения? Просто из города приходят именно 11тизнак.
Отрезать префикс 7495?

TM.IP в этой системе позиционируется как СЛ

Я не для организации дискуссии на сей счет, но было бы здорово это в описании указать, а то управляется плата TM.IP как поточная (СЛку в транк группу не добавить), а обрабатывается как СЛ. Немного сей подход нарушает целостность понимания всей концепции МС240.
Если бы TM.IP позволяла разбивать себя на кусочки, причем было бы совсем здорово - создание 802.1q VLAN и привязки к нему определенного числа "слотов" TM.IP - вот это была бы круть. (Кстати, добавить административный VLAN было бы здорово в любом случае).

Что-то вы через раз "через город" заворачиваете. Если АТС не сможет разрулить на внутренних абонентов номера, то и "город" не справится. Номера же будут совпадать.

Может я неправильно выразил мысль. Если внутренние номера совпадают, то можено отправить в город с уже городским АОНом и оттуда вернется звонок в соседнюю виртуальную АТС.

Мой взгляд на такой конфиг:
Делаем 3 плана нумерации 0 основной, 1 для компании 1, 2 для компании 2.
- транк группу помещаем в 0 план.
- делаем префикс перехода 71234567 в план 1
- делаем префикс перехода 70987654 в план 2
- в планах делаем группы вызова (наверняка там нескольких абонентов надо вызывать)
- всем абонентам прописываем АОН: 71234567890 для плана 1 и 70987654321 для плана 2.
- если часть номеров не на портах АК, то по нужным префиксам выводим на общую группу на TM.IP (если SIP абоненты)

Да, я именно так все и настроил. Спасибо большое за подсказку.

Ограничение на количество одновременно занятых каналов по PRI для каждого номера нет возможности сделать. Можно только ограничить общее количество используемых таймслотов на потоке.

Ой, а как же быть? Я - оператор связи и людям продаю городские номера и "серийные" линии. И, понятное дело, что за каждую линию (одновременный звонок) люди должны будут заплатить. Есть вариант "закольцевать" два PRI и на них делать "стайки" таймслотов для каждого пользователя по чисду опдаченных линий и менять планы набора постоянно. Но согласитесь, что это немножко через не то место, через которое хочется.

[Алексей Сергеев]

А какие будут советы относительно "разруливания" этого ограничения? Просто из города приходят именно 11тизнак.
Отрезать префикс 7495?

Можно отрезать префикс (4знака) сведя все к семизначке внутри АТС.
отрезать можно несколькими способами:
- на входе транк группы
- при попадании на префикс перехода в другой план (тут можно вообще свое поставить для вызова группы).

Может я неправильно выразил мысль. Если внутренние номера совпадают, то можено отправить в город с уже городским АОНом и оттуда вернется звонок в соседнюю виртуальную АТС.

Правильно. Виртуальные АТС изолированы, они могут общаться друг с другом либо по прямому городскому номеру (у каждой АТС он свой), либо если вы им пропишете шлюз на определенный префикс. И, кстати, можно прямой городской семизнак соседней АТС прописать в плане другой АТС для экономии каналов при разговорах между ними (с соотвествующим закрытием остальных номеров на "город").

Ой, а как же быть? Я - оператор связи и людям продаю городские номера и "серийные" линии. И, понятное дело, что за каждую линию (одновременный звонок) люди должны будут заплатить. Есть вариант "закольцевать" два PRI и на них делать "стайки" таймслотов для каждого пользователя по чисду опдаченных линий и менять планы набора постоянно. Но согласитесь, что это немножко через не то место, через которое хочется.

Достаточно не тривиальная задача ограничить количество вызовов по PRI у которых либо called либо calling совпадает с требуемым. Да еще и для нескольких таких номеров. Навскидку могу сказать, что наверное не решается в текущей версии ПО (может кто-нибудь поправит из более знающих). При использовании CAS все легко разделяется, так как там поканальный принцип. В PRI принцип все-таки группового канала.

[Алексей Сергеев]

Подумал и еще вариант.
Для виртуальных АТС все, кроме собственных абонентов, закрывается на базовый план нумерации, с подстановкой городского АОНа. А уже из базового можно попасть как на "город", так и на "соседнюю" АТС по ее городскому номеру.
Плюс внутри плана будут свои номера и АОНы.

[Антон Никифоров]

Подумал и еще вариант.
Для виртуальных АТС все, кроме собственных абонентов, закрывается на базовый план нумерации, с подстановкой городского АОНа. А уже из базового можно попасть как на "город", так и на "соседнюю" АТС по ее городскому номеру.
Плюс внутри плана будут свои номера и АОНы.

Вариант, но не очень "сладкий". Дело все в том, что межАТСные звонки по 4х знаку не будут ходить. А это очень удобно в случае технопарка или иной динамичной структуры. Нужно только модификаторами запретить звонки от "простых смертных" руководству, чтобы звонки попадали секретарям.

[Алексей Сергеев]

Что-то я опять Вас не понял.
Виртуальные АТС и изолированны для того чтобы 4-х знаки только внутри плана ходили. Наружу только "город".

[Антон Никифоров]

Что-то я опять Вас не понял.
Виртуальные АТС и изолированны для того чтобы 4-х знаки только внутри плана ходили. Наружу только "город".

Приветствую Вас, Алексей!

Давайте я Вам представлю мою ситуацию.
Есть технопарк в котором компании (скажем от 20 до 50 в разное время) состоят из 3-15 человек каждая, решающих определенный набор задач, достаточно узких.

Теперь моя задача: сделать им всем "Счастье", начиная от заказа электрика/сантехника/пиццы/переводчика через меню SIP терминала и заканчивая звонками в город и между собой. Я уж не говорю про "follow me" фунцию.

Однако, как отдельное юридическое образование, все эти компании должны иметь:
1. свою "интимную" часть (локальная сеть, АТС, офис)
2. "технопарковскую" (внутренняя связь, интрасеть, общие переговорные и места приема пищи)
3. публичную (внешний сайт, номер в сети ТФОП, юр. адрес).

Вот и все Именно это я и реализую

Именно по-этому возникают столь "странные" для Вас, но совершенно "обычные" для меня пожелания и запросы.
Кроме того, есть много других проектов, в которых требуется какая-то часть из описанного и мы занимаемся внедрением таких решений.

[Антон Никифоров]

Ой, а как же быть? Я - оператор связи и людям продаю городские номера и "серийные" линии. И, понятное дело, что за каждую линию (одновременный звонок) люди должны будут заплатить. Есть вариант "закольцевать" два PRI и на них делать "стайки" таймслотов для каждого пользователя по чисду опдаченных линий и менять планы набора постоянно. Но согласитесь, что это немножко через не то место, через которое хочется.

Достаточно не тривиальная задача ограничить количество вызовов по PRI у которых либо called либо calling совпадает с требуемым. Да еще и для нескольких таких номеров. Навскидку могу сказать, что наверное не решается в текущей версии ПО (может кто-нибудь поправит из более знающих). При использовании CAS все легко разделяется, так как там поканальный принцип. В PRI принцип все-таки группового канала.

Приветствую Вас, Господа! Скажите, а появилась ли возможность ограничения числа соединений по конкретному номеру? Может для виртуальной АТС? Может как еще обойти можно? Может в новых версиях ПО? А то дюже сложно постоянно "кольцевать" станцию потоками саму с собой и "резать эти потоки на маленькие группы". Цепь переходов становится почти неуправляемой. Да и потоки жалко, их можно подо что-то более полезное использовать. Спасите-помогите пожалуйста.
На всякий случай напомню задачу: Компания, покупает у меня, скажем 4 линии, а сотрудников в компании 10, каждый из них сидит на своем SIP терминале или является подключенным к АК.24 абонентом. Если все эти 10 человек захотят позвонить, то они займут 10 тайм слотов, а купили (оплатили) всего 4. А если этим людям еще и из города в это время наберут? Сплошные растраты выходят с моей стороны, а абоненты довольны.
Текущее решение - берется 2 потока, замыкаются друг на друга. Вырезается в них группа из 4х тайм слотов. В 0ом плане нумерации входящие на номер этой компании отправляется в эту группу, в плане нумерации (или виртуальной АТС) этой компании исходящим тоже указывается эта группа. Соответственно, если все тайм слоты в группе заняты - получаем занято. Если хоть один свободен - звоним.
Проблемы этого решения:
1. Нужно занимать два потока под такой цикл (думал про один, чтобы TX на RX замкнуть, но что-то не вышло сразу, может из-за недостаточности опыта)
2. Проблемы с тарификатором, поскольку надо мудро фильтровать записи. Меня же интересуют звонки не только в город, но и внутри станции тоже надо тарифицировать.
3. Куча условий и преобразований, обслуживание которых совсем нетривиально.

Помогите пожалуйста.

[Женя]

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