Архив метки: freeswitch

Freeswitch: Аутентификация по ip-адресу с использованием ACL

http://pro-voip.com.ua freeswitchДанный пост посвящен вопросам аутентификации пользователей c использованием acl при регистрации и совершении исходящих вызовов.

Хочу обратить внимание на 3 параметра в sip-профиле

<param name=»auth-calls» value=»true»/>
<param name=»apply-register-acl» value=»customers»/>
<param name=»apply-inbound-acl» value=»customers»/>

apply-register-acl — разрешать регистрацию пользователям, которые прошли проверку acl customers
apply-inbound-acl — разрешать совершать вызовы пользователям, которые прошли проверку acl customers
auth-calls — вкл/выкл аутентифицикацию c использованием acl

если auth-calls=true — apply-register-acl и apply-inbound-acl проверяются
если auth-calls=false — apply-register-acl и apply-inbound-acl игнорируются

Далее разные варианты настройки данных параметров и действия FS и клиента при разных комбинациях и исходах проверки acl

 

На что влияет auth-calls без apply-register-acl и apply-inbound-acl

auth-calls=true/false
apply-register-acl — не указан
apply-inbound-acl — не указан

Здесь аутенфицикация по логину-паролю действует! auth-calls на это никак не влияет.

Процесс регистрации пользователя (Client <-> FS):

REGISTER ->
<- SIP/2.0 401 Unauthorized
REGISTER ->
<- SIP/2.0 200 OK

… как и на входящие инвайты

Процесс совершения исходящего вызова (Client <-> FS):

INVITE ->
<- SIP/2.0 100 Trying
<- SIP/2.0 407 Proxy Authentication Required
ACK ->
INVITE ->
Proxy-Authorization: Digest username=»11″,realm=»10.10.10.10″,nonce=»8898………
<- SIP/2.0 100 Trying

 

На что влияет apply-register-acl

auth-calls=true
apply-register-acl — указан в sip-профиле
apply-inbound-acl — не указан

 

acl: allow

Если ip-пользователя проходит проверку acl (allow):

REGISTER ->
<- SIP/2.0 200 OK

логин-пароль не проверяются
пользователь попадает в тот домен, который укажет сам при подключении, и в соответствующий контекст.
Если у нас на профиле несколько доменов, пользователь при желании может попасть во все, не зная ни логинов, ни паролей!

acl: deny

Если ip-пользователя не проходит acl (deny):

REGISTER ->
<- SIP/2.0 403 Forbidden

в регистрации отказано

fs_cli

 

На что влияет apply-inbound-acl

auth-calls=true/false
apply-register-acl = не указан
apply-inbound-acl — указан в sip-профиле

 

apply-inbound-acl на регистрацию никак не влияет, пользователь проходит проверку логин-пароль, как положено:

REGISTER ->
<- SIP/2.0 401 Unauthorized
REGISTER ->
<- SIP/2.0 200 OK

 

А вот здесь с исходящими вызовами интересная история:

acl: allow

Если при совершении исходящего вызова ip пользователя проходит apply-inbound-acl(allow):
пользователь попадает в контекст public (указаный в sip-профиле)

INVITE ->
<- SIP/2.0 100 Trying
<- SIP/2.0 480 Temporarily Unavailable

acl: deny

Если при совершении исходящего вызова ip пользователя не проходит apply-inbound-acl (deny):
попадает в контекст company1 (указаный в домене)

INVITE ->
<- SIP/2.0 100 Trying
<- IP/2.0 407 Proxy Authentication Required
ACK ->

INVITE->
Proxy-Authorization: Digest username=»11″,realm=»10.10.10.10.»,nonce=»c52788bc………..
<- SIP/2.0 100 Trying

 

Что же за беда с этими контекстами? Пользователь проверку то прошел. Тут вопрос в «месте проведения» этой самой проверки. Поскольку проверка на айпи прошла успешно в sip-профиле! , то к пользователю применились все параметры sip-профиля! , а не домена, к которому подключается клиент.

Когда пользователь не прошел проверку по ip-адресу, FS запросил digest-аутентификацию, которая перекинула его в его домен и в его нужный контекст.

 

Выводы

Будьте аккуратны в использовании аутентификации по acl, особенно если у вас мультидоменная система. Если все же нуждаетесь в apply-register-acl и apply-inbound-acl, то лучше их ставить как можно ближе к клиенту (например, в настройке домена).

