По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
При первичной настройке Asterisk или дальнейшей отладке очень часто может возникнуть потребность в совершении звонка без использования физического телефона или софтфона.
К примеру, изменились настройки фаерволла, транка или экстеншена и необходимо при каждом изменении совершать тестовые исходящие звонки. Подобную функцию выполняет команда «Dial», но в данном случае необходимо создать так называемый «call» файл, просто текстовый файл, который содержит следующие строки:
Channel: SIP/flowroute/84951112233
MaxRetries: 1
RetryTime: 60
WaitTime: 30
Context: test_forcall
Extension: 1
Priority: 1
Set: variablename=variablevalue
CallerID: Test <84954445566>
Первая строчка определяет канал, который будет использоваться для совершения вызова и экстеншен, в данном случае – любой номер телефона, в данном примере 84951112233. Следующая строка – параметр, определяющий сколько раз Asterisk произведет попыток вызова на данный номер. Далее – временной интервал между вызовами и начальное время ожидания перед первым звонком. Параметр «Context» отвечает соответственно за контекст, через который пойдет вызов, экстеншен и приоритет.
Кроме того, можно настроить CallerID (номер вызывающего абонента), в данном случае - Test <84954445566>.
Для того, что бы Астериск прочел и использовал .call файл, его необходимо поместить в директорию /var/spool/asterisk/outgoing/ - важно, что он должен быть именно перемещён в неё с помощью команды «mv», а не создан в самой директории. Кроме того, необходимо, что бы Астериск имел достаточно прав для того, чтобы удалить этот файл после использования.
Суммируя вышесказанное, необходимо:
Создать .call файл с необходимым наполнением
Настроить необходимые разрешения с помощью команды chmod
chmod 777 callfile.call
3. Переместить файл в директорию для его исполнения командой mv
mv callfile.call /var/spool/asterisk/outgoing/
Так как файл совершает вызов с использованием контекста, экстеншена и приоритета, ниже приведён пример контекста, который использовался для данного примера:
[test_forcall]
exten => 1,1,Answer()
exten => 1,n,Record(/home/test/asterisk_sounds/rec/incoming_call.gsm,5,30)
exten => 1,n,Playback(vm-goodbye)
exten => 1,n,Hangup()
В описании данного контекста нет никакой специфики, кроме того что необходимо зарегистрировать экстеншен с номером 1, так как через него идет вызов (.call файл в начале статьи).
Если изменить дату создания .call файла, то Asterisk совершит вызов в указанный момент. Для этого используется команда touch, как указано ниже.
touch -t YYYYMMDDHHMM.SS filename // формат использования команды
touch -t echo date('YmdHi'); .00 callfile.call // изменение даты файла так, что Asterisk совершит вызов echo date('d');
function getMonthRus($num_month = false){
if(!$num_month){
$num_month = date('n');
}
$monthes = array(
1 => 'января', 2 => 'февраля', 3 => 'марта',
4 => 'апреля', 5 => 'мая', 6 => 'июня',
7 => 'июля', 8 => 'августа',9 => 'сентября',
10 => 'октября', 11 => 'ноября',
12 => 'декабря'
);
$name_month = $monthes[$num_month];
return $name_month;
}
echo getMonthRus(); echo date('Y'); года в echo date('H:i'); .Это если Вы решите позвонить прямо сейчас :)
Если необходимо проверить список файлов, которые ожидают исполнения, необходимо ввести следующую команду:
ls --full-time /var/spool/asterisk/outgoing/
Таким образом, можно генерировать файлы для совершения автодозвона в целях тестирования, в любое необходимое время – к примеру, можно проверять работоспособность АТС в критичные моменты.
Телефонная станция Cisco Unified Communications Manager (далее CUCM) является системой обработки вызовов на базе программного обеспечения, разработанного компанией Cisco Systems. Первая версия CUCM была анонсирована в 1997 году, под названием CallManager 1.0. На момент написания статьи последняя и самая актуальная версия - CUCM 10.5. CUCM работает с такими элементами сетей передачи голоса поверх протокола IP (VoIP) как: шлюзы, телефонные аппараты, мосты для конференцсвязи, голосовая почта, видеоконференцсвязью и многими другими.
Чаще всего, для работы с оконечными устройствами CUCM использует собственный протокол сигнализации, разработанный компанией Cisco Systems под названием Skinny Client Control Protocol (SCCP). Помимо собственных разработок, CUCM поддерживает и открытые стандарты, такие как H.323, Media Gateway Control Protocol (MGCP) или Session Initiation Protocol (SIP). Схема работы CUCM приведена рисунке ниже:
На рисунке схематично обозначена схема работы CUCM в рамках корпоративной сети. Пунктирными линиями обозначены Real-time Transport Protocol (RTP) потоки, которые переносят в поле информационной (полезной) нагрузки медиа – данные разговора. Особое внимание следует обратить на расположение линий направления RTP – они проходят напрямую от телефонного аппарата до телефонного аппарата. Телефонная станция CUCM контролирует телефонную сигнализацию, на данном примере, по протоколам SIP/SCCP. Это означает, что если во время разговора CUCM перестанет работать, разговор между абонентами будет продолжен, но такие функции как удержание, трансфер, отбой вызова и другие функции управления вызовом будут не доступны.
Цифровая телефонная станция CUCM выполнена на базе операционной системы Linux с закрытыми правами администратора и с предустановленной базой данных IBM Informix. В совокупности, такой вид операционной системы носит название VOS (voice operating system). Продукт устанавливается пакетом, сначала VOS, а затем само программное обеспечение.
Интерфейс управления цифровой телефонной станцией CUCM выполнен как WEB – приложение, доступное через протокол HyperText Transfer Protocol (HTTP). Интерфейс имеет удобную навигацию по вкладкам, пять разных Graphical user interface (GUI) для сегментации функций администрирования и возможность предоставлять уровни доступа администраторам. Основной интерфейс проиллюстрирован на рисунке:
Как было сказано ранее, CUCM имеет пять различных панелей администрирования:
Cisco Unified CM Administration
Cisco Unified Reporting
Disaster Recovery System
Cisco Unified Serviceability
Cisco Unified OS Administration
Интерфейс Cisco Unified CM Administration – основной интерфейс администратора. Здесь можно настраивать системные настройки, параметры маршрутизации вызовов, настройка медиа – ресурсов, таких как Music On Hold (MOH), параметров интеграции с другими продуктами компании Cisco Systems, конфигурацию телефонных аппаратов, шлюзов, «привратников» (gatekeepers), администрирование групп пользователей и многие другие настройки.
Интерфейс Cisco Unified Reporting обеспечивает доступ к отчетам о работе телефонной станции. Данная консоль отчетности собирает данные с различных системных журналов и предоставляет эту информацию в просто для администратора виде.
Интерфейс Disaster Recovery System (DRS) создан для резервирования конфигурации, или как принято говорить «бэкапа» телефонной станции CUCM. Бэкап может происходить как локально на сервер, так и на удаленные площадки по протоколу SSH File Transfer Protocol (SFTP).
Графический интерфейс Cisco Unified Serviceability предоставляет наблюдение и контроль работоспособности телефонной станции, включая в себя такие настройки как конфигурацию опций оповещения о проблемах в работе CUCM, систему трассировки для обнаружения причин проблем, богатое меню инструментов, в котором можно смотреть отчеты Call Detail Record (CDR). Данный интерфейс позволяет настроить параметры Simple Network Management Protocol (SNMP), созданного для управления и контроля.
Последним в списке интерфейсов значится Cisco Unified OS Administration. Он предназначен для мониторинга аппаратной платформы и различных системных статистических данных, таких как: загруженность центрального процессора, свободного пространства жестких дисков, мониторинга системного времени, информации об IP – адресах, работы в рамках протокола Internet Control Message Protocol (ICMP).
Еще один немаловажный интерфейс, это Command Line Interface (CLI) – консоль. Он удобен для перезагрузки сервиса, например, при недоступности основного графического интерфейса через порт 8080.
Cisco UCM - решение для крупного бизнеса или государственного учреждения
Телефонная станция CUCM это гибкое и масштабируемое решение. Одним из важных преимуществ является возможность кластеризации серверов, или другими словами объединения. В общем случае, в одном кластере может работать до 20 серверов. Среди них только 8 серверов занимаются обработкой вызовов, остальные, это дополнительные сервера предназначенные для расширения функционала кластера (сервисы музыка на удержании, Trivial File Transfer Protocol (TFTP) сервер и многие другие). Работая в кластере, сервера CUCM могут работать с 30 000 абонентами.
При работе в кластере различают два типа серверов – «паблишер» (публикатор) и «сабскрайбер» (подписчики). В данной модели один сервер, который является «паблишером» дублирует базу данных на все остальные сервера, которые являются «сабскрайберами. Схема работы кластера показана на рисунке:
Большое преимущество IP PBX CUCM – это возможность развернуть сервер в виртуальной среде.
Системы виртуализации появились после того, как соотношение эффективности использования одного аппаратного сервера к стоимости данного сервера, с каждым днем стремилось к меньшему и меньшему значению. Виртуализация позволяет делить аппаратные ресурсы сервера между различными приложениями. Например, предприятие покупает аппаратный сервер, для конкретной цели. Системный администратор данной организации устанавливает на него операционную систему на базе Windows, а затем, приложение, для которого был куплен этот сервер. Спустя некоторое время, у организации появилось требование для внедрения в корпоративный контур бизнес – приложений, которые работают на базе Linux. За неимением систем виртуализации, компания сталкивается с новой проблемой – покупкой нового сервера, по причине того, что разнородные операционные системы не смогут существовать на одном и том же аппаратном ресурсе.
При наличии системы виртуализации, компания может установить специальное программное обеспечение «гипервизор» на имеющийся Windows сервер. Гипервизор позволит изолировать друг от друга различные операционные системы на одном и том же сервере, обеспечит безопасность, защиту, целостность данных, предоставит централизованное и удобное управление виртуальным серверным ресурсом компании, а так же множество встроенных средств и инструментов автоматизации, предназначенных для автоматического резервирования данных и конфигурации серверов. Предприятия решит поставленную задачу, оптимизировав расходы на аппаратные сервера.
Преимущества
Выделим основные конкурентные преимущества систем виртуализации
Экономия расходов предприятия на покупке дополнительного сервера.
Экономия места в телекоммуникационной стойке.
Снижение тепловыделения и электропотребления.
«Бесшовное» обновление операционной системы сервера, позволяющее не производить перезагрузку и не останавливать работу приложения.
Централизация управления и администрирования серверов.
Гибкая настройка конфигурации, автоматического резервирования. Создание отказоустойчивости внутренними средствами программного обеспечения гипервизора.
Общий принцип работы систем виртуализации проиллюстрирован на рисунке: Виртуализация CUCM
Ведущие производители систем виртуализации, это такие компании как VMware, Hyper-V, Xen и Citrix Systems.
В данной статье рассматривается вопросы настройки и использования командной оболочки.
Вопросы:
Установка переменных во время входа в систему или при запуске оболочки.
Написание bash-сценариев для часто используемых цепочек команд.
Управление структурой каталогов для новых пользователей.
Настройка корректных путей поиска команд.
Командная оболочка в Unix системах называется Shell – это командный интерпретатор, который используется во всех Unix подобных операционных системах. Оболочек огромное количество. Одной из основных оболочек является оболочка BASH или Bourne-again-shell (Еще одна оболочка Борна). Данная оболочка самая распространенная оболочка Unix, которая используется по умолчанию практически во всех дистрибутивах Linux. Все, о чем будет написано далее справедливо для большинства дистрибутивов Linux. Есть небольшой нюанс с Ubuntu.
Есть вот такая картинка по профилям. Значок ~ в данном случае означает домашнюю папку пользователя по умолчанию. Например, /home/john.
Существует папка /etc/profile в ней лежат настройки глобального профиля. Такой профиль, который будет применяться для всех пользователей на данной машине, которые запускают командную оболочку. Функционал у него достаточно большой, но в первую очередь он грузит все что есть в /etc/profile.d и настройки глобального пользователя /etc/bash.bashrc и /etc/bashrc. Получается так, что ищется файл bash.bashrc или bashrc файлы, т.к в разных дистрибутивах разные файлы и грузит то, что он нашел. В документации по Linux написано, если запускается инициализационный скрипт при входе в систему, т.е пользователь заходит в систему, то отрабатывает левая часть картинки, если запускается оболочка вне контекста пользователя, то правая часть.
Если пользователь залогинился в систему, то помимо того, что отрабатывает папка /etc/profile.d начинается проверка в домашнем каталоге пользователя наличие файлов ~/.bash_profile, ~/.bash_login, ~/.profile. В разных дистрибутивах по-разному называется локальный профиль пользователя. В Ubuntu файл ~/.profile просто ссылит на ~/.bashrc, который так же лежит в домашней папке пользователя. Т.е у нас по порядку инициализационный скрипт ищет, как указанно в левой части картинки. Точкой у Ubuntu обозначаются скрытые файлы.
Вот этот файл ~/.bashrc – это настройки конкретного пользователя, настройки оболочки. Файл /etc/bashrc – это настройки глобального пользователя, настройки для всех пользователей.
Суть процесса: оболочка bash используется, как интерактивная оболочка входа в систему. Данная оболочка вызывает команды из файла /etc/profile, если он существует. Далее она по порядку начинает обрабатывать файлы ~/.bash_profile, ~/.bash_login, ~/.profile. И еще есть такой файл в home директории ~/.bash_logout – он отрабатывает при выходе из системы, что следует из его названия.
Есть второй сценарий, использование интерактивной оболочки bash, без входа в систему, то читаются файлы /etc/bash.bashrc и /etc/bashrc.
Мы можем посмотреть, что происходит при запуске оболочки. Для начала найдем файл /etc/profile.
Из картинки мы видим, что данный файл грузит /etc/bash.bashrc, в некоторых дистрибутивах это просто /etc/bashrc. И затем он выполняет из папки /etc/profile.d/*.sh, т.е все скрипты. Об этом можно прочитать в комментарии, всего два действия.
Посмотрим файл cat /etc/bash.bashrc.
Данный файл определяет поведение командной строки, он определяет глобальный профиль пользователей. Все, что в нем указанно справедливо для всех пользователей. Данный файл запускает различные псевдонимы и глобальные функции, различные настройки.
В каталоге /etc, есть папка profile.d, в ней могут находиться различные скрипты и они будут запускаться.
Теперь посмотрим, что у нас в домашней папке, в ней лежат настройки конкретного пользователя, который работает в оболочке. Переходим в домашнюю директорию cd ~, смотрим какие файлы там находятся.
Смотрим очередность запуска файлов и видим, что следующий файл, который запустится, будет ~/.profile. он содержит настройки конкретного пользователя. Посмотрим, что в нем есть cat ~/.profile.
В нем несколько переменных и он ссылит на файл ~/.bashrc. Это особенность Ubuntu. И в файле ~/.bashrc хранятся все настройки.
Он достаточно большой. В нем пишутся настройки истории, как происходит обновление, псевдонимы, цветовые настройки.
Можно посмотреть файл ~/.bash_logout.
В данном файле нет ничего особенного, просто, когда кто-то выходит экран в целях безопасности очищается.
Посмотрим, как создается структура каталогов для новых пользователей. Есть такая папка в /etc/skel/. Если мы туда перейдем и посмотрим, что в ней находиться.
Как вы видите в папке есть несколько файлов. В ней содержится все, то что будет добавляться в домашнюю папку нового пользователя. Если мы хотим пользователю, что-то добавить в его домашнюю папку, мы можем создать в данной папке файл или директорию. И у всех новых пользователей данные папки или файлы будут появляться.