18.10.2024
Последние:

3dsattv.ru

Самый полезный портал в интернете

Статьи 

использовать ip адрес в sdp

admin 0 Comments

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

🔥 Популярное

DHCP: Опция 150 и 66

VoIP кодеки – подробное описание и характеристики

IP- телефония и VLAN

SIP против PRI – сравнение и преимущества

👌 Похожее

Версус: сравнение виртуальной и офисной АТС

Регистрация IP телефона

Описание протокола SIP

Про Session Description Protocol

Одним из важных компонентов установления соединения по протоколу SIP является протокол Session Description Protocol, или сокращенно SDP.

Продвинутый курс по Asterisk

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

использовать ip адрес в sdp. old phone. использовать ip адрес в sdp фото. использовать ip адрес в sdp-old phone. картинка использовать ip адрес в sdp. картинка old phone. использовать ip адрес в sdp. old phone. использовать ip адрес в sdp фото. использовать ip адрес в sdp-old phone. картинка использовать ip адрес в sdp. картинка old phone.

О протоколе SDP впервые заговорили в 1998 году в рамках опубликованного RFC2327. Спустя 8 лет, в 2006 году протокол претерпел некоторые изменения, которые были отображены в RFC4566.

Протокол SDP используется для установления соединения и согласования параметров передачи и приема аудио или видео потоков между оконечными устройствами. Наиболее важными параметрами обмена являются IP – адреса, номера портов и кодеки. Давайте разбираться?

Пример SDP

При установлении сессии SDP параметры передаются в рамках SIP – запросов. Давайте взглянем на один из таких запросов. В данном случае распарсим SIP INVITE, который прилетело на нашу IP – АТС Asterisk с помощью утилиты sngrep:

использовать ip адрес в sdp. 1. использовать ip адрес в sdp фото. использовать ip адрес в sdp-1. картинка использовать ip адрес в sdp. картинка 1.

Про SDP поля

Каждый из параметров SDP сообщения можно отнести к одной из следующих категорий:

Продвинутый курс по Asterisk

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

Источник

NAT, SIP и Asterisk

Если у вас нет звука, нет звука в одну сторону, нет слышимости, прочтите внимательно эту инструкцию.

Reinvite

Клиент за NAT

Начиная с версии Asterisk 11: ‘nat=yes’ устарело, используйте ‘nat=force_rport,comedia’
nat=force_rport,comedia

SIP клиенты и Asterisk за NAT

Чтобы избежать потери звука запретите re-invite в файле sip.conf

Опция canreinvite устарела. Используйте ‘directmedia’.

По умолчанию задан диапазон от 10000 до 20000. Измените диапазон в соответсвии с вашими потребностями (3 порта на каждый конкурирующий вызов).

Основные параметры конфигурации NAT для Asterisk

sip.conf

Поддержка NAT в Asterisk 12

localnet

параметр ‘localnet’ список сетевых адресов, которые считаются «внутренними».

externaddr
externhost

«externhost = hostname[:port]» то же что и «externaddr» только это ‘hostname’ обновляемое через «externrefresh» секунд (по умолчанию 10сек.).

настройки могут совмещаться:

Установка force_rport принуждает Asterisk всегда передавать ответы обратно на адрес / порт, с которых он получил запросы, даже если другая сторона не поддерживает добавления параметра ‘rport’.

media_address
icesupport
directmedia

устаревшие настройки sip.conf

bindaddr= IP адрес Asterisk, если указано 0.0.0.0, то любой адрес.

Этот адрес будет использован для общения с устройствами с установленным параметром nat=force_rport.

localnet= Этот параметр задается в секции [general] файла sip.conf и указывает на локальную сеть и используется для обращения к устройствам с параметром nat=no.

Начиная с версии Asterisk 11: nat=yes is deprecated, use nat=force_rport,comedia instead

Asterisk будет отправлять голосовые пакеты на порт и IP адрес с которого их получает а не указанные в SIP и SDP сообщениях.

directmedia

Этот параметр задает проверку по умолчанию каждые 2 секунды.

Это выключает проверку.

Включает проверку через заданное время в 300 ms.

rtp.conf

В Asterisk начиная с версии 11 появилась поддержка stun. icesupport должно быть включено.

Настройка res_pjsip для работы через NAT

Устройства используемые в примере:

