Что такое SIP и как он работает

Архитектура сервера SER и файл конфигурации ser.cfg

Ядро и модули.

Работа SER основана на ядре-обработчике, которое принимает SIP сообщения и поддерживает только самые базовые действия по их обработке. Большинство других функциональных возможностей SER обеспечивается путем подключения к нему модулей, что очень похоже на метод, примененный в http сервере Apache. Использование модульной архитектуры, позволяет SER иметь очень небольшое, быстро работающее и устойчивое основное функциональное ядро. Модули SER'a расширяют его функциональные возможности, которые могут быть задействованы в файле конфигурации SER - ser.cfg. Файл ser.cfg - это файл конфигурации, в нем определяется, какие модули должны быть загружены и как они должны работать, путем установки переменных для каждого конкретного модуля. Файл ser.cfg - это мозг SIP маршрутизатора SER.

Семь секций файла конфигурации ser.cfg.

Файл ser.cfg имеет семь главных логических разделов:

1. Раздел с глобальными определениями. В этой части файла ser.cfg обычно содержатся IP адрес и порт для приема и отправки сообщений, уровень отладки, и т.д. Параметры настройки в этом разделе относятся непосредственно к демону SER.
2. Секция модулей. Этот раздел содержит список внешних библиотек, которые необходимо загрузить для обеспечения требуемых функциональных возможностей, не предоставляемых ядром, как это было отмечено выше. Модули - это .so файлы, которые загружаются командой loadmodule.
3. Секция конфигурации загруженных модулей. Для многих из внешних библиотек, определенных в секции модулей, должны были установлены параметры, необходимые для их работы. Эти параметры устанавливаются при помощи команды modparam, которая имеет форму: modparam (module_name, module_parameter, parameter_value).
4. Главный блок маршрутизации. Этот блок похож на функцию main() программы, написанной на языке C. Это - точка входа для обработки SIP сообщений, где определяется, как каждое полученное сообщение должно быть обработано.
5. Вторичные блоки маршрутизации. В дополнение к главному блоку маршрутизации, файл ser.cfg может содержать дополнительные блоки маршрутизации, которые можно вызывать из главного блока или из других вторичных блоков маршрутизации. Вторичные блоки маршрутизации больше похожи на вызываемые функции или подпрограммы.
6. Блок маршрутизации ответов. Дополнительные блоки маршрутизации для ответов на SIP сообщения могут использоваться для обработки ответов. Чаще всего - это сообщения OK.
7. Блок маршрутизации сообщений об отказах. Дополнительные блоки маршрутизации, которые используются в случае, если требуется специальная обработка состояний ошибок или отказов, таких как занятость вызываемого абонента или таймаутов.

Для настройки очень важно понимание SIP протокола и назначение различных типов сообщений, использующихся в SIP сигнализации. Естественно, после описания различных установок в этой документации, Вы найдете рабочий пример с настройками. Однако, перед тем как начать приспосабливать эту конфигурацию под Ваши потребности, рекомендуется самостоятельно изучить принципы работы протокола SIP. Обратите внимание на неплохое введение по ссылке: http://www.iptel.org/ser/doc/sip_intro/sip_introduction.html. Более детальное описание можно найти по ссылке: http://www.iptel.org/sip/siptutorial.pdf. Официальное RFC для SIP протокола, находиться по ссылке: http://www.ietf.org/rfc/rfc3261.txt.

Транзакции, Диалоги и Сеансы.

Для должного понимания синтаксиса, применяемого в файле конфигурации ser.cfg, Вы должны понять три концепции, используемые в SIP протоколе:

1.SIP транзакция: это SIP сообщение (и все повторные попытки его передачи) и прямое на него (чаще всего быстрое и непосредственное) ответное сообщение (например: пользовательский клиент отправляет сообщение REGISTER серверу SER и получает ответное сообщение - OK);
2.SIP диалог: Общение между (как минимум) двумя SIP устройствами, которое производится в течении некоторого времени (например, диалог начинается с отправки сообщения INVITE и заканчивается сообщением BYE);
3.Сеанс: Состояние установленного потока обмена медиаданными (например, голосовой канал) между SIP устройствами (SIP телефонами).

