p asserted identity что это

Андрей Погребенник

Всё, что вы хотели знать о протоколе 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-адрес и номер порта, с которых запрос был на самом деле получен, в качестве контакта пользователя.

Рисунок 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).

Рисунок 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).

Рисунок 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.

Наконец, мы подошли к главному. 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.

Рисунок 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

Источник

Asterisk Call Party, Privacy, and Header Presentation

Home > Blog > Asterisk Call Party, Privacy, and Header Presentation

Asterisk Call Party, Privacy, and Header Presentation

Asterisk allows users to manipulate call party identification information through mechanisms like configuration options and dialplan functions (for instance CALLERID and CONNECTEDLINE to name a couple). This grants the user freedom to adjust values with regards to what call/caller information to expose and/or override. With this freedom, though, comes some complexity, and confusion. Especially when you mix in some PJSIP configuration options.

This post attempts to alleviate some of that confusion by clarifying the relationships between the presentation information and the relevant PJSIP endpoint configuration options. Primarily, with regards to the final presentation found in any applicable SIP headers: From, P-Asserted-Identity, Remote-Party-ID, Contact.

Depending on the options and parameters set within Asterisk you can mask or expose some, or all of the caller’s presentation information. For instance, setting the from_user and/or from_domain options on an endpoint will affect what’s written for the header’s SIP URI. If given that endpoint “alice” dials endpoint “mad_hatter”, by altering “mad_hatter’s” from user and domain options you’ll see something similar to the From headers written below (Note, 127.0.0.1 is only an example of IP address):

Of course altering the callerid also has an effect. For example, by prohibiting the callerid’s presentation some or all of the header’s sip URI will be anonymized:

What happens though if you invalidate just the callerid number? The string literal ‘asterisk’ is used in the SIP URI instead:

As you can see there is an order to things with the from user and domain options taking precedence over other settings.

P-Asserted-Identity and Remote-Party-ID

These headers are added to appropriate outbound SIP messages only under certain conditions. Once those conditions are met, and the header is added, parts of the privacy information transmitted can be concealed based on what’s allowed by the presentation. In order to add one or both of the headers, enable one or both of the following options on the target endpoint in the pjsip.conf configuration file:

By setting one of those options the applicable header is now added, and will contain the pertinent privacy information. Much like the From header, by setting the domain option you can override some of the privacy data.

Notice though that setting the from_user did not alter the header in any way. Only setting the from_domain has an effect. You can, though, remove the quoted name portion of the URI by invalidating the name presentation. For instance, by doing the following:

It results in something like below (from_domain not set):

However, if you use the CALLERID function to invalidate the number then the headers are blocked from being added to outgoing messages. The headers are also blocked from addition if you prohibit, or set the total presentation to unavailable:

This last case though is overridden if the following option is set on the endpoint definition in the pjsip.conf file:

Contact

I’ll only briefly talk about the contact header as it is not affected by call party data. However, it can be affected by an option already mentioned, namely the from_user option, so I figured it is worth showing what happens to the Contact header if that option is used. Here is a table showing how that option can override the default:

Note, that the from_domain option has no affect on the header. The user portion can also be further overridden by the contact_user endpoint option:

Concluding Remarks

As you can see Asterisk allows many ways to control the final presentation seen in various SIP headers. Hopefully, things are a little clearer about how you apply these methods to obtain a desired outcome.

Источник

• ← Ттк телеком что это
• мультик три богатыря актеры и роли →