Архив рубрики: Freeswitch: Sofia

SIP-стек 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

2015-12-03 16:20:00.908959 [WARNING] sofia_reg.c:2005 IP 10.10.10.10 Rejected by register acl "customers"

 

На что влияет 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: 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. Продолжение следует…