Открыто в IPv4 (3.17.181.112)

Возможности  ::   Установка  ::   Сообщество  ::   База знаний  ::   Специалисты

SER Модуль tm

Обзор

Модуль ТМ занимается обработкой stateful SIP транзакций (где результат обработки SIP сообщений зависит от состояния диалога). Основная причина использования stateful режима, который использует довольно много памяти и процессорного времени сервера - это предоставление и обработка услуг, состояние которых мы должны отслеживать. Например, Модуль Поддержки аккаутинга обрабатывает состояния транзакций, а не отдельные SIP сообщения, и любые виды ответвлений или изменений должны осуществляться в stateful режиме с контролем состояния SIP транзакции. Другое применение stateful обработки сообщений - это использование мощностей сервера для хранения данных, необходимых для повторной передачи SIP сообщений. Однако, это имеет смысл только, если есть существенный запас по процессорной мощности и памяти. Например, если Вы хотите избежать долгих DNS запросов при каждой повторной передаче SIP запроса по адресу, пункт назначения которого невозможно разрешить с помощью DNS, используйте stateful режим. Тогда, трудность возникнет с определением адреса назначения по DNS только один раз, все последующие повторные передачи будут блокированы, и не будут приводить к большему количеству запросов к DNS серверу. Ценой этого является больше потребления памяти и увеличение задержки при обработки SIP сообщений.

С точки зрения пользователя, основные возможности предоставляет главная функция - t_relay(). Она инициирует транзакцию и устанавливает ее состояние, контролирует и отбрасывает повторные передачи с upstream, генерирует повторные передачи SIP сообщений для downstream, и сопоставляет SIP ответы соответствующим запросам.

Вообще, при использовании этого модуля, он помещает копии полученных SIP сообщений в совместно используемой памяти (shared memory). Это приводит к повышенному потреблению памяти, а также потребляет процессорное время (функции: memcpys, lookups, shmem locks, и т.д.) Стоит отметить, что другие функции SER сервера, не принадлежащие ТМ модулю, работают с полученным SIP сообщением в своей частной памяти. Это означает, что любые основные операции с SIP сообщениями, не будут иметь никакого эффекта, в statefully режиме, после создания SIP транзакции. Например, вызов функции record_route после вызова t_relay - бесполезен, поскольку RR будет добавлено к локально сохраненному сообщению, тогда как пересылаться будет его копия, созданная модулем ТМ.

Модуль ТМ содержит весьма большое количество и не очень удобных в использовании наборов mutex'ов, кодов для доступа к совместно используемой памяти, функций malloc и free, и различных таймеров - Надо быть очень осторожным, когда Вы пытаетесь что-либо сделать. Для упрощения программы модуля ТМ используется инструмент обратных вызовов (callback). Этот механизм позволяет регистрировать определенные функции на определенные события. См. содержимое файла: t_hooks.h, чтобы получить список возможных событий.

Другая полезная для программистов вещь - UAC, это очень простой код, который позволяет Вам создавать собственные SIP транзакции. Что может быть полезно, например, для отправки NOTIFY сообщений или для организации системы обмена мгновенными сообщениями (IM). UAC заботится обо всех присущих транзакции моментах: повторной передачи SIP сообщений, FR таймауты, ответвления (fork), и т.д. См. описание прототипа: t_uac в файле uac.h для получения дополнительной информации.

Флаги специфичные для ветвления (branchs) маршрута.

Для начала, в чем состоит концепция обработки ветвления (branch) маршрутов для транзакции: ветка маршрута - это альтернативный маршрут до точки назначения, который обрабатывается отдельно для каждой из существующих веток (их может быть несколько) до того, как сообщение будет отправлено. Любые изменения в маршруте, должны отражаться только для конкретной ветки.

В OpenSER существует несколько типов флагов:

• флаги для сообщения/транзакции - они видны везде в пределах транзакции (во всех блоках маршрутизации, во всех последующих ответах и запросах).
• флаги для ответвлений в маршрутах (branch flag) - они видны только для конкретного ветвления в маршруте - во всех ответах и запросах, которые соответствуют конкретному ответвлению.
• флаги скрипта (script flags) - существуют только когда скрипт обрабатывает сообщение. Они ни где не сохраняются и теряются при выходе из главного блока маршрутизации.