Эти концепции довольно трудны для понимания, но Вы можете вернуться к этому разделу еще раз, когда будете читать разделы, посвященные изучению ser.cfg в этом документе. Эти концепции используются в следующих разделах этой документации для объяснения некоторых довольно запутанных моментов.

Обратите внимание: если Вы взгляните на SIP сообщение, то Вы можете соотнести его с определенной SIP транзакцией, используя числовое значение поля Cseq в заголовке сообщения. Каждый SIP диалог будет иметь одинаковое значение поля ]]Call-Id[ в заголовке сообщения (так же, как один ID используется для идентификации каждой стороны в процессе диалога).

Понимание процесса обработки SIP с использованием файла ser.cfg.

Вы можете представить ser.cfg как файл сценария, который выполняется каждый раз, когда принимается новое SIP сообщение. Например, пользовательский агент (UA) (SIP телефон Васи) хочет послать приглашение другому пользовательскому агенту (UA) (SIP телефону Пети) начать сеанс связи (Вася звонит Пете). Вася отправляет SIP сообщение INVITE к SER серверу и тот начинает обрабатывать его, начиная с точки main route{} в файле ser.cfg, выполняя найденные там команды.

Обработка продолжится, пока не будет достигнута точка завершения обработки сообщения, где будет принято одно из решений: отправить ли SIP сообщение INVITE Пете (используя команду t_relay() ), отправить ли Васе ответ с сообщением об ошибке (используя sl_send_reply()) или просто игнорировать это сообщение INVITE от Васи (при достижении конца основного блока маршрутизации или директивы break), что, конечно, не рекомендуется.

Петя ответит на INVITE сообщением OK. OK – это непосредственный ответ на сообщение инициации сеанса INVITE, и такое ответное сообщение обрабатывается в шестой секции маршрутизации - on_reply_route [x] . Если Петя не ответил или ответил сообщением об ошибке (занято, и т.д.), то оно будет обработано в седьмом блоке маршрутизации - failure_route [x] .

И, наконец, Вася отправит сообщение ACK, чтобы сказать Пете, что все было получено и подтверждено.

Замечание 1: описанное поведение зависит от использования команды t_relay() в файле ser.cfg. В этом случае, говорят, что SER имеет дело с транзакцией зависимой от состояния - ‘stateful’ (см следующий раздел).

Замечание 2: INVITE диалог также включает в себя промежуточные ответные SIP сообщения (пытаюсь вызвать - ‘trying’, вызываю абонента – ‘ringing’) перед окончательным ответным SIP сообщением ‘OK’, но мы не будем их рассматривать для простоты картины.

Итак, все это обрабатывается в файле ser.cfg? Все SIP сообщения, инициализирующие новую SIP транзакцию, попадают в main route{}. Как рассматривалось Выше, Вася начинает транзакцию сообщением INVITE, на которую Петя отвечает сообщением OK.

Вы имеете большую степень свободы в том, как будет описана обработка SIP сообщений в файле ser.cfg. Например, для определения, что учетная запись Пети доступна для вызова, Вы можете использовать функцию save(location) для всех SIP сообщений REGISTER с IP телефона Пети. Далее, вызов функции lookup(location) отыщет местоположение IP телефона Пети, для того, чтобы имелась возможность его вызвать. Кроме того, некоторая небольшая информация о телефоне Пети может быть сохранена в форме флажков, при использовании функции setflags(). (Начиная с версии 0.9.0 также появилась поддержка пар атрибут-значение, которые могут быть загружены/получены для заданного подписчика, но более детально об этом позже).

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

Этот документ представляет справочную информацию по синтаксису файла ser.cfg, дабы дать Вам возможность быстро настроить SER для большинства часто востребованных функций, которые обычно требуются от SIP маршрутизатора SER.

Stateful и stateless

Очень часто наблюдается недопонимание различий двух концепции обработки сообщений: stateful – где результат обработки сообщений зависит от состояния диалога и stateless – где результат обработки SIP сообщений не зависит от состояния диалога. Описание SIP транзакции INVITE - это пример обработки сообщений в режиме stateful диалога. Это значит, что SER будет знать, что принятое ответное SIP сообщение OK соответствует изначальному сообщению INVITE, и Вы будете иметь возможность обработать это сообщение OK в блоке onreply_route [x] . При обработке сообщений, не зависящих от состояния диалога - stateless (что является простым транзитом сообщения), каждое сообщение в процессе диалоге обрабатывается вне какого-либо контекста. Транзит SIP сообщений используется для простой обработки SIP сообщений, например, в целях распределения нагрузки.

Чтобы иметь возможность осуществлять любые расширенные функциональные возможности, такие, как учет вызовов, перенаправление вызова при занятости абонента, голосовая почта и другие, настройка которых описывается в этом документе, Вам необходимо использовать обработку сообщений в режиме stateful. Каждая SIP транзакция сохраняется в памяти маршрутизатора SER так, чтобы любые ответные сообщения, отказы или повторные передачи сообщений можно было бы отнести к какой-либо транзакции. Одно последствие – это то, что при использовании t_relay () для SIP сообщений маршрутизатор SER будет опознавать, новое ли это сообщение или повторное, и будет действовать соответствующим образом. При использовании обработки сообщений в режиме, не зависящем от состояния - stateless, повторно принятое INVITE сообщения будет передано так, как будто оно было первым сообщением.

Тут возникает некоторая неразбериха вследствие того, что stateful обработка сообщений основывается на SIP транзакциях, а не на SIP диалогах (что по сути есть телефонные вызовы)! Телефонный вызов (SIP диалог) состоит из нескольких транзакций, а SER не сохраняет информацию о транзакциях происходящих в пределах одного телефонного вызова. Следствием этого является то, что SER не может завершить установленное соединение по телефону (он просто не знает, что вызов все еще продолжается), и как итог - SER не может вычислить продолжительность телефонного вызова (для учета и билинга). Однако SER может сохранить поле ]]Call-Id[, когда он получает SIP сообщения: INVITE (или ACK) и BYE. Приложение, которое ведет учет вызовов, в свою очередь может найти соответствующие пары сообщений INVITE/BYE и вычислить продолжительность вызова.

Понимание, что такое SIP и что такое RTP.

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

Когда SIP сервер, такой как SER, принимает сообщение, он может решить, остаться ему на пути следования телефонного вызова или нет. Если нет, то SER предоставит каждому пользователю информацию о том, как они могут связаться друг с другом и передавать SIP сообщения непосредственно между собой.

Если же SER желает остаться на пути следования вызова, например, чтобы быть уверенным в получении SIP сообщения BYE в целях учета вызовов, маршрутизатор SER должен вставить в заголовок SIP сообщения поле Route (используя функцию record_route () ), чтобы сообщить каждому абоненту и другим SIP серверам, что он участвует в передаче сообщений. Для того, чтобы работала эта схема, SER и другие потенциальные SIP сервера на пути следования вызова могут производить его маршрутизацию по своему усмотрению, добавляя при этом заголовок Route в SIP сообщение. Упрощая, это означает, что SIP сообщения не должны отправляться непосредственно пользовательским агентам, а косвенно через всех, кто поместил заголовок Route в SIP сообщение (чтобы проверить эти записи маршрута, используется функция loose_route (),).

SIP сообщение может включать дополнительную информацию, например, связанную с тем, как установить звуковое или видео соединение (оно называется SDP - Протокол Описания Сеанса). Информация из SDP приведет к созданию одного или нескольких RTP потоков (или сеансов), которые обычно создаются непосредственно между двумя пользовательскими агентами. SER никогда не участвует в создаваемых RTP потоках. RTP потоки по своей природе требуют большой пропускной способности канала и интенсивной обработки. Однако, как мы опишем позже, SER может обеспечивать, чтобы приложения сторонних производителей, такие как B2BUA или RTP proxy, могли находиться на пути следования RTP потоков.
Наконец, Протокол Управления в Реальном Времени (RTCP) используется для передачи информации о RTP потоках между пользовательскими агентами (RTCP будет использовать либо порт RTP + 1, либо порт, указанный в сообщении SDP ).

Back-end приложения и B2BUA

Мы знаем, что SER не сохраняет состояние диалога, а только передает SIP сообщения (как часть транзакций) между двумя пользовательскими агентами. Из-за этого SER не может быть инициатором или выступать в роли конечного пользователя в SIP диалоге.

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

Замечание: В добавление к каше понятий: когда SER используется в stateful режиме обработки транзакций, для обозначения режима работы back-end приложения, обеспечивающего функции пользовательского агента, его называют stateful пользовательский агента сервера. (Пользовательский агент работающий на сервере и отслеживающий состояние диалога и сеанса в целом).

Кроме того, если Вы захотите осуществлять обслуживание по предоплате, то у Вас могут возникнут проблемы, так как SER не может завершить соединение, когда, например, закончились деньги на счету! При этом сценарии Вам необходима третья сторона для этого SIP диалога (и весьма возможно и для всего сеанса). Она будет выступать в роле посредника как для SIP сообщений, так и для аудио потока. В этом случае, каждый пользовательский агент будет работать с этим посредником и ничего не будет знать об реальном удаленном пользователе. Этого посредника можно представить как пользовательского агента с интерфейсами в две стороны B2BUA (Back-to-Back User Agent), как его называют в списке рассылки serusers. B2BUA агент может обрабатывать или только SIP сообщения, или одновременно SIP сообщения и RTP потоки.

NAT, STUN и проксирование RTP потоков.

Существует одна из проблем, которая часто возникает у пользователей - это одностороннее прохождение звука (односторонняя слышимость) или вообще отсутствие его у обоих из абонентов в том случае, когда пользовательские агенты находятся за маршрутизатором с трансляцией адресов (NAT), при попытке их связаться с пользователями, которые находятся в публичной части Интернета или с теми, что находятся за маршрутизатором с NAT. Этими маршрутизаторами с трансляцией адресов могут быть такие устройства, как ADSL маршрутизаторы, межсетевые фильтры (firewall), маршрутизаторы беспроводных сетей и т.д. Чтобы уяснить, как работает NAT и проксирование RTP потока, Вы должны понимать то, что происходит, когда телефон пользователя регистрируется на SIP сервере регистраций (SIP регистраторе), и в тот момент, когда совершается вызов.

В следующих разделах, в качестве примера будут использованы функции модуля nathelper. Описания работы Mediaproxy будет рассмотрено позднее.

Обратите внимание: В SER имеется два различных предложения для работы с NAT и проксированием RTP потоков, а именно - модули rtpproxy и mediaproxy. Эти два приложения работают независимо друг от друга и будут рассмотрены далее в этой документации. Из-за наличия этих двух различных решений для работы через NAT маршрутизаторы возник некоторый бардак. Кроме того, отмеченный выше модуль nathelper некоторые считают частью приложения проксирования RTP потоков - rtpproxy, хотя Вы можете использовать предоставляемые им функции для совместной работы с модулем mediaproxy.

Регистрация на SIP сервере, находящимся за NAT.

Когда пользовательский агент отправляет серверу SER сообщение REGISTER, то он знает только свой IP адрес из приватной локальной сети, которая находится за маршрутизатором с NAT (напр. 192.0.2.13). Таким образом, он будет полагать, что myself@192.0.2.13:5060 - это вполне правильная информация для поля Contact, и будет включать его в сообщение REGISTER (предположим, что порт 5060 - это порт, который пользовательский агент использует для приема SIP сообщений). Естественно, что никакие SIP сообщения из публичной части Интернета не смогут достичь myself@192.0.2.13:5060 , поскольку этот адрес имеет смысл только внутри локальной сети за NAT маршрутизатором.

SER получит сообщение REGISTER с адреса: a.b.c.d:f, где a.b.c.d - публичный IP адрес NAT маршрутизатора а f - это порт, выделенный NAT маршрутизатором в начале сеанса для организации соединения между двумя точками. SER в состоянии ответить только на IP адрес: a.b.c.d:f для того, чтобы его сообщения могли достигнуть агента пользователя и, вследствие этого, должен зарегистрировать именно этот адрес вместо того, который предоставил пользовательский агент. Функция модуля Nathelpers для проверки того, находится ли агент пользователя за NAT или нет, называется nat_uac_test (). В ней можно задать параметр для определения того, какие проверки она должна осуществлять. Рекомендуется использовать параметр 19 (все проверки). Описание производимых этой функцией проверок выходит за рамки этого описания. Вы можете найти их самостоятельно в описании этой функции.

Кроме того, SER должен пометить эту запись на предмет того, находится ли агент пользователя за NAT или нет, чтобы соответствующим образом обработать все последующие сообщения от него. Это делается путем установки флага для агента с использованием функции setflag (). Этот флаг доступен для проверки как для вызываемого, так и для вызывающего агента.

Модуль nathelper имеет функцию fix_nated_contact () для перезаписи заголовочного поля Contact SIP сообщения. Однако это действие не полностью согласуется с RFC, вследствие этого в модуле nathelper (версии больше 0.9.0) имеется другая функция - fix_nated_register (), которая только регистрирует правильный адрес и порт, не перезаписывая заголовочное поле Contact.

Замечание: в разделе 10.3 RFC3261 говорится, что Вы не должны изменять поле Contact при обработке SIP сообщения REGISTER, вследствие этого, Вы никогда не должны использовать функцию fix_nated_contact () для обработки запросов REGISTER. Вместо нее всегда используйте функцию fix_nated_register(), а для всех других типов SIP сообщений - fix_nated_contact().

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

Еще одна проблема состоит в том, что NAT маршрутизатор резервирует выделенный порт 'f' только на некоторое определенное время, и если в течении него нет активности по этому порту, то NAT маршрутизатор удаляет соответствие адреса и порта внутреннего устройства с внешним портом, и тогда SER не сможет связаться с зарегистрированным пользовательским агентом. Эта проблема решается или пользовательским агентом, который регулярно отправляет SIP сообщения SER серверу, или же SER должен регулярно послать SIP сообщения на адрес a.b.c.d:f (keep-alive).

Совершение вызовов с клиента, находящимся за NAT.

Когда пользовательский агент отправляет SIP сообщение INVITE, оно содержит в себе тело сообщения - SDP (протокол описания параметров связи). В этом теле сообщения описываются различные параметры про пользовательского агента, например, какие типы сеансов он может поддерживать, и как вызываемая сторона может связаться с вызывающим абонентом. Как было описано выше, эта информация может выглядеть примерно так: 192.0.2.13:23767, где 23767 - это порт, который для этого сеанса выделил агент пользователя для приема аудиопотока (для протокола реального времени - RTP ). Во время отправки сообщения INVITE NAT маршрутизатор еще не выделил соответствие портов между локальным и внешним адресом (т.к. в это время еще нет никакой активности по протоколу RTP). Соответствующие строки SDP тела INVITE сообщения выглядят примерно так:

c=IN IP4 192.0.2.13.
m=audio 23767 RTP/AVP 0 101.
(c=contact, m=media)

Также стоит добавить, что информация в поле contact, как и в сообщении REGISTER, является неправильной. SER должен изменить это поле и вставить в него внешний адрес a.b.c.d:f, так же как и для SIP сообщения REGISTER. В модуле nathelper это делается с помощью вызова функции fix_nated_contact (). Для других SIP сообщений, относящихся к транзакциям, таких как ACK, CANCEL и BYE, также необходимо изменять значение поле contact.

По части аудиопотока SER может сделать только три вещи с сообщением INVITE перед его отправкой вызываемому пользовательскому агенту:

Добавить SDP команду: 'direction:active' в контекст SDP сообщения
Изменить адрес в строке 'c=' на 'a.b.c.d'
Заставить RTP поток проходить через прокси, меняя поле "c=" на: "c=IN IP4 <адрес прокси сервера>" и поле "m=" на "m=<порт прокси сервера> RTP/AVP 0 101"

1 способ - это сообщить вызываемому пользовательскому агенту, что он должен ждать получения RTP данных, и только после этого он может начать передачу своих аудиоданных на тот же адрес и порт, откуда были получены данные RTP (это называется Symmetric RTP - симметричный RTP). Этот вариант может работать только если вызываемый агент имеет публичный IP, или если он знает свой RTP порт на NAT маршрутизаторе (например, с использованием STUN). Если же они оба находятся за NAT, то тогда они оба будут ждать начала передачи друг друга, и она так никогда и не начнется. Однако этот метод может хорошо подойти для совершения вызовов на VoIP шлюзы с публичными IP адресами. В модуле nathelper, это делается с помощью вызова функции: fix_nated_sdp ("1").

2 способ - по большей части это то же самое, что описано в методе 1, но вызываемый пользовательский агент получает еще некоторую дополнительную информацию. В модуле nathelper, это делается с помощью вызова функции fix_nated_sdp ("2"). Вы можете объединить оба метода, указав в качестве параметра цифру 3.

3 способ подразумевает, что Вы должны установить отдельное приложение, называемое RTP прокси (с публичным IP адресом) так, чтобы оба пользовательских агента могли бы направить туда свои аудиопотоки. Этим вы добавите дополнительный узел в цепи (который может добавить время задержки звукового сигнала), и для каждого вызова Вам нужно обеспечить удвоенную полосу пропускания канала, которая требуется для работы голосового кодека, используемого пользовательскими агентами (например, 88 Kbps для G 711). В модуле nathelper это делается с помощью вызова функции force_rtp_proxy ().

Обратите внимание, что вызывающий агент может иметь публичный IP адрес, в то время как вызываемый - находиться за NAT. Ответные SIP сообщения "OK", нужно обрабатывать так же, как описано выше. Следовательно, проверка на работу с пользователем, находящимся за NAT, должна быть включена в секцию onreply_route [x] файла конфигурации ser.cfg. Вызываемый пользователь также имеет установленный флаг, как это было описано в предыдущей главе про регистрацию (функция setflag() ). Следовательно, в блоке маршрутизации "onreply" можно проверить, находится ли вызываемый пользователь за NAT или нет. Если да, то поле contact необходимо менять и (желательно) использовать RTP проксирование.

STUN

Простой проводник для UDP протокола через маршрутизатор с трансляцией адресов (NAT), называется STUN...

STUN - это протокол, предназначенный для того, чтобы пользовательские агенты могли узнать свой IP адрес и порт, под которым они видны в публичной части Интернета. Вам необходимо установить STUN сервер отдельно (т.к. это не часть сервера SER). В этом случае пользовательский агент будет пробовать изменять поле 'contact' и информацию в SDP сообщениях самостоятельно. Когда пользовательским агентом используется STUN сервер, SER не должен производить каких-либо изменений в полях SIP сообщений, как это было описано в предыдущем разделе. Исключение - это когда пользовательский агент находится за маршрутизатором с симметричным NAT (описание различных типов NAT - не входят в задачу этого документа). В этом случае пользовательский агент не должен самостоятельно изменять вышеуказанные поля, поскольку STUN протокол сообщит неправильный номер порта. В этих случаях SER может использоваться для перезаписи поля 'contact' и нужных полей в SDP сообщений. Для исходящих вызовов из сети за симметричным NAT маршрутизатором может понадобиться перезапись поля 'direction:active', но вызовы между пользовательскими агентами, которые оба находятся за маршрутизатором с симметричным NAT, должны всегда обрабатываться с использованием проксирования RTP потока.

Внимание: У некоторых пользовательских агентов имеются дефекты в реализации работы со STUN сервером. Тогда при использовании STUN сервера клиент делает неправильные заключения о номере порта, что обычно является причиной одностороннего прохождения звука (или вообще его отсутствия) или просто отсутствия прохождения вызовов. Некоторые такие ситуаций фактически могут быть обнаружены средствами тестирования на наличие маршрутизатора NAT самого сервера SER (путем сравнения IP адреса/порта отправителя с заголовком 'contact' в SIP сообщении INVITE, в модуле nathelper - это тест с номером 16), но рекомендуется сначала проверять новых пользовательских агентов на предмет работы с различными NAT маршрутизаторами, дабы удостовериться в нормальной их работе.

Другие методы прохождения NAT маршрутизаторов, не контролируемые SER сервером.

Некоторые маршрутизаторы с NAT и межсетевые экраны (firewall) содержат в себе встроенный механизм для передачи SIP протокола, например, маршрутизатор Cisco 3600 с IOS версией 12.3 (9). Такие возможности часто упоминаются, как "Шлюз Прикладного Уровня" - "Application Level Gateway" (ALG). SIP ALG будет прозрачно перезаписывать все SIP сообщения (в оба направления). Если это будет правильно производиться , то и пользовательский агент и SER будет себя прекрасно чувствовать. В противном случае ничего хорошего не получится, и Вам придется или выключить ALG на маршрутизатор или использовать для SER другой порт для SIP сигнализации (например, 5065). Однако тогда Вы получите другие проблемы, связанные с NAT. Решение проблем неправильно функционирующего ALG пока невозможно реализовать в SER версий 0.9.0, но в следующих версиях появятся новые особенности, разработанные для решения этой задачи.

Второй вариант - Пограничный Контроллер Сеанса" - "Session Border Controllers" (SBC). Их трудно выделить в отдельную группу, поскольку часто они могут выполняют много задач, но чаще всего они работают как полноценный B2BUA (является окончанием для SIP и RTP сессий обоих пользовательских агентов так, что они оба видят только SBC). SBC чаще всего используются провайдерами для управления работой своей сети.

URI, R-URI и разветвление маршрутов.

URI - Uniform Resource Identifier (Унифицированный Идентификатор Ресурса), используются для идентификации каждого местоположения в сети конкретного пользователя. URI используются как адрес, когда совершается вызов абонента. Типичные URI для SIP протокола выглядят так: "sip:username@domain.com". Оригинальные URI, которые находятся в первой линии SIP сообщения, называются request-URI (R-URI). С этими URI можно работать в файле ser.cfg используя тег uri (напр: if (uri = ~ sip:username @. *))

Со значением поля URI можно работать везде в файле конфигурации ser.cfg, используя множество разных функций различных модулей. Например, функция lookup(location) использует значение uri и производит с ним некоторые манипуляции, ищет его в базе данных маршрутов и перезаписывает это поле, приводя его к правильной форме контактной информации (включая части: @ipaddress:port). Когда вызывается функция t_relay (), полученное после преобразования окончательное значение поля URI, будут использоваться как адрес назначения SIP сообщения.

Некоторые функции, например, lookup(location) могут добавлять URI с вариантами маршрутов к оригинальному набору значений URI. Это означает, что, когда будет вызвана функция t_relay (), SIP сообщение INVITE будет продублировано на все URI в полученном списке. Стоит отметить, что команда uri будет все еще ссылаться на поле request-URI, на его (возможно) преобразованное значение. Команда ядра: revert_uri () заменяет текущий URI назначения, обратно к оригинальному значению request-URI.

Замечание: backported версия модуля xlog (до 0.9.x) содержит новые параметры, которые могут использоваться для того, чтобы получить полный набор маршрутов сообщения. Backported версию можно найти на сайте: ttp://www.onsip.org/.

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

SIP: Протокол Инициирования Сеанса (Session initiation protocol)
SDP: протокол описания параметров связи.
RTP: Протокол передачи данных в реальном времени