Пример создания виртуальной АТС
Условие примера
Давайте создадим условную виртуальную АТС ( далее вАТС ) для небольшой компании ООО "Иванов":
- Компания имеет 10 сотрудников, каждый сотрудник имеет на рабочем месте телефон с 3-х значной нумерацией;
- Компания имеет два городских номера, все звонки поступают на номер секретаря компании;
- Руководитель имеет выделенный городской номер;
- Часть сотрудников могут делать исходящие звонкина город (включая руководителя и секретаря);
- Часть сотрудников может выполнять только локальные звонки, (для звонка на город они звонят через секретаря);
- Все дополнительные услуги поддерживаемые станцией ECSS-10 могут быть активизированы на любом телефоне компании;
- Одновременно может быть установлено не более 3 звонков на город;
- Внутренние звонки , без ограничений;
- Городские номера имеют 6-и значную нумерацию 420xxx, домен "gorod" уже настроен.
Пример реализации вАТС
В системе ECSS-10 домен можно представить как логическую часть гибкого коммутатора, реализующую функционал отдельной АТС. В системе ECSS-10 домен и вАТС — синонимы. Каждая вАТС содержит следующий набор параметров:
- список контекстов маршрутизации вАТС;
- список алиасов(абонентов), которые содержатся в данной вАТС;
- список услуг, установленных в вАТС.
Создадим домен с именем компании "ivanov". Выполнить это можно через Cocon или веб.
Вариант через Cocon
Создание вАТС
Как указывалось в задании, кол-во абонентов (alias)=10. Разрешаем нашему пользователю быть администратором данной вАТС:
/domain/declare ivanov --add-domain-user-privileges --add-domain-admin-privileges --alias-limit 10 New domain ivanov is declared
Наша вАТС будет работать через IP сеть , поэтому необходимо указать IP set , используемый в ECSS-10 (создавался на этапе инсталляции ECSS-10)
/domain/ivanov/sip/network/set ip_set [test_set] [set] test_set set for different pbx's: ivanov, gorod, test_domain, pbx continue: yes/no ?> yes Property "ip_set" successfully changed from: [] to ["test_set"].
В нашем примере предполагается возможность использования абонентами вАТС "ivanov" всеми доступными услугами, поэтому подключим все услуги к домену:
/cluster/storage/ds1/ss/access-list add ivanov * Supplementary services successfully added in the domain ivanov.
Для возможности применения пакета услуг у абонентов сразу после создания, необходимо настроить политику применения лицензионных пакетов услуг (детальную информацию вы можете посмотреть здесь )
Создать политику применения лицензии с именем -"new_sub"
/domain/ivanov/ss/licence/politics/declare new_sub Licence politic new_sub successfully declared.
Посмотрим какое имя имеет пакет лицензионных услуг в ECSS-10
/cluster/storage/ds1/licence/show-licence 2 . . . Supplementary Services licence package(s) name 'ECSS-FULL+' limit 200000 description "Пакет со всеми услугами" SS list [1,2,3,4,5] . . .
Добавить в созданную политику пакет лицензионных услуг с именем "ECSS-FULL+" (если пакетов несколько , то выберите какой будете использовать), именно так он описан в лицензии:
/domain/ivanov/ss/licence/politics/package-add new_sub ECSS-FULL+ Licence packages ["ECSS-FULL+"] successfully added to politic new_sub.
Пакет добавлен, но в настоящий момент политика не активна (не может быть применена к абоненту). Для активации политики new_sub выполнить следующую команду:
/domain/ivanov/ss/licence/politics/activate new_sub Licence politic new_sub successfully activated.
Теперь при создании абонентов можем использовать дополнительные услуги.
Создание внутренних абонентов вАТС
Давайте создадим 10 абонентов , с номерами 100-109. В примере для упрощения будем использовать имя пользователя и пароль пользователя =номер абонента:
/domain/ivanov/sip/user/declare default_routing sip 100@ivanov alias-as-user qop_authentication login-as-user 100 Executed on the sip1@ecss2 Intermediate (incomplete) result: Declaration for range: 100@ivanov..104@ivanov (1) ... 1 interfaces check for existing ... [**********************************************************************] 160mks 1 users interfaces declaration ... [**********************************************************************] 10ms 1 users divided into 1 parts to declare ... [**********************************************************************] 83mks 1 users aliases declaration ... [**********************************************************************] 2ms 1 users trying licence packages activating ... [**********************************************************************] 2ms 5 interfaces recall to base [**********************************************************************] 2ms Executed on the sip1@ecss2 ┌────────────────────────┐ │ declared 1 subscribers │ └────────────────────────┘
Создадим оставшиеся 9 абонентов через веб интерфейс или Cocon интерфейс на ваше усмотрение.
результат:
/domain/ivanov/sip/user/list sip --active 10 users check for active ... [**********************************************************************] 2ms Executed on the sip1@ecss1 ┌─────┬──────────┬─────────────────────────────────┐ │group│ user │ current contact(s) │ ├─────┼──────────┼─────────────────────────────────┤ │sip │100@ivanov│<sip:100@10.0.20.35>;expires=1782│ │sip │101@ivanov│<sip:101@10.0.20.35>;expires=1783│ │sip │102@ivanov│<sip:102@10.0.20.35>;expires=1772│ │sip │103@ivanov│<sip:103@10.0.20.35>;expires=1788│ │sip │104@ivanov│<sip:104@10.0.20.35>;expires=1785│ │sip │105@ivanov│<sip:105@10.0.20.35>;expires=1789│ │sip │106@ivanov│<sip:106@10.0.20.35>;expires=1772│ │sip │107@ivanov│<sip:107@10.0.20.35>;expires=1777│ │sip │108@ivanov│<sip:108@10.0.20.35>;expires=1775│ │sip │109@ivanov│<sip:109@10.0.20.35>;expires=1775│ └─────┴──────────┴─────────────────────────────────┘ ┌──────────────┐ │ elements: 10 │ └──────────────┘
Организовать подключение между ECSS-10 (городской АТС) и вАТС "ivanov"
Для организации проключение между городской АТС и вАТС, необходимо определить (выделить) полный городской номер (номера) для звонков на вАТС, а так же определить каким внутренним абонентам разрешен прямой выход в город, а каким запрещен. В нашем примере мы выделим два номера 420100 и 420101. Внутренние абоненты 100-105 будут иметь прямой выход в город, а 106-109 нет.
создание Планов нумерации
для организации связи между абонентами вАТС и абонентами ECSS-10, а так же звонков на другие станции необходимо создать План нумерации как в вАТС, так и в городском домене ECSS-10.
в домене "gorod"
/domain/gorod/np/declare ivanov xxxxxx Numbering plan "ivanov" declared successfully.
/domain/gorod/np/info ┌───────┬───────────┬────────────────────┐ │ # │ Property │ Value │ ├───────┼───────────┼────────────────────┤ │1 │Name │ ivanov│ │ │Digitmap │ xxxxxx│ │ │Options │ │ │ │Description│ │ │ │Numbers │ │ └───────┴───────────┴────────────────────┘
в домене "ivanov"
/domain/ivanov/np/declare ivanov xxx Numbering plan "ivanov" declared successfully.
/domain/ivanov/np/info ┌───────┬───────────┬────────────────────┐ │ # │ Property │ Value │ ├───────┼───────────┼────────────────────┤ │1 │Name │ ivanov│ │ │Digitmap │ xxx│ │ │Options │ │ │ │Description│ │ │ │Numbers │ │ └───────┴───────────┴────────────────────┘
Создание бриджа
После создания планов нумерации необходимо создать бридж, который будет связывать 2 домена. При декларации бриджа в поле "план нумерации", необходимо указать соответствующие планы нумерации. Бридж создаем из основного домена "gorod"(рекомендуется), основной домен должен быть доменом А.
- Указываем имя домена А/Б, указываем План нумерации домена А/Б (которые мы только что создали).
- Временно указываем Контекст А/Б = "default_routing" позже контекст должен быть изменен.
- В нашем примере - не более 3-х одновременных разговоров, поэтому устанавливаем "Количество каналов Всего" =3.
/bridge/declare to_ivanov false 3 gorod ivanov bridge:ivanov tg:ivanov default_routing ivanov ivanov bridge:to_gorod tg:to_gorod default_routing
результат:
/bridge/info to_ivanov ┌─────────┬──────┬─────────┬─────────┬─────┬────────┬─────────┬────────────────┬────────────┬───────────────┬──────────────┬────────┬─────────┬───────────────┬───────────┬───────────────┬──────────────┐ │ Name │Strict│ In │ Out │Total│Domain A│Numbering│ Iface A │ Trunk │ Context A │Access group A│Domain B│Numbering│ Iface B │ Trunk │ Context B │Access group B│ │ │ │ │ │ │ │ plan A │ │ group A │ │ │ │ plan B │ │ group B │ │ │ ├─────────┼──────┼─────────┼─────────┼─────┼────────┼─────────┼────────────────┼────────────┼───────────────┼──────────────┼────────┼─────────┼───────────────┼───────────┼───────────────┼──────────────┤ │to_ivanov│false │unbounded│unbounded│3 │gorod │ivanov │bridge:to_ivanov│tg:to_ivanov│default_routing│all │ivanov │ivanov │bridge:to_gorod│tg:to_gorod│default_routing│all │ └─────────┴──────┴─────────┴─────────┴─────┴────────┴─────────┴────────────────┴────────────┴───────────────┴──────────────┴────────┴─────────┴───────────────┴───────────┴───────────────┴──────────────┘ Bridges in table: 1
Проброс номеров через бридж
в домене A "gorod"
этим шагом мы закрепляем выделенные номера , 420100 и 420101 за планом нумерации "ivanov"
/domain/gorod/np/numbers/add ivanov 420100 ┌─────────┬──────┐ │NP Number│Result│ ├─────────┼──────┤ │420100 │ok │ └─────────┴──────┘ /domain/gorod/np/numbers/add ivanov 420101 ┌─────────┬──────┐ │NP Number│Result│ ├─────────┼──────┤ │420101 │ok │ └─────────┴──────┘
результат:
/domain/gorod/np/numbers/info ivanov * ┌───────┬──────────┬───────────────────────┐ │ # │ Number │ Binded resources │ ├───────┼──────────┼───────────────────────┤ │1 │420100 │ │ │2 │420101 │ │ └───────┴──────────┴───────────────────────┘
Следующий шаг:
данным шагом мы переправляем все звонки на номера 420100 и 42010 в бридж "to_ivanov" к вАТС
/domain/gorod/np/numbers/bind ivanov 420100 --bridge to_ivanov ok /domain/gorod/np/numbers/bind ivanov 420101 --bridge to_ivanov ok
результат:
/domain/gorod/np/numbers/info ivanov * ┌───────┬──────────┬───────────────────────────────────┐ │ # │ Number │ Binded resources │ ├───────┼──────────┼───────────────────────────────────┤ │1 │420100 │-> to_ivanov │ │2 │420101 │-> to_ivanov │ └───────┴──────────┴───────────────────────────────────┘
в домене В "ivanov"
переходим в домен "ivanov"
Мы сразу видим наши номера 420100 и 420101. Мы их пробросили из городского домена , и видим в домене вАТС. Наша задача закрепить за городскими номерами локальные номера вАТС.
/domain/ivanov/np/numbers/info ivanov * ┌───────┬──────────┬───────────────────────────────────┐ │ # │ Number │ Binded resources │ ├───────┼──────────┼───────────────────────────────────┤ │1 │420100 │ │ │2 │420101 │ │ └───────┴──────────┴───────────────────────────────────┘
При этом выбирая номер с функцией "Владелец" мы указываем на какой внутренний номер будут поступать входящие звонки с городских номеров. Номера которые подключены к городскому номеру , смогут выполнять исходящие звонки на город.
/domain/ivanov/np/numbers/bind ivanov 420100 --alias 100 ok
результат(* после номера указывает , что на этот номер можно делать прямые входящие звонки из города):
/domain/ivanov/np/numbers/info ivanov * ┌───────┬──────────┬───────────────────────────────────┐ │ # │ Number │ Binded resources │ ├───────┼──────────┼───────────────────────────────────┤ │1 │420100 │100 * │ │ │ │102-105 │ │2 │420101 │101 * │ └───────┴──────────┴───────────────────────────────────┘
теперь нам нужно обновить конфигурацию бриджа, при создании был использован контекст маршрутизации "default_routing" , требуется заменить контекст А с "default_routing" на "to_ivanov". А так же активизировав функцию "Проверка номеров" мы разрешаем звонки с номеров которые были привязаны в плане нумерации к городским номерам.
/bridge/change to_ivanov strict true Bridge with name "to_ivanov" changed successfully.
/bridge/change to_ivanov routing_contex_a to_ivanov Bridge with name "to_ivanov" changed successfully.
результат:
/bridge/info to_ivanov ┌─────────┬──────┬─────────┬─────────┬─────┬────────┬─────────┬────────────────┬────────────┬─────────┬──────────────┬────────┬─────────┬───────────────┬───────────┬───────────────┬──────────────┐ │ Name │Strict│ In │ Out │Total│Domain A│Numbering│ Iface A │ Trunk │Context A│Access group A│Domain B│Numbering│ Iface B │ Trunk │ Context B │Access group B│ │ │ │ │ │ │ │ plan A │ │ group A │ │ │ │ plan B │ │ group B │ │ │ ├─────────┼──────┼─────────┼─────────┼─────┼────────┼─────────┼────────────────┼────────────┼─────────┼──────────────┼────────┼─────────┼───────────────┼───────────┼───────────────┼──────────────┤ │to_ivanov│true │unbounded│unbounded│3 │gorod │ivanov │bridge:to_ivanov│tg:to_ivanov│to_ivanov│all │ivanov │ivanov │bridge:to_gorod│tg:to_gorod│default_routing│all │ └─────────┴──────┴─────────┴─────────┴─────┴────────┴─────────┴────────────────┴────────────┴─────────┴──────────────┴────────┴─────────┴───────────────┴───────────┴───────────────┴──────────────┘ Bridges in table: 1
Вариант через веб
Создание вАТС
Для создания вАТС с лимитом в 10 абонентов потребуется выполнить несколько шагов:
- Выбрать приложение "Домены"
- Выбрать "Добавить Домен"
- В дополнительном окне указать имя нового домена (вАТС) , в нашем примере "ivanov"
- Подтвердить выполнение
На следующем шаге:
- Выбрать приложение "Домены"
- Выбрать нужный домен , в нашем случае "ivanov"
- Выбрать "Свойства домена"
- Выбрать Системные параметры/Ограничения
- В поле "alias_limit" указать значение 10 (наши ограничения на 10 абонентов)
- Сохранить
Подключить нашу вАТС к IP set-у
- Выбрать приложение "Домены"
- Выбрать нужный домен , в нашем случае "ivanov"
- Выбрать "Свойства домена"
- Выбрать SIP / SIP транспорта
- В поле "IP set" выбрать какой будем использовать , в нашем примере "test_set"
- Сохранить
Создание внутренних абонентов вАТС
Давайте создадим 10 абонентов , с номерами 100-109. В примере для упрощения будем использовать имя пользователя и пароль пользователя =номер абонента:
- Выбрать приложение "Карточка абонента"
- Выбрать "Добавить"
- Имя интерфейса = внутренний абонентский номер
- Выбрать sip
- Выбрать Авторизация = register
- Включить "Использовать номер в качестве логина"
- Пароль = внутренний абонентский номер
- Подтвердить
Создадим оставшиеся 9 абонентов через веб интерфейс или Cocon интерфейс на ваше усмотрение.
Результат :
Сейчас все 10 абонентов могут устанавливать соединения между собой.
Организовать подключение между ECSS-10 (городской АТС) и вАТС "ivanov"
Для организации проключения между городской АТС и вАТС, необходимо определить (выделить) полный городской номер (номера) для звонков на вАТС, а так же определить каким внутренним абонентам разрешен прямой выход в город, а каким запрещен. В нашем примере мы выделим два номера 420100 и 420101. Внутренние абоненты 100-105 будут иметь прямой выход в город, а 106-109 нет.
создание Планов нумерации
для организации связи между абонентами вАТС и абонентами ECSS-10, а так же звонков на другие станции необходимо создать План нумерации как в вАТС, так и в городском домене ECSS-10.
- в вАТС , выбрать приложение "Менеджер планов нумерации" в домене "ivanov"
Cразу видим список доступных абонентов в данной вАТС, но имя плана нумерации отсутствует. Его нужно создать. В нашем примере создадим имя "ivanov":
- Выбрать "Добавить план"
- Указать имя плана нумерации "ivanov"
- Сохранить
результат
- в городском домене создать план нумерации который будет поддерживать связь с вАТС "ivanov", выполняется аналогичным образом , только в домене "город":
Создание бриджа
После создания планов нумерации необходимо создать бридж, который будет связывать 2 домена. При декларации бриджа в поле "план нумерации", необходимо указать соответствующие планы нумерации. Бридж создаем из основного домена "gorod"(рекомендуется), основной домен должен быть доменом А.
- Указываем имя домена А/Б, указываем План нумерации домена А/Б (которые мы только что создали).
Временно указываем Контекст А/Б = "default_routing" позже контекст должен быть изменен.
В нашем примере - не более 3-х одновременных разговоров, поэтому устанавливаем "Количество каналов Всего" =3. - Сохраняем.
Настройка контекста маршрутизации
После того, как были созданы "планы нумерации" и "бридж", необходимо настроить маршрутизацию между доменами. Для этого создадим контекты маршрутизации.
В данном примере, у домена "gorod" существует центральный контекст (default_routing), маршрутизация в котором происходит на транки/бриджи/другие контексты.
Задавать план нумерации на этот контекст не рекомендуется.
Создадим на домене "gorod" контекст маршрутизации, название — "to_ivanov", план нумерации — "ivanov".
- Выбрать "Менеджер маршрутизации"
- Выбрать "Контекст" добавить
- Указать имя "to_ivanov"
- Указать План нумерации "ivanov"
- Подтвердить
и добавим туда правило маршрутизации (в домене "gorod"):
- Выбрать добавить "Контекст"
- Выбрать контекст "to_ivanov"
- Выбрать добавить правило
- Указать указать имя правила , для примера, "420100"
- Добавить номер cdpn = 42010(0,1) . (этим параметром мы задали два номера 420100 и 420101)
- Задать результат маршрутизации = внешний , bridge:to_ivanov
- Сохранить
этим правилом мы направим все звонки на номера 420100/420101 в бридж с именем "to_ivanov"
Но, наши городские абоненты, обслуживаются в контексте "default_routing". Поэтому требуется проключить звонки на номера 420100/420101 из контекста "default_routing" в контекст "to_ivanov"
- Создать правило с условием номер В 42010(0,1) , результат= анализ в контексте с именем "to_ivanov". Не забыть поставить его перед правилом "local_calls"
Следующим шагом мы должны пробросить эти два номера , 420100/420101, через бридж на нашу вАТС. Так же указать какие внутренние номера из диапазона 100-109 будут подключены к этим городским номерам.
Проброс номеров через бридж
в домене A "gorod"
этим шагом мы закрепляем выделенные номера , 420100 и 420101 за планом нумерации "ivanov"
- Выбрать приложение "Менеджер планов нумерации"
- Выбрать ранее созданный план "ivanov"
- Выбрать добавить номера
- Указать номера , для примера, "42010{0,1}" (одной командой добавим два номера 420100 и 420101)
- Сохранить
Следующий шаг:
данным шагом мы переправляем все звонки на номера 420100 и 42010 в бридж "to_ivanov" к вАТС
- Выбрать план нумерации "ivanov"
- Выбрать ранее добавленные номера 420100 и 42010
- Выбрать Бриджи
- Указать бридж "to_ivanov"
- Сохранить
в домене В "ivanov"
переходим в домен "ivanov"
- Выбрать приложение "Менеджер планов нумерации"
- Выбрать ранее созданное имя плана нумерации "ivanov"
Мы сразу видим наши номера 420100 и 420101. Мы их пробросили из городского домена , и видим в домене вАТС. Наша задача закрепить за городскими номерами локальные номера вАТС.
При этом выбирая номер с функцией "Владелец" мы указываем на какой внутренний номер будут поступать входящие звонки с городских номеров. Номера которые подключены к городскому номеру , смогут выполнять исходящие звонки на город.
- Выбрать городской номер, для примера "420100"
- Выбрать Алиасы
- Выбрать номер который будет "владельцем"
- Выбрать номер который сможет использовать исходящую связь на город
- Выбрать номер который сможет использовать исходящую связь на город
- Выбрать номер который сможет использовать исходящую связь на город
- Выбрать номер который сможет использовать исходящую связь на город
- Сохранить
аналогично подключим второй номер , он будет закреплен за начальником компании "ООО Иванов"
подключаем план нумерации "ivanov" c уже проброшенными номерами к контексту маршрутизации внутри домена (вАТС)
- Выбрать Контекс "default_routing", редактирование
- Выбрать План нумерации, и изменить дефолтное значение на созданное "ivanov"
- Сохранить
теперь нам нужно обновить конфигурацию бриджа, при создании был использован контекст маршрутизации "default_routing"
- Заменить контекст А с "default_routing" на "to_ivanov"
- Сохранить
Чтобы разрешить абонентам компании "ООО Иванов" звонить на город, в контексте маршрутизации "default_routing" домена "ivanov" сделать правило выхода в город по номерам 4200?? с результатом внешний brige:to_gorod. Не забыть поставить его на первую позицию.
Теперь абоненты компании "OOO Иванов" могут делать исходящие звонки на городские номера 4200xx, а так же получать входящие звонки из города на телефон секретаря и телефон начальника.
Но условиях было сказано что не все абоненты , а только 100-105 могут делать исходящую связь в город. А в настоящий момент все 10 абонентов могут позвонить на город. Давайте исправим эту ошибку.
- В приложение "Менеджер бриджей" активизировать функционал "Проверка номеров"
- Сохранить
Активизировав функцию "Проверка номеров" мы разрешаем звонки с номеров которые были привязаны в плане нумерации к городским номерам
на примерах видно , что разрешенные номера 100,102,103,104,105,101.
Теперь только с этих номеров звонки в город будут успешные. То есть в домене "ivanov" мы активизировали контроль за номерами прописанными в плане нумерации, только с них можно делать исходящие звонки.
Так же активизируется контроль в домене "gorod" , со стороны А звонки будут проходить только на номера привязанные к бриджу. Если создать правило маршрутизации с коротким номером В=100-109 звонок все равно не состоится (будет выполнена блокировка на бридже) .
Если же отключить проверку номера на бридже , то можно будет звонить по короткому номеру (100-109) и по городскому номеру (420100/420101), но это не корректно, с точки зрения сети общего пользования.
Мы успешно создали вАТС, с 10-ю внутренними номерами.
- Данные абоненты могут делать внутренние звонки без ограничения.
- Абоненты с номерами 100-105 могут делать исходящие звонки в город.
- Для руководителя выделен отдельный городской номер.
- Все входящие звонки поступают на секретаря, который будет переводить звонки на сотрудников используя услугу "Передача вызова (ctr)".