Например: Мы получаем вызов и направляем его одновременно на шлюз и конкретному пользователю. И мы хотим знать, с какой из веток этого маршрута мы получили отрицательный финальный ответ (если получили). Мы устанавливаем блок маршрутизации сообщений, который будет обрабатывать сообщения относящихся к ответвлениям, перед отправкой этого вызова (с двумя ветками в маршруте). Обработка этих двух ответвлений одного маршрута будет производиться раздельно для каждой из ветки; для той части маршрута, что идет через шлюз (ее можно определить, используя поле request-URI), мы установим branch флаг. Этот флаг будет существовать в блоке обработки ответов только для сообщений поступивших с этого шлюза. Он также будет виден в блоке маршрутизации - failure_route, если финальный ответ относится к ветке маршрута к шлюзу. Этот флаг НЕ будет виден для других веток маршрута (в маршрутах, сообщения которых относятся к другим веткам).

О том, как использовать branch флаги и использовать их в скриптах, смотри описание функции t_on_branch(branch_route), setbflag(), resetbflag() и isbflagset().

Кроме того, модуль может установить branch флаг перед созданием транзакции (в настоящий момент, эта особенность не реализована). Модуль REGISTRAR был первым, в котором использовался этот тип флагов. NAT флаг теперь является branch флагом, вместо, ранее использовавшегося флага сообщения/транзакции.

Система преодоления отказов на основе таймеров.

Таймеры могут использоваться, для изменения работы в случае возникновения отказов. Например, если мы посылаем запрос на определенный шлюз и не получаем никакого ответа о начале обработки нашего запроса в течении 3 секунд, то мы хотим отменить этот запрос и послать вызов через другой шлюз. Второй пример: после отправки вызова SIP клиенту мы ожидаем ответа в течении 30 секунд, а затем переадресовывать вызов в систему голосовой почты.

В сервере SER существует два таймера:

• fr_timer - этот таймер используется, когда не получено никакого ответа. Если в течении fr_timer секунд не получено ни какого ответа, то срабатывает функция связанная с таймером (будет выполнен блок fail route, если была вызвана функция t_on_failure () ). Если был получено промежуточное ответное сообщение, таймер устанавливается в значение fr_inv_timer для INVITE транзакции или в RT_T2 для всех других транзакций. Если был получен окончательный ответ на запрос, то транзакция заканчивается.

• fr_inv_timer - этот таймер используется, когда был получен промежуточный ответ в пределах INVITE транзакции.

Например: Мы хотим перехватить управление, если не получен промежуточный ответ в течении 3 секунд, но Мы хотим ждать ответа абонента в течении 60 секунд. Тогда, устанавливаем fr_timer в значение 3 и fr_inv_timer в значение 60.

Система преодоления отказов на основе DNS

Система преодоления отказов, базирующаяся на DNS записях, может быть использована при передаче запросов в stateful режиме. Согласно RFC 3263, Она должна быть реализована либо на транспортном уровне, либо на уровне обработки транзакций. Модуль ТМ поддерживает обе технологии.

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

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

Набор IP адресов назначения выбирается из DNS записей пошагово (по запросу) основываясь на DNS записях типа: NAPTR, SRV и A, указанных для домена назначения SIP запроса.

Система преодоления отказов на основе DNS по умолчанию включена, за исключением тех случаев, когда это глобально запрещено (см. параметр ядра сервера: disable_dns_failover), или когда установлен relay флаг (для транзакции) (см. описание функции: t_relay() ).

Зависимости от других модулей.

Этот модуль имеет зависимости от следующих модулей (другими словами, ниже перечисленные модули должны быть загружены до загрузки этого модуля):

Нет зависимостей от других модулей.

Зависимости от внешних библиотек и приложений.

Следующие библиотеки или приложения должны быть установлены перед использованием SER с этим модулем:

Нет.

Экспортируемые параметры

fr_timer (integer)

Значение для таймера, который сработает, если на отправленный запрос не получено никакого ответа в указанный промежуток времени (в секундах).