УстройствоIP адрес в примере
VOIP телефон(7777)10.10.2.77
PC/Asterisk10.10.2.10
МаршрутизаторLAN : 10.10.2.1
WAN: 123.123.123.123
ITSP SIP шлюз203.0.113.1(gw1.example.com)
203.0.113.2(gw2.example.com)

Для наглядности, в примере использованы фальшивые детали:

pjsip.conf конфигурация
local_net

Диапазон адресов локальной сети.

external_media_address
external_signaling_address
direct_media

Удаленные телефоны за NAT

Источник

NAT, SIP и Asterisk

Трансляция сетевых адресов (NAT) является обычной практикой в сети и нередко мешает прохождению голосовых пакетов (нет звука) и инициализации соединений (нет соединения). Решение этой проблемы требует понимания принципов работы NAT и VoIP. В этой статье рассматривается протокол SIP и Asterisk, но проблемы и решения применимы и к большинству других приложений и протоколов.

Reinvite

использовать ip адрес в sdp. nat reinvite. использовать ip адрес в sdp фото. использовать ip адрес в sdp-nat reinvite. картинка использовать ip адрес в sdp. картинка nat reinvite.

Клиент за NAT

использовать ip адрес в sdp. nat simple3. использовать ip адрес в sdp фото. использовать ip адрес в sdp-nat simple3. картинка использовать ip адрес в sdp. картинка nat simple3.

[sip_phone]
nat=yes
qualify=300 ; проверять соединение каждые 300 мс.

nat=force_rport,comedia

При такой конфигурации Asterisk использует внешний IP адрес externip для вызовов клиентов с параметром nat=yes. Дополнительно параметр qualify=yes поддерживает соединение, не позволяя удалять запись из таблицы трансляций.

SIP клиенты и Asterisk за NAT

использовать ip адрес в sdp. nat simple3. использовать ip адрес в sdp фото. использовать ip адрес в sdp-nat simple3. картинка использовать ip адрес в sdp. картинка nat simple3.
Все усложняется если и Asterisk, и клиенты, находятся за NAT. Клиенты с внешней стороны не смогут получать SIP сообщения и принимать звонки. Или в SIP сообщении будет указан локальный IP адрес телефона, что приведет к потере звука.
Чтобы избежать потери звука запретите re-invite в файле sip.conf

Опция canreinvite устарела. Используйте ‘directmedia’.

Но клиенты находящиеся за NAT, все равно не смогут инициировать соединение с Asterisk и направить голосовые пакеты RTP на требуемый екстеншен. Для того чтобы это работало, надо пробросить требуемые порты через брандмауер на Asterisk. Диапазон RTP портов используемых Asterisk, назначается в файле rtp.conf.

По умолчанию задан диапазон от 10000 до 20000. Измените диапазон в соответствии с вашими потребностями (3 порта на каждый конкурирующий вызов).
Для нормальной работы за NAT, потребуется пробросить диапазон RTP портов в соответствии с настройками в файле rtp.conf и порт SIP (обычно 5060). В iptables это будет выглядеть так:

Где eth0 – внешний интерфейс, а 192.168.1.10 – IP адрес Asterisk.

Основные параметры конфигурации NAT для Asterisk

localnet

Параметр ‘localnet’ список сетевых адресов, которые считаются «внутренними».

externaddr

Внешний адрес щлюза (маршрутизатора) во внешнюю сеть. «externaddr = hostname[:port]» указывает статический адрес[:port] который будет использован в SIP и SDP сообщениях. Имя хоста (hostname) поднимается каждый раз, когда [пере]загружается sip.conf. Если порт не назначен, используется значение указанное в параметре «udpbindaddr». примеры:

externhost

«externhost = hostname[:port]» то же что и «externaddr» только это ‘hostname’ обновляемое через «externrefresh» секунд (по умолчанию 10 сек.).

В дополнение к вышесказанному Asterisk имеет дополнительный параметр «NAT» для разрешения вопросов, связанных со входящими SIP или медиа сессиями. В частности, в зависимости от настроек ‘NAT=’ как описано ниже, Asterisk может переопределить адрес/порт информацию, указанную в SIP/SDP сообщениях.

настройки могут совмещаться:

media_address