И еще… acl в FS не призван защищать, пользуйтесь для защиты фаерволом.

Freeswitch: Подключение к SIP-серверу провайдера

Подключение к оператору (провайдеру) связи производится через секцию <gateways> sip-профиля. Каждый gateway в секции <gateways> определяет одну регистрацию на сервере оператора. В дефолтном конфиге FS предлагает для таких вот внешних регистраций использовать sip-профиль external, описаный в файле external.xml. В дополнение к файлу external.xml подключается директория external, в котором в каждом xml-файле описан один gateway (вообще, такое деление на мелкие файлы мне лично кажется удобным для администрирования — удобно смотреть, редактировать, добавлять, удалять).

В этой статье я хочу описать несколько вариантов подключения FS к операторам/провайдерам связи. Это не все варианты — на страницах документации freeswitch.org можно найти больше примеров.

 

1. Регистрация Freeswitch по логину и паролю — один аккаунт у одного провайдера

В данном случае username, используемый для регистрации, является и нашим номером — 5555555, — на который мы будем принимать звонки, и номером, с которого мы будем звонить через этот gateway — поле From тоже будет 5555555. Регистрация будет происходить на сервере 192.168.100.100 — ip-адрес сервера прописан в gateway name.

 

2. Регистрация Freeswitch по логину и паролю — несколько аккаунтов у одного провайдера

Для того, чтобы зарегистрировать пару аккаунтов на одном и том же sip-сервере, нужно создать два отдельных gateway c разными названиями (name) —  при этом name не должен быть ip-адресом либо доменным именем, просто произвольное слово, например, gateway1 и gateway2, — а реальный ip-адрес сервера необходимо прописать в  параметре realm.

 

3. Регистрация Freeswitch по логину и паролю, один номер, username для регистрации отличается от номера

Параметр from-user используется для установки поля From при исходящих вызовах через данный gateway, параметр extension — для установки поля To при входящих вызовах с gateway. Если эти параметры явно не указать, по умолчанию применится значение username — user1 и, логично, вызовы с/на 5555555 проходить не будут.

 

4. Регистрация Freeswitch по логину и паролю, несколько номеров в одном аккаунте (построение транка с регистрацией)

Параметр caller-id-in-from позволяет каждому абоненту звонить со своим параметром From. Для этого в диалплане в extension, который описывает исходящий вызов через этот внешний gateway, нужно в переменную effective_caller_id_number подставить значение реального номера.

Например, есть абонент с внутренним номером 11, который при звонке «в город» должен звонить с номера 5555557. Прописываем в переменную абонента outbound_caller_id_number значение 5555557:

И прописываем в диалплане extension, в котором effective_caller_id_number подменяется значением переменной outbound_caller_id_number:

 

5. Подключение Freeswitch к провайдеру без регистрации

Просто ставим register=false и FS не будет отправлять запросы REGISTER к провайдеру. Обратите внимание, что username и password все равно должны присутствовать.

 

Зависимость значений некоторых параметров друг от друга в описании gateway

freeswitch gateway parameters

gateway name — обязательно нужно указывать. Параметр realm, если не указано другое, принимает значение gateway name. Параметр from-domain, если не указано другое, принимает значение realm и т.д.

Freeswitch: Dialplan. Conditions

http://pro-voip.com.ua freeswitch

Multiple Conditions (Logical AND)

Действие выполняется, когда все условия выполняются.

— здесь action выполняется только если destination_number=500 и день недели — воскресенье. Если хоть одно из условий вернет false, Freeswitch перейдет к anti-action, а если anti-action не задан, то к следующему extension.

 

Nested Conditions — вложенные условия

require-nested  важный атрибут в nested conditions. Этот атрибут определяет, должно ли вложенное условие (sub-condition) вернуть значение true, чтобы выполнился action в родительском условии (top-level condition). Принимает значения: true или false;
Default: require-nested=true.

Если require-nested=true — sub-condition тоже должно вернуть true или иметь параметр break=never, чтобы выполнился action в родительском condition. При этом выполняются action, определенные и в sub-condition, и в top-level condition — и именно в таком порядке — сначала выполняются все action во всех sub-condition, а только потом все action в top-level condition (порядок записи не играет роли — даже если сначала записан action, а потом описан sub-condition).