Значение по умолчанию: 30 сек.

fr_inv_timer (integer)

Значение для таймера, который сработает, если на отправленный запрос INVITE не было получено финального ответа, после того, как был получен промежуточный ответ на это сообщение (в секундах). Таймер начинает отсчитываться после получения первого промежуточного ответа на сообщение. Таким образом, можно обеспечить алгоритм быстрого обнаружения нерабочего узла (не получено сообщения "100: trying" от шлюза) путем уменьшения значения для таймера fr_timer. См. примеры далее..

Значение по умолчанию: 120 сек.

wt_timer (integer)

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

Значение по умолчанию: 5 сек.

delete_timer (integer)

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

Значение по умолчанию: 2 сек.

T1_timer (integer)

Период для таймера повторной передачи сообщений - T1, в миллисекундах.

Значение по умолчанию: 500 миллисекунд.

T2_timer (integer)

Максимальный период для повторной передачи, в миллисекундах.

Значение по умолчанию: 4000 миллисекунд.

noisy_ctimer (integer)

Если значение установлено в ненулевое значение, то при срабатывании FR таймера для сообщений INVITE, вызов будет отменяться сообщением CANCEL, иначе - транзакция удаляется без всяких сообщений. Предпочтительнее, выключать отправку сообщения CANCEL при очень длительных попытках вызовов. Эта модель работы (без отправки сообщения CANCEL) отменяется, если запрос одновременно поступает по нескольким адресам, или какие-либо другие функции сервера явно включили отправку сообщения отмены для транзакции (например, модуль acc включает отправку сообщения CANCEL, чтобы избежать учета лишних соединений, при срабатывании таймера).

Значение по умолчанию: 0 (false).

ruri_matching (integer)

Значение параметра определяет, должна ли производиться проверка запрашиваемого uri (request-uri), согласно стандарту pre-3261 для SIP транзакций или нет. Рекомендуется выключать эту функцию, только для улучшения взаимодействия с устройствами, которые нарушают это соглашение и используют разные r-uri в сообщениях CANCEL/ACK отличные от указанных в оригинальном сообщении INVITE.

Значение по умолчанию: 1 (true).

via1_matching (integer)

Значение параметра определяет, должна ли производиться проверка полей VIA, согласно стандарту pre-3261 для SIP транзакций или нет. Рекомендуется выключать эту функцию, только для улучшения взаимодействия с устройствами, которые нарушают это соглашение и используют разные поля VIA в сообщениях CANCEL/ACK отличные от указанных в оригинальном сообщении INVITE.

Значение по умолчанию: 1 (true).

unix_tx_timeout (integer)

Значения таймаута для отправки, который будет использован для функций, работающими с UNIX сокетами (например: t_write_unix).

Значение по умолчанию: 2 сек.

restart_fr_on_each_reply (integer)

Если установлено true (не нулевое значение), таймер ожидания финального ответа будет перезапущен после приема каждого промежуточного ответа. В этом случае, время ожидания финального ответа на SIP сообщение может стать больше, чем указано для таймера в параметре fr_inv_timer (если UA периодически посылает промежуточные ответы).

Значение по умолчанию: 1 (true).

fr_timer_avp (string)

Полная спецификация (NAME, ID, Alias) для AVP, которая содержит значение таймаута ожидания финального ответа на сообщение. Если указано, то это значение перекрывает статически указанное значение в параметре fr_timer.

Если указана пустая строка, этот механизм, с применением различных значений таймаутов, будет выключен, будет использоваться значение статического параметра fr_timer.

Значение по умолчанию: "NULL" (выключено).

fr_inv_timer_avp (string)

Полная спецификация (NAME, ID, Alias) для AVP , которая содержит значение таймаута ожидания финального ответа на INVITE сообщение. Если указано, то это значение перекрывает статически указанное значение в параметре fr_inv_timer.

Если указана пустая строка, этот механизм, с применением различных значений таймаутов, будет выключен, будет использоваться значение статического параметра fr_inv_timer.

Значение по умолчанию: "NULL" (выключено).

tw_append (string)