IP адрес используемый для медиа (аудио, видео и текста) в SDP может быть переназначен параметром ‘media_address’. Данный параметр может быть использован только в секции [general].

icesupport

ICE/STUN/TURN использование может быть включено глобально или для конкретного пира с помощью ‘icesupport’ опции.

directmedia

Для отключения прямых RTP потоков (peer-to-peer) используйте опцию:

устаревшие настройки sip.conf

externip= Этот параметр задается в секции [general] файла sip.conf и указывает внешний IP адрес, или имя хоста на вашем устройстве NAT.

Этот адрес будет использован для общения с устройствами с установленным параметром nat=force_rport.
localnet = Этот параметр задается в секции [general] файла sip.conf и указывает на локальную сеть и используется для обращения к устройствам с параметром nat=no.

Возможные значения:
NAT= yes, no, never, route

Начиная с версии Asterisk 11: nat=yes is deprecated, use nat=force_rport,comedia instead

Asterisk будет отправлять голосовые пакеты на порт и IP адрес с которого их получает а не указанные в SIP и SDP сообщениях.
Это будет работать только, если телефоны за NAT будут использовать для одинаковый порт для голосовых пакетов RTP и одинаковый (но отличный от голосового) для сигнализации RTCP.

directmedia

qualify = Эта опция имеет два назначения.Первое – поддерживать запись в таблице трансляций NAT и контролировать регистрацию телефона.
Возможные значения:

Этот параметр задает проверку по умолчанию каждые 2 секунды.

Это выключает проверку.

ключает проверку через заданное время в 300 ms.

rtp.conf

Задает первый порт диапазона для приема и оправки голосовых пакетов RTP.

Задает последний порт диапазона для приема и оправки голосовых пакетов RTP.

В Asterisk начиная с версии 11 появилась поддержка stun. icesupport должно быть включено.

Настройка res_pjsip для работы через NAT

В данной статье приведены примеры рабочей конфигурации драйвера канала PjSIP, когда Asterisk находится за NAT (Network Address Translation). Asterisk подключается через NAT к провайдеру IP телефонии (ITCP).
Этот пример подходит для большинства простых сценариев NAT при следующих условиях: Asterisk и телефоны находятся в частной сети. Маршрутизатор имеет локальный и публичный интерфейсы. Маршрутизатор реализует функции Трансляции Сетевых Адресов (NAT) и файерволла. На маршрутизаторе настроен проброс SIP и RTP портов на локальный IP адрес сервера Asterisk. В данном примере проброшены порты 5060 TCP/UDP и UDP 10000-10100 на LAN 10.10.2.10.
Устройства используемые в примере:

УстройствоIP адрес в примере
VOIP телефон (7777)10.10.2.77
PC/Asterisk10.10.2.10
МаршрутизаторLAN: 10.10.2.1
WAN: 123.123.123.123
ITSP SIP шлюз203.0.113.1(gw1.example.com)
203.0.113.2(gw2.example.com)

Для наглядности, в примере использованы фальшивые детали:
TSP номер аккаунта : 123456789 и DID номер входящий от провайдера IP телефонии (ITSP): 3216111.

Любое использование материалов сайта возможно только с разрешения автора и с обязательным указанием источника.

Источник

Работа PJSIP за NAT

Рассмотрим работу PJSIP за NAT на примере CentOS 8 и Asterisk 16. PJSIP — мультимедийная коммуникационная библиотека, написанная на Си. Поддерживает такие протоколы как SIP, SDP, RTP, STUN, TURN, и ICE. Она сочетает лучшие возможности SIP сигнализации, хорошую проходимость NAT и высокий уровень взаимодействия с приложениями. Network Address Translation (NAT) При настройке с помощью chan_sip […]

Рассмотрим работу PJSIP за NAT на примере CentOS 8 и Asterisk 16.

PJSIP — мультимедийная коммуникационная библиотека, написанная на Си. Поддерживает такие протоколы как SIP, SDP, RTP, STUN, TURN, и ICE. Она сочетает лучшие возможности SIP сигнализации, хорошую проходимость NAT и высокий уровень взаимодействия с приложениями.

Network Address Translation (NAT)

no — Не выполняйте обработку NAT, отличную от RFC 3581.

force_rport — Если параметр rport отсутствует, все равно отправьте ответы на исходный IP-адрес и порт, как если бы присутствовал параметр rport.

