sip pai address что это
SIP-технология
Что такое SIP
Session Initiation Protocol (SIP) – сетевой протокол для управления сеансами связи, т.е. установления, контроля и разрыва сессий между двумя или несколькими участниками. Иначе говоря, SIP – протокол сигнализации для сетей IP-телефонии.
SIP – простой и универсальный протокол. Он позволяет устанавливать между пользователями не только голосовое соединение, но и другие виды коммуникаций: видеосвязь, аудио- и видеоконференции, чат, онлайн-игры и т.д.
Строго говоря, SIP не описывает передачу медиа-трафика. Например, для передачи голоса две стороны должны договориться об использовании одинаковых кодеков, закодировать и упаковать речь в IP-пакеты на одном конце соединения, передать ее и раскодировать на другом конце. Эти процессы описаны в других протоколах, таких как SDP (Session Description Protocol) или RTP. Но обычно SIP-приложения поддерживают все протоколы, необходимые для передачи медиа-трафика.
Другие протоколы
В IP-телефонии используются и другие протоколы, например, H.323, IAX (для Asterisk) или MGCP (протокол управления VoIP-шлюзами). Но благодаря простоте, гибкости и открытым стандартам SIP стал самым распространенным протоколом IP-телефонии. Поэтому операторы связи часто называют свои услуги SIP-телефонией.
Преимущества SIP
SIP победил другие протоколы IP-телефонии благодаря ряду преимуществ:
Адреса SIP
Каждому пользователю SIP (Session Initiation Protocol) присваивается SIP-адрес, состоящий из имени пользователя и домена и похожий на email адрес. Например, anna@company.ru. Если писать полный SIP-адрес с указанием протокола, то он выглядит как sip: anna@company.ru для нешифрованных соединений или sips: anna@company.ru для шифрованных.
SIP-адрес не привязан к географическому месту, пользователь может принять звонок на такой адрес в любой точке мира.
Набирать SIP-адрес вида alice@company.de не всегда удобно, а абоненты традиционной телефонии не могут позвонить по такому номеру. Поэтому провайдеры облачных SIP-АТС, помимо SIP-адресов, выделяют пользователям и обычные телефонные номера. Звонок на эти номера переадресуется на SIP-телефон пользователя.
Если пользователь – частное лицо или предприниматель, он получает обычный городской номер (из номерного плана России). Если пользователь подключен к облачной АТС компании, он получает короткий внутренний номер, например, 1234.
Для того, чтобы избежать путаницы, имя пользователя в SIP-адресе часто делают совпадающим с телефонным номером. Например, пользователю назначается внутренний телефонный номер 1234 и присваивается SIP-адрес 1234@company.ru.
Основные стандарты и протоколы
Разработкой протокола SIP (Session Initiation Protocol) занимается интернет-сообщество IETF (Internet Engineering Task Force). Стандарт имеет номер RFC 3261. Кроме того, IETF выпустил несколько расширений протокола, например, RFC 6665 (event notification) или RFC 3262 (reliable provisional responses).
Для передачи медиа-потока: голоса, видео, текста, SIP работает в связке с другими протоколами. Прежде всего это
На практике оборудование и приложения SIP разных производителей обычно совместимы друг с другом. Но иногда бывают проблемы совместимости, если сервис-провайдер или производитель оборудования не строго придерживается стандартов.
Как работает SIP
SIP строго разделяет установление соединения и передачу мультимедийных данных. Если Анна звонит через SIP-телефонию Борису, происходит вот такой обмен сообщений:
Обычно обмен сообщениями происходит не непосредственно между SIP-телефонами (они называются UAC – User Agent Client), а через вспомогательные серверы. Иначе Анна не узнает, по какому IP-адресу находится телефон Бориса и готов ли он принимать сообщения. А вот передача медиа-данных может происходить как непосредственно между абонентами, так и через сервер провайдера услуг.
SIP-сеть содержит ряд серверов, для того, чтобы обеспечить надежную передачу сообщений, определить местонахождение абонента, связать SIP-сеть с традиционной телефонной сетью:
В случае облачных SIP-АТС все эти серверы находятся в дата центрах провайдера, который их обслуживает и обновляет. Пользователь непосредственно имеет дело только с SIP-телефонами.
В чем разница между VoIP (Voice over IP) и SIP?
Эти слова звучат похоже и часто взаимозаменяемы. Но все же между ними есть некоторая разница.
SIP отвечает за установление соединений.
VoIP тоже содержит протоколы для установления соединений (чаще всего это SIP, но могут быть и другие протоколы). Но кроме этого, VoIP содержит механизмы для оцифровки и компрессии голоса, заполнения IP-пакетов голосовыми данными и передачи голоса по сетям IP.
Таким образом, SIP-телефония является разновидностью VoIP-телефонии (IP-телефонии). Наиболее успешной разновидностью.
NAT & Firewalls
Одно из немногих слабых мест SIP—сложности работы протокола с NAT Firewall, производящих трансляцию сетевых IP-адресов и портов. Дело в том, технологии NAT Firewall разрабатывались до появления SIP, и без проблем устанавливать SIP-соединение можно только через NAT Firewall определенного типа.
Для того, чтобы SIP работал через NAT firewall, были разработаны несколько технологий: самая распространенная STUN/TURN, а также ICE и ALG (Application Level Gateways).
С практической точки зрения важно, что сегодня проблемы прохождения SIP через NAT Firewall решены сервис-провайдерами для подавляющего большинства конфигураций маршрутизаторов. Но если у вас возникли сложности с прохождением VoIP-трафика через NAT, обращайтесь в нашу службу технической поддержки.
Безопасность SIP
Вопреки расхожему мнению, SIP можно хорошо защитить от прослушивания и взлома сигнализации. Поток голосовых данных может быть зашифрован помощью протокола sRTP или с помощью VPN с шифрованием, например, IPsec.
Методы защиты сигнализации SIP, используемые провайдером, аналогичны тем, которые используются для защиты HTTP и e-mail сообщений – это разные схемы шифрования и аутентификации: Digest Authentication, S/MIME, IPsec, SIPS URI (TLS). Наиболее удобный вариант для организации массовых услуг – Digest
Authentication и шифрование сигнализации SIP с помощью TLS протокола. SIP, зашифрованный с помощью TLS, называется SIPS.
Впрочем, как показывает практика MANGO OFFICE, протокол SIP подвергается атакам редко. Чаще всего злоумышленники пытаются получить доступ к SIP учетной записи пользователя, подобрав слишком простой пароль. Другой вариант – получить внутри компании доступ к данным, составляющим коммерческую тайну. Поэтому в MANGO OFFICE уделяется большое внимание мерам по борьбе с простыми паролями и разработке системы ролей и разграничения прав доступа. Если вы хотите передавать телефонию по зашифрованному каналу, обращайтесь к нашим специалистам.
Аппаратный телефон. Такие телефоны могут быть настольными или переносными (DECT или Wi-Fi), а также могут поддерживать видеосвязь.
Для звонков необходим мобильный интернет, например, Wi-Fi или LTE
Session Initiation Protocol и сервисы MANGO OFFICE
Облачная телефонная система MANGO OFFICE построена на основе SIP. Основные SIP-серверы реализованы на основе открытого ПО OpenSIPS, в развитии которого принимают участие разработчики MANGO OFFICE. Наиболее функциональный SIP-клиент для облачной телефонии MANGO OFFICE – Mango Talker. Это корпоративный мессенджер-софтфон, позволяющий пользователям общаться с коллегами и клиентами через множество голосовых, текстовых и видеоканалов.
Остались вопросы или хотите подключить сервис?
В интернет-магазине
Вы сможете сразу пользоваться услугой после оформления заказа в интернет-магазине. Выберите свой тариф.
По телефону
Позвоните нам, и наши специалисты за нескольких минут подберут для вас оптимальное решение.
P-Asserted-Identity против истории
Я новичок в области SIP. Поэтому, пожалуйста, простите, если есть старые/простые вопросы.
Пожалуйста, возьмите базовый поток вызовов, как показано ниже, для анализа.
A, B, C являются расширениями на той же УАТС.
Вопрос 1. Итак, в сообщении INVITE, информация о истории будет содержать:
Вопрос 2. И заголовок PAI будет генерировать сообщение INVITE C
Вопрос 3. Я просто хочу знать, когда в SIP-сообщении встречаются 2 заголовка SIP: история-информация и P-Asserted-Identity (PAI)? и в каком случае?
Вопрос 4. Разница между двумя заголовками SIP выше и их целью. Создаются ли они на сообщении INVITE или других?
Пожалуйста, помогите мне сделать эти проблемы ясными.
Q1: Не знаете, в чем вопрос, но если все UA (расширения) отправляют вызовы через УАТС, УАТС может добавлять поля History info в любой запрос, не связанный с установленным диалоговым окном (INVITE, REGISTER, MESSAGE, REFER и ОПЦИИ, ПУБЛИКАЦИЯ, ПОДПИСКА. )
Q2: Поле PAI должно быть установлено с идентификатором вызывающей стороны, который по-прежнему является расширением A для внутренних вызовов. В другом сценарии, например, когда A вызывает B и B, перенаправление на внешнюю линию, PAI может быть перезаписана УАТС с исходящим номером B до того, как вызов будет отправлен через внешнюю магистраль SIP.
Q4: Q3 объясняет разницу между ними, PAI держит идентификатор, а поля histinfo содержат индексированное отслеживание SIP URI, через которое передается сообщение, и любую дополнительную информацию. PAI может появиться в INVITE/OPTIONS/SUBSCRIBE/NOTIFY, для того, чтобы histinfo смотри Q1.
Взаимодействие клиентов SIP. Часть 2
В предыдущей статье мы рассмотрели простое взаимодействие клиентов SIP без использования Proxy-сервера. Такое взаимодействие на практике встречается чрезвычайно редко, но отлично подходит для того, чтобы понять основы SIP.
Выбор транспортного протокола и поиск Proxy
Поскольку протокол SIP поддерживает несколько транспортных протоколов (UDP, TCP, SCTP, TLS), необходимо каким-то образом определять, какой протокол использовать. Для этого существет несколько способов.
Первый способ предполагает явное указание транспорта в SIP URI (кроме TLS). Выглядит это вот так:
Итак, мы выяснили, параметры Proxy-сервера Ивана. Теперь предлагаю рассмотреть использование Proxy в рамках SIP-диалога.
Ремарка для тех, кто не знает, что такое NAPTR. Я узнал, что есть такой тип DNS-записи только, когда писал эту статью, так что не отчаивайтесь. Чуть подробнее про NAPTR здесь.
Взаимодействие с использованием Proxy
Для чего же нам необходим SIP Proxy? Как я уже сказал, в примере из 1-ой части статьи клиенты знали IP-адреса друг друга и могли общаться напрямую. В реальной жизни клиенты чаще всего получают адреса динамически, поэтому нет смысла «запоминать» тот или иной IP. Первое, что приходит на ум в данной ситуации – использовать A-записи DNS и определить реальный действующий адрес. Однако тут кроется следующая проблема: IP-адрес идентифицирует конкретное устройство, а не пользователя на нем. Особенностью взаимодействия SIP является то, что обмен сообщения происходит не на уровне устройство-устройство, а на пользователь-пользователь. При этом один пользователь может одновременно использовать несколько SIP-клиентов: на мобильном телефоне, на рабочем компьютере, на домашнем компьютере и на SIP-телефоне. Как же быть?
Протокол SIP предлагает следующее решение: создается SIP Proxy и каждый пользователь регистрирует свои устройства на этом Proxy (точнее пользователи регистрируются на сервере регистрации, а Proxy имеет доступ к базе регистрации, но для простоты будем считать, что это один и тот же сервер). Как это делается, я покажу ниже. Пока просто запомните, что Proxy знает, как именно найти тот или иной клиент пользователя.
Для тех, кто изучил первую часть статьи, все выглядит довольно знакомо; добавился только промежуточный Proxy-сервер. Соответственно и обмен сообщениями изменился незначительно.
Прежде, чем преступим к детальному рассмотрению, маленькая ремарка. В рамках SIP разделяют два типа URI. Первый из них – ползовательский URI, также известный как address of recorf (AOR). Запрос, отправленный на этот адрес предполагает поиск в базе данных Proxy и отправку запроса одному или несольким устройствам. Второй – URI устройства (а точнее – пользователя на устроястве). URI устройства обычно называется контакт и содержится, соответственно, в поле Contact SIP-сообщения. AOR содердится в полях From и To.
Начало разговора
Итак, Петр посылает INVITE для Ивана на Proxy-сервер:
Proxy-сервер перенаправляет запрос всем SIP-клиентам Ивана. Для простоты предположим, что Иван использует только одно устройство. Чтобы SIP-клиент понимал, что запрос был перенаправлен через Proxy, сервер добавляет свое заголовочное поле via:
SIP-клиент Ивана шлет ответ 180 Ringing (Иван слышит звонок). При этом он добавляет tag в поле To и указывает свой контакт в поле Contact. Кроме того, в первом поле via добавился параметр received этот параметр показывает, с какого адреса клиент Ивана получил запрос (т.е. адрес Proxy-сервера, как его видит Иван). Это бывает полезно знать для решения возникающих проблем:
Proxy, соответственно, перенаправляет запрос клиенту Петра. При этом он убирает свой via:
После отправки 180 Ringing, как только Иван снимет трубку, клиент Ивана отправляет на Prxoy ответ 200 OK:
Proxy передает этот ответ Петру, убирая при этом via:
Теперь самое интересное. Клиент Петра отправляет сообщение АСК непосредственно клиенту Ивана в обход Proxy. Причем, если бы Иван одновременно использовал несколько клиентов SIP, ответ пришел именно на тот, который нужно. Благодаря чему это возможно?
200 ОК отправляется с клиента на котором Иван снял трубку. Более того, в поле Contact ответа 200 ОК содержится URI, соответствующий пользователю Иван на конкретном устройстве. Таким образом клиент Петра отправляет АСК именно на это устройство, после чего участие Proxy больше не требуется:
Все остальные сообщения, включая медиа-траффик идут в обход Proxy.
Конец разговора
В конце разговора клиент Ивана отправляет BYE напрямую клиенту Петра:
Петр в ответ шлет подтверждение:
Здесь все, как в первой части статьи.
Итак, мы рассмотрели взаимодействие SIP-клиентов с участием Proxу-сервера. Остался один единственный вопрос: откуда Proxy узнал адреса клиентов Ивана? С помощью процедуры регистрации. Как это происходит, я расскажу ниже.
SIP-регистрация
Регистрация выглядит следующим образом:
Давайте подробнее рассмотрим каждое из сообщений. Иван отправляет на сервер запрос Register (для простоты считаем, что роль сервера регистрации установлена на proxy.domain.ru). Самое важное в этом запросе – поле Contact. Это адрес Ивана на конкретном устройстве:
В ответ сервер присылает 401 Unauthorized, то есть требование авторизации. Самое важное поле в ответе — WWW-Authenticate. Не сложно догадаться, что realm — это домен, а algorithm указывает, какой хеш-алгоритм мы будем использовать. Интерес вызывает поле nonce:
Nonce — это сокращение от «number used once». Nonce — это одноразовая случайная последовательность, которую клиент Ивана cкомбинирует со строкой пароля, после чего сгенерирует MD5-хеш от полученной строки и поместит результат в новый запрос в поле WWW-Authenticate (на самом деле все несколько сложнее, но для простоты будем считать, что все именно так). Для этого служит параметр response.
Зачем нужен nonce? Если бы клиент генерировал MD5 от пароля и не использовал nonce, то хеш каждый раз получался бы один и тот же. Злоумешленник мог бы перехватить такой хеш и использовать для авторизации. Это было бы столь же небезопасно, как передавать пароль в открытом виде.
Если использовать nonce, MD5 каждый раз берется от новой строки и получается разным. Поэтому даже перехватив хеш, злоумышленник скорее всего не сможет его использовать для авторизации.
Кстати, обратите внимание, что новый запрос на регистрацию имеет CSeq на единицу больше:
Сервер также комбинирует nonce с паролем Ивана и получает MD5-хеш. После этого он сравнивает свой хеш с хешем, полученным от Ивана. Если они совпадают, то сервер присылает 200 ОК. Обратите внимание на то, что в поле Contact добавился параметр expires. В данном случае регистрация будет храниться в базе сервера в течение 3600 секунд или одного часа:
Если Иван хочет продлить регистрацию, то он должен отправить еще один REGISTER в течение этого часа.
Что делать, если Иван использует сразу несколько устройств с поддержкой SIP? Все очень просто – необходимо отправить запрос на регистрацию с каждого из них.
После того, как в базе данного сервера регистрации появится соответствующая запись, Proxy-сервер сможет перенаправлять запросы на SIP-клиенты Ивана.
Bonus для тех, кому интересно
Вы могли заметить, что, в ответ на запрос регистрации, сервер присылает ответ, содержащий To-tag:
Понятно, что при установке диалога данный tag помогает избежать повторного получения одного и того же сообщения. Для этого существует правило: если сообщение не содержит To-tag и UAS уже получал сообщение с таким же CSeq, From-tag и Call-ID, то сообщение отбрасывается. Для чего же нужен To-tag, если мы не устанавливаем диалог с сервером регистрации. Лучший ответ, который я смог найти — в RFC 3261 написано, что ответ 200 ОК, приходящий на запрос без To-tag должен содержать To-tag. То есть, это ни для чего не нужно, но так принято.
Надеюсь, что работа протокола SIP, после прочтения статьи, стала для вас более понятной. Буду рад вашим комментариям.
SIP Configuration Guide, Cisco IOS Release 15M&T
Book Title
SIP Configuration Guide, Cisco IOS Release 15M&T
Chapter Title
PAI or PPI Header in Incoming and Outgoing SIP Calls
View with Adobe Reader on a variety of devices
Results
Chapter: PAI or PPI Header in Incoming and Outgoing SIP Calls
PAI or PPI Header in Incoming and Outgoing SIP Calls
Prior to the introduction of the PAI or PPI Header in Incoming and Outgoing SIP Calls feature, the P-Asserted-Identity (PAI) or the P-Preferred-Identity (PPI) privacy header was supported for outgoing calls at the global level. The PAI or PPI Header in Incoming and Outgoing SIP Calls feature is an enhancement to support PAI or PPI header for incoming and outgoing calls at the global level and dial-peer configuration mode.
This module describes how to enable support for the PAI or the PPI privacy header in incoming and outgoing Session Initiation Protocol (SIP) requests or response messages.
Finding Feature Information for PAI or PPI Header in Incoming and Outgoing SIP Calls
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information for Handling PAI or PPI Header in Incoming and Outgoing SIP Calls.
Contents
Information About PAI or PPI Header in Incoming and Outgoing SIP Calls
PAI or PPI Header Overview
For incoming SIP requests or response messages, when the PAI or PPI privacy header is set, the SIP gateway builds the PAI or PPI header into the common SIP stack, thereby providing support to handle the call data present in the PAI or PPI header. To process the data from the PAI or PPI header of incoming SIP calls, we recommend that you enable the asserted ID for the incoming dial peer.
For outgoing SIP requests or response messages, when the PAI or PPI privacy header is set, privacy information is sent using the PAI or PPI header.