Список дополнительной информации, которая будет добавлена к функциям: t_write_fifo и t_write_unix.

Значение по умолчанию: пустая строка.

Синтаксис параметра:

tw_append = append_name':' element (';'element)*

element = ( [name '='] pseudo_variable)


Лист поддерживаемых псевдо переменных (pseudo-variables) в OpenSER можно найти на: http://openser.org/docs/pseudo-variables-1.1.x.html.

Каждый элемент будет добавлен построчно в формате "name: value". Элемент "$rb (тело сообщения)" является единственным, который не имеет имени; тело сообщения будет всегда добавлено в конце, игнорируя его позицию в строке определения.

pass_provisional_replies (integer)

Включение/выключение передачи промежуточных ответов в FIFO приложения.

Значение по умолчанию: 0.

syn_branch (integer)

Включить/выключить использование генерации synonym branch ID для stateful режима в заголовках Via. Это увеличивает скорость обработки сообщений, но информация теряется при перезагрузке.

Значение по умолчанию: 1 (использовать synonym branches).

onreply_avp_mode (integer)

Параметр описывает, как должны обрабатываться AVP в блоке "reply route":


0 - AVP используются только для каждого отдельного сообщения; они не пересекаются с AVP сохраненными для транзакции; изначально - это будет пустой список в конце маршрута, все созданные тут AVPs будут отброшены.

1 - все AVP хранятся в пределах транзакции; изначально все AVP транзакции видимы в конце маршрута, список будет помещен обратно в транзакцию (со всеми внесенными изменениями).


При использовании режима 1, Вы можете видеть AVP, которые вы установили в блоке request route, branch route или failure route. Побочный эффект - уменьшение производительности из-за блокировок, которые необходимы для сохранения структуры AVP списков.

Значение по умолчанию: 0.

Экспортируемые функции.

t_newtran()

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

Внимание: все изменения в запросе, которые сделаны после вызова этой функции, не будут сохранены в транзакции!!!

Эта функция может использоваться из блока REQUEST_ROUTE.

t_relay( [flags] )

Передает сообщение в statefull режиме адресату, указанному в текущем URI. (Если оригинальное значение URI было перезаписано другими функциями, такими как: UsrLoc, RR, strip/prefix, и т.д., то будет использоваться новое значение URI). Возвращает отрицательное значение при ошибке - Вы можете все еще отправить отрицательный ответ вызывающему UA, в stateless режиме, чтобы не оставлять его в неопределенности.

Соответствующая SIP транзакция уже может быть создана или еще не существовать. Если она еще не была создана, данная функция ее автоматически создаст.

• 0x01 - не генерировать промежуточные ответы "100: trying" при создании транзакции. По умолчанию - эти промежуточные ответы будут отправляться. Используется, когда Вы уже отправили промежуточные сообщения другими функциями в stateless режиме.

• 0x02 - Не отправлять самостоятельно отрицательный ответ в случае неудачи. Это распространяется только на момент создания транзакции. По умолчанию - такие сообщения отправляются. Используется, если Вы хотите самостоятельно реализовать алгоритм обработки ситуаций с неудачными попытками вызовов.

• 0x04 - Выключение системы преодоления отказов на основе DNS для данной транзакции. Будет использоваться только первый полученный IP адрес. Данная система преодоления отказов блокируется, как на транспортном уровне, так и на уровне транзакций.

Эта функция может использоваться из блоков: REQUEST_ROUTE, FAILURE_ROUTE.

t_relay(proto:host:port,[flags])

Передает сообщение в statefull режиме по явно указанному адресу. Адрес указывается в виде: "[proto:]host[:port]" .

Эта функция может получать в качестве параметра набор флагов, которые модифицируют ее поведение - смотри описание выше, для функции "t_relay([flags])" .

Эта функция может использоваться из блоков: REQUEST_ROUTE, FAILURE_ROUTE.

t_reply(code, reason_phrase)

Отправка ответа в stateful режиме, когда транзакция уже создана. Смотри описание функции t_newtran.

Параметры содержат след. значения:

• code - Номер возвращаемого кода.
• reason_phrase - Строка с описанием причины.

