Перевод настроек файла sofia.conf.xml (Часть первая)

Sofia.conf.xml

Что делает Sofia

Sofia — это модуль FreeSWITCH (mod_sofia), который обеспечивает возможность входящих и исходящих SIP-подключений к FreeSWITCH, действуя в качестве юзер-агента.

Юзер-агент (UA) представляет собой приложение, используемое для обработки определенного сетевого протокола, это относится и к Sofia UA, только в последнем случае сетевым протоколом является SIP. Sofia — общее название для любого использующего сетевой протокол SIP юзер-агента во FreeSWITCH.

Например, Sofia принимает вызовы, отправленные на FreeSWITCH с других SIP юзер-агентов, посылает вызовы на другие юзер-агенты, выступает в качестве клиента для подключения FreeSWITCH к другим агентам, позволяет клиентам подключаться к FreeSWITCH, а также переключает звонки на локальные направления.

Для добавления SIP-провайдера (юзер-агента Sofia) во FreeSWITCH надо найти нужный вам пример в списке SIP-провайдеров, после чего, воспользовавшись полученной информацией, добавить данные провайдера в *.XML-файл, сохранённый в conf/sip_profiles/.

В Sofia допускается использование нескольких юзер-агентов

Юзер-агент (UA) — это приложение, используемое для работы с определенным сетевым протоколом, это относится и к Sofia UA, только в данном случае сетевым протоколом является SIP.

При запуске FreeSWITCH считывает информацию из файла conf/autoload_configs/sofia.conf.xml. В этом файле содержится директива "X-PRE-PROCESS", которая предписывает FreeSWITCH последовательно загружать и объединять все имеющиеся файлы conf/sip_profiles/.xml. В каждом таком .xml файле должно содержаться полное описание одного или нескольких профилей SIP. Загруженные таким образом профили SIP являются частями юзер-агента; то есть, по терминологии FreeSWITCH, UA = User Agent = Sofia Profile = SIP Profile.

Обратите внимание, что все загруженные во FreeSWITCH юзер-агенты сливаются воедино и не должны конфликтовать друг с другом. Точнее, каждый UA должен иметь уникальный порт для приёма вызовов(по умолчанию для SIP установлен порт 5060).

Множественные юзер-агенты (профили) и диалплан

Зачем может понадобиться создание нескольких юзер-агентов? Вот пример.

Допустим, в офисной сети используется брандмауэр. В этом случае при совершении вызовов на номера, находящиеся за пределами брандмауэра, необходимо использовать STUN-сервер, чтобы обойти защиту NAT, в то время как для внутренних звонков по офису STUN-сервер не требуется. Для того, чтобы обеспечить соответствие всем названным требованиям, создаются два разных юзер-агента. Один из них использует STUN-сервер и подключается к телефонным сетям общего пользования через оператора связи. Второй юзер-агент применяется только для местных SIP-вызовов.

Получается, что в ваших профилях будут определены два юзер-агента, каждый из которых может обрабатывать вызовы. Какой из них будет использоваться при наборе SIP-адреса или телефонного номера? Этот определяется параметрами диалплана. Один из определяемых диалпланом вариантов синтаксиса для совершения звонков через Sofia выглядит таким образом:

    sofia/ profile_name /destination

То есть, задача довольно простая. Для определения способа обработки вызова в диалпланах используется сопоставление с шаблонами, а также другие способы проверки. Диалплан проверяет уже набранные символы, после чего определяет, какой из профилей использовать для данного звонка. При наборе телефонного номера в диалплане выбирается юзер-агент, который подключается к публичной телефонной сети. При наборе SIP-адреса, расположенного за пределами защищённой брандмауэром сети, в диалплане выбирается тот же самый юзер-агент, так как звонок осуществляется через STUN-сервер. Однако при наборе SIP-адреса, расположенного внутри защищённой брандмауэром сети, в диалплане выбирается "локальный" юзер-агент.

Чтобы понять, как составлять диалпланы, осуществлять сопоставление с шаблоном и так далее, смотрите Dialplan

Связь между SIP-профилями и доменами

В ответ на вопросы о том, как профили SIP связаны с доменными именами во FreeSWITCH, Энтони Минессал написал статью для списка рассылки.

Лучше всего взглянуть на эти вещи, немного абстрагировавшись.

