- База знаний
- Пример файла конфигурации XML для Cisco 8851 phone
- Пример файла конфигурации XML для Cisco 7970 phone
- Пример файла конфигурации XML для Cisco 9971
- Отладка VoIP звонка с Wireshark
- Книги
- Использование поля Diversion в SIP пакете
- Астериск и Н.323
- ISDN release cause codes
- Пример файла конфигурации голосового шлюза Cisco
- Пример конфигурации интерфейса E1 PRI в голосовом шлюзе Cisco
- Аналоговое зло
- Интернациональные телефонные коды стран
- Практикум по интеграции Астериск в комплексе с OpenBSC/Osmocom
- Факс по IP
SER Модуль rr
Данный модуль реализует логику записи маршрутов для SIP сообщений и поддержку диалогов.
Поддержка SIP диалогов.
Сервер SER, в основном, является только статусозависимым (statefull) прокси сервером, который ориентирован на использование транзакций, без встроенной поддержки SIP диалогов. Есть много особенностей/сервисов, для которых фактически требуется наличие механизма диалогов, как места для хранение информации, формируемой в стадии создания диалога, которая будет использоваться в течении всего SIP диалога.
Большинство примеров обхода проблем, возникающих при использовании NAT, имеют дело со всем диалогом, который начинается с сообщения INVITE (re-INVITE). Обрабатывая первое сообщение INVITE, прокси сервер определяет, находиться ли вызывающая или вызываемая сторона за NAT, и корректирует некоторые параметры сигнализации и канала передачи медиаданных - т.к. не весь механизм обнаружения NAT доступен для запросов в пределах диалога (usrloc) для того, чтобы мы смогли соответствующим образом скорректировать последующие запросы, прокси сервер должен помнить, как был обработан оригинальный запрос на предмет обнаружения NAT. Есть много других случаев, где применение механизма диалогов очень сильно помогает и облегчает жизнь.
Решение этой задачи состоит в том, чтобы хранить дополнительную, связанную с диалогом информацию, в наборе параметров, используемых для маршрутизации (заголовки Record-Route/Route), эти заголовки присутствуют во всех последующих запросах. Таким образом, любая информация, добавленная к заголовку Record-Route будет обнаружена (вне зависимости от направления) в заголовке Route (который соответствует адресу прокси сервера).
Как хранилище информации, будут использоваться параметры заголовка: Record-Route / Route - использование параметра Record-Route отражено и закреплено в RFC 3261 (см. 12.1.1 UAS behavior).
Для этих целей, модули предоставляет следующие функции:
- add_rr_param()
- check_route_param()
Зависимости от других модулей.
Этот модуль имеет зависимости от следующих модулей (другими словами, ниже перечисленные модули должны быть загружены до загрузки этого модуля):
Нет зависимостей от других модулей.
Зависимости от внешних библиотек и приложений.
Следующие библиотеки или приложения должны быть установлены перед использованием OpenSER с этим модулем:
Нет.
Экспортируемые параметры.
enable_full_lr (integer)
Если значение естановлено в 1, тогда будет использоваться форма ";lr=on", вместо ";lr". Это предотвращает возможные проблемы при работе с некоторыми некорректно работающими пользовательскими агентами, которые отрезают параметр ";lr", при формировании заголовочного поля Route из Record-Route (использование ";lr=on" помогает решить эту проблему).По умолчанию: 0 (нет).
Пример использования параметра enable_full_lr:
...
modparam("rr", "enable_full_lr", 1)
...
append_fromtag (integer)
Если включено, то from тег из запроса будет добавлен в record-route; это полезно для определения того, от кого из сторон диалога пришли последующие запросы (например, BYE), с вызывающей стороны (from тег в поле route==from тегу BYE сообщения) или от вызываемой стороны (from тег в поле route==to тегу в сообщении BYE) .По умолчанию: 1 (да).
Пример использования параметра append_fromtag:
...
modparam("rr", "append_fromtag", 0)
...
enable_double_rr (integer)
Существуют некоторые ситуаций, когда сервер должен вставить два заголовочных поля Record-Route вместо одного. Например, при использовании двух разъединенных сетей или пересылая сообщения с трансляцией протоколов: UDP-> TCP. Этот параметр допускает вставку двух заголовочных полей Record-Route. Позже сервер удалит оба из них.По умолчанию: 1 (да).
Пример использования параметра enable_double_rr:
...
modparam("rr", "enable_double_rr", 0)
...
add_username (integer)
Если параметр установлен в ненулевое значение (что подразумевает - yes), часть, хранящая имя пользователя, также будет добавлена в URI поля Record-Route.По умолчанию: 0 (нет).
Пример использования параметра add_username:
...
modparam("rr", "add_username", 1)
...
Экспортируемые функции.
loose_route()
Функция выполняет маршрутизацию SIP запросов, которые содержат набор параметров для маршрутов. Название является несколько странным, т.к. эта функция также используется для маршрутизации запросов в формате "строгой маршрутизации (strict router)".Эта функция часто используется, для маршрутизации запросов в пределах диалога (такие, как: ACK, BYE, re-INVITE). Однако запросы, не принадлежащие диалогу, также могут иметь "предварительно загруженный набор параметров для маршрута" и могут быть обработаны с помощью этой функции. Она также заботится о трансляции между "строгой маршрутизацией" и "свободной маршрутизацией".
Функция loose_route анализирует заголовка Route: в поступающих запросах. Если нет никаких заголовков Route:, функция возвращает FALSE, и маршрутизация должна производиться обычными функциями поиска маршрута. Если найден заголовок Route:, функция вернет 1 и ведет себя как это описано в разделе 16.12 RFC 3261. Есть только одно исключение: Если запрос не принадлежит диалогу (нет тега to:) и есть только один заголовок Route:, указывающий на локальный прокси сервер, тогда заголовок Route: удаляется и функция возвращает FALSE.
Позаботьтесь о том, чтобы Ваша функция loose_routing не могла бы быть использована для обхода авторизации Вашего прокси сервера.
Логика работы функции loose_routing очень обширная. Для дополнительной информации см. RFC3261 (для начала, в этот RFC можно вникать при помощи команды: grep "route set").
Эта функция может использоваться из блока REQUEST_ROUTE.
Пример использования функции loose_route:
...
loose_route();
...
record_route() и record_route(string)
Эта функция добавляет новое заголовочное поле Record-Route. Это поле будет помещено в сообщение до всех остальных полей Record-Route.Если в качестве параметра указана любая строка, она будет добавлена в качестве URI параметра к заголовочному полю Record-Route. Строка должна иметь форму: ";name=value" и в ней можно использовать псевдопеременные.
Эта функция может использоваться из блоков REQUEST_ROUTE, BRANCH_ROUTE и FAILURE_ROUTE.
Пример использования функции record_route:
...
record_route();
...
record_route_preset(string)
Эта функция поместит строку в заголовочное поле Record-Route, используйте эту функцию, если Вы точно уверены в том, что Вы делаете.Параметры имеют следующие значения:
- string - Строка, которая будет помещена в заголовочное поле; Она может содержать псевдопеременные.
Эта функция может использоваться из блоков REQUEST_ROUTE, BRANCH_ROUTE и FAILURE_ROUTE.
Пример использования функции record_route_preset:
...
record_route_preset("1.2.3.4:5090");
...
add_rr_param(param)
Добавление параметра к URI в заголовочном поле Record-Route (параметр должен быть в формате: ";name=value"). Эта функция может вызываться как до, так и после функции record_route().Параметры имеют следующие значения:
- param - строка, содержащая добавляемый к URI параметр. Должна быть в формате: ";name=value"; может содержать в себе псевдопеременные.
Эта функция может использоваться из блоков REQUEST_ROUTE, BRANCH_ROUTE и FAILURE_ROUTE.
Пример использования функции add_rr_param:
...
add_rr_param(";nat=yes");
...
check_route_param(re)
Эта функция проверяет параметры URI локального заголовка Route (который относится к нашему серверу) на соответствие заданному регулярному выражению. Она должна вызываться после функции loose_route().Параметры имеют следующие значения:
- re - регулярное выражение, с которым производиться соответствие параметров в URI, заголовка Route.
Эта функция может использоваться из блока REQUEST_ROUTE.
Пример использования функции check_route_param:
...
if (check_route_param("nat=yes")) {
setflag(6);
}
...
is_direction(dir)
Функция проверяет направление движения полученного запроса. Для проверки используется параметр "ftag" заголовка Route, для работы необходимо включить параметр append_fromtag. Функция должна вызываться также после вызова loose_route().Функция возвращает TRUE, если проверяемое направление, указанное в параметре "dir", совпадает с направлением движения запроса.
Определение для направления запроса: "downstream" (от UAC к UAS) соответствует тому клиенту, SIP запрос которого создал данный SIP диалог.
Параметры имеют следующие значения:
- dir - строка, содержащая проверяемое направление следования сообщения. Она может принимать значение: "upstream" (от UAS к UAC) или "downstream" (от UAC к UAS).
Эта функция может использоваться из блока REQUEST_ROUTE.
Пример использования функции is_direction:
...
if (is_direction("upstream")) {
xdbg("upstream request ($rm)\n");
}
...