Эта функция может использоваться из блоков: REQUEST_ROUTE, FAILURE_ROUTE.

t_replicate(URI,[flags])

Отправляет копии запроса на другие адреса назначения. Никакой информации (например, коды ответа) не отправляется SIP клиенту, отправившему запрос.

Адрес назначения указывается в виде SIP URI. Если используется несколько адресов назначения, то все дополнительные SIP URI будут помечены, как ответвления (branches).

Эта функция может получать в дополнительном параметре необязательный набор флагов, для управления особенностями внутреннего поведения - они аналогичны флагам функции "t_relay([flags])" . Стоит отметить, что здесь применим только флаг: 0x4.

Эта функция может использоваться из блока: REQUEST_ROUTE.

t_release()

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

Эта функция может использоваться из блока: REQUEST_ROUTE.

t_check_status(re)

Возвращает истину, если регулярное выражение "re" подходит для кода возврата полученного ответного SIP сообщения, следующим образом:

• в основном блоке маршрутизации - выражение сопоставляется с кодом возврата последнего отправленного ответного сообщения.
• в блоке маршрутизации on_reply - сопоставляется с кодом возврата текущего полученного ответа.
• в блоке маршрутизации on_failure - сопоставляется с кодом ошибки полученного финального отрицательного ответа на SIP запрос.

Эта функция может использоваться из блоков: REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE и BRANCH_ROUTE .

t_flush_flags()

Очищает флаги текущего запроса в пределах уже созданной транзакции. Это имеет значение, только в блоках маршрутизации, если транзакция была создана функцией t_newtran(), и после этого значения флагов изменились.

Эта функция может использоваться из блоков: REQUEST_ROUTE и BRANCH_ROUTE .

t_local_replied(reply)

Возвращает истину, если все или последний (в зависимости от параметра) локально сгенерированные ответ(ы) были отправлены (но не приняты).

Параметр может принимать значения: "all" или "last".

Эта функция может использоваться из блоков: REQUEST_ROUTE, BRANCH_ROUTE, FAILURE_ROUTE и ONREPLY_ROUTE.

t_write_fifo(info,fifo) t_write_unix(info,sock)

Функции записывают в FIFO файл или UNIX сокет некоторую информацию из запроса. То, какая информация должна быть записана, управляется параметром "tw_append".

Эта функция может использоваться из блоков: REQUEST_ROUTE, FAILURE_ROUTE и BRANCH_ROUTE.

t_check_trans()

Возвращает истину, если текущий запрос связан с транзакцией. Отношения между транзакцией и запросом определяются следующим образом:

• non-CANCEL/non-ACK запросы - истина, если запрос принадлежит транзакции; если так, то это означает, что запрос является повторной передачей.
• Запрос CANCEL - истина, если отменяется существующая INVITE транзакция.
• Запрос ACK - истина, если ACK - локальный согласованный ACK для существующей INVITE транзакции.

Эта функция может использоваться из блоков: REQUEST_ROUTE и BRANCH_ROUTE.

t_was_cancelled()

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

Эта функция может использоваться из блоков: ONREPLY_ROUTE, FAILURE_ROUTE.

t_on_failure(failure_route)

Функция определяет блок, который будет обрабатывать ответы на SIP запросы в том случае, если транзакция завершилась с отрицательным результатом, но до отправки финального ответа. В указанном блоке, Вы можете либо запустить новое ответвление для вызова (например, реализовать сервис переадресации при не ответе - forward_on_no_reply) или отправить финальный ответ самостоятельно (например, подходит для хранилища сообщений, когда при получении отрицательного ответа с upstream, можно отправить ему сообщение - "202 I will take care of it").

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

Только один блок failure_route может быть закреплен за запросом. Если Вы несколько раз используете t_on_failure(), то будет использоваться значение только последней функции.

Обратите внимание, что всякий раз, при входе в блок маршрутизации failure_route, значение R-URI будет установлено в значение того ответвления SIP транзакции, которое первым удалось успешно организовать.

Значение параметров следующие:

• failure_route - название блока маршрутизации ответных сообщений, который будет использоваться.

