что такое sip и rtp
База знаний
Что такое SIP и как он работает
Архитектура сервера SER и файл конфигурации ser.cfg
Ядро и модули.
Семь секций файла конфигурации ser.cfg.
Файл ser.cfg имеет семь главных логических разделов:
Транзакции, Диалоги и Сеансы.
Для должного понимания синтаксиса, применяемого в файле конфигурации ser.cfg, Вы должны понять три концепции, используемые в SIP протоколе:
Обратите внимание: если Вы взгляните на 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), что, конечно, не рекомендуется.
И, наконец, Вася отправит сообщение ACK, чтобы сказать Пете, что все было получено и подтверждено.
Итак, все это обрабатывается в файле 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
Понимание, что такое 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 (),).
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 потоков.
В следующих разделах, в качестве примера будут использованы функции модуля nathelper. Описания работы Mediaproxy будет рассмотрено позднее.
Регистрация на SIP сервере, находящимся за NAT.
Кроме того, SER должен пометить эту запись на предмет того, находится ли агент пользователя за NAT или нет, чтобы соответствующим образом обработать все последующие сообщения от него. Это делается путем установки флага для агента с использованием функции setflag (). Этот флаг доступен для проверки как для вызываемого, так и для вызывающего агента.
Для всех сообщений, проходящих через NAT, часто используется встроенная функция force_rport () для гарантии того, что заголовочные поля Via (используемые для поиска подходящей транзакции и т.д.) включают номер порта удаленного клиента. Таким образом обеспечивается то, что в процессе транзакции все ответные сообщения будут отправлены на правильный номер порта. Это работает только для клиентов, у которых поддерживается симметричная сигнализация (принимает сообщения на тот же номер порта с которого их отправляет). Однако на сегодняшний момент большинство клиентов использует именно симметричную сигнализацию.
Еще одна проблема состоит в том, что NAT маршрутизатор резервирует выделенный порт ‘f’ только на некоторое определенное время, и если в течении него нет активности по этому порту, то NAT маршрутизатор удаляет соответствие адреса и порта внутреннего устройства с внешним портом, и тогда SER не сможет связаться с зарегистрированным пользовательским агентом. Эта проблема решается или пользовательским агентом, который регулярно отправляет SIP сообщения SER серверу, или же SER должен регулярно послать SIP сообщения на адрес a.b.c.d:f (keep-alive).
Совершение вызовов с клиента, находящимся за NAT.
Также стоит добавить, что информация в поле contact, как и в сообщении REGISTER, является неправильной. SER должен изменить это поле и вставить в него внешний адрес a.b.c.d:f, так же как и для SIP сообщения REGISTER. В модуле nathelper это делается с помощью вызова функции fix_nated_contact (). Для других SIP сообщений, относящихся к транзакциям, таких как ACK, CANCEL и BYE, также необходимо изменять значение поле contact.
По части аудиопотока SER может сделать только три вещи с сообщением INVITE перед его отправкой вызываемому пользовательскому агенту:
3 способ подразумевает, что Вы должны установить отдельное приложение, называемое RTP прокси (с публичным IP адресом) так, чтобы оба пользовательских агента могли бы направить туда свои аудиопотоки. Этим вы добавите дополнительный узел в цепи (который может добавить время задержки звукового сигнала), и для каждого вызова Вам нужно обеспечить удвоенную полосу пропускания канала, которая требуется для работы голосового кодека, используемого пользовательскими агентами (например, 88 Kbps для G 711). В модуле nathelper это делается с помощью вызова функции force_rtp_proxy ().
Простой проводник для UDP протокола через маршрутизатор с трансляцией адресов (NAT), называется STUN.
Другие методы прохождения NAT маршрутизаторов, не контролируемые SER сервером.
URI, R-URI и разветвление маршрутов.
Со значением поля 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 и как он работает
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Plugin disabled
Архитектура сервера SER и файл конфигурации ser.cfg
Plugin disabled
Ядро и модули.
Plugin disabled
Семь секций файла конфигурации ser.cfg.
Файл ser.cfg имеет семь главных логических разделов:
Plugin disabled
Транзакции, Диалоги и Сеансы.
Для должного понимания синтаксиса, применяемого в файле конфигурации ser.cfg, Вы должны понять три концепции, используемые в SIP протоколе:
Обратите внимание: если Вы взгляните на SIP сообщение, то Вы можете соотнести его с определенной SIP транзакцией, используя числовое значение поля Cseq в заголовке сообщения. Каждый SIP диалог будет иметь одинаковое значение поля ]]Call-Id[[ в заголовке сообщения (так же, как один ID используется для идентификации каждой стороны в процессе диалога).
Plugin disabled
Понимание процесса обработки 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), что, конечно, не рекомендуется.
И, наконец, Вася отправит сообщение ACK, чтобы сказать Пете, что все было получено и подтверждено.
Итак, все это обрабатывается в файле 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.
Plugin disabled
Stateful и stateless
Plugin disabled
Понимание, что такое 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 (),).
Plugin disabled
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 потоки.
Plugin disabled
NAT, STUN и проксирование RTP потоков.
В следующих разделах, в качестве примера будут использованы функции модуля nathelper. Описания работы Mediaproxy будет рассмотрено позднее.
Plugin disabled
Регистрация на SIP сервере, находящимся за NAT.
Кроме того, SER должен пометить эту запись на предмет того, находится ли агент пользователя за NAT или нет, чтобы соответствующим образом обработать все последующие сообщения от него. Это делается путем установки флага для агента с использованием функции setflag (). Этот флаг доступен для проверки как для вызываемого, так и для вызывающего агента.
Для всех сообщений, проходящих через NAT, часто используется встроенная функция force_rport () для гарантии того, что заголовочные поля Via (используемые для поиска подходящей транзакции и т.д.) включают номер порта удаленного клиента. Таким образом обеспечивается то, что в процессе транзакции все ответные сообщения будут отправлены на правильный номер порта. Это работает только для клиентов, у которых поддерживается симметричная сигнализация (принимает сообщения на тот же номер порта с которого их отправляет). Однако на сегодняшний момент большинство клиентов использует именно симметричную сигнализацию.
Еще одна проблема состоит в том, что NAT маршрутизатор резервирует выделенный порт ‘f’ только на некоторое определенное время, и если в течении него нет активности по этому порту, то NAT маршрутизатор удаляет соответствие адреса и порта внутреннего устройства с внешним портом, и тогда SER не сможет связаться с зарегистрированным пользовательским агентом. Эта проблема решается или пользовательским агентом, который регулярно отправляет SIP сообщения SER серверу, или же SER должен регулярно послать SIP сообщения на адрес a.b.c.d:f (keep-alive).
Plugin disabled
Совершение вызовов с клиента, находящимся за NAT.
Также стоит добавить, что информация в поле contact, как и в сообщении REGISTER, является неправильной. SER должен изменить это поле и вставить в него внешний адрес a.b.c.d:f, так же как и для SIP сообщения REGISTER. В модуле nathelper это делается с помощью вызова функции fix_nated_contact (). Для других SIP сообщений, относящихся к транзакциям, таких как ACK, CANCEL и BYE, также необходимо изменять значение поле contact.
По части аудиопотока SER может сделать только три вещи с сообщением INVITE перед его отправкой вызываемому пользовательскому агенту:
3 способ подразумевает, что Вы должны установить отдельное приложение, называемое RTP прокси (с публичным IP адресом) так, чтобы оба пользовательских агента могли бы направить туда свои аудиопотоки. Этим вы добавите дополнительный узел в цепи (который может добавить время задержки звукового сигнала), и для каждого вызова Вам нужно обеспечить удвоенную полосу пропускания канала, которая требуется для работы голосового кодека, используемого пользовательскими агентами (например, 88 Kbps для G 711). В модуле nathelper это делается с помощью вызова функции force_rtp_proxy ().
Plugin disabled
Простой проводник для UDP протокола через маршрутизатор с трансляцией адресов (NAT), называется STUN.
Plugin disabled
Другие методы прохождения NAT маршрутизаторов, не контролируемые SER сервером.
Plugin disabled
URI, R-URI и разветвление маршрутов.
Со значением поля 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/.