пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ FreePBX
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В Cisco Unified Communications Manager (CUCM) существует разделение по интерфейсам администратора – каждый из них отвечает за свою область настроек.
В CUCM есть следующие интерфейсы:
Cisco Unified CM Administration (https://[IP_сервера]/ccmadmin);
Cisco Unified Serviceability (https://[IP_сервера]/ccmservice);
Cisco Unified OS Administration (https://[IP_сервера]/cmplatform);
Cisco Unified Reporting (https://[IP_сервера]/ccmservice);
Cisco Unified IM and Presence Reporting (https://[IP_сервера]/cucreports);
Disaster Recovery System (https://[IP_сервера]/drf);
Command Line Interface (CLI);
К каждому из них можно подключиться только по HTTPS (кроме интерфейса командной строки CLI, для него используется SSH), а переключаться между интерфейсами можно через выпадающее меню в правой верхней части экрана.
Логин и пароль администратора платформы, которые задаются при установке (administrator id) используется для доступа в DRS и OS Administration. Также при установке задаются логин и пароль (application user) для входа в CM Administration, Serviceability и Cisco Unified Reporting.
Рассмотрим подробнее эти интерфейсы и что в них включено. Стоит заметить что наличие того или иного пункта в меню зависит от версии CUCM.
Интерфейс Cisco Unified Communications Manager Administration
Меню System: включает в себя конфигурирование групп CM, Presence и Device Mobility, настройку Device Pool, Region, Locations, Survivable Site Telephony (SRST), DHCP, LDAP, сервисных параметров, а также лицензирование;
Меню Call Routing: здесь находятся разделы, отвечающие за маршрутизацию звонков, паттерны, интерком, Dial Rules, меню Class of Control, включающее Calling Search Space и Partitions, а также такие функции как Call Pickup, Call Park и другие;
Меню Media Resources: в этом меню расположены настройки таких ресурсов, как Music on Hold (MOH), Annunciator, Transcoder, Media Termination Point (MTP), а также файловый менеджер MOH;
Меню Advanced Features: тут можно найти настройки Voicemail интеграций, Inter-Company Media Engine Configuration и VPN;
Меню Device: настройка IP-телефонов, шлюзов, гейткиперов, транков, профилей телефонов, функциональных кнопок и многое другое;
Меню Application: содержит мастер конфигурации CUCM и меню настройки плагинов;
Меню User Management: настройка пользователей End User, Application User, User Group и ролей;
Меню Bulk Administration: предоставляет множество возможностей для выполнения повторяющихся задач настройки (например, добавления большого числа пользователей или телефонов) автоматическим способом;
Меню Help: тут собранны полезные статьи о работе в CUCM;
Интерфейс Cisco Unified Serviceability Administration
Меню Alarm: тут находятся конфигурационные опции для системных предупреждений для мониторинга производительности и общего состояния системы;
Меню Trace: настройки трекинга для мониторинга системы и поиска проблем;
Меню Tools: здесь в подменю CDR Analysis and Reporting предоставляет интерфейс для сбора журналов вызовов и отчетов о вызовах, выполненных с использованием системы. Раздел Service Activation предоставляет интерфейс для активации сервисов, установленных в первый раз. Используя этот интерфейс, администраторы могут останавливать, запускать или перезапускать активированные службы. Архив отчетов Serviceability Reports обеспечивает доступ к интерфейсу отчетов для анализа системы. Интерфейс управления CDR позволяет администраторам настраивать и проверять использование дискового пространства для Call Detail Report (CDR). Страница Audit Log Configuration содержит параметры для того, что будет включено в журналы аудита;
Меню SNMP: тут расположены подменю (V1/V2c, V3 и SystemGroup) конфигурации протокола Simple Network Management Protocol (SNMP);
Меню Help: здесь также расположены материалы о CUCM;
Интерфейс Cisco Unified Operating System Administration
Этот интерфейс позволяет администратору следить и взаимодействовать с платформой операционной системы на базе Linux. Административные задачи, которые могут быть выполнены здесь, включают в себя:
Мониторинг использования аппаратного ресурса (центральный процессор, дисковое пространство);
Проверка и обновление версий программного обеспечения;
Проверка и изменение информации об IP-адресе;
Управление IP адресом протокола Network Time Protocol (NTP);
Управление безопасностью сервера, включая IPsec и цифровые сертификаты;
Создание учетной записи удаленной помощи TAC;
Ping других IP-устройств;
Интерфейс Disaster Recovery System
Система аварийного восстановления (DRS) обеспечивает резервное копирование (с планировщиком) и возможность восстановления. Доступ к этому интерфейсу использует учетная запись администрирования платформы, определенная при установке (также как и интерфейс Cisco Unified Operating System Administration). Дополнительные учетные записи могут быть созданы для доступа других лиц.
Резервные копии должны быть записаны на сетевой SFTP-сервер. Планировщик предоставляется для автоматического резервного копирования или может быть выбран немедленный запуск копирования. Также может выполняться резервное копирование отдельного сервера или полного кластера.
Интерфейс Cisco Unified Reporting
Cisco Unified Reporting предоставляет упрощенный метод доступа к системным отчетам. Эти отчеты собирают информацию из существующих журналов и форматируют данные в простые, полезные отчеты с одним щелчком мыши. Данные собираются из журналов через кластер (Publisher и Subscribers), чтобы предоставить обобщенную информацию и выделить проблемы или нарушения, которые могут повлиять на работу кластера. Интерфейс также предупреждает, что запуск конкретного отчета может неблагоприятно повлиять на работу сервера и повлиять на производительность или занять много времени.
Command Line Interface
К CLI обычно получают доступ с использованием SSH, хотя можно напрямую подключить клавиатуру и монитор. Изначально единственной учетной записью, которая может войти в систему с использованием CLI, является учетная запись администрирования платформы, определенная во время установки, хотя для доступа можно создать дополнительные учетные записи.
Команды и функциональные возможности CLI включают все те, которые находятся в интерфейсе OS Administration, плюс следующие (но это далеко не полный список):
Выключение или перезагрузка системы;
Изменение версий после обновления;
Запуск, остановка и перезапуск служб;
Изменение сетевых настроек (IP-адрес, маска, шлюз и так далее.);
Использование сетевых инструментов, таких как ping, traceroute и захват пакетов;
Использование DRS (резервное копирование и восстановление);
Добавление и изменение учетных записей администратора;
Отображение нагрузки на сервер и информации о процессах;
Проверка состояния сервера, включая версии программного обеспечения, процессор, память и использование диска, аппаратную платформу, серийные номера и так далее;
Предыдущая статья из цикла про популярные приложения TCP/IP тут.
Установление TCP-соединения происходит до того, как любая из других функций TCP сможет начать свою работу. Установление соединения относится к процессу инициализации полей "Sequence" и "Acknowledgment" и согласования используемых номеров портов. На рисунке 5 показан пример процесса установления соединения.
Этот трехсторонний процесс установления соединения (также называемый трехсторонним рукопожатием) должен завершиться до начала передачи данных. Соединение существует между двумя сокетами, хотя в заголовке TCP нет единственного поля сокета. Из трех частей сокета подразумеваются IP-адреса на основе IP-адресов источника и назначения в IP-заголовке. TCP подразумевается, потому что используется заголовок TCP, как указано значением поля протокола в заголовке IP. Следовательно, единственные части сокета, которые необходимо закодировать в заголовке TCP, - это номера портов.
TCP сообщает об установлении соединения, используя 2 бита в полях флагов заголовка TCP. Эти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает "синхронизировать порядковые номера", что является одним из необходимых компонентов при инициализации TCP.
На рисунке 6 показано завершение TCP-соединения. Эта четырехсторонняя последовательность завершения проста и использует дополнительный флаг, называемый битом FIN. (FIN - это сокращение от "finished", как вы могли догадаться.) Одно интересное замечание: перед тем, как устройство справа отправит третий сегмент TCP в последовательности, оно уведомляет приложение о том, что соединение прерывается. Затем он ожидает подтверждения от приложения перед отправкой третьего сегмента на рисунке. На случай, если приложению потребуется некоторое время, чтобы ответить, ПК справа отправляет второй поток на рисунке, подтверждая, что другой ПК хочет разорвать соединение. В противном случае ПК слева может повторно отправить первый сегмент.
TCP устанавливает и завершает соединения между конечными точками, а UDP - нет. Многие протоколы работают в рамках одних и тех же концепций, поэтому термины "ориентированный на соединение" и "без установления соединения" используются для обозначения общей идеи каждого из них. Более формально эти термины можно определить следующим образом:
Протокол, ориентированный на соединение: протокол, который требует обмена сообщениями до начала передачи данных или который имеет требуемую предварительно установленную корреляцию между двумя конечными точками.
Протокол без установления соединения: протокол, который не требует обмена сообщениями и не требует предварительно установленной корреляции между двумя конечными точками.
Восстановление после ошибок и надежность
TCP обеспечивает надежную передачу данных, что также называется reliability or error recovery. Для обеспечения надежности TCP нумерует байты данных, используя поля "Sequence" и "Acknowledgment" в заголовке TCP. TCP обеспечивает надежность в обоих направлениях, используя поле Sequence Number одного направления в сочетании с полем Acknowledgment в противоположном направлении.
На рисунке 7 показан пример того, как поля TCP Sequence и Acknowledgment позволяют ПК отправлять 3000 байтов данных на сервер, при этом сервер подтверждает получение данных. Сегменты TCP на рисунке расположены по порядку, сверху вниз. Для простоты все сообщения содержат 1000 байтов данных в части данных сегмента TCP. Первый порядковый номер - красивое круглое число (1000), опять же для простоты. В верхней части рисунка показаны три сегмента, каждый из которых на 1000 больше предыдущего, что указывает на первый из 1000 байтов сообщения. (То есть в этом примере первый сегмент содержит байты 10001999; второй - байты 20002999, а третий - байты 30003999.)
Четвертый сегмент TCP на рисунке - единственный, который возвращается от сервера к веб-браузеру - подтверждает получение всех трех сегментов. Как? Значение подтверждения 4000 означает: "Я получил все данные с порядковыми номерами на единицу меньше 4000, поэтому я готов принять ваш байт 4000 следующим". (Обратите внимание, что это соглашение о подтверждении путем перечисления следующего ожидаемого байта, а не номера последнего полученного байта, называется прямым подтверждением.)
Однако этот пример не исправляет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле порядкового номера для идентификации данных, а хост-получатель использует прямые подтверждения для подтверждения данных. Более интересное обсуждение вращается вокруг того, как использовать эти же инструменты для восстановления ошибок. TCP использует поля "Sequence" и "Acknowledgment", чтобы принимающий хост мог заметить потерю данных, попросить отправляющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли.
Существует множество вариантов того, как TCP выполняет исправление ошибок. На рисунке 8 показан только один такой пример, детализация которого аналогична предыдущему. Веб-браузер снова отправляет три сегмента TCP, снова по 1000 байт каждый, снова с легко запоминающимися порядковыми номерами. Однако в этом примере второй сегмент TCP не может пройти через сеть.
Рисунок указывает на три набора идей, лежащих в основе того, как думают два хозяина. Во-первых, справа сервер понимает, что он не получил все данные. Два полученных сегмента TCP содержат байты с номерами 10001999 и 30003999. Очевидно, сервер не получил байты, пронумерованные между ними. Затем сервер решает подтвердить все данные вплоть до потерянных, то есть отправить обратно сегмент с полем подтверждения, равным 2000.
Получение подтверждения, которое не подтверждает все данные, отправленные на данный момент, заставляет хост-отправитель повторно отправить данные. ПК слева может подождать несколько секунд, чтобы убедиться, что другие подтверждения не поступят (используя таймер, называемый таймером повторной передачи), но вскоре решит, что сервер сообщает: "Мне действительно нужно 2000 - отправьте его повторно". ПК слева делает это, как показано на пятом из шести сегментов TCP на рисунке.
Наконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. В этом случае сервер получил повторно отправленный второй сегмент TCP (данные с порядковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). Следующее поле подтверждения сервера подтверждает данные в обоих этих сегментах с полем подтверждения, равным 4000.
Управление потоком с использованием окон
TCP реализует управление потоком, используя концепцию окна, которая применяется к количеству данных, которые могут быть ожидающими подтверждения в любой момент времени. Концепция окна позволяет принимающему хосту сообщать отправителю, сколько данных он может получить прямо сейчас, давая принимающему хосту способ замедлить или ускорить отправляющий хост. Получатель может перемещать размер окна вверх и вниз (это называется скользящим окном или динамическим окном), чтобы изменить объем данных, который может отправить хост-отправитель.
Механизм раздвижного окна имеет больше смысла на примере. В примере, показанном на рисунке 9, используются те же основные правила, что и в примерах на нескольких предыдущих рисунках. В этом случае ни один из сегментов TCP не содержит ошибок, и обсуждение начинается на один сегмент TCP раньше, чем на предыдущих двух рисунках.
Начнем с первого сегмента, отправленного сервером на ПК. Поле Acknowledgment должно быть вам знакомо: оно сообщает ПК, что сервер ожидает следующий сегмент с порядковым номером 1000. Новое поле, поле окна, установлено на 3000. Поскольку сегмент передается на ПК, это значение сообщает ПК, что ПК может послать не более 3000 байтов по этому соединению до получения подтверждения. Итак, как показано слева, ПК понимает, что может отправлять только 3000 байтов, и прекращает отправку, ожидая подтверждения, после отправки трех 1000-байтовых сегментов TCP.
Продолжая пример, сервер не только подтверждает получение данных (без потерь), но и решает немного увеличить размер окна. Обратите внимание, что второе сообщение, идущее справа налево на рисунке, на этот раз с окном 4000. Как только ПК получает этот сегмент TCP, ПК понимает, что он может отправить еще 4000 байтов (окно немного больше, чем предыдущее значение).
Обратите внимание, что хотя на последних нескольких рисунках показаны примеры с целью объяснения того, как работают механизмы, из этих примеров может сложиться впечатление, что TCP заставляет хосты сидеть и долго ждать подтверждения. TCP не хочет заставлять хост-отправитель ждать отправки данных. Например, если подтверждение получено до того, как окно будет исчерпано, начинается новое окно, и отправитель продолжает отправлять данные до тех пор, пока текущее окно не будет исчерпано. Часто в сети, где мало проблем, мало потерянных сегментов и небольшая перегрузка, окна TCP остаются относительно большими, а узлы редко ждут отправки.
Закрепим самое важное про TCP и UDP в следующей статье.
Автоматизировать свою IP – АТС Asterisk с каждым днем всё больше и больше нам приносит невероятное удовольствие. Поэтому, сегодня хотим вам поведать о том, как сократить расходы на звонки сотрудников в командировках, или просто находящихся вне офиса с помощью модуля FreePBX - DISA
/p>
Что такое DISA?
Представьте – выходной день, вы находитесь у себя на даче и спокойно поливаете свои любимые бархатцы на клумбе. Вдруг на телефон приходит смс – сообщение, о том, что один из самых прибыльных ваших клиентов из города Владивосток звонил, и не смог дозвониться. Что – то срочное, подумали вы, надо бы перезвонить. Но сколько будет стоить звонок в столицу приморского края? Интернета нет на ближайшие 20 километров, и позвонить через софтфон не получится. Тут на помощь приходит модуль DISA.
Взяв руки свой мобильный телефон, вы набираете номер вашей офисной IP – АТС Asterisk. Из голосового меню, нажимаете спасительные цифры 0897 и попадаете в сам модуль. Приятный голос спрашивает, не могли бы вы ввести пин – код, и, конечно, вы набираете на клавиатуре 384701. Гудок. Вы набираете номер клиента во Владивостоке. Через несколько секунд на том конце трубке раздается голос вызываемого абонента.
Скажем прямо, клиент был приятно удивлен, что в выходной день вы позвонили ему из офиса (у него определился номер вашей офисной IP – АТС Asterisk). Вы быстро решили все вопросы и вернулись.
Хотите такой же функционал? Сейчас расскажем как его настроить.
Настройка модуля DISA
Переходим к настройке модуля. Перейдите во вкладку Applications -> DISA. Нажмите на кнопку + Add DISA
Перед нами откроется форма настройки. Разберемся конкретно по каждому из пунктов:
DISA Name - название DISA. Создавайте названия, которые помогут вам проще понимать для чего создавалась конкретная опция, чтобы избежать путаницы в будущем.
PIN - при попадании на DISA, у пользователя будет запрошено ввести пароль, указанный в данном поле.
Обязательно создавайте PIN на DISA.Потенциально, злоумышленник, который получит доступ к этому модулю, сможет совершать звонки с телефона вашей компании. Это могут быть как финансовые, так и репутационные риски.
Response Timeout - если вы укажите номер, который не будет подходить по формату, то система будет ожидать время, указанное в данном поле, а после, разорвет соединение. По умолчанию 10 секунд. .
Digit Timeout - время, которое система отводит на ввод 1 цифры вызываемого номера. Например, когда номер будет полностью набран, лишь через 5 секунд DISA совершит на него звонок.
Call Recording - записывать ли звонки, совершаемые через модуль DISA.
Require Confirmation - запрашивать ли подтверждение о начале работы с модулем до того, как запрашивать пароль.
Caller ID -не обязательное поле. При совершении вызовов, система может подставлять определенный CallerID. Например, это может пригодиться для сбора статистики. Формат вода таков: "Имя" <123456789>
Context - в этом поле, вы можете указать контекст обработки исходящего от АТС вызова. Советуем оставить это поле по умолчанию – "from – internal"
Allow Hangup - позволяет завершить новый вызов с помощью нажатий сервисного кода (**)
По окончанию настроек, нажмите Submit и затем Apply Config. В списке настроек модуля появится наш новый DISA:
Настройка доступа к DISA из IVR
Перейдем к настройке доступа к DISA из IVR. Как мы сказали ранее, для доступа к модулю мы будем звонит на голосовое меню и набирать 0897. Итак, переходим в вкладку Applications -> IVR и начинаем редактировать наше существующее IVR – меню. Листаем в самый низ,до пункта IVR Entries и делаем настройку, как указано ниже:
Сохраняем конфигурацию. Готово, теперь мы будем экономить на звонках даже находясь в командировка, или на отдыхе.