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. Продолжение следует…