comedia — Отправьте медиа на адрес и порт, с которого Asterisk получил его, независимо от того, где SDP указывает, что его следует отправить.

auto_force_rport — Автоматически разрешить отправку ответов на исходный IP-адрес и порт, как если бы присутствовал rport, если Asterisk обнаружит NAT. По умолчанию.

auto_comedia — Автоматически отправлять носитель на порт, с которого Asterisk получил его, независимо от того, где SDP указывает, что его следует отправить, если Asterisk обнаружит NAT.

Версии Asterisk до 1.8 имели меньшую степень детализации для параметра nat:

no — Не выполняйте обработку NAT кроме RFC 3581.

yes — Отправьте медиа на порт, с которого Asterisk получил его, независимо от того, где SDP указывает, что его следует отправить; отправлять ответы на исходный IP-адрес и порт, как если бы присутствовал rport; и переписать SIP-контакт на адрес источника и порт запроса, чтобы последующие запросы перешли на этот адрес и порт.

never — Не выполнять обработку NAT.

route — Отправьте носитель на порт, с которого Asterisk получил его, независимо от того, где SDP указывает, что он должен быть отправлен, и перезапишите SIP-контакт по адресу источника и порту запроса, чтобы последующие запросы перешли на этот адрес и порт.

Asterisk и телефоны, соединяющиеся через NAT с провайдером.

Этот пример подходит для большинства простых сценариев NAT, которые соответствуют следующим критериям:

Asterisk и телефоны находятся в частной сети.

Существует маршрутизатор, взаимодействующий с частными и общедоступными сетями. Где общедоступная сеть интернет.

Маршрутизатор выполняет функции трансляции сетевых адресов и брандмауэра.

Маршрутизатор настроен для переадресации портов, где он отображает необходимые диапазоны трафика SIP и RTP на ваш внутренний сервер Asterisk.

В этом примере маршрутизатор перенаправляет порты WAN TCP / UDP 5060 и UDP 10000-20000 в LAN 192.168.32.47

Устройства, включенные в пример:

Ради полного примера и ясности в этом примере мы используем следующие поддельные детали:

Конфигурация pjsip.conf

local_net — Это IP-сеть, которую мы хотим рассмотреть в нашей локальной сети. Для связи с адресами в этом диапазоне мы не будем применять какие-либо настройки, связанные с NAT.

external_media_address — Это внешний IP-адрес для использования при обработке RTP. Когда запрос или ответ отправляется из Asterisk, если пункт назначения сообщения находится за пределами IP-сети, определенной в опции «local_net», и медиа-адрес в SDP находится в локальной сети, тогда медиа-адрес в SDP будет переписан в значение, определенное для external_media_address.

external_signaling_address — Это очень похоже на настройку external_media_address, но для сигнализации SIP вместо RTP media. Упомянутые здесь две внешние опции должны быть установлены на один и тот же адрес, если вы не разделите сигнальный и медиа трафик и направите на разные IP адреса или сервера..

direct_media — Определяет, медиа поток и направляет RTP трафик непосредственно между конечными точками, или через Asterisk.

Вместе эти параметры гарантируют, что дальний конец знает, куда отправлять обратно пакеты SIP и RTP, а direct_media гарантирует, что Asterisk остается на пути передачи мультимедиа. Это важно, потому что наша система имеет частный IP-адрес, на который SIP провайдер не может направить трафик. Мы хотим убедиться, что трафик SIP и RTP возвращается на адрес WAN / Public Internet нашего маршрутизатора. Разделы с префиксом «sipus» — это все настройки, необходимые для входящих и исходящих соединений магистрали SIP, а разделы с именем 201 предназначены для телефона VOIP.

Пример настройки chan_pjsip(pjsip.conf):

Для удаленных телефонов за NAT

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

В этих случаях вы можете рассмотреть следующие параметры для удаленных конечных точек.

media_address — IP-адрес, используемый в SDP для обработки медиа

Во время создания SDP IP-адрес, определенный здесь, будет использоваться в

качестве медиа-адреса для отдельных потоков в SDP.

rtp_symmetric — Обеспечить, чтобы RTP был симметричным. Отправьте RTP обратно на тот же адрес / порт, с которого мы его получили.

