Расширенные средства SIP телефонии

Про Asterisk, думается, слышал чуть ли не каждый админ — он встречается буквально на каждом шагу, будь то офисная АТС или нечто связанное с телекомом. Но если в первом случае его применение практически всегда оправданно, то во втором могут иметь место некоторые проблемы. Существуют ли альтернативы Asterisk?

SIP: Краткое введение

Прежде всего стоит разобраться, как работает SIP в принципе и что это вообще за протокол. Итак, SIP — Session Initiation Protocol, служащий исключительно для целей установления и завершения сессии. Обмен пакетами от установления соединения до его завершения называется диалогом. Медиапоток по данному протоколу не передается — для этого есть протокол RTP. Инкапсулированный же в пакете SIP SDP (Session Description Protocol) определяет, в частности, и параметры медиапотока, такие как используемый кодек и тип данных.

Важно понимать, что прохождение этих двух потоков — SIP/SDP и RTP (или, как говорят связисты, сигнализации и данных) — совершенно независимо друг от друга. Посмотрим, что происходит при нормальном вызове (очень упрощенно, правда).

Вызывающая сторона инициирует соединение, посылая SIP-пакет INVITE, в нем же инкапсулирован и SDP с информацией о желаемых параметрах RTP. Этот пакет может пройти через несколько SIP-прокси — о них чуть ниже.
В зависимости от того, проходит ли вызов через SIP-прокси или нет, вызывающая сторона получает либо ответ от SIP-прокси TRYING (а уж прокси тем временем направляет INVITE вызываемой стороне) и следом RINGING, либо сразу RINGING. Пакет RINGING означает, что вызываемая сторона посылает сигнал абоненту «звоню» и теперь нужно ожидать, условно говоря, «поднятия трубки».
Как только вызываемая сторона поднимает трубку, она посылает SIP-пакет с кодом 200 «OK». В этот пакет снова инкапсулирована нагрузка SDP, содержащая параметры, которые поддерживаются этой стороной. Вызывающая же сторона, если параметры совпадают, посылает ответный пакет ACK.
Клиенты соединяются по протоколу RTP напрямую независимо от того, проходил ли предыдущий обмен пакетами SIP через SIP-прокси или нет. Происходит разговор.
При отбое отбивающая сторона посылает SIP-пакет BYE, а вторая сторона посылает опять же пакет ACK. Соединение завершено.

Теперь стоит разобраться с устройством сети SIP — какие логические сущности в ней вообще имеются.

sip телефония

UAC и UAS — User Agent Client и User Agent Server. Очень условно их можно назвать вызывающей и вызываемой стороной. В SIP-терминалах и программных клиентах реализуется как UAC, так и UAS.
SIP-прокси занимается в основном маршрутизацией.
SIP-регистратор сохраняет информацию о логическом местоположении UAC/UAS.
SIP-редиректор предоставляет UAC/UAS информацию о маршрутизации и в случае необходимости перенаправляет вызов в другое место.
Сервер местоположения на самом деле представляет собой базу данных, где указано, какой адрес или какие адреса соответствуют тому или иному SIP URI. Фактически это лишь удобная абстракция.
B2BUA может находиться на месте SIP-прокси, но им не является. В случае с прокси терминал устанавливает соединение с другим терминалом напрямую (хоть оно и проходит через прокси, но лишь до определенного этапа. И прокси в общем случае не изменяет заголовки и тело SIP-пакета). В случае с B2BUA терминал сначала устанавливает с ним соединение, затем B2BUA устанавливает соединение с вызываемым терминалом, и в дальнейшем весь процесс происходит исключительно через него, с использованием двух независимых сессий — вызывающий терминал-B2BUA и B2BUA-вызывающий терминал. Применение B2BUA дает гораздо большую гибкость, нежели применение обычного SIP-прокси, — хотя бы потому, что он позволяет изменять тело SIP-пакета. Кроме того, по названным выше причинам его применяют и при тарификации вызовов. Но есть у него и недостаток — большее потребление памяти.

Стоит отметить, что зачастую логические сущности объединяются в одном ПО. Так, SIP-прокси чаще всего объединяется с регистратором и редиректором.

SIP-прокси существуют двух типов — stateless и stateful.Если ты знаком с iptables, думаю, объяснять их различия нет необходимости. А если нет… Stateful SIP-прокси хранит со-стояние транзакции, то есть знает, какому пакету INVITE соответствует тот или иной пакет ACK. Stateless-прокси же ничего этого не знает и тупо передает пакет куда следует.