Эта функция может использоваться из блоков: REQUEST_ROUTE, BRANCH_ROUTE, ONREPLY_ROUTE и FAILURE_ROUTE.

t_on_reply(reply_route)

Функция определяет блок, который будет обрабатывать ответы на SIP запросы, управление которому передается каждый раз при приеме (промежуточных и финальных ) ответов в пределах транзакции. Этот блок маршрутизации не используется для локально сгенерированных ответов! В описываемом блоке маршрутизации, Вы можете анализировать ответные сообщения и выполнять с ними некоторые текстовые операции.

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

Только один блок reply_route может быть закреплен за запросом. Если Вы несколько раз используете t_on_reply(), то будет использоваться значение только последней функции.

При обработке промежуточных ответных сообщений (с кодом: 1xx), вызывая функцию drop() (экспортируется ядром сервера SER), Вы можете закончить обработку этого сообщения без дальнейшей его отправки клиенту.

Значение параметров следующие:

• reply_route - название блока маршрутизации ответных сообщений, который будет использоваться.

Эта функция может использоваться из блоков: REQUEST_ROUTE, BRANCH_ROUTE, ONREPLY_ROUTE и FAILURE_ROUTE.

t_on_branch(branch_route)

Функция устанавливает блок маршрутизации, который будет обрабатывать сообщения отдельно для каждого из ответвления (branch) транзакции, до отправки сообщения. Изменения в маршруте касаются только того ответвления, которое обрабатывается в данный момент.

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

Только один блок branch_route может быть закреплен за запросом. Если Вы несколько раз используете t_on_branch(), то будет использоваться значение только последней функции.

Вызывая функцию drop() (экспортируется ядром сервера SER), Вы можете закончить обработку этого ответвления маршрута, и оно не будет далее использоваться.

Значение параметров следующие:

• branch_route - название блока маршрутизации сообщений для ответвлений (branch) транзакции, который будет использоваться.

Эта функция может использоваться из блоков: REQUEST_ROUTE, BRANCH_ROUTE, ONREPLY_ROUTE и FAILURE_ROUTE.

Экспортируемые псевдопеременные.

$T_branch_idx

$T_branch_idx - это индекс (начинается с 1 для первого ветвления маршрута) ветвления маршрута для которого выполняется блок маршрутизации branch_route[]. Если используется вне блока маршрутизации branch_route[], то принимает значение - '0'.

$T_reply_code

$T_reply_code - код ответа, определяется следующим образом: в блоке маршрутизации request_route - это код последнего ответа, отправленного в режиме stateful; в блоке reply_route - код ответа текущего обрабатываемого ответа; в блоке failure_route - это код отрицательного финального ответа. В случае если нет ответов или произошла ошибка, возвращаемое значение равно '0'.

Экспортируемая статистика.

• received_replies - Общее кол-во ответных сообщений, принятых модулем TM (значение можно сбросить).
• relayed_replies - Общее кол-во ответных сообщений, принятых и переправленных модулем TM (значение можно сбросить).
• local_replies - Общее кол-во ответных сообщений, локально сгенерированных модулем TM (значение можно сбросить).
• UAS_transactions - Общее кол-во транзакций, которые были созданы поступившими запросами (значение можно сбросить).
• UAC_transactions - Общее кол-во транзакций, созданных локально сгенерированными запросами (значение можно сбросить).
• 2xx_transactions - Общее кол-во транзакций, завершившихся ответом с кодом возврата 2xx (значение можно сбросить).
• 3xx_transactions - Общее кол-во транзакций, завершившихся ответом с кодом возврата 3xx (значение можно сбросить).
• 4xx_transactions - Общее кол-во транзакций, завершившихся ответом с кодом возврата 4xx (значение можно сбросить).
• 5xx_transactions - Общее кол-во транзакций, завершившихся ответом с кодом возврата 5xx (значение можно сбросить).
• 6xx_transactions - Общее кол-во транзакций, завершившихся ответом с кодом возврата 6xx (значение можно сбросить).
• inuse_transactions - Кол-во транзакций, которые в данный момент существуют в памяти (значение нельзя сбросить).

Ссылки по теме

• Документация на модуль tm
• SIP Express Router