force_rport — Принудительное поведение, совместимое с RFC3581, даже если отсутствует параметр rport. По сути, всегда отправляйте ответы SIP обратно на тот же порт, с которого мы получили запросы SIP.

direct_media — Определяет, может ли носитель передаваться напрямую между конечными точками.

rewrite_contact — Определите, будут ли запросы SIP отправляться на исходный IP-адрес и порт вместо адреса, предоставленного конечной точкой.

Источник

использовать ip адрес в sdp. partbullet. использовать ip адрес в sdp фото. использовать ip адрес в sdp-partbullet. картинка использовать ip адрес в sdp. картинка partbullet.Всё, что вы хотели знать о протоколе SIP

Архив номеров / 2007 / Выпуск №9 (58) / Всё, что вы хотели знать о протоколе SIP

использовать ip адрес в sdp. No foto man. использовать ip адрес в sdp фото. использовать ip адрес в sdp-No foto man. картинка использовать ip адрес в sdp. картинка No foto man.Андрей Погребенник

Всё, что вы хотели знать о протоколе SIP
Часть 3

Мир IP, возможно, и родственен классической телефонии, однако стоящие перед ним проблемы носят особый характер. Сервер трансляции сетевых адресов (NAT) создаёт серьёзные препятствия нормальной работе с VoIP. Как решается проблема NAT в сетях IP-телефонии на базе протокола SIP? Как бороться с угрозами безопасности в таких сетях? Ответы на эти вопросы вы узнаете из заключительной части статьи.

Проблема обхода NAT

Вряд ли стоит долго объяснять, почему NAT является проблемой для голосового трафика. Достаточно уже того факта, что голосовой трафик обособлен от сигнализации и использует динамически назначенные номера портов. А IP-адреса и номера портов, помещаемые находящимся за NAT-пользовательским агентом в поля заголовков Contact и Via, а также в SDP-сообщение, не маршрутизируемы. Маршрутизатор с поддержкой NAT-транспортного уровня модели OSI, а SIP-заголовки формируются на уровне приложения. Следовательно такое устройство не может проанализировать заголовки и SDP-сообщение и переопределить анонсированные там IP-адреса и номера портов (а также открыть обратный канал для маршрутизации входящего трафика к пользовательскому агенту), равно как и не может знать, к какому SIP-диалогу относится тот или иной медиапоток.

Как результат, каждый не понаслышке знакомый с IP-телефонией человек сталкивался с явлениями односторонней слышимости или вовсе отсутствия звукового потока. Сразу следует заметить, что «серебряной пули» здесь нет: все решения этой проблемы в большей или меньшей степени частные.

Впрочем, проблема обхода NAT медиатрафиком – это лишь одна сторона медали. Вначале мы рассмотрим, какие препятствия создаёт NAT для сигнальных сообщений и какие расширения SIP были разработаны для их преодоления.

Обход NAT SIP-сигнализацией

При использовании протоколов транспортного уровня без гарантии доставки отправка ответа на SIP-запрос производится на тот IP-адрес, с которого запрос был получен. Этот IP-адрес транспортный уровень протокола SIP заносит в параметр received заголовка Via перед передачей сообщения вышележащим уровням. Номер же порта для отправки извлекается из заголовка Via. В случае применения NAT – это порт, на котором ожидает ответа находящийся за NAT пользовательский агент, а не тот порт, через который происходит NAT-трансляция и на котором NAT ожидает поступления ответа; следовательно, ответ не может достичь адресата.

Решение этой проблемы было предложено в RFC 3581 [1] и заключается в отправке ответа на порт, с которого запрос был получен, вместо порта, взятого из заголовка Via. При этом сам порт заносится в специальный параметр rport-заголовка Via. Таким образом, прокси-сервер отсылает ответное сообщение на порт и IP-адрес, с которых пришёл запрос. Это позволяет ответу найти соответствие в таблице трансляции NAT и достичь целевого узла. Этот метод называется симметричной маршрутизацией ответов.

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

На рис. 1 запрос REGISTER был отправлен клиентом с порта 8023 и получен прокси-сервером на порту 5060, создав при этом запись в таблице трансляции NAT и (в случае использования транспортного протокола с установлением соединения) соединение транспортного уровня. При необходимости отправки запроса данному UA, прокси-сервер отправляет сформированный запрос на IP-адрес и порт, взятые из заголовка Contact при регистрации. Этот же IP-адрес не маршрутизируем; следовательно, для корректной маршрутизации входящих запросов сервер регистрации должен сохранить в базе данных с информацией о местоположении пользователей IP-адрес и номер порта, с которых запрос был на самом деле получен, в качестве контакта пользователя.