! Обрабатываются сначала вложенные condition

Если require-nested=false — то неважно, что вернет sub-condition, action в родительком condition в любом случае выполнится.

 

break — флаг condition —  при каком результате проверки условия остановить обработку данного extension и перейти к следующему extension. Принимает значения: on-false, on-true, never;
Default: break=on-false;

break можно указывать в цепочке из условий, например, при создании логики Logical AND.

break применяется и в nested conditions (sub-condition). В обычной работе без указания данного флага (при require-nested=true и break=on-false — это дефолтные значения), если первый sub-condition возвращает false, то следующий (sub)-condition (если он есть) уже не проверяется, и в целом работа с данным extension прекращается и парсится уже следующий extension.

Так вот, если указать в первом sub-condition break=never, то даже если он вернет false, следующий за ним sub-condition проверяться будет!

 

Пример:

в top-level condition указан require-nested=false — результат проверки вложенных условий не повлияет на выполнение action в родительском condition); в sub-condition’ах указан флаг break=never — не прерывать выполнение всего extension, разрешить проверку следующих condition.

Для чего break=never для второго sub-condition? Ведь после него больше sub-condition нет. Да, но после второго sub-condition еще есть top-level condition, ведь проверка условий будет выполняться в следующем порядке: sub-condition 1, sub-condition 2, top-level condition — сначала по порядку все вложенные, и только потом родитель.

В итоге после выполнения данного extension у нас в логах будут записи в такой очередности:

 

Multiple Conditions (Logical OR, XOR)

Логическое ИЛИ — action выполняется, если хоть одно из условий возвращет true.

Если ИЛИ нужно организовать для одного поля, т.е. смотрим только на одну переменную, то можно воспользоваться следующей конструкцией:

— action будет выполнен, если destination_number 501 ИЛИ 502.

Если ИЛИ для разных полей, используется regex.

regex может иметь следующие значения:

  • all — logical AND — все условия должны вернуть true, чтобы выполнилось action;
  • any — logical OR — хотя бы одно из условий должны возвратить true, чтобы выполнилось action;
  • xor — logical XOR — только одно условие должно возвратить true, чтобы выполнилось action;

 

Комплексный пример — маршрутизация по времени (time-based routing):

Пользователь звонит на extension 1100. Вызов перенаправляется на extension 1105 с понедельника по четверг с 8:00 до 21:59. В пятницу звонок перенаправляется на 1105 с 8:00 до 12:59. Во все остальное время вызовы перенаправляются в голосовую почту.

— в первом condition в данном примере можно было и не указывать break=on-false, ведь это значение по умолчанию, если не задано другое.

Больше примеров в wiki.freeswitch.org

Freeswitch: Dialplan

http://pro-voip.com.ua freeswitch Для начала, что такое диалплан. Диалплан — это схема маршрутизации вызовов (звонков). В диалплане мы проверяем некоторые параметры вызова (например, номер вызывающего и вызываемого абонента) и на основании значения этих параметров указываем, куда перенаправить этот вызов дальше — на локальный номер, на шлюз оператора, в голосовую почту и т.д.

Для Freeswitch дефолтным диалпланом является XML dialplan. XML dialplan подключается к главному конфигурационному файлу freeswitch.xml с помощью include:

Диалплан может быть поделен на контексты (context) для разделения правил обработки и маршрутизации между разными группами пользователей. Пользователь с одним контекстом не может воспользоваться диалпланом другого контекста. Но существует возможность перенаправления вызовов между контекстами с помощью приложений диалплана (application).

Когда поступает входящий вызов, он поступает не из-неоткуда, он поступает от какого-либо зарегистрированного на Freeswitch абонента (будь то локальный абонент, или gateway оператора, или вызов может быть сгенерирован самим Freeswitch) и попадает сперва в обработку модуля mod_sofia. В Sofia вычисляются значения канальных переменных — channel variables — на основании значений в sip-заголовках входящего вызова, согласованных параметров вызова между вызывающим абонентом и Freeswitch, параметров, выставленных вручную в directory. Затем уже Freeswitch, используя вычисленные канальные переменные, парсит диалплан в поисках подходящего направления для данного вызова.

