IP-Телефония: Архитектура сети SIP

Архитектура сети SIP

Рис. 2 Архитектура «клиент-сервер»

Клиент выдает запросы, в которых указывает, что он желает получить от сервера. Сервер принимает запрос, обрабатывает его и выдает ответ, который может содержать уведомление об успешном выполнении запроса, уведомление об ошибке или информацию, затребованную клиентом.

Управление процессом обслуживания вызова распределено между разными элементами сети SIP. Основным функциональным элементом, реализующим функции управления соединением, является терминал. Остальные элементы сети отвечают за маршрутизацию вызовов, а в некоторых случаях предоставляют дополнительные услуги.

Кроме терминалов определены два основных типа сетевых элементов SIP: прокси-сервер (proxy server) и сервер переадресации (redirect server).

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

Сервер первого типа позволяет предоставить большее количество услуг, но работает медленнее, чем сервер второго типа. Он может применяться для обслуживания небольшого количества клиентов, например, в локальной сети. Прокси-сервер должен сохранять информацию о состояниях, если он:

— использует протокол TCP для передачи сигнальной информации;
— работает в режиме многоадресной рассылки сигнальной информации;
— размножает запросы.

Последний случай имеет место, когда прокси-сервер ведет поиск вызываемого пользователя сразу в нескольких направлениях, т.е. один запрос, который пришел к прокси-серверу, размножается и передается одновременно по всем этим направлениям.

Алгоритм работы пользователей с прокси-сервером выглядит следующим образом. Поставщик услуг IP-телефонии сообщает адpec прокси-сервера своим пользователям. Вызывающий пользователь передает к прокси-серверу запрос соединения. Сервер обрабатывает запрос, определяет местоположение вызываемого пользователя и передает запрос этому пользователю, а затем получает от него ответ, подтверждающий успешную обработку запроса, и транслирует этот ответ пользователю, передавшему запрос. Прокси-сервер может модифицировать некоторые заголовки сообщений, которые он транслирует, причем каждый сервер, обработавший запрос в процессе его передачи от источника к приемнику, должен указать это в SIP-запросе для того, чтобы ответ на запрос вернулся по такому же пути.

Сервер переадресации предназначен для определения текущего адреса вызываемого пользователя. Вызывающий пользователь передает к серверу сообщение с известным ему адресом вызываемого пользователя, а сервер обеспечивает переадресацию вызова на текущий адрес этого пользователя. Для реализации этой функции сервер переадресации должен взаимодействовать с сервером определения местоположения.

Сервер переадресации не терминирует вызовы как сервер RAS и не инициирует собственные запросы как прокси-сервер. Он только сообщает адрес либо вызываемого пользователя, либо прокси-сервера. По этому адресу инициатор запроса передает новый запрос. Сервер переадресации не содержит клиентскую часть программного обеспечения.

Но пользователю не обязательно связываться с каким-либо SIP-сервером. Он может сам вызвать другого пользователя при условии, что знает его текущий адрес.

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

Этот сервер может быть совмещен с прокси-сервером (в таком случае он называется registrar) или быть реализован отдельно от прокси-сервера, но иметь возможность связываться с ним.

В RFC 2543 сервер определения местоположения представлен как отдельный сетевой элемент, но принципы его работы в этом документе не регламентированы. Стоит обратить внимание на то, что вызывающий пользователь, которому нужен текущий адрес вызываемого пользователя, не связывается с сервером определения местоположения напрямую. Эту функцию выполняют SIP-серверы при помощи протоколов LDAP (RFC 1777), rwhois (RFC 2167), или других протоколов.

Резюмируя все сказанное выше, отметим, что сети SIP строятся из элементов трех основных типов: терминалов, прокси-серверов и серверов переадресации. На рис. 3 приведен пример возможного построения сети SIP.

Рис. 3 Пример построения сети SIP

Структурная схема организации услуг SIP-сервера представлена на рисунке 4.