использовать ip адрес в sdp. image001. использовать ip адрес в sdp фото. использовать ip адрес в sdp-image001. картинка использовать ip адрес в sdp. картинка image001.

Рисунок 1. Маршрутизация входящих запросов

Но запись в таблице трансляции NAT удаляется после истечения определенного промежутка времени (чаще всего – несколько минут). Проблема актуальна не только в период после регистрации пользователя: во время SIP-диалогов новые сообщения также могут не поступать в течение длительного промежутка времени, чего достаточно для того, чтобы запись из таблицы трансляции была удалена. Имеющиеся SIP-стеки решают эту проблему путём периодической посылки SIP-запросов re-INVITE, OPTIONS, INFO, NOTIFY или (при использовании UDP) дейтаграмм, не содержащих полезной нагрузки.

Более полная и совершенная техника описана в проекте Managing Client Initiated Connections in SIP Инженерной проблемной группы Интернет (IETF) [2]. Остановимся на ней подробнее.

При регистрации пользователя регистратор сохраняет данные о транспортном соединении, через которое был получен запрос. Два специальных параметра instance-id и reg-id заголовка Contact позволяют найти в базе данных сервера регистрации данные о соединении и направить входящий запрос к UA по тому соединению транспортного уровня, через которое был получен запрос регистрации. Также в черновике описаны механизмы для постоянного обновления записей таблицы трансляции NAT.

Подытожим сказанное небольшим примером регистрации пользователя, находящегося за NAT и использующего UDP (см. рис. 2).

использовать ip адрес в sdp. image002. использовать ip адрес в sdp фото. использовать ip адрес в sdp-image002. картинка использовать ip адрес в sdp. картинка image002.

Рисунок 2. Обход NAT SIP-сигнализацией

Запрос REGISTER содержит параметр заголовка Via rport, информирующий UAS о поддержке RFC 3581, а также параметры reg-id и +sip.instance в заголовке Contact:

REGISTER sip:proxy.example.com SIP/2.0

Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK

From: Client ;tag=djks8732

Ответ прокси-сервера выглядит так:

SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP client.example.com:5060

From: Client ;tag=djks8732

To: Client ;tag=876877

WWW-Authenticate: [не показан]

Параметры reg-id и +sip.instance делают возможным повторное использование соединения транспортного уровня, по которому был получен REGISTER, в соответствии с [2]. Заметьте, что IP-адрес и порт, с которых был получен запрос, прокси-сервер заносит в параметры received и rport заголовка Via. На них же и производится отправка ответа в соответствии с RFC 3261 и RFC 3581. Причём ответ должен быть отправлен прокси-сервером с того же IP-адреса и порта, на котором был получен запрос, чтобы ответ был опознан NAT-транслятором, как принадлежащий к установленному соединению.

Обход NAT медиатрафиком

Решение проблемы обхода NAT медиатрафиком требует более сложных изменений, поскольку необходимо заменить IP-адрес и номер порта, анонсированные в SDP-сообщении, таковыми, что обеспечат доставку потоков нужному адресату за NAT (см. рис. 3).

использовать ip адрес в sdp. image003. использовать ip адрес в sdp фото. использовать ip адрес в sdp-image003. картинка использовать ip адрес в sdp. картинка image003.

Рисунок 3. Обход NAT медиатрафиком

Simple Traversal of UDP through NAT (STUN)

Терминология NAT и сведения о разных типах NAT были изложены в [3]. Там же был рассмотрен протокол STUN (Simple Traversal of UDP through NAT, RFC 3489 [4]), позволяющий определить факт наличия NAT и его тип путем отправки на STUN-сервер последовательности зондирующих запросов. В контексте SIP нас интересует возможность определения пользовательским агентом публичного IP-адреса NAT и записей в таблице трансляции с помощью STUN. Но вначале напомню специфику разных типов NAT.

