По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Привет! Недавно мы рассказывали про то как подружить телефоны Cisco с IP-АТС Asterisk на примере телефона Cisco 7811. Там мы рассматривали базовую конфигурацию, так что теперь затронем дополнительную, но важную функцию – отображение пропущенных звонков. Также вместе с этим включим журнал звонков, который будет показывать исходящие и принятые вызовы. Конфигурация Возьмем наш рабочий XML файл конфигурации (SEP[MAC_ADDRESS].cnf.xml) который лежит у нас на TFTP сервере. Для того чтобы наш телефон начал отображать пропущенные звонки нужно внести следующие изменения. Во-первых, нужно добавить строчку lineIndex="1" в тег line button в той линии, на которой необходимо включить отображение пропущенных: <line button="1" lineIndex="1"> Далее в конец нужно добавить сточки для добавления сервиса: <phoneServices> <provisioning>0</provisioning> <phoneService type="1" category="0"> <name>Missed Calls</name> <url>Application:Cisco/MissedCalls</url> <vendor></vendor> <version></version> </phoneService> </phoneServices> И наконец необходимо добавить строчку для включения логирования пропущенных звонков перед тегом <commonProfile>: <missedCallLoggingOption>1</missedCallLoggingOption> 1 включает логирование на линии, 0 – выключает. Если у нас на телефоне несколько линий, то для них все необходимо указать в этой строке. Например, если у нас три линии и нам нужно включить логирование на 1й и на 3й, то мы в теге укажем 101. После этого перезагружаем телефон, он у нас должно скачать новый файл конфигурации, и после этого можно пробовать тестировать отображение пропущенных звонков. При пропущенном звонке он будет отображаться на экране телефона: Все пропущенные звонки можно посмотреть, нажав на появившуюся кнопку “Недавние” Вот такими манипуляциями можно заставить отображать пропущенные звонки на телефоне Cisco 7811 при подключении к Asterisk. А как теперь включить отображение всех остальных звонков и получить рабочий журнал? Все просто – добавляем следующие сточки в конфиг в раздел phoneServices </phoneService> <phoneService type="1" category="0"> <name>Received Calls</name> <url>Application:Cisco/ReceivedCalls</url> <vendor></vendor> <version></version> </phoneService> <phoneService type="1" category="0"> <name>Placed Calls</name> <url>Application:Cisco/PlacedCalls</url> <vendor></vendor> <version></version> </phoneService> Готово! Таким образом мы получили абсолютно рабочий журнал вызовов на телефоне Cisco 7811
img
Буферизация пакетов для работы с перегруженным интерфейсом кажется прекрасной идеей. Действительно, буферы необходимы для обработки трафика, поступающего слишком быстро или несоответствия скорости интерфейса - например, при переходе от высокоскоростной LAN к низкоскоростной WAN. До сих пор это обсуждение QoS было сосредоточено на классификации, приоритизации и последующей пересылке пакетов, помещенных в очередь в этих буферах, в соответствии с политикой. Максимально большой размер буферов кажется хорошей идеей. Теоретически, если размер буфера достаточно велик, чтобы поставить в очередь пакеты, превышающие размер канала, все пакеты в конечном итоге будут доставлены. Однако, как большие, так и переполненные буферы создают проблемы, требующие решения. Когда пакеты находятся в буфере, они задерживаются. Некоторое количество микросекунд или даже миллисекунд добавляется к пути пакета между источником и местом назначения, пока они находятся в буфере, ожидая доставки. Задержка перемещения является проблемой для некоторых сетевых разговоров, поскольку алгоритмы, используемые TCP, предполагают предсказуемую и в идеале небольшую задержку между отправителем и получателем. В разделе активного управления очередью вы найдете различные методы управления содержимым очереди. Некоторые методы решают проблему переполненной очереди, отбрасывая достаточно пакетов, чтобы оставить немного места для вновь поступающих. Другие методы решают проблему задержки, поддерживая небольшую очередь, минимизируя время, которое пакет проводит в буфере. Это сохраняет разумную задержку буферизации, позволяя TCP регулировать скорость трафика до скорости, соответствующей перегруженному интерфейсу. Управление переполненным буфером: взвешенное произвольное раннее обнаружение (WRED) Произвольное раннее обнаружение (RED) помогает нам справиться с проблемой переполненной очереди. Буферы не бесконечны по размеру: каждому из них выделено определенное количество памяти. Когда буфер заполняется пакетами, новые поступления отбрасываются. Это не сулит ничего хорошего для критического трафика, такого как VoIP, от которого нельзя отказаться, не повлияв на взаимодействие с пользователем. Способ решения этой проблемы - убедиться, что буфер никогда не будет полностью заполнен. Если буфер никогда не заполняется полностью, то всегда есть место для приема дополнительного трафика. Чтобы предотвратить переполнение буфера, RED использует схему упреждающего отбрасывания выбранного входящего трафика, оставляя места открытыми. Чем больше заполняется буфер, тем больше вероятность того, что входящий пакет будет отброшен. RED является предшественником современных вариантов, таких как взвешенное произвольное раннее обнаружение (WRED). WRED учитывает приоритет входящего трафика на основе своей отметки. Трафик с более высоким приоритетом будет потерян с меньшей вероятностью. Более вероятно, что трафик с более низким приоритетом будет отброшен. Если трафик использует какую-либо форму оконного транспорта, например, такую как TCP, то эти отбрасывания будут интерпретироваться как перегрузка, сигнализирующая передатчику о замедлении. RED и другие варианты также решают проблему синхронизации TCP. Без RED все входящие хвостовые пакеты отбрасываются при наличии переполненного буфера. Для трафика TCP потеря пакетов в результате отбрасывания хвоста приводит к снижению скорости передачи и повторной передаче потерянных пакетов. Как только пакеты будут доставлены снова, TCP попытается вернуться к более высокой скорости. Если этот цикл происходит одновременно во многих разных разговорах, как это происходит в сценарии с отключением RED-free, интерфейс может испытывать колебания использования полосы пропускания, когда канал переходит от перегруженного (и сбрасывания хвоста) к незагруженному и недоиспользованному, поскольку все д throttled-back TCP разговоры начинают ускоряться. Когда уже синхронизированные TCP-разговоры снова работают достаточно быстро, канал снова становится перегруженным, и цикл повторяется. RED решает проблему синхронизации TCP, используя случайность при выборе пакетов для отбрасывания. Не все TCP-разговоры будут иметь отброшенные пакеты. Только определенные разговоры будут иметь отброшенные пакеты, случайно выбранные RED. TCP-разговоры, проходящие через перегруженную линию связи, никогда не синхронизируются, и колебания избегаются. Использование каналов связи более устойчиво. Управление задержкой буфера, Bufferbloat и CoDel Здесь может возникнуть очевидный вопрос. Если потеря пакетов - это плохо, почему бы не сделать буферы достаточно большими, чтобы справиться с перегрузкой? Если буферы больше, можно поставить в очередь больше пакетов, и, возможно, можно избежать этой досадной проблемы потери пакетов. Фактически, эта стратегия больших буферов нашла свое применение в различных сетевых устройствах и некоторых схемах проектирования сети. Однако, когда перегрузка канала приводит к тому, что буферы заполняются и остаются заполненными, большой буфер считается раздутым. Этот феномен так хорошо известен в сетевой индустрии, что получил название: bufferbloat. Bufferbloat имеет негативный оттенок, потому что это пример слишком большого количества хорошего. Буферы - это хорошо. Буферы предоставляют некоторую свободу действий, чтобы дать пачке пакетов где-нибудь остаться, пока выходной интерфейс обработает их. Для обработки небольших пакетов трафика необходимы буферы с критическим компромиссом в виде введения задержки, однако превышение размера буферов не компенсирует уменьшение размера канала. Канал имеет определенную пропускную способность. Если каналу постоянно предлагается передать больше данных, чем он может передать, то он плохо подходит для выполнения требуемой от него задачи. Никакая буферизация не может решить фундаментальную проблему пропускной способности сети. Увеличение размера буфера не улучшает пропускную способность канала. Фактически, постоянно заполненный буфер создает еще большую нагрузку на перегруженный интерфейс. Рассмотрим несколько примеров, противопоставляющих протоколов Unacknowledged Datagram Protocol (UDP) и Transmission Control Protocol (TCP). В случае VoIP-трафика буферизованные пакеты прибывают с опозданием. Задержка чрезвычайно мешает голосовой беседе в реальном времени. VoIP - это пример трафика, передаваемого посредством UDP через IP. UDP-трафик не подтверждается. Отправитель отправляет пакеты UDP, не беспокоясь о том, доберутся ли они до места назначения или нет. Повторная передача пакетов не производится, если хост назначения не получает пакет UDP. В случае с VoIP - здесь важно, пакет приходит вовремя или нет. Если это не так, то нет смысла передавать его повторно, потому что уже слишком поздно. Слушатели уже ушли. LLQ может прийти вам в голову как ответ на эту проблему, но часть проблемы - это слишком большой буфер. Для обслуживания большого буфера потребуется время, вызывающее задержку доставки трафика VoIP, даже если LLQ обслуживает трафик VoIP. Было бы лучше отбросить VoIP-трафик, находящийся в очереди слишком долго, чем отправлять его с задержкой. В случае большинства приложений трафик передается по протоколу TCP через IP, а не по протоколу UDP. TCP - протокол подтверждений. Отправитель трафика TCP ожидает, пока получатель подтвердит получение, прежде чем будет отправлен дополнительный трафик. В ситуации bufferbloat пакет находится в переполненном, слишком большом буфере перегруженного интерфейса в течение длительного времени, задерживая доставку пакета получателю. Получатель получает пакет и отправляет подтверждение. Подтверждение пришло к отправителю с большой задержкой, но все же пришло. TCP не заботится о том, сколько времени требуется для получения пакета, пока он туда попадает. И, таким образом, отправитель продолжает отправлять трафик с той же скоростью через перегруженный интерфейс, что сохраняет избыточный буфер заполненным и время задержки увеличивается. В крайних случаях отправитель может даже повторно передать пакет, пока исходный пакет все еще находится в буфере. Перегруженный интерфейс, наконец, отправляет исходный буферизованный пакет получателю, а вторая копия того же пакета теперь находится в движении, что создает еще большую нагрузку на уже перегруженный интерфейс! Эти примеры демонстрируют, что буферы неподходящего размера на самом деле не годятся. Размер буфера должен соответствовать как скорости интерфейса, который он обслуживает, так и характеру трафика приложения, который может проходить через него. Одна из попыток со стороны сетевой индустрии справиться с большими буферами, обнаруженными вдоль определенных сетевых путей, - это контролируемая задержка, или CoDel. CoDel предполагает наличие большого буфера, но управляет задержкой пакетов, отслеживая, как долго пакет находится в очереди. Это время известно, как время пребывания. Когда время пребывания пакета превысило вычисленный идеал, пакет отбрасывается. Это означает, что пакеты в начале очереди-те, которые ждали дольше всего-будут отброшены до пакетов, находящихся в данный момент в хвосте очереди. Агрессивная позиция CoDel в отношении отбрасывания пакетов позволяет механизмам управления потоком TCP работать должным образом. Пакеты, доставляемые с большой задержкой, не доставляются, а отбрасываются до того, как задержка станет слишком большой. Отбрасывание вынуждает отправителя TCP повторно передать пакет и замедлить передачу, что очень желательно для перегруженного интерфейса. Совокупный результат - более равномерное распределение пропускной способности для потоков трафика, конкурирующих за интерфейс. В ранних реализациях CoDel поставлялся в устройства потребительского уровня без параметров. Предполагаются определенные настройки по умолчанию для Интернета. Они включают 100 мс или меньше времени двустороннего обмена между отправителями и получателями, а задержка 5 мс является максимально допустимой для буферизованного пакета. Такая конфигурация без параметров упрощает деятельность поставщиков сетевого оборудования потребительского уровня. Потребительские сети являются важной целью для CoDel, поскольку несоответствие высокоскоростных домашних сетей и низкоскоростных широкополосных сетей вызывает естественную точку перегрузки. Кроме того, сетевое оборудование потребительского уровня часто страдает от слишком большого размера буферов.
img
OpenSIPS - это SIP-прокси-сервер с открытым исходным кодом операторского уровня, используемый для сигнализации SIP, и может обрабатывать все типы операций SIP. Он используется многими провайдерами телекоммуникационных услуг, телефонии и операторами связи из-за его надежности и производительности. Итак, если вы, ребята, хотите обрабатывать тысячи одновременных вызовов и SIP-сессий, тогда OpenSIPS - ваш выход. Существует множество различных сценариев, в которых openSIPS может хорошо играть в вашей инфраструктуре. Некоторые из них: OpenSIPS как SIP Edge Proxy OpenSIPS в качестве среднего регистратора или главного сервера регистрации OpenSIPS как входящий и исходящий шлюз OpenSIPS как балансировщик нагрузки И многое другое Примечание: OpenSIPS обрабатывает только SIP-сигнализацию, а не медиа. Для обработки мультимедиа вы можете использовать RTPPROXY или RTPENGINE. Как установить OpenSIPS 3 из исходного кода на Debian 9 Являясь модульным, мощным и гибким SIP-сервером, OpenSIPS можно установить на все основные дистрибутивы Linux. В этом уроке мы будем использовать Debian 9 в качестве базовой операционной системы. Итак, вот шаги, которым мы должны следовать, чтобы запустить наш первый экземпляр OpenSIPS и запустить его: Установите все необходимые зависимости Склонируйте последнюю версию репозитория OpenSIPS Скомпилируйте это Создайте файлы конфигурации Настройте сервис OpenSIPS Настройте OpenSIPS-CLI Создайте базу данных OpenSIPS Запустите сервер OpenSIPS 3 Поэтому, прежде чем мы начнем устанавливать зависимости, нам нужно сначала понять, как мы будем настраивать наш экземпляр OpenSIPS. Что ж, базовому серверу OpenSIPS не нужно много библиотек или зависимостей, но мы будем использовать панель управления OpenSIPS позже вместе с поддержкой MySQL, поэтому мы установим некоторые другие зависимости, чтобы мы могли легко скомпилировать некоторые дополнительные модули OpenSIPS. Шаг 1: Установка всех зависимостей Давайте обновим все списки пакетов, которые у нас есть. apt update Теперь давайте установим все зависимости вместе с сервером MySQL (MariaDB). apt install git gcc bison flex make openssl perl libdbi-perl libdbd-mysql-perl libdbd-pg-perl libfrontier-rpc-perl libterm-readline-gnu-perl libberkeleydb-perl mysql-server ssh libxml2 libxml2-dev libxmlrpc-core-c3-dev libpcre3 libpcre3-dev subversion libncurses5-dev git ngrep libssl-dev net-tools После того, как мы установили все эти пакеты, нам нужно установить пакеты devel для сервера MySQL. Для MariaDB: apt install libmariadbclient-dev-compat sudo Для сервера MySQL: apt install libmysqlclient-dev Теперь нам нужно установить зависимости для сервера micro httpd, который OpenSIPS будет использовать для прослушивания соединений JSON RPC. apt install libmicrohttpd-dev pkg-config libjsoncpp-dev libjson-c-dev ln -s /usr/include/jsoncpp/json/ /usr/include/json wget http://ftp.us.debian.org/debian/pool/main/j/json-c/libjson-c3_0.12.1-1.1_amd64.deb dpkg -i libjson* Все зависимости должны быть установлены сейчас, и теперь мы готовы клонировать исходный код openSIPS 3. Примечание: не забудьте установить имя пользователя и пароль root для msyql, используя - mysql_secure_installation Шаг 2: Клонирование репозитория OpenSIPS Мы будем клонировать последнюю версию репозитория OpenSIPS 3 в /usr/src cd /usr/src ; git clone https://github.com/OpenSIPS/opensips.git -b 3.0 opensips-3.0 Шаг 3: Скомпилируйте исходный код Чтобы сначала скомпилировать модули OpenSIPS или исходный код, перейдите в каталог opensips-3.0. cd /usr/src/opensips-3.0 Теперь наберите make menuconfig Откроется главное меню конфигурации OpenSIPS. Из этого меню мы можем скомпилировать OpenSIPS и сгенерировать наши конфигурационные скрипты. Поэтому, прежде чем мы скомпилируем, нам нужно включить дополнительный модуль, который нам нужен для поддержки MySQL и JSON. Теперь давайте выберем несколько дополнительных модулей, которые нам нужны. Итак, перейдите к Configure Compile Options -> Configure Excluded Module (Настройка параметров компиляции -> Настройка исключенного модуля). Мы должны выбрать 4 модуля - db_mysql, dialplan, json, httpd Примечание: если вы хотите выбрать или скомпилировать какой-либо другой модуль, обязательно установите его зависимости. Теперь вернитесь, используя клавишу со стрелкой влево и сохраните изменения. И как только мы выберем наши модули для компиляции, тогда просто выберите Compile and Install OpenSIPS Компиляция началась, и если вы правильно установили все зависимости, то ошибок быть не должно. После успешной компиляции вам будет предложено нажать любую клавишу, чтобы вернуться в главное меню. Шаг 4: Генерация скрипта конфигурации OpenSIPS. Скрипт конфигурации OpenSIPS - это мозг сервера OpenSIPS, он контролирует всю маршрутизацию, обработку SIP-трафика, регистрации и почти все операции SIP. Поэтому для нас очень важно создать его из меню конфигурации. После компиляции всех модулей, перейдите к Generate OpenSIPS Script. Мы можем сгенерировать 3 типа скриптов из меню конфигурации: Residential Script - обеспечивает регистрацию пользователя. Trunking Script - Подходит для предоставления услуги транкинга. Он не поддерживает регистрацию. Load-Balancer Script - используется для балансировки нагрузки входящих и исходящих вызовов. Примечание. Эти конфигурационные файлы будут иметь базовую конфигурацию. Вам всегда нужно редактировать эти файлы, чтобы они работали в соответствии с вашим сценарием. Для этой установки мы будем использовать Trunking Script. Теперь перейдите к настройке скрипта Configure Script Выберите функции, которые вы хотите добавить в свой скрипт. После выбора всех необходимых параметров сохраните сценарий и выберите Generate Trunking Script. Это все. Теперь вернитесь и сохраните все изменения - Exit & Save All Changes. Шаг 5: Настройка сервиса OpenSIPS Очень важно понять файловую структуру OpenSIPS и важные каталоги, прежде чем начать работу над ней. Вот некоторые основные каталоги, над которыми мы будем работать во всей этой установке. /usr/local/etc/opensips/ - Каталог файлов конфигурации OpenSIPS по умолчанию /usr/local/lib64/opensips/modules/ - Каталог модулей OpenSIPS /etc/init.d/ - Каталог файлов сервиса OpenSIPS /etc/default/opensips - Файл конфигурации службы OpenSIPS Мы можем найти файл opensips.init и opensips.default в каталоге /usr/src/opensips-3.0/packaging/debian/. Поэтому нам нужно скопировать эти файлы в каталог /etc/init.d/ и /etc/default/. cp /usr/src/opensips-3.0/packaging/debian/opensips.init /etc/init.d/opensips cp /usr/src/opensips-3.0/packaging/debian/opensips.default /etc/default/opensips chmod 755 /etc/init.d/opensips update-rc.d opensips defaults 99 mkdir -p /var/run/opensips Теперь у нас все настроено и готово запустить наш первый сервис OpenSIPS, но прежде чем мы это сделаем, нам нужно скопировать наш файл конфигурации в каталог /usr/local/etc/opensips/, который мы создали из меню конфигурации OpenSIPS. Этот файл конфигурации находится в /usr/src/opensips-3.0/etc/ ls /usr/src/opensips-3.0/etc/ Теперь мы скопируем этот конфигурационный файл транкинга в /usr/local/etc/opensips/ mv /usr/src/opensips-3.0/etc/opensips_trunking* /usr/local/etc/opensips/opensips_trunk.cfg Теперь вы можете видеть, что у нас есть opensips_trunk.cfg в каталоге /usr/local/etc/opensips, и мы будем использовать этот же файл для нашего сервера OpenSIPS, поэтому мы должны указать путь к нему в файле инициализации opensips. Примечание: мы также должны убедиться, что у нас есть правильный двоичный путь OpenSIPS в файле инициализации opensips. nano /etc/init.d/opensips Мы должны добавить путь к скрипту и демону в переменную DAEMON и CFGFILE. Шаг 6: Настройка OpenSIPS-CLI Начиная с OpenSIPS 3, мы будем использовать инструмент OpenSIPS-CLI для управления экземплярами OpenSIPS. Ранее мы использовали для работы со скриптом opensipsctl, но он был удален из OpenSIPS версии 3. Мы будем использовать это приложение для выполнения всех видов различных операций, таких как отправка команд MI, создание базы данных и многое другое. Давайте клонируем репозиторий opensips-cli в /usr/src/ cd /usr/src && git clone https://github.com/OpenSIPS/opensips-cli.git Теперь давайте установим все зависимости, которые нам нужны для этого удобного небольшого приложения. sudo apt install python3 python3-pip python3-dev gcc default-libmysqlclient-dev sudo pip3 install mysqlclient sqlalchemy sqlalchemy-utils pyOpenSSL Как только мы установим все зависимости, пришло время установить OpenSIPS-CLI. cd /usr/src/opensips-cli sudo python3 setup.py install clean После успешной установки мы сможем выполнить команду opensips-cli. Примечание. Когда opensips-cli запускается, она всегда ищет файл opensips-cli.cfg в каталоге /etc/. Если файл отсутствует, она запустится с настройками по умолчанию. Теперь мы создадим файл opensips-cli.cfg в каталоге /etc/. nano /etc/opensips-cli.cfg [opensips-1] log_level: WARNING prompt_name: opensips-cli prompt_intro: Welcome to OpenSIPS at SECUREVOIP prompt_emptyline_repeat_cmd: False history_file: ~/.opensips-cli.history history_file_size: 1000 output_type: pretty-print communication_type: fifo fifo_file: /tmp/opensips_fifo database_path: /usr/src/opensips-3.0/scripts/ database_url: mysql://root:password@localhost database_name: opensips Мы должны добавить вышеуказанный блок в файл opensips-cli.cfg. Вы можете настроить все параметры в файле конфигурации. Синтаксис и значение каждой переменной следующие: [opensips-1] - Имя экземпляра log_level - Уровень сообщений лога prompt_name - Имя оболочки prompt_intro - Приветственное сообщение оболочки history_file - Где хранить историю opensips-cli output_type - Параметры вывода, вы также можете использовать json communication_type - Тип связи - fifo, json database_path - Путь к сценариям базы данных database_url - URL вашей базы данных MySQL database_name - База данных, которая будет использоваться Теперь давайте запустим opensips-cli с нашим новым файлом конфигурации. opensips-cli -i [instance_name] -f [config file] Шаг 7: Создание базы данных OpenSIPS Наконец, пришло время создать базу данных OpenSIPS. Мы будем использовать бэкэнд MySQL, и если вы захотите использовать другой бэкэнд, такой как PostgreSQL, вам, возможно, придется установить некоторые зависимости. Сначала откройте файл opensips-cli и выполните следующие действия: Запустите OpenSIPS-CLI Выполните - database create Введите URL базы данных MySQL Теперь давайте проверим базу данных и таблицы opensips, войдя в MySQL. Примечание. Рекомендуется создать отдельного пользователя mysql для доступа к базе данных opensips. Шаг 8: Запуск сервера OpenSIPS 3 Теперь пришло время наконец запустить наш сервер OpenSIPS, но прежде чем мы это сделаем, нам нужно настроить некоторые параметры в файле opensips_trunk.cfg. nano /usr/local/etc/opensips/opensips_trunk.cfg Нам необходимо обновить URL-адрес MySQL всех модулей в скрипте, указав имя пользователя и пароль MySQL. Примечание. Если после запуска службы opensips вы получаете сообщение об ошибке отказа в доступе на стороне сервера MySQL, создайте нового пользователя MySQL только для базы данных opensips. Нам нужно убедиться, что у нас указан правильный путь к модулю в скрипте конфигурации. Обновите переменную PATH в файле /etc/init.d/opensips. PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin Как только мы это сделаем, последний шаг - установить для переменной RUN_OPENSIPS значение yes. nano /etc/default/opensips Примечание. Убедитесь, что в вашей ОС существует пользователь opensips, или вы можете добавить его с помощью - useradd -r opensips. После обновления конфигурации в файле default нам нужно выполнить systemctl daemon-reload. Итак, теперь мы готовы запустить наш сервис opensips. Во-первых, давайте удостоверимся, что в нашем конфигурационном файле OpenSIPS нет неправильной конфигурации. opensips -C -f /usr/local/etc/opensips/opensips_trunk.cfg Теперь давайте запустим сервис OpenSIPS systemctl start opensips systemctl enable opensips Если вы выполнили все шаги и установили все зависимости, вы увидите, что сервер opensips работает и прослушивает порт 5060. Примечание. По умолчанию OpenSIPS использует файл /var/log/syslog для ведения журнала. Поэтому, если вы получаете какие-либо ошибки при запуске службы opensips, обратитесь к этому файлу логов для устранения неполадок. Мы можем убедиться, что сервер OpenSIPS работает или нет по-разному. Проверяя файл opensips_fifo в каталоге /tmp. Выполняя команды MI через opensips-cli Поздравляем! Вы успешно установили свой первый сервер OpenSIPS, и мы желаем вам всего наилучшего в вашем путешествии по VoIP.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59