Домены внутри XML-реестра значительно отличаются как от доменов в интернете, так и от доменов в SIP-пакетах. Профили во всех вышеперечисленных случаях также абсолютно разные. Работа по приведению их в соответствие ложится на вас, если вы того пожелаете.

Во входящей в комплект поставки FreeSWITCH конфигурации по умолчанию настроен сценарий, который с большой долей вероятности загрузится на любом компьютере и будет работать из коробки. Именно это и является первоочередной задачей данной конфигурации, поэтому домен одновременно устанавливается в каталоге и глобальной переменной стандартного домена, а имя внутреннего профиля должно совпадать с IP-адресом устройства, имеющего доступ в интернет. Затем настраивается SIP, чтобы связать его параметры с заданным ранее значением. Если вас не устраивает работа в данном режиме, то можете предпринять попытку настроить своего рода многоканальную систему.

Aliases внутри тегов <aliases> представляют собой список ключей, доступных для использования при конфигурировании вашего текущего профиля. Можете считать их аналогами файла /etc/hosts в Unix, только предназначенными для профилей. Если после определения псевдонимов для всех возможных доменов, размещенных в конкретном профиле, вам понадобится взять строчку вида user@host.com и выяснить, из какого она профиля, то при поиске можно использовать псевдонимы, но только в том случае, если вы добавили <alias name="host.com"/> для этого профиля.

Тег <domains> является индикатором, по сигналу которого профиль открывает XML-реестр FreeSWITCH и проверяет записанные в нём домены. Двумя важнейшими атрибутами являются:

    alias: [true/false] (автоматически создаёт псевдоним для данного домена как описано выше)

    parse: [true/false] (сканирование домена на предмет входных данных для шлюза и включение их в данный профиль)

    name: [<string>] (имя конкретного домена или значение 'all', означающее проведение анализа каждого домена в каталоге)

В конфигурации по умолчанию

    <domain name="all" alias="true" parse="false"/>

Если вы примените этот алгоритм, он проведёт сканирование каждого домена (по умолчанию только один), присвоит псевдонимы, но не станет выполнять разбор для передачи на шлюзы. В каталоге по умолчанию используются глобальные конфигурационные переменные для установки домена, соответствущего локальному IP-адресу компьютера. То есть сейчас у вас в конфигурационном файле имеется домен, совпадающий с IP-адресом, к которому присоединяется внутренний профиль и добавляется псевдоним, так что значение снова будет расширено.

Этот процесс описывается в комментарии в верхней части файла directory/default.xml:

FreeSWITCH работает на основе концепции пользователей и доменов аналогично электронной почте. Каждый из пользователей относится к определенному домену, например, 1000@domain.com. Когда FreeSWITCH получает запрос на регистрацию, он ищет пользователя в каталоге по имени домена в поле from или to, в зависимости от того, как сконфигурирован ваш профиль sofia. Из коробки в качестве домена по умолчанию установлен IP-адрес компьютера, на котором работает FreeSWITCH. Узнать IP-адрес можно, набрав в командной строке фразу "sofia status". При регистрации телефоны по умолчанию привязываются к IP, а не к имени хоста. Если вы хотите зарегистрироваться с использованием домена, откройте файл vars.xml в корневой директории и установите нужное вам имя хоста в качестве домена по умолчанию. После этого при регистрации во FreeSWITCH вместо IP-адреса в клиенте будет использоваться доменное имя.

То есть наличие нескольких профилей с установленными по умолчанию параметрами

    <domain name="all" alias="true" parse="false"/>

может привести к присвоению одних и тех же доменных имён для всех профилей, из-за чего возможно переписывание таблиц поиска и появление ошибок. Если у вас во всех профилях установлено parse="true", то каждый из них будет пытаться подключиться к шлюзам во всех ваших доменах.

Если взглянуть на шаблонный конфигурационный файл, неплохим примером которого для вторичного профиля является external.xml, вы увидите

    <domain name="all" alias="false" parse="true"/>,

то есть, никаких псевдонимов и везде разрешён парсинг — полная противоположность внутреннему профилю, поэтому все шлюзы будут регистрировать как внешние, так и внутренние вызовы, приходящие на локальный IP-адрес.

Следовательно, вам понадобятся отдельные имена вида <domain name="example.com"/> для каждого домена, который вы захотите привязать к профилю, а также придётся использовать более сложную процедуру настройки.