Алгоритм работы STUN следующий. Клиент STUN (встроенный в UA) отправляет на расположенный снаружи NAT STUN-сервер зондирующие сообщения. STUN-сервер анализирует это сообщение и информирует клиента о том, какие IP-адрес и порт были использованы NAT (cм. рис. 4). Эти IP-адрес и порт клиент и помещает в SDP-часть SIP-запроса (а также поля заголовков Via и Contact). Путём отправки специальной последовательности запросов клиент может точно определить тип NAT.

использовать ip адрес в sdp. image004. использовать ip адрес в sdp фото. использовать ip адрес в sdp-image004. картинка использовать ip адрес в sdp. картинка image004.

Наконец, мы подошли к главному. STUN не решает проблему обхода NAT в SIP в общем случае. Да, он работает в сценариях Port Restricted Cone NAT, а иногда – и в Restricted Cone NAT, но наиболее распространенным типом NAT был и остается симметричный, и здесь STUN бесполезен. К тому же не все UA даже в случае более дружественных типов NAT хорошо «дружат» с STUN, а в более старых устройствах поддержка STUN не была широко распространена.

Ещё одна «ложка дёгтя» – в существующих реализациях STUN не работает с SIP поверх TCP, поскольку не отслеживает должным образом состояние открытых TCP-сессий.

Traversal Using Relay NAT (TURN)

Дальнейшим развитием STUN является протокол TURN (Traversal Using Relay NAT). TURN позволяет клиенту получить маршрутизируемый IP-адрес для общения с одним внешним узлом (и не пригодный для чего либо еще). TURN-сервер, обычно располагаемый DMZ абонентской сети или в сети сервис-провайдера, имитирует поведение Restricted Cone NAT: он транслирует пакеты с внешнего IP-адреса к клиенту только в том случае, если клиент ранее уже отправлял пакеты на внешний узел через TURN-сервер.

Таким образом, TURN-сервер служит транзитным узлом (прокси-сервером) для всего последующего сигнального и медиатрафика (см. рис. 5). При этом он приемлемо работает даже с клиентами за симметричным NAT. Для выделения IP-адреса и отправки пакетов в спецификации протокола определены специальные запросы Allocate и Send; в остальном же структура протокола аналогична STUN. В качестве транспортных протоколов для сигнального и медиатрафика TURN поддерживает TCP и UDP.

использовать ip адрес в sdp. image005. использовать ip адрес в sdp фото. использовать ip адрес в sdp-image005. картинка использовать ip адрес в sdp. картинка image005.

Рисунок 5. Обход NAT SIP-сигнализацией

Недостаток данного метода очевиден: вследствие проксирования всего трафика увеличивается односторонняя задержка и повышается вероятность потери пакетов. По этой причине TURN рекомендуется использовать лишь в тех случаях, когда менее «дорогие» методы обхода NAT бессильны. Заметим, что с недавнего времени TURN больше не считается самостоятельным протоколом: сейчас он описан как расширение к STUN в [5].

Interactive Connectivity Establishment (ICE)

TURN-сервер проксирует весь RTP-трафик даже тогда, когда простого STUN было бы достаточно для обхода NAT. С целью выбора наименее «дорогого» метода обхода NAT путем проведения согласования возможных опций между конечными точками ассоциация IETF предложила инфраструктуру ICE (Interactive Connectivity Establishment). Это не протокол в привычном смысле этого слова; ICE называют инфраструктурой (framework), и базируется он на существующих протоколах STUN и TURN и расширениях SIP.

Механизм работы ICE следующий. Пользовательские агенты производят поиск возможных маршрутов между собой. Каждый UA для начала диалога может использовать либо IP-адрес одного из локальных сетевых интерфейса, либо определённый с помощью STUN (или UPnP, Universal Plug and Play) маршрутизируемый IP-адрес, либо же IP-адрес TURN-сервера. Список маршрутов-кандидатов образуют пары – все возможные комбинации транспортных адресов одного пользовательского агента с транспортными адресами другого.

В списке маршрутов-кандидатов наивысший приоритет получают маршруты без задействования STUN, более низкий – маршруты с задействованием STUN, и наиболее низкий – маршруты с проксированием медиатрафика через TURN-сервер. Изложение здесь намеренно усложнено: на самом деле гибкая система приоритетов позволяет учитывать топологию сети, данные о задержке и вариации задержки, требования к безопасности и т. д. В итоге каждый маршрут получает уникальное значение приоритета. Затем проверяется их работоспособность (достижимость противоположной стороны). Из маршрутов, прошедших проверку, выбирается один с наивысшим приоритетом.

