По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье будет описан процесс настройки вашей АТС Asterisk с провайдером Zadarma.
Настройка с помощью файлов конфигурации Asterisk
Важный момент - у вас уже должны быть логин и пароль для данного провайдера, получить которые можно на сайте. Для примера будут указаны следующие данные: 1234567 - ваш SIP - номер, полученный при регистрации, ****** - ваш пароль и 321 - номер экстеншена. Рассмотрим самый стандартный вариант, при котором исходящие звонки с вышеуказанного внутреннего номера (экстеншена) маршрутизируются через SIP - транк zadarma-trunk.
Для начала настройки необходимо отредактировать файл sip.conf следующим образом:
[general]
srvlookup=yes
[zadarma-trunk]
host=sip.zadarma.com
insecure=invite,port
type=friend
fromdomain=sip.zadarma.com
disallow=allallow=alaw&ulaw
dtmfmode=autosecret=password
defaultuser=1234567
trunkname=zadarma-trunk
fromuser=1234567
callbackextension=zadarma-trunk
context=zadarma-in
qualify=400
directmedia=no
[321]
secret=password
host=dynamic
type=friend
context=zadarma-out
Настройки маршрутизации производятся в файле extensions.conf следующим образом:
[zadarma-in]
exten => 1234567,1, Dial(SIP/321)
[zadarma-out]
exten => _XXX,1,Dial(SIP/${EXTEN})
exten => _XXX.,1,Dial(SIP/${EXTEN}@zadarma-trunk)
Для контекста [zadarma-in] все входящие вызовы направляются на экстеншен 321, и для [zadarma-out] возможны два варианта: если в набираемом номере 3 цифры, то вызов пойдет на один из экстеншенов, настроенных на вашей АТС, если же 4 и больше - вызов уйдет на транк zadarma-trunk.
В случае, если ваша АТС находится не за маршрутизатором, а имеет публичный IP-адрес, то входящие вызовы можно принимать по следующей схеме, с использованием SIP URI.
К примеру, 12039485767 - ваш DID номер подключенный к Zadarma, а 200.132.13.43 - адрес вашего Asterisk. Для этого нужно в личном кабинете в поле Настройки-Прямой телефонный номер нужно указать маршрутизацию с прямого DID номера на внешний сервер (SIP URI) в формате 12039485767@200.132.13.43 и отредактировать sip.conf следующим образом:
[zadarma]
host=sipde.zadarma.com
type=friend
insecure=port,invite
context=zadarma-in
disallow=all
allow=alaw&ulaw
dtmfmode = auto
directmedia=no
[zadarma2]
host=siplv.zadarma.com
type=friend
insecure=port,invite
context=zadarma-in
disallow=all
allow=alaw&ulaw
dtmfmode = auto
directmedia=no
[zadarma3]
host=sipfr.zadarma.com
type=friend
insecure=port,invite
context=zadarma-in
disallow=all
allow=alaw&ulaw
dtmfmode = auto
directmedia=no
Указываем исходящий маршрут в файле extensions.conf
[zadarma-in]
extended => 12039485767,1,Dial(SIP/321)
Далее будет рассмотрена настройка транка для FreePBX 13 версии.
Настройка с помощью FreePBX
Важный момент, перед настройкой транка необходимо включить функцию SRV Lookup. Для этого необходимо пройти по пути Settings → Asterisk SIP Settings → Chan SIP Settings и для опции Enable SRV Lookup выбрать опцию Yes.
Далее происходит уже знакомый процесс настройки транка – переходим во вкладку Connectivity → Trunks. Необходимо нажать на кнопку + Add Trunk и добавить chan_sip транк
Присваиваем имя транку – в данном случае это «Zadarma_test»
Далее необходимо перейти во вкладку sip Settings и указать настройки для входящей и исходящей связи (вкладки Outgoing и Incoming)
Для удобства копирования, приведу настройки SIP - транка и строки регистрации в текстовом виде:
host=sip.zadarma.com
insecure=invite,port
type=friend
fromdomain=sip.zadarma.com
disallow=all
allow=alaw&ulaw
dtmfmode=auto
secret=******
defaultuser=1234567
fromuser=1234567
qualify=400
directmedia=no
1234567:******@sip.zadarma.com/1234567
Далее нужно нажать на Submit и Apply Config. Переходим к настройке входящего маршрута
Маршрутизация
Во вкладке Connectivity → Inbound Routes по уже знакомому способу создаём входящий маршрут (кнопка + Add Inbound Route), присваиваем описание и указываем номер.
Далее нажимаем Submit и переходим к настройке исходящего маршрута: переходим по пути Connectivity → Outbound Route, создаём новый исходящий маршрут таким же образом как и входящий и указываем следующие параметры – имя маршрута, CID маршрута и используемый транк (тот, что был настроен в начале всего процесса.)
Последним шагом является настройка Dial Patterns – переходим в одноименную вкладку и после поля префикс необходимо поставить одну единственную точку – иначе не будет возможности совершать исходящие вызовы.
После этого необходимо нажать Submit и Apply Config. На этом настройка заканчивается.
В версиях Asterisk начиная с версии 1.4 периодически наблюдались проблемы с утечкой памяти, которые лечились с помощью перезагрузки сервера. Так как никто не застрахован от вероятных неизвестных багов, лучше для перестраховки перезагружать сервер IP - АТС раз в неделю (или чаще) с помощью скрипта. В статье расскажем про создание bash скрипта и его настройку в cron.
Скрипт перезагрузки
По факту, в скрипте достаточно одной команды перезагрузки. Сделаем немного информативной нагрузки – добавим запись в лог – файл: мы будем записывать дату и время ребута с лог – файл. Итак, создаем файл reboot.sh:
[root@asterisk ~]# touch reboot.sh
Далее открываем этот файл для редактирования через vim редактор:
[root@asterisk ~]# vim reboot.sh
Открыв файл, нажмите «О» для редактирования. Вставьте код, указанный ниже:
#!/bin/sh
LOGFILE=/home/admin/log_mail.txt
DATE="`date +%d.%m.%Y" "%H:%M:%S`"
echo "REBOOT :: $DATE :: Reboot is in progress" >> "$LOGFILE"
shutdown -r now
После этого нажимаем комбинацию «:x!» для сохранения конфигурации. В данном скрипте:
LOGFILE - переменная, которая указывает на лог – файл;
DATE - записываем дату и время в указанную переменную;
echo "…" - записываем в лог – файл отметку о перезагрузке;
shutdown -r now - команда перезагрузки сервера;
Получаем простенький скрипт для осуществления перезагрузки. Осталось только сделать его работу по расписанию. Для этого, мы воспользуемся планировщиком cron:
* * * * * команда для выполнения
- - - - -
| | | | |
| | | | +----- день недели (0 - 6) (Воскресенье=0)
| | | +------- месяц (1 - 12)
| | +--------- день месяца (1 - 31)
| +----------- час (0 - 23)
+------------- минута (0 - 59)
Зашедулим скрипт на выполнение каждую полночь в воскресение. Для этого, открываем для редактирования crontab файл:
[root@asterisk ~]# crontab -e
В открывшийся файл добавляем:
0 0 * * 0 /bin/bash /home/reboot.sh >/dev/null
Где /home/reboot.sh - полный путь к скрипту перезагрузки сервера. Нажимаем F2 и далее Yes. Задача на выполнение сохранена.
Примеры планирования в cron
Разберем пару примеров того, по какому расписанию можно планировать выполнение скрипта:
15 0 1 1,3,6,9,12 * - выполнение скрипта каждое 1 число января, марта, июня, сентября и декабря в 00:15 ночи;
0 20 * 8 1-5 - выполнение скрипта каждый будний день в 20:00 в августе;
0 0 1,15,25 * * - выполнение скрипта в полночь каждого месяца первого, пятнадцатого и двадцать пятого числа;
Буферизация пакетов для работы с перегруженным интерфейсом кажется прекрасной идеей. Действительно, буферы необходимы для обработки трафика, поступающего слишком быстро или несоответствия скорости интерфейса - например, при переходе от высокоскоростной 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, поскольку несоответствие высокоскоростных домашних сетей и низкоскоростных широкополосных сетей вызывает естественную точку перегрузки. Кроме того, сетевое оборудование потребительского уровня часто страдает от слишком большого размера буферов.