И тут мы плавно переходим к вопросу, какие еще свободные средства для работы с SIP-протоколом (помимо Asterisk,о котором знают все) существуют в *nix-системах. На данный момент есть два проекта, предназначенные для этой цели, —Kamailio и OpenSIPS. Они имеют общего предка, так что подробно описывать их различия смысла нет. В статье будет рас-смотрен OpenSIPS.

ЧТО ТАКОЕ OPENSIPS? УСТАНОВКА

OpenSIPS обеспечивает функциональность практически всех серверных компонентов, которые были упомянуты выше, —от SIP-прокси до B2BUA. Отличие же его от Asterisk’а заключается, во-первых, в том, что OpenSIPS манипулирует паке-тами и сессиями SIP на более низком уровне, чем это делаетAsterisk, а во-вторых, Asterisk по сути является комбайном,например содержит в себе, помимо SIP, медиа сервер. Кроме того, Asterisk не поддерживает масштабирование.

OpenSIPS имеет давнюю историю: как минимум он (если считать и его предшественников) не младше Asterisk, а с учетом того, что SIP для последнего неродной, возможно, даже и старше. Он также поддерживает и модульную архитектуру,при этом модулей там предостаточно. В настоящий момент с нуля разрабатывается ветка 2.0, которая будет иметь другую архитектуру, — текущая закладывалась без учета части современных реалий, которые в те времена еще и не прогнозировались. Однако данная ветка находится в состоянии активной разработки, а я предпочитаю стабильные версии,поэтому здесь будет описана версия 1.11.3, которая, кстати,является LTS.

Итак, поехали устанавливать:

$ wget -qO - http://apt.opensips.org/key.asc | sudo apt-key add -
$ sudo sh -c "echo 'deb http://apt.opensips.org/stable111 main' &gt; /etc/apt/sources.list.d/opensips.list"
$ sudo apt-get update
$ sudo apt-get install opensips opensips-console

$ wget -qO - http://apt.opensips.org/key.asc | sudo apt-key add -

$ sudo sh -c "echo 'deb http://apt.opensips.org/stable111 main' > /etc/apt/sources.list.d/opensips.list"

$ sudo apt-get update

$ sudo apt-get install opensips opensips-console

НАЧАЛЬНАЯ НАСТРОЙКА OPENSIPS

В файле /etc/opensips/opensipsctlrc нужно настроить имя или адрес SIP-домена:

SIP_DOMAIN=192.168.56.103

1	SIP_DOMAIN=192.168.56.103

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

СКРИПТ МАРШРУТИЗАЦИИ

Основной конфигурационный файл OpenSIPS (в моем случае он был расположен по пути /etc/opensips/opensips.cfg) делится на три части:

Глобальные параметры, такие как логирование с отладкой,адреса, на которых OpenSIPS слушает, настройка количества дочерних процессов.
Параметры модулей. Сюда относятся путь к каталогу с мо-дулями, список самих загружаемых модулей и их параметры, например для модуля транзакций tm предусмотрена настройка самых разнообразных таймеров.
Наконец, логика маршрутизации. Именно здесь находитсясамая вкусная часть OpenSIPS. Каждый SIP-пакет, приходящий на (и проходящий через) OpenSIPS, обрабатывает-ся в соответствии с данной логикой. Разумеется, именно поэтому она может быть достаточно сложной. Как правило, здесь имеются несколько маршрутов — основной, аналогичный точке входа в какую-либо программу и несколь-ко дополнительных, направление на которых вызывается из основного. Дополнительные маршруты аналогичны функциям в процедурных языках программирования.

В принципе, для создания базового конфигурационного файла можно использовать команду osipsconfig, но его, темне менее, придется править ручками. Ниже будут приведены наиболее важные части из файла конфигурации с комментариями (к слову, допустимы как однострочные комментариив *nix-стиле, так и многострочные в стиле C++). Итак, часть секции глобальных параметров:

# Указываем на какм адресе или порте будет случать OpenSIPS
listen=udp:192.168.56.103:5060
# Отключаем поддержкуTCP и TLS
disable_tcp=yes
disable_tls=yes

# Указываем на какм адресе или порте будет случать OpenSIPS

listen=udp:192.168.56.103:5060

# Отключаем поддержкуTCP и TLS

disable_tcp=yes

disable_tls=yes

А теперь посмотрим некоторые параметры модулей:

# Пути к модулям
mpath="/usr/lib/opensips/modules"
# Загружаем модули sl и tm
loadmodule "sl.so"
loadmodule "tm.so"

#Настраиваем параметры модуля tm
modparam("tm", "fr_timeout", 5)
modparam("tm", "fr_inv_timeout", 30)
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "onreply_avp_mode", 1)
# Загружаем модуль-обертку SIGNALING
loadmodule "signaling.so"
&lt;...&gt;

# Пути к модулям

mpath="/usr/lib/opensips/modules"

# Загружаем модули sl и tm

loadmodule "sl.so"

loadmodule "tm.so"

#Настраиваем параметры модуля tm

modparam("tm", "fr_timeout", 5)

modparam("tm", "fr_inv_timeout", 30)

modparam("tm", "restart_fr_on_each_reply", 0)

modparam("tm", "onreply_avp_mode", 1)

# Загружаем модуль-обертку SIGNALING

loadmodule "signaling.so"

<...>

Пожалуй, стоит обратить внимание на данные модули.Первым загружается модуль sl, который отвечает за stateless-прокси. Параметры его мы не трогаем. Следующая строчказагружает модуль tm, который отвечает за stateful-прокси, —и уж тут как раз некоторые параметры нужно изменить. Рас-смотрим, что они означают:

fr_timeeout — интервал между запросом и предварительным ответом (таким как trying). Транзакция на моментпредварительного ответа еще не завершена. Этот тайм-аут истекает, если нет никакого ответа, при наличии жепредварительного ответа он сбрасывается. В секундах;
fr_inv_timeout — интервал между предварительным и окончательным ответом. Тайм-аут истекает, если с моментаполучения предварительного ответа окончательного таки не пришло. Опять же в секундах;• restart_fr_on_each_reply — указывает, должен ли fr_timeoutначинать отсчет сначала, если вызываемая сторона регу-лярно шлет предварительные ответы. Нулевое значение —false, любое другое — true;
onreply_avp_mode — как будут обрабатываться AVP(Atribute-Value pair) в маршруте Reply. Если не вдаватьсяв подробности, 1 означает, что AVP, относящиеся к данно-му маршруту, можно будет видеть и использовать и в не-которых других ветвях скрипта маршрутизации. Это, тем не менее, снижает производительность.

Модуль SIGNALING представляет собой обертку вокруг мо-дулей tm и sl для удобства работы.

Теперь наконец можно перейти к разбору структуры последней секции, которая, собственно, и является скриптом обработки запросов.

Первым идет так называемый main route block, в который попадают все пакеты. Как уже говорилось выше, этот блок аналогичен точке входа в стандартные программы. Рассмотрим, что он делает:

Пакет входит в данный блок, и происходят некоторые проверки.
Если пакет не предназначен нам, мы его направляем в блокrelay.
А если же он пришел к нам, мы, в зависимости от нужд,совершаем какие-то действия. Отмечу, что здесь можно направлять поток обработки в другие блоки, аналогично тому, как в программе на си из функции main() можно вызывать другие функции, описанные в коде программы.

Кроме блока типа route (к которому относится и названный выше и который обрабатывает входящие запросы), существует еще несколько типов блоков маршрутизации. Опишу неко-торые из них:

• branch_route — позволяет задавать действия в пределаходной транзакции. Понятно, что это актуально лишь в слу-чае stateful-маршрутизации;

• failure_route — обрабатывает полученные отрицатель-ные (с кодом большим или равным 300) ответы — при-чем ответы как приходящие извне, так и генерируемыесамим OpenSIPS. Опять же актуально только для stateful-маршрутизации;

• onreply_route — обрабатывает все нормальные ответы.Может быть как stateful — в случае если мы специальноуказываем, что ответ принадлежит какой-либо транзак-ции, так и stateless — если указываем, что маршрутизацияглобальная;

• error_route — обрабатывает ошибки при парсинге SIP-пакетов.

Поскольку даже самый простой скрипт маршрутизации,который почти ничем не занимается (реализует только базовый регистратор и редиректор), достаточно сложен, мы его разберем по косточкам:

# Точка входа
route{
# # Следующий условный оператор осуществляет проверку поля заголовка MaxForwards - счетчик «прыжков» маршрутизации. Если его значение равно нулю, посылается ответ 483 и прекращается обработка данного пакета. Помимо этого, функция mf_process_maxfwd_header() смотрит. а имеется ли вообще такой заголовок в пакете, если нет, то он создается и устанавливается в заданное значение - в данном случае 10.
if (!mf_process_maxfwd_header("70")) {
sl_send_reply("483","Too Many Hops");
exit;
}
# Далее мы проверяем наличие тега у поля To, который показывает, относится ли данный пакет к какому-либо диалогу.
if (has_totag()) {
# Пакет OPTIONS, помимо собственно запроса доступных опций, обычно используется в качестве средства проверки соединения. Следующая проверка служит для того, чтобы удостовериться, действительно ли пакет предназначен именно нашему прокси.
if (is_method("OPTIONS") &amp;&amp;
uri==myself &amp;&amp; (! uri=~"sip:.*[@]+.*")) {
options_reply();
exit;
}
# Смотрим, есть ли в пакете указание, куда его маршрутизировать дальше. Функция loose route() сама по себе очень многозначная (как и многие другие функции), и, если таковое указание имеется, она действует в соответствии с секцией 16.12 RFC 3261 за некоторыми исключениями (о них лучше почитать в документации).
if (loose_route()) {
# В серьезных скриптах маршрутизации здесь
и спрятана вся логика - например, осуществляется аккаунтинг. Однако, поскольку скрипт у нас исключительно простой, пакет мы просто маршрутизируем по направлению, которое в нем и задано.
route(relay);
} else {
#В случае же, если пакет не содержит маршрута, мы смотрим, не является ли он пакетом ACK, пришедшим в ответ на сообщение об ошибке, и переправляем его куда следует.
if (is_method("ACK")) {
if ( t_check_trans() ) {
t_relay();
exit;
} else {
# Если же данный запрос ACK не принадлежит никакой транзакции, мы просто его игнорируем.
exit;
}
}
#В остальных же случаях мы отправляем сообщение с кодом "404", аналогичное подобному же в HTTP.
sl_send_reply("404","Not here");
}
exit;
}
#Обрабатываем запросы, не относящиеся к заданному диалогу. Запрос CANCEL мы не трогаем и пересылаем дальше.
if (is_method("CANCEL")) {
if (t_check_trans()) {
t_relay();
}
exit;
}
#Функция t check trans() тоже имеет двойное назначение - если запрос не относится ни к ACK, ни к CANCEL, но относится к какой- то транзакции ретрансляции, она его ретранслирует дальше, что следующая строчка и делает. t_check_trans();
# Фильтруем пакеты, у которых есть поле Route, но не задано поле To (за исключением пакета ACK), и логируем о подобных попытках.
t_check_trans();
#Если запрос адресован не нам, добавляем поле Record-Route для принудительной маршрутизации SIP-трафика через наш прокси.
if (loose_route()) {
xlog("L_ERR",
"Attempt to route with preloaded Route's
[$fu/$tu/$ru/$ci]");
if (!is_method("ACK")) {
sl_send_reply("403",
"Preloaded Route denied");
}
}
#Если в запросе не фигурирует URI, который хоть как-то относится к нашему серверу, мы его отправляем в route(relay).
if (!is_method("REGISTER|MESSAGE")) {
record_route();
}
#Поддержку presence (сообщений о статусе присутствия абонента) тоже не реализуем, для чего отключаем методы.
if (!uri==myself) {
route(relay);
}
#Поддержку presence (сообщений о статусе присутствия абонента) тоже не реализуем,
для чего отключаем методы.
PUBLISH и SUBSCRIBE
if (is_method("PUBLISH|SUBSCRIBE")) {
sl_send_reply("503",
"Service Unavailable");
exit;
}
#Обработка запроса REGISTER. Для упрощения скрипта мы даем возможность регистрироваться всем, безо всякой аутентификации. Кроме того, база местоположений по тем же соображениям временная, в настоящую БД ничего не пишется
if (is_method("REGISTER")) {
if (!save("location", "m")) {
sl_reply_error();
}
exit;
}
#Функция lookup() проверяет, есть ли у нас в базе местоположений данный пользователь. Если его нет, мы создаем новую транзакцию и возвращаем "404". Опять же в серьезных скриптах здесь еще и проверяются поддерживаемые клиентом методы, чего мы не делаем.
if (!lookup("location")) {
t_newtran();
t_reply("404", "Not Found");
exit;
}
route(relay);
}
#Блок relay, который и обрабатывает все проходящие пакеты.
route[relay] {
#В случае INVITE мы смотрим, есть ли отрицательный результат транзакции, и, если есть, отправляем в соответствующий блок.
if (is_method("INVITE")) {
t_on_failure("fail");
}
#Наконец, пропускаем пакет дальше и, если он почему-либо не проходит,выдаем ошибку "500".
if (!t_relay()) {
send_reply("500",
"Internal Server Error");
}
}
# Блок fail, о котором было упомянуто выше.
failure_route[fail] {
#Если транзакция была отменена, мы просто выходим из блока.
if (t_was_cancelled()) {
exit;
}
}

100

101

102

103

104

105

106

# Точка входа

route{

# # Следующий условный оператор осуществляет проверку поля заголовка MaxForwards - счетчик «прыжков» маршрутизации. Если его значение равно нулю, посылается ответ 483 и прекращается обработка данного пакета. Помимо этого, функция mf_process_maxfwd_header() смотрит. а имеется ли вообще такой заголовок в пакете, если нет, то он создается и устанавливается в заданное значение - в данном случае 10.

if (!mf_process_maxfwd_header("70")) {

sl_send_reply("483","Too Many Hops");

exit;

}

# Далее мы проверяем наличие тега у поля To, который показывает, относится ли данный пакет к какому-либо диалогу.

if (has_totag()) {

# Пакет OPTIONS, помимо собственно запроса доступных опций, обычно используется в качестве средства проверки соединения. Следующая проверка служит для того, чтобы удостовериться, действительно ли пакет предназначен именно нашему прокси.

if (is_method("OPTIONS") &&

uri==myself && (! uri=~"sip:.*[@]+.*")) {

options_reply();

exit;

}

# Смотрим, есть ли в пакете указание, куда его маршрутизировать дальше. Функция loose route() сама по себе очень многозначная (как и многие другие функции), и, если таковое указание имеется, она действует в соответствии с секцией 16.12 RFC 3261 за некоторыми исключениями (о них лучше почитать в документации).

if (loose_route()) {

# В серьезных скриптах маршрутизации здесь

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

route(relay);

} else {

#В случае же, если пакет не содержит маршрута, мы смотрим, не является ли он пакетом ACK, пришедшим в ответ на сообщение об ошибке, и переправляем его куда следует.

if (is_method("ACK")) {

if ( t_check_trans() ) {

t_relay();

exit;

} else {

# Если же данный запрос ACK не принадлежит никакой транзакции, мы просто его игнорируем.

exit;

}

#В остальных же случаях мы отправляем сообщение с кодом "404", аналогичное подобному же в HTTP.

sl_send_reply("404","Not here");

}

exit;

}

#Обрабатываем запросы, не относящиеся к заданному диалогу. Запрос CANCEL мы не трогаем и пересылаем дальше.

if (is_method("CANCEL")) {

if (t_check_trans()) {

t_relay();

}

exit;

}

#Функция t check trans() тоже имеет двойное назначение - если запрос не относится ни к ACK, ни к CANCEL, но относится к какой- то транзакции ретрансляции, она его ретранслирует дальше, что следующая строчка и делает. t_check_trans();

# Фильтруем пакеты, у которых есть поле Route, но не задано поле To (за исключением пакета ACK), и логируем о подобных попытках.

t_check_trans();

#Если запрос адресован не нам, добавляем поле Record-Route для принудительной маршрутизации SIP-трафика через наш прокси.

if (loose_route()) {

xlog("L_ERR",

"Attempt to route with preloaded Route's

[$fu/$tu/$ru/$ci]");

if (!is_method("ACK")) {

sl_send_reply("403",

"Preloaded Route denied");

}

#Если в запросе не фигурирует URI, который хоть как-то относится к нашему серверу, мы его отправляем в route(relay).

if (!is_method("REGISTER|MESSAGE")) {

record_route();

}

#Поддержку presence (сообщений о статусе присутствия абонента) тоже не реализуем, для чего отключаем методы.

if (!uri==myself) {

route(relay);

}

#Поддержку presence (сообщений о статусе присутствия абонента) тоже не реализуем,

для чего отключаем методы.

PUBLISH и SUBSCRIBE

if (is_method("PUBLISH|SUBSCRIBE")) {

sl_send_reply("503",

"Service Unavailable");

exit;

}

#Обработка запроса REGISTER. Для упрощения скрипта мы даем возможность регистрироваться всем, безо всякой аутентификации. Кроме того, база местоположений по тем же соображениям временная, в настоящую БД ничего не пишется

if (is_method("REGISTER")) {

if (!save("location", "m")) {

sl_reply_error();

}

exit;

}

#Функция lookup() проверяет, есть ли у нас в базе местоположений данный пользователь. Если его нет, мы создаем новую транзакцию и возвращаем "404". Опять же в серьезных скриптах здесь еще и проверяются поддерживаемые клиентом методы, чего мы не делаем.

if (!lookup("location")) {

t_newtran();

t_reply("404", "Not Found");

exit;

}

route(relay);

}

#Блок relay, который и обрабатывает все проходящие пакеты.

route[relay] {

#В случае INVITE мы смотрим, есть ли отрицательный результат транзакции, и, если есть, отправляем в соответствующий блок.

if (is_method("INVITE")) {

t_on_failure("fail");

}

#Наконец, пропускаем пакет дальше и, если он почему-либо не проходит,выдаем ошибку "500".

if (!t_relay()) {

send_reply("500",

"Internal Server Error");

}

# Блок fail, о котором было упомянуто выше.

failure_route[fail] {

#Если транзакция была отменена, мы просто выходим из блока.

if (t_was_cancelled()) {

exit;

}

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

Конфигурация учетной записи в Linphone

Создание профиля в Twinkle

# sudo opensips -C

1	# sudo opensips -C

Затем включаем возможность запуска OpenSIPS в файле

/etc/default/opensips:
RUN_OPENSIPS=yes
И стартуем его:
$ sudo service opensips start

/etc/default/opensips:

RUN_OPENSIPS=yes

И стартуем его:

$ sudo service opensips start

Можно приступать к тестированию.

ТЕСТИРОВАНИЕ КОНФИГУРАЦИИ

Для тестирования используем два клиента, запущенныена двух машинах. Я использовал Linphone и Twinkle. В пер-вом для добавления учетной записи открываем настройки(Linphone → Preferences) и переходим на вкладку Manage SIPAccounts, где и добавляем с помощью кнопки Add.

В поле YourSIP identity ставим SIP-идентификатор (вида sip:имя_пользо-вателя@SIP-домен), а в поле SIP Proxy address пишем адрес(не SIP-домен!) SIP-прокси.В случае же с Twinkle при первом запуске будет пред-ложено создать учетную запись. Назови профиль и выберитип Wizard для создания учетной записи. Далее вбиваем всенужное. Единственное отличие от Linphone состоит в том,что в Twinkle имя пользователя пишется отдельно от домена.

После регистрации, чтобы убедиться, что клиенты доступ-ны, можно посмотреть список местоположений пользователей на сервере, для чего нужно набрать MI-команду:

# sudo opensipsctl fi fo ul_dump

1	# sudo opensipsctl fi fo ul_dump

Эта команда вызывает функцию MI (интерфейса управления) модуля usrloc — ul_dump, которая и выводит список пользователей, фактически зарегистрированных на сервере.
После этого уже можно звонить. С этим не должно возник-нуть особых проблем, но если они все-таки будут — используй функцию xlog() для логирования и tcpdump/Wireshark для ис-следования пакетов.

ЗАКЛЮЧЕНИЕ

OpenSIPS позволяет манипулировать с пакетами SIP чрезвычайно гибко. Однако порог вхожденияв него достаточно высокий — тре-буется не только досконально знатьпротокол, но и понимать, что дела-ет та или иная функция, и иметьпредставление, для чего в общемможет понадобиться какой-либомодуль, даже сам список которыхвыглядит внушительно.

В статье, разумеется, был за-тронут лишь самый минимумиз того, что умеет OpenSIPS, —не были рассмотрены ни автори-зация при регистрации, ни акка-унтинг, ни, тем более, настройкаOpenSIPS в качестве B2BUA. Темне менее общее представлениео возможностях OpenSIPS и о син-таксисе его файла конфигурацииу тебя должно сложиться. Ну а в том случае, если тебе это нуж-но, — дальше сможешь разобраться и сам.

Kurgan-Telecom Ru | Информационные технологии

Navigation

User login

Languages

Recent blog posts

Active forum topics

Habr.com

Linux.org.ru

SIP: Краткое введение

ЧТО ТАКОЕ OPENSIPS? УСТАНОВКА

НАЧАЛЬНАЯ НАСТРОЙКА OPENSIPS

СКРИПТ МАРШРУТИЗАЦИИ

ТЕСТИРОВАНИЕ КОНФИГУРАЦИИ

ЗАКЛЮЧЕНИЕ

Who's online