Если в роли транспортного протокола выступают RTP/RTCP, для которых назначаются порты со смежными номерами, с целью оптимизации выполняется согласование маршрутов только для одного порта. К слову, если в результате использования STUN или TURN, назначение для RTCP-порта с номером на единицу большим, чем у порта, выделенного для RTP-трафика, невозможно, специальный атрибут rtcp в SDP-части (RFC 3605) может содержать произвольный номер порта и IP-адрес, на котором UA готов принимать RTCP-сообщения.

Словом, спецификация ICE выглядит весьма многообещающе, и это решение находит поддержку VoIP-индустрии. Описание ICE дано в [6].

Один пример с проксированием как SIP-сигнализации, так и медиатрафика, мы уже видели – это TURN. Рассмотрим, каким образом можно реализовать проксирование одного лишь медиатрафика при помощи RTP-прокси-сервера и B2BUA («Back-to-back user agent» – SIP-узел, состоящий из двух SIP UA, которые общаются между собой строго на прикладном уровне). Критерием для определения факта присутствия NAT чаще всего служит наличие немаршрутизируемого IP-адреса в поле заголовка Contact.

Далее, нам известно, что для того, чтобы RTP-трафик достиг UA за NAT, в качестве адреса и порта назначения следует использовать IP-адрес NAT-устройства и порт, анонсированный в определении медиапотока в SDP части. Следовательно, когда факт присутствия NAT установлен, B2BUA «запоминает» IP-адрес, с которого был получен запрос, и сообщает пару «IP-адрес : номер порта» устройству RTP-прокси, чтобы тот использовал эти данные для отправки трафика инициатору вызова в дальнейшем. RTP-прокси создаёт новый сеанс, выделяет новую пару IP-адрес: порт для медиа-потока и сообщает её B2BUA. Тот подставляет полученные (маршрутизируемый) IP-адрес и порт в SDP-сообщение перед пересылкой запроса адресату. Аналогичные манипуляции выполняются c SDP-сообщением адресата. В результате весь медиатрафик протекает через RTP-прокси.

Для функционирования этого механизма принципиально важным является свойство симметричности пользовательского агента: использование для передачи и приёма одного и того же порта (UA должен отправлять медиа-поток с того порта, который он анонсировал в SDP). Но такой подход идеален в смысле точности данных: не требуется ничего, кроме собственно пакета, и поскольку пакет приходит на тот порт, с которого будет посылаться встречный поток – решаются проблемы со всеми видами NAT. В таком прокси-сервере можно реализовать любую дополнительную функциональность, связанную с модификацией SDP-части. В то же время это вносит дополнительную задержку в сеанс, повышает нагрузку на прокси-сервер и расходы сервис-провайдера.

Расширения Cisco COMEDIA

Если быть кратким, эти расширения [7] позволяют маршрутизатору обновить IP-адрес и порт источника, сохранённые для RTP-потока на этапе установления сессии, IP-адресом и портом, с которых был получен первый (прошедший через NAT) RTP-пакет.

Ведь пользовательский агент, находящийся за любым видом NAT, может успешно слать RTP-пакеты другому агенту с маршрутизируемым IP-адресом, а тот, в свою очередь, может достичь инициатора этого трафика по IP-адресу и номеру порта, с которых был получен первый RTP-пакет (при условии, что первый пользовательский агент симметричен). Такой подход напоминает симметричную маршрутизацию ответов, описанную в RFC 3581 [1], но для медиатрафика. Рассмотрим, как это работает в случае обоюдной поддержки COMEDIA сторонами. Пусть в INVITE было получено SDP-описание следующего содержания:

o=client 28908445312 28908445312 IN IP4 10.1.2.23

Источник

Вам также понравится

this is sparta актер

admin 0

как определить что кошка забеременела

admin 0

как правильно заваривать чабрец и чем он полезен

admin 0

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Все права сохранены. © 2024 3dsattv.ru Внимание! Информация, опубликованная на сайте, носит исключительно ознакомительный характер и не является рекомендацией к применению. Материалы могут содержать информацию, предназначенную для пользователей старше 18 лет. 18+.
Рубрика: IP-телефония / Инструменты