Рис. 4 Структурная схема организации услуг SIP-сервера

Модуль управления услугами отвечает за предоставление услуг и за общее управление сервером. Принятые сервером запросы и ответы поступают в модуль управления услугами и обрабатываются им, на основании чего определяется реакция на полученные сообщения. Интерфейс человек-машина позволяет гибко менять настройки сервера и вести мониторинг сети.

Источник

VoIP для начинающих. Часть II: SIP

Разное.

Разве что можно особо выделить эффективность дополнительных средств защиты на базе ферромагнитных сердечников (смотреть тут внизу страницы). Практика показала, что такое нехитрое устройство (получившее уже прозвище «бочка») мало уступает по эффективности обычной диодно-сапрессорной грозозащите, а их совместное использование так и вообще приближает качество к заветным (но недостижимым) 100%.

Небольшая коллекция грозоужастиков:

Эти защиты (классический АРС) стояли с двух сторон одной линии. После грозы в них не осталось ни одного целого элемента. Даже текстолит выгорел.

Несмотря на лето, время отпусков и снижения объемов продаж, интересно и на другом краю провайдерского рынка. Так, в Екатеринбурге интрига прихода на рынок новой «дочки» телефонного монополиста начала приобретать реальные черты. Время презентаций еще не настало (для них есть осень), однако какие-то выводы сделать уже можно.

Напомню предысторию. До недавнего времени основным трансгородским транспортным средством была сеть «ОАО СЦК», построенная в основном на инфраструктуре телефонного монополиста «Уралтелеком». При этом конечных пользователей мог подключить через сеть ADSL любой оператор, которому «ОАО СЦК» предоставляло в аренду транспорт на равных и публичных условиях.

Однако время идет. Вместо Уралтелекома появился филиал Уралсвязьинформа, который объявил о планах самостоятельной работы по АДСЛ с конечным пользователем (через дочку «Уралком»). Правда намерения целых два месяца не могли получить развития в виде коммерческого предложения. Только на прошлой неделе оно появилось, но по нему условия для провайдеров стали, пожалуй, только хуже.

В то же время сразу несколько альтернативных операторов успели построить свои магистральные сети масштаба города (сотни километров оптоволокна), и относительно успешно их продают конечным пользователям и небольшим субпровайдерам (как правило «домашним сетям»). Так что можно сказать, что роль ADSL как магистрального транспорта уже сыграна, и новое его позиционирование должно быть сделано на домашнего пользователя. Это значит, что конкуренция домашним сетям усилится, а транзитная сеть для них должна в недалекой перспективе стать оптической (для сохранения качественного отрыва).

Кроме того, есть примерно полдюжины «выносов» в разных районах города, от которых можно проложить «волокно до стола» чуть не в любой офис. Последнее, кстати, выгодно отличает «GigaLine» от MSK-IX (структура, тарифы).

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

Так что думаю, что осенью скучать не придется. 😉

Немного ссылок на полезные ресурсы и документы:

Компания J’son & Partners (J&P) предлагает новый (июньский) выпуск информационного бюллетеня «Российский рынок интернет-доступа». Бюллетень представляет результаты постоянного мониторинга развития Интернета в России, который осуществляется компанией J&P.

Беспроводные сети и прочее Ужасы по построению радиолинка в военной части.

Бесплатная биллинговая система для ВПН сетей. Работает только под LINUX-ом. Практически все нужные и ненужные функции, открытый исходный код, возможность легкого изменения под свои нужды. Подойдет для использования средним ISP (количество пользователей до 5000), в домашних сетях, организациях и т.п.

Забавное объяснение чему равен 1U и подарок админу на день рождения:

Узел называется (вроде бы) кулак обезьяны.

VoIP для начинающих. Часть вторая: SIP

Автор данного текста Эдуард Афонцев, Екатеринбург.