Диалплан работает по принципу «условие-действие»; «условие» задается в виде регулярного выражения — используется синтаксис Perl Regular Expression; «действие» — это одно или несколько приложений Freeswitch, также в качестве «действия» можно подключать свои внешние скрипты.

XML dialplan состоит из таких структурных единиц, как:

  • context (контекст),
  • extension («направление»),
  • condition (условие),
  • action (действие).

context состоит из множества extension, которые с помощью condition определяют action.

 

context

— логическое разделения групп правил маршрутизации вызовов.

Когда вы создаете пользователя в directory,  в переменной «user_context» вы указываете контекст, который пользователь может использовать для совершения вызовов — тем самым вы определяете набор доступных extension (направлений) для данного пользователя или группы пользователей, или всего домена. Если вы этого не сделаете, будет применяться контекст, указанный в переменной «context» sip-профиля.

Из выше сказанного и знаний про работу sip-профиля можно сделать следующие выводы: в sip-профиле может быть сколько угодно контекстов; в домене может быть сколько угодно контекстов; можно отдельного пользователя в домене завернуть в его отдельный контекст и чисто для этого пользователя написать диалплан; можно один контекст использовать для нескольких доменов.

context имеет обязательный параметр — это «name» — он должен быть уникальным. Для значения параметра name есть зарезервированное слово any — которое означает «любой контекст».

extension

— это отдельное направления для вызова — упрощенно — отдельная пара «условие-действие».

Также имеет обязательный параметр «name«, значение этого параметра может быть неуникальным; используется для описания extension — часто в name кратко описывают, что делает данный extension — это облегчает восприятие диалплана при просмотре его «глазками» без необходимости лезть внутрь самого екстеншена. При принятии решения о маршрутизации вызова Freeswitch парсит extension’ы и как только находит подходящий, на нем и останавливается, не досматривая остальные extension’ы до конца.

condition

— условие для выбора.

Здесь задаем, какую переменную проверяем, и под какое условие должно попасть значение этой переменной, чтобы применился данный extension. Можно сохранить значение всей переменной или непрерывную часть значения, для того, чтобы ее дальше можно было использовать в action. Для этого регулярное выражение или часть регулярного выражения заключаем в круглые скобки ( ). То, что окажется в пределах круглых скобок, сохранится в специальных переменных — $1, $2$9. Поскольку condition’ов может быт несколько, то и скобок в регулярных выражениях может быть несколько. Значение, попавшее в первые скобки, заносится в переменную $1, во вторые — $2 и т.д.

На примере:

здесь мы проверяем номер вызываемого абонента (destination_number) — он должен состоять из любых 4-х цифр. Если условие выполняется — то последние 2 цифры заносятся в переменную $1. Например, если destination_number=3589, то переменная $1=89.

Если после переменной $N нужно записать еще какую-то цифру, число, то используем фигурные скобки — ${N}

$1, $2$9 работают только в пределах того extension, где они были вычислены.

Переменных $10, $11, $12 и т.д. здесь не бывает. Если нужно переменных больше, чем 9, есть специальные приемы, но о них как-нибудь потом.

action

действие, которое мы выполняем, если мы попали под условие condition. Здесь мы указываем действие — это может быть направление вызова, установление каких-либо параметров, проигрывание музыки и т.д. Действие — это запуск определенного приложения (application).

В противовес action, есть еще anti-action — это действие, которое выполняется, когда результат проверки условий — false:

 

Написание тегов

Хочу обратить внимание на соблюдение порядка открывающих/закрывающих тегов.

<condition … > — открывающий тег
</condition> — закрывающий тег

<action … /> — не имеет отдельного закрывающего тега, поэтому в конце не забудьте про слеш

Если condition’ов несколько, то все, кроме последнего закрываем с помощью />, а последний condition закрываем  </condition>

<condition  … />
<condition … />
<condition … >
    <action … />
</condition>

Freeswitch: Tone stream. Генерирование тонов

http://pro-voip.com.ua freeswitch

Что такое тон в контексте телефонии?

В двух словах, тон — это звуковой сигнал определенной частоты, определенной продолжительности, посылаемый телефонным оборудованием для информирования пользователя об определенном событии.

Например, длинный гудок, который мы слышим, когла поднимаем трубку, чтобы совершить звонок, — это ответ станции — тон «dial tone». Продолжительные гудки дозвона — «ringback tone». Короткие гудки, сообщающие, что пользователь занят — «busy tone».

 

