По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! В этой статье мы расскажем, что такое Call Park в Cisco Unified Communications Manager (CUCM) , и как его настроить. Функция Call Park позволяет абоненту временно удержать вызов, поместив его в так называемый Call Park слот, чтобы потом другой абонент в системе CUCM смог его забрать (извлечь из слота). Например, вам звонит клиент и спрашивает о продукте, которым занимается другой отдел. В этом случае вы можете запарковать вызов, связаться с коллегой из другого отдела и сказать, чтобы он перехватил вызов, набрав Call Park номер. На каждый Call Park номер можно запарковать один звонок. Есть другой тип этой функции, который называется Directed Call Park, где для перехвата вызова необходимо ввести префикс код.
Настройка Call Park
В Call Manager Administration переходим во вкладку Call Routing → Call Park и для создания нажимаем Add New. В строке Call Park Number/Range нужно указать номе или диапазон номеров, которые будут использоваться для парковки. Если указываем диапазон номеров, то можно использовать wildcard символы, которые используются в Route Pattern (например, если нам нужно значение номера с 8880 по 8889, то указываем 888X). Затем в строке Cisco Unified Communications Manager из выпадающего меню выбираем желаемый сервер. Если Call Park настраивается на нескольких серверах, то необходимо убедиться что диапазоны номеров не пересекаются между серверами. После настройки нажимаем кнопку Save.
Для настройки Directed Call Park нужно произвести похожие действия.
Переходим во вкладку Call Routing → Directed Call Park и нажимаем Add New. В новом окне в поле Number указываем номер или диапазон номеров для парковки. Затем в строке Retrieval Prefix указываем код, который необходимо набрать, для того чтобы перехватить удерживаемый звонок. Также в поле Reversion Number можно указать номер, на который будет переадресовываться вызов, если никто его не перехватит до того как истечет таймер Call Park Reversion (по умолчанию 60 секунд). Для сохранения настроек нажимаем Save.
Теперь Call Park настроен и кнопку парковки можно вывести на экран, добавив ее в Button Template или Softkey Template.
Когда администратор является единственным администратором АТС, то проблем с выяснением причин кто и что сломал не возникает, так как административный аккаунт один и им пользуется только один человек.
А вот когда администраторов много, да ещё необходимо разграничивать права доступа в зависимости от выполняемых обязанностей, тогда как раз и встает вопрос о персональных аккаунтах для администраторов.
Для этого можно создавать как персональные профайлы (под единичные доступы), так и групповые (например, для сотрудников, выполняющих ограниченные функции – проверка состояния транков, создание абонентов, настройка Call Center и так далее).
Стоит заметить, что первые 19 профайлов являются системными и их менять или удалять не стоит. Для новых профайлов следует использовать номера с 20.
Выполнение в терминале или консоли GEDI
Для начала надо создать новый профайл командой:
add user-profile-by-category НОМЕР
или
add user-profile НОМЕР
В открывшемся окне выставляем параметры, которые нам необходимы.
User Profile Name – имя профайла. Служит для идентификации уровня доступа (имя пользователя или имя группы пользователей, для которых и создается данный профайл).
Shell Access? – разрешен ли данному профайлу доступ в командную строку системы
В терминале это выглядит так:
А в консоли GEDI это будет немного поудобнее, тем более, что выставление параметров можно выполнять при помощи мыши, при этом по нажатию правой кнопки показывается подсказка по значениям в конкретном поле:
На первой странице выставляются общие (групповые для функций) права на доступ. Более детальные разрешения выставляются на последующих страницах. Однако без выставления прав на группу нельзя выставить права на функцию, входящую в эту группу.
Например, нельзя разрешить настраивать абонентов или транки, не разрешив при этом группу Maintenance (G) на первой странице. Но можно разрешить доступ только к абонентам, но запретив доступ к транкам.
Чтобы не открывать все группы, можно найти необходимую функцию, посмотреть в какую группу (категорию) входит данная функция и на первой странице разрешить именно эту группу.
Разрешение r позволяет только просматривать без возможности создания или внесение изменений в настройки.
Разрешение w дополнительно позволяет ещё и создавать, изменять и удалять настройки.
Разрешение m позволяет выполнять дополнительные действия по обслуживанию (трассировки, включение/выключение абонентов или транков и так далее)
Обычно создают профайл для полного доступа администраторов (с включением всех групп (категорий) и правами доступа wm) и профайлы с ограниченным доступом для других пользователей, выполняющих некоторое задачи (например, 1-линия для создания абонентов, служба мониторинга для просмотра статусов абонентов или транков и так далее).
После установки всей настроек сохраняем настройки путем нажатия F3 в терминале или Enter (F3) в консоли GEDI.
Выполняется в web-браузере
Подключаемся к Avaya Communication Manager по IP-адресу, заходим под учетной записью dadmin (если она у нас единственная) или под учетной записью «полного» администратора (если ранее был создан такой аккаунт).
Далее Administration → Server (Maintenace) → Security → Administrator Accounts → Add Login и создаем уже сами аккаунты:
Сначала выбираем уровень доступа. В зависимости от выбранного уровня предоставляются разные права, не настраиваемые в профайле.
Вот пример предоставляемых прав для 2-х администраторов:
Для уровня «полного» администратора выбираем Privileged Administrator.
Login name – создаваемый логин, по которому будет осуществляться авторизация.
Additional groups (profile) – в выпадающем списке выбираем созданный ранее профайл.
Enter password or key – вводим пароль для входа.
Re-enter password or key – подтверждаем введенный ранее пароль.
Как правило пользователь должен сам создавать и помнить свои пароли, поэтому
Force password/key change on next login – отмечаем в Yes. Тогда при первом входе пользователю будет предложено для продолжения работы сменить пароль на новый.
Далее подтверждаем введенные данные Submit.
Для добавления доступа к Web-настройкам созданный ранее профайл надо добавить через Administration → Server (Maintenace) → Security → Web Access Mask.
Нажимаем Add, потом вводим номер нашего созданного профайла и выбираем какую маску доступа будем применять или сразу будем применять все включено/выключено.
После сохранения убеждаемся, что вновь добавленная маска применилась, выбираем её, заходим в нее нажав Change и проверяем/добавляем/удаляем необходимые настройки.
Далее заходим под созданной учетной записью и проверяем уровень доступа по доступным командам. После проверки полного доступа рекомендуется сменить пароль для учетной записи dadmin и не выдавать этот логин никому.
Дальше в логах на СМ мы можем просмотреть историю входов, введенных команд и выполненных действий по каждому логину.
Чтобы понять NoSQL, нужно разобраться, что такое SQL и почему мы говорим ему No.
Итак, SQL (structured query language) расшифровывается как «язык структурированных запросов», и это язык запросов для управления данными в так называемых реляционных базах данных, или просто БД
В реляционных базах мы храним данные в таблицах, которые логически связаны между собой - отсюда и название - реляционные от слова relation, связь. Это один из самых популярных типов баз.
В этих таблицах есть строки и столбцы. В столбце таблицы хранится определенный тип данных, а в каждой ячейке – значение.
Строка же получается как набор связанных значений, которые относятся к одному объекту - мы видим что у крыла типа чайка длина 25 метров.
Ну и каждая строка в таблице может быть помечена каким то уникальным идентификатором, который называется первичным ключом (primary key). А затем при помощи него мы можем связать данные из нескольких таблиц, например в отдельной таблице, где он станет внешним ключом (foreign key).
В общем, как таблица в экселе, только данные могут быть связаны.
Что еще важно знать: реляционные БД требуют так называемую схему (schema) - описание структуры таблицы ее полей и ограничений. То есть если нам например нужно добавить или убрать столбец в таблице, то это изменение коснется всех данных внутри нее.
Также БД этого типа соответствуют так называемым принципам ACID (Atomicity — Атомарность, Consistency — Согласованность, Isolation — Изолированность, Durability — Надёжность), что вкратце означает, что при работе с базой, целостность и согласованность данных гарантирована, даже если возникли проблемы с сетью или железом, что полезно при работе с финансами, например.
В качестве примеров таких баз назовем: Microsoft SQL Server, Oracle Database, MySQL и PostgreSQL.
Разобрались. Теперь вернемся к NoSQL. Это тип баз данных, которые хранят данные в отличном от реляционных таблиц формате. Они узкоспециализированны для конкретных задач и нужны для улучшения производительности, масштабируемости и удобства в работе.
Базы данных "ключ-значение" (key-value)
Суть в том, что мы храним данные в таком виде: у нас есть уникальный ключ, который указывает на какое-то значение. А сама база - это совокупность этих пар. Вот так просто! Причем эти данные могут быть чем угодно, числом, строкой или даже другой парой ключ-значение потому что в отличии от реляционных баз данных они не имеют предопределенной структуры данных.
Многие БД такого типа хранят данные в памяти (RAM), в отличии от других баз, которые хранят данные на диске, что хоть и может ограничивать объем хранимых данных (хотя они требуют гораздо меньше памяти), но это обеспечивают просто невероятную скорость. Ну и раз это NoSQL то никаких сложных запросов, никаких связей друг с другом - мы просто записываем ключ и его значение, и получаем значение по ключу.
Где их использовать? Они отлично подходят для хранения кэша или пользовательских сессий. А в качестве самого простого примера можно назвать корзину в интернет магазине - где мы храним идентификатор пользователя, и сколько товаров он положил в корзину.
Самые популярные хранилки по типу “ключ - значение” это Redis, Memcached и DynamoDB.
Wide-column (columnstore базы данных, БД с широкими столбцами или колоночные БД)
Все также просто - берем key-value БД, и делаем так чтобы в значении мы могли хранить несколько столбцов сразу. Это позволяет удобно хранить связанную информацию. Похоже на реляционную БД, но только в отличии от нее, тут у нас нет схемы, поэтому мы можем хранить разные неструктурированные данные.
Такой тип БД подойдет для хранения логов, данных с умных холодильников и чайников, а также различных аналитических приложений, где данные хранятся в большом объеме. Netflix, например, хранит в таких таблицах историю просмотров пользователя.
В качестве примеров таких баз назовем Cassandra, Hbase и ClickHouse.
Базы данных документов или документориентированные БД (Document DB)
Подробнее про них можно прочитать в нашей отдельной статье.
Если предыдущие типы NoSQL БД обычно используются для специфических задач, то эти базы уже более универсальны, и могут стать основным местом хранения информации.
Здесь мы храним документы. Документ это набор нескольких пар ключ-значение, о которых мы говорили раньше, и раз это не SQL, то они неструктурированны и не требуют схему. Это значит, что мы можем легко добавлять и удалять поля в документе, в отличие от реляционных БД, где изменения затронули бы всю таблицу. Документы даже могут быть вложенными, и содержать в себе другие документы.
Данные хранятся в стандартных форматах, таких как XML, YAML и JSON. Такая форма хранения идеально подходит к объектам, которые используются в приложениях. Мы буквально сразу получаем полный объект который нам нужен, а в SQL нужно сначала приложить усилия и даже сделать несколько запросов и все собрать в необходимый вид.
Документы можно группировать друг с другом собирая их в коллекции, которые можно собирать в логическую иерархию, получая что-то по типу реляционных БД.
Это как шкаф на работе - в один ящик мы можем положить трудовые договоры, в другой - договоры с партнерами, а в третий договоры аренды.
Ничто нам не мешает сложить всё в одну кучу, но так удобнее. И вот эти ящики как раз и будут коллекциями в нашем случае. А отсутствие схемы позволяет нам положить в один ящик договоры, которые схожи логически, но имеют разную структуру внутри. Например, долгосрочный договор с сотрудником и договор с компанией. Коллекции есть не у всех БД такого типа, некоторые системы используют теги или древовидные иерархии.
Они часто используются для мобильных приложений и игр, блогов, интернет магазинов и всяких штук где у нас имеется много контента.
Самые популярные БД такого типа - MongoDB, Amazon DynamoDB, CouchDB.
Графовые БД (Graph DB)
Тут мы больше значения уделяем тому как данные связаны друг с другом, и эта БД лучше всего обрабатывает такие данные.
Тут у нас есть узлы, которые представляют данные и ребра (или соединения), которые описывают связь между этими данными. Помните как в реляционных базах мы записывали связь в отдельной таблице? Тут мы можем обойтись без нее, просто показав связь.
Такие базы просто необходимы для алгоритмов рекомендаций, социальных сетей, управления компьютерными сетями и маршрутизацией или даже обнаружения финансового мошенничества.
Самые популярные графовые базы: Neo4j и DGraph
Поисковые БД (Search-engine database)
Они, как понятно из названия, нужны для поиска данных из большого количества источников.
Работают они примерно также как и базы данных документов - мы добавляем документы с текстом внутри, а БД проанализирует весь текст в этих документах и создаст индексы для этого текста.
По сути это работает как указатели, которые ты видел в конце книги, где указывается какой-то термин и страница на которой он встречается.
И когда пользователь выполняет поиск, то сканируются только эти индексы, а не все документы в базе.
Ну и очевидно что они используются в качестве полнотекстового поиска, а также для хранения и анализа логов. Примеры - Elasticsearch, Solr, Algolia
Базы данных временных рядов (Time series database)
Это базы данных, оптимизированные для данных с отметками времени. Такое используется, для мониторинга систем, где мы храним значение времени и данные в этот момент. Например, загрузка сервера или количество подключений.
Примеры - InfluxDB и Prometheus
Многомодульные БД (multi-model)
Также существуют так называемые много-модульные БД (multi-model), которые поддерживают несколько моделей данных.
Например тот же рredis умеет и в ключ-значение, и документы с графами и даже временные данные обработает.