Одним из наиболее перспективных протоколов сигнализации в современных приложениях IP телефонии является SIP. Расшифровывается как Session Initiation Protocol, то есть протокол управления (инициализации, модификации и прерывания) коммуникационными сессиями с одним или несколькими участниками. Определение сессии включает в себя: интернет мультимедиа конференции, интернет телефонные звонки и прочее.

По мнению многих специалистов SIP более приближен к IP сетевому взаимодействию, чем все остальные протоколы (H323, MGCP и другие). SIP использует обычные текстовые сообщения и очень напоминает http (практически базируется на нем). Архитектура сети SIP базируется на клиент-серверном взаимодействии.

Компоненты SIP делятся на два класса: клиенты и серверы.

Только UA непосредственно взаимодействует с клиентом. Все остальные компоненты SIP сети этого не могут, они взаимодействуют только с UA или между собой.

Часто Registrar комбинируется с proxy, но это отдельный логический процесс.

Redirect сервер не терминирует звонки.

В результате SIP архитектура выглядит следующим образом:

Поиск серверов.

Адресация.

Синтаксис SIP адреса следующий:

Кроме того, в SIP адрес могут входить дополнительные параметры (пароли, номера портов и тому подобное).

Приведем примеры SIP адресов:

Sip: vasya@home.ru
Sip: petya@192.168.0.1
Sip: 12345@gate.ru

Структура SIP сообщения.

Все SIP сообщения делятся на два вида: запросы и ответы на них.

Структура любого сообщения выглядит так:
Start line
Headers
Body.

В свою очередь Start line запроса включает в себя Method, Request-URI, SIP version.

Для примера приведем начало стандартного sip запроса:
INVITE sip: vasya@etel.ru SIP/2.0

Ответы делятся на две группы: информационные и финальные.

Информационные ответы содержат в себе ознакомительные данные. Например:
Trying, ringing.

Финальные обозначают завершение каких-либо транзакций. Например:
Ok. Начало любого SIP ответа (start line) состоит из SIP version, Status Code и Reason Phrase, например:
SIP 2.0 Trying

Сценарии SIP взаимодействий.

UA-UA. Взаимодействие непосредственно между клиентскими приложениями (UA) без участия серверов. Для этого вызывающий UA должен знать текущий адрес вызываемого абонента.

Далее идет разговор (RTP/RTCP между клиентскими приложениями).

Звонки c участием Proxy сервера (или нескольких серверов).

Вызывающий UA должен знать постоянный адрес абонента, а прокси осуществит поиск и приглашение к сеансу связи. Текущий адрес знать не обязательно. Кроме того, UA должен предварительно выяснить IP адрес прокси сервера (например заданный в конфигурации).

Фаза вызова (звонка):

Разговорная фаза (RTP, RTCP) проходит только между клиентскими приложениями (UA) и не задействует прокси.

Фаза завершения связи (разрыва соединения):

Завершение связи, так же как и инициализация, проходит через Proxy сервер, который практически ретранслирует SIP сообщения.

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

Обычно сервер регистрации и прокси сервер объединяют в одно приложение и в результате получают комбинированный SIP сервер доступа к VoIP сети.

Взаимодействие с участием Redirect сервера.

В данном случае UA в итоге самостоятельно установит соединение, а сервер переадресации только преобразует постоянный адрес в текущий. Текущий адрес знать не обязательно, это задача сервера переадресации.

Фаза вызова (звонка):

Далее вызывающий абонент взаимодействует с вызываемым непосредственно и без участия REDIRECT сервера.

Фаза завершения связи (разрыва соединения):

Практически участие REDIRECT сервера сводится к сообщению текущего адреса вызываемого абонента (UA), а все дальнейшее взаимодействие происходит по схеме UA-UA.

Заключение.

Как видно даже из такого неполного описания, протокол SIP позволяет строить гибкие схемы IP телефонии, предоставляя клиентам расширенные сервисы управления соединениями.

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

Анонс

Источник

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

Источник