Модуль mod_tone_stream

 

Генерированием тонов в Freeswitch занимается модуль mod_tone_stream. Отдельного файла настроек для данного модуля нет. Задание параметров выдаваемого тона происходит в диалплане.

Выглядит запись тона в обобщенном виде следующим образом:

tone_stream://[L=x;][v=y;]%(<on-duration>, <off-duration>, <freq-1> [, freq-2] [, freq-3] [, freq-n] [;loops=x])

  • L=x — создать x копий определенного тона в памяти перед проигрыванием. Отрицательное значение неприемлемо — L=-1 не работает. Если нужно сделать сигнал, повторяющийся неопределенное количество раз, пользуйтесь конструкцией loop=-1. L=x ставится в начале строки, задающей тон;
  • v=y — громкость тона в децибелах. «0» — максимальная громкость. Используются отрицательные значения;
  • on-duration — длительность звучания тона в милисекундах;
  • off-duration — длительность тишины (паузы) в милисекундах;
  • freg-1 … freg-n — задаем частоту в герцах;
  • ;loops=x  — повторить x раз; loop=-1 — бесконечный цикл. Генерирует тон и повторяет процесс генерации каждый раз до завершения цикла, в отличие от параметра L, который сначала создаст один длительный тон, который будет занимать место в памяти в x раз больше, а только потом его проиграет. Данный параметр записывается в конце строки.

 

freeswitch-tone-stream

 

Пример

«busy tone»

Проиграть 8 гудков сигнала «занято», длительность тона и тишины по 500 ms.

 

Параметры тонов в большинстве своем определены на национальном уровне. В разных странах может быть разное кол-во тонов и разные параметры для тонов одного и того же назначения.

Разнообразие тонов и их параметры по версии ITU-T можно посмотреть в Recommendation E.180/Q.35.

Freeswicth: vars.xml

Freeswitch FAQ:http://pro-voip.com.ua freeswitch
Q: Какая разница между ${var} и $${var} в конфигурационных файлах?

  • ${var} — эта переменная вычисляется, когда встречается в диалплане;
  • $${var} — эта переменная вычисляется при загрузке FS или при reloadxml.
Preprocessor variables

Переменные $${var} называют препроцессорными — preprocessor variables.Чаще всего используются для установки дефолтных значений.

Эти переменные устанавливаются вручную в файле vars.xml;

Например:

Кстати, строки с <X-PRE-PROCESS …> , где бы они не встречались, НИКОГДА не комментируются! Или оставляем, или удаляем.

Predefined variables

Отдельный тип переменных — predefined (предопределенные) переменные.

  • hostname
  • local_ip_v4
  • local_mask_v4
  • local_ip_v6
  • switch_serial
  • base_dir
  • recordings_dir
  • sound_prefix
  • sounds_dir
  • core_uuid
  • zrtp_enabled
  • nat_public_addr
  • nat_private_addr
  • nat_type

Эти переменные устанавливаются динамически — вычисляются, если возможно, FS’ом на основании своего окружения — и доступны в конфиге как $${variable}.

Вычисленные переменные можно увидеть в fs_cli командой:

Также эти переменные можно использовать как значения для preprocessor переменных.

Freeswitch: SIP-стек Sofia

Осноhttp://pro-voip.com.ua freeswitchвой любой VoIP-телефонии является какой-либо VoIP-протокол (SIP, H.323, IAX и др.), согласно правилам которого и работает эта самая VoIP-телефония. Нативным протоколом для FS является SIP — SIP-стек представлен в виде модуля mod_sofia.

SIP is a crazy protocol and it will make you crazy too if you aren’t careful.

Настройка SIP-стека FS по своему вкусу производится через, так называемые, sip_profile (SIP-профили). В этих профилях, помимо различных настроек sip’а, указываются «фундаментальные» (что-то другого слова не приходит на ум) — это пары ip-port, которые слушает FS на предмет входящих запросов.

Профилей может быть столько, сколько вы можете обеспечить уникальных пар ip-port.

В дефолтной конфигурации FS представлены 2 профиля: internal  и external:

  • internal  — для регистраций внутренних пользователей (users), слушает порт 5060
  • external — для подключения внешних линий (gateways), слушает порт 5080.

Sofia. Логическая структура

Схема:

Sofia-Logical-Structure

То же самое в XML:

 

Физически же эту структуру для удобства администрирования можно разбивать на несколько файлов, не забывая их связать друг с другом в нужной иерархической последовательности с помощью команды препроцессора —  include.

 

Sofia. Profiles

Подробнее про каждую секцию конфигурации профиля


<aliases>

alias — это просто еще одно имя для одного и того же профиля;


<gateways>

gateways — секция подключения к внешним шлюзам; если хотите зарегистрировать FS у оператора и иметь выход во внешний мир, то вам сюда (или в настройку домена — там тоже встречается секция gateway).

Минимальная конфигурация gateway:

 

Некоторые (не все) параметры для расширенной настройки смотрите ниже:

gateway name:
<gateway name=»provoip»>
— имя шлюза; можно указывать реальное доменное имя или ip-адрес; также можно указывать произвольное имя, но тогда реальное доменное имя или ip-адрес нужно будет указать в параметре realm;

username:
<param name=»username» value=»username1» />
— имя пользователя *required*;

realm:
<param name=»realm» value=»provoip.in.ua«/>
— auth realm: *optional* — если это поле не указано, используется имя gateway. realm — это поле sip-запроса аутентификации, которое определяет область отклика аутентификации (заумная фраза не моя — так написано в книге по sip); короче, это «домен», к которому будет относиться пользователь. Обязательно должен содержать реальное имя домена или ip-адрес;

from-user:
<param name=»from-user» value=»5555555«/>
— имя пользователя в поле From: *optional* — если не указано, используется значение поля username;

from-domain:
<param name=»from-domain» value=»provoip.in.ua«/>
— имя домена в поле From: *optional* — если не указано, используется значение поля realm;

password:
<param name=»password» value=»mystrongpassword«/>
— пароль пользователя *required*;

extension:
<param name=»extension» value=»8888888«/>
— номер (extension) для входящих звонков *optional* — если не указано, исп-ся значение поля username;

proxy:
<param name=»proxy» value=»provoip.in.ua«/>
— proxy host: *optional* — если не указан, исп-ся значение поля realm;

register-proxy:
<param name=»register-proxy» value=»pro-voip.com.ua«/>
— посылать register на этот хост (другими словами, регистрироваться на этом хосте) *optional* — если не указано, исп-ся значение поля proxy;

expire-seconds:
<param name=»expire-seconds» value=»60«/>
— register expire (in seconds) *optional* — по умолчанию 3600 сек;

register:
<param name=»register» value=»false«/>
— не регистрироваться; параметр пригодится, если, например, нужно будет построить sip-транк с оператором на множество номеров, а оператор вас авторизирует по ip-адресу и не дает вам логин-пароль 🙂 НО! даже если вы не используете регистрацию, то поля username и password все равно должны быть заполнены какими-либо значениями (пофигу какими);

register-transport:
<param name=»register-transport» value=»udp«/>
— какой транспорт (читай: протокол транспортного уровня) — tcp или udp — использовать при регистрации; default — udp;

retry-seconds:
<param name=»retry-seconds» value=»30«/>
— если регистрация потерпела неудачу или отвалилась по таймауту, то сколько секунд ждать перед повторной попыткой? — указываем здесь; default — 30;

caller-id-in-from:
<param name=»caller-id-in-from» value=»true«/>
— при исходящих вызовах через данный шлюз callerid берем из поля From (берем значение поля From A-ноги и суем это значение в поле From B-ноги); default —  false — callerid = username;

<!—extra sip params to send in the contact—>
<!—<param name=»contact-params» value=»tport=tcp»/>—>
<!—send an options ping every x seconds, failure will unregister and/or mark it down—>
<!—<param name=»ping» value=»25″/>—>

</gateway>

Настройки вне тега <gateway>, но внутри тега <gateways> (пока без описания):

<!—rfc5626 : Abilitazione rfc5626 ///—>
<!—<param name=»rfc-5626″ value=»true»/>—>
<!—rfc5626 : extra sip params to send in the contact—>
<!—<param name=»reg-id» value=»1″/>—>


<domains>

domain — индикатор, который дает установку профилю открыть XML-регистр FS’а и выполнить действия над доменом в зависимости от следующих настроек:

  • alias: [true/false] — автоматически создавать алиас для данного профиля; alias name = domain name в этом случае;
  • parse: [true/false] — сканировать домен на наличие gateway и включать их в этот профиль;
  • name: [<string>] — здесь указываем имя конкретного домена или all (для всех доменов), над которыми производим вышеперечисленные действия alias и parse.

Например:

дает указание создавать алиасы к этому профилю для всех доменов и не сканировать домены на наличие gateway.


<settings>

 

Basic settings

user-agent-string:
<param name=»user-agent-string» value=»FreeSWITCH Rocks!»/>
— выставляем свой User-Agent заголовок во всех SIP-сообщениях. Можно выставлять любое значение. но нужно быть внимательным к спец-символам — например,  другие SIP-сервера, с которыми общается наш FS, может отклонить сообщение из-за наличия в заголовке User-Agent символа «@». Без установки этого параметра, User-Agent будет выглядеть примерно следующим образом (зависит от вашей инсталяции FS):

User-Agent: FreeSWITCH-mod_sofia/1.2.22+git~20140311T001049Z~9495f2534d~32bit

shutdown-on-fail:
<param name=»shutdown-on-fail» value=»true»/>
— если нужно, чтобы FS потушился, если данный профиль не загрузится, ставим true; default: false;

context:
<param name=»context» value=»public»/>
указываем, в какой контекст помещать входящие вызовы, которые идут на ip-port этого профиля

sip-port:
<param name=»sip-port» value=»5060″/>
— порт, который слушает FS на предмет входящих соединений;

sip-ip:
<param name=»sip-ip» value=»10.10.10.10″/>
— ip-адрес, на который FS принимает входящие sip-запросы; Не используйте доменные имена — только IP-адрес!

rtp-ip:
<param name=»rtp-ip» value=»10.10.10.10″/>
— ip-адрес, на который FS принимает rtp-потоки; Не используйте доменные имена — только IP-адрес!

dialplan:
<param name=»dialplan» value=»XML»/>
— какой тип диалплана использовать для пользователей этого профиля.

 

Media relaited options

resume-media-on-hold и bypass-media-after-hold:

<param name=»media-option» value=»resume-media-on-hold»/>
<param name=»media-option» value=»bypass-media-after-hold»/>

— если FS настроен так, чтобы не проксировать через себя медиа-потоки (bypass_media = true), а у нас появилась необходимость перехватить медиапоток, нажав на кнопку hold, то используются эти две медиа-опции (работают в паре): resume-media-on-hold перехвачивает медиа, а bypass-media-after-hold после повторного нажатия hold, возвращает вызов в исходный bypass-media режим.

bypass-media-after-att-xfer:
<param name=»media-option» value=»bypass-media-after-att-xfer»/>
— после перевода вызова (при attended transfer) вернуться к режиму bypass media.

inbound-bypass-media и inbound-proxy-media:
— два взаимоисключающих параметра (если один параметр true, второй должен быть false)- установка режима работы с медиапотоками.
<param name=»inbound-bypass-media» value=»true»/> — не прокрисовать медиапоток через FS; FS контролирует только SIP-сессию, а rtp-потоки текут напрямую между конечными точками.
<param name=»inbound-proxy-media» value=»true»/> — проксировать медиапоток через FS; rtp-потоки проходят через FS, но модифицировть их мы не можем.
default: false/false — при такой конфигурации rtp-потоки проксируются через FS и можем с ними производить любые манипуляции.

t38-passthru:
<param name=»t38-passthru» value=»true»/>
— [true/false/once] — факс по протоколу t38

 

Codecs related options

inbound-codec-prefs:
<param name=»inbound-codec-prefs» value=»PCMA, PCMU»/>
— порядок предпочтения того или иного кодека в процессе согласования кодека с другой стороной диалога при входящих (inbound) вызовах. Здесь предпочтение кодеку PCMA.

outbound-codec-prefs:
<param name=»outbound-codec-prefs» value=»PCMA, PCMU»/>
— то же самое, но по отношению к исходящим (outbound) вызовам.

codec-prefs:
<param name=»outbound-codec-prefs» value=»PCMA, PCMU»/>
— то же самое, но для inbound и outbound направлений одновременно.

inbound-codec-negotiation:
<param name=»inbound-codec-negotiation» value=»generous»/>
— параметр, значение которого решает «кто главный» в процессе согласования кодека:

  • «generous» — «главный» список кодеков удаленной стороны;
  • «greedy» — «главный» список кодеков FS;
  • «scrooge» — идет дальше «greedy» — FS выигрывает даже тогда, когда противоположная сторона лжет о своих возможностях в ходе переговорного процесса.

inbound-late-negotiation:
<param name=»inbound-late-negotiation» value=»true»/>
— позволяет сначала пройтись по диалплану, а зачем уже выбирать кодек для a-leg.

disable-transcoding:
<param name=»disable-transcoding» value=»true»/>
— запретить транскодинг; FS будет предлагать вызываемой стороне только те кодеки, которые поддерживает вызывающая сторона.

 

DTMF

dtmf-type:
<param name=»dtmf-type» value=»info»/>

  • «info»
  • «rfc2833»
  • «none»

— тип DTMF. Этот же параметр можно представить в виде переменной в секции <gateway> или <user> (но это не канальная переменная!):

Заметьте, параметр dtmf-type пишется через дефис «-«, а переменная dtmf_type через нижнее подчеркивание «_».

Для распознавания inbound DTMF есть приложение в диалплане start_dtmf.

rfc2833-pt:
<param name=»rfc2833-pt» value=»101″/>
— rfc2833 payload type — идентификатор для отличия rfc2833 dtmf от остальных типов rtp-трафика.

dtmf-duration:
<param name=»dtmf-duration» value=»2000″/>
— длительность dtmf-тона.

liberal-dtmf:
<param name=»liberal-dtmf» value=»true»/>
— всегда предлагать rfc2833, а принимать и rfc2833, и info dtmf.

 

Информация почерпана с wiki.freeswitch.org. Продолжение следует…

Freeswitch: Регистрация пользователя

http://pro-voip.com.ua freeswitchSIP-аккаунты в FS построены по принципу электронной почты. Каждый аккаунт принадлежит определенному домену. Например, 1000@example.com — это абонент с номером 1000 в домене example.com. Доменом может выступать  ip-адрес FS’а или доменное имя, которое с помощью DNS преобразуется в тот же ip-адрес.

В общем виде структура домена выглядит следующим образом:

Вот такая иерархия:

  • есть домен;
  • домену принадлежат пользователи;
  • пользователи могут объединяться в группы;
  • пользователи могут находиться в нескольких группах одновременно.

Параметры (params) и переменные (variables) могут быть указаны в настройках:

  • домена — тогда они распостраняются на всех пользователей домена;
  • группы — распостраняются на пользователей группы;
  • отдельного пользователя — соответсвенно, распостраняются только на этого пользователя.

Чем ниже уровень вложения, тем выше приоритет настроек. Например, если один и тот же параметр указан в настройках и домена, и отдельно пользователя, но имеет разные значения, конкретно для этого пользователя будет применяться его настройка, а не всего домена.

 

Расположение файлов пользователей

$FS_ROOT/conf/directory/

Дефолтная конфигурация FS предлагает вести конфигурационные файлы домена и пользователей следующим образом:

  • есть отдельно файл домена example.com.xml
  • и есть директория , в котором хранится множество xml-файлов пользователей — по одному файлу на каждого пользователя;
  • директория с пользователями example.com подключается к файлу домена example.com.xml с помощью   X-PRE-PROCESS. Вот как это выглядит в файле домена:

$FS_ROOT/conf/directory/example.com.xml

Минимальная конфигурация подключения пользователя предполагает задание значений ID (логин) и password (пароль):

$FS_ROOT/conf/directory/example.com/1000.xml

 

Группы пользователей

Группа (group) — это логическое объединение пользователей. Может использоваться для задания общих параметров, чтобы не прописывать их для каждого пользователя отдельно; также применяется для групповых вызовов, чем упрощает написание диалплана.

Следующий пример конфигурации домена говорит о том, что:

  • в домене example.com создаем группу из всех пользователей домена, называем группу example.com;
  • создаем группу managers, которая состоит из пользователей 1000, 1001 и 1002;
  • создаем группу support, которая состоит из пользователей 1000, 2000 и 2001;

$FS_ROOT/conf/directory/example.com.xml

В группы managers и support пользователи были добавлены с указанием типа «pointer» — указатель — именно благодаря этому можно одного и того же пользователя добавлять одновременно в несколько групп.