Содержание

Чем отличается SIP-телефония от IP и VoIP

Если вы хоть раз читали про виртуальную АТС, то наверняка сталкивались с этими терминами. Поэтому для начала разберемся — в чем же разница между SIP, IP-телефонией и VoIP. Это поможет вам не запутаться в терминологии и сразу понять, как все устроено.

Начнем с самого обширного понятия — IP (Internet Protocol — «межсетевой протокол»). Можно сказать, что это “начало всех начал”, так как именно протокол IP связал все компьютерные сети мира в глобальную сеть интернет. Именно поэтому у каждого компьютера есть свой уникальный IP-адрес, который нужен для обмена данными.

Для передачи аудиоданных по сети есть своя технология — она называется VoIP (Voice over IP — «голос по интернет-протоколу IP»). Благодаря ей мы можем обмениваться любыми данными, где присутствует голос — звонить через интернет, транслировать вебинары или смотреть видео с камер видеонаблюдения со звуком.

IP-телефония — общее название для телефонной связи через интернет. Это составляющая часть VoIP, но сюда относятся только звонки и видеообщение по сети и ничего больше. Как понятно из названия, связь происходит благодаря тому же самому протоколу IP.

Еще более узкое понятие SIP-телефония. Если IP-телефония — это название технологии в целом, то SIP — лишь одна из ее разновидностей, протокол связи. Если проводить сравнение, то они так же относятся друг к другу, как ноутбук и ASUS.

О SIP мы поговорим ниже, а пока подытожим:

SIP-телефония: что это и как она работает

Итак, SIP (Session Initiation Protocol) — протокол передачи данных. Его можно сравнить с языком, который помогает устройствам понять друг друга и обмениваться данными без ошибок. Он используется для множества целей — для IP-телефонии, видео и аудиоконференций и даже онлайн-игр. Говоря упрощенно, он работает по схеме “клиент-сервер”, постоянно чередуя запросы и ответы.

Так сложилось, что часто словом SIP иногда называют технологию звонков через интернет в целом. Тогда возникает вопрос: SIP и IP-телефония — в чем разница? Отличие в том, что SIP-телефония — это связь через интернет только с помощью конкретно этого протокола. Например, ее использует Skype.

Есть и другие протоколы для IP-телефонии. Но в наше время SIP — это универсальный стандарт для обмена данными по сети. Специалисты считают его самым перспективным, и он чаще всего используется. SIP-телефония доступна там, где есть интернет со скоростью не менее 64 Кбит в секунду. То есть практически повсюду.

IP-телефония позволяет привязать номер не к локации, а к конкретному пользователю, и это открывает широкие возможности, например, для аналитики. Ведь так о клиенте можно узнать гораздо больше. В частности, эта технология лежит в основе отслеживания звонков (call tracking).

Как можно звонить и принимать звонки с помощью SIP:

  • с помощью компьютера или ноутбука, если установить на него специальную программу (SIP-клиент) и оснастить его наушником и микрофоном;
  • через WI-FI или 3g/4g с помощью SIP-программ для планшетов и мобильных телефонов;
  • используя специальный стационарный SIP-телефон, который включаются в роутер;
  • подключить обычный телефон к VoIP-шлюзу, а сам шлюз — к роутеру.

Как работает SIP-телефония

Рассмотрим пример, когда человек звонит с компьютера, на котором установлен SIP-клиент, в компанию, которая использует SIP-телефонию:

  1. Во время звонка специальная программа (кодек) сжимает голос клиента в цифровой сигнал. Это ускоряет связь и снижает нагрузку на сеть.
  2. Сигнал передается в устройство, которое использует компания (компьютер, SIP-телефон и т. д.).
  3. Два устройства находят друг друга по IP-адресу и начинают сеанс связи по SIP-протоколу.
  4. Сигнал снова преобразуется в аналоговый, и менеджер, принимающий звонок, слышит обычный голос клиента.

Ниже упрощенная схема, которая иллюстрирует работу SIP-телефонии при таком входящем звонке:

Преимущества SIP-телефонии

Этот вид телефонии настолько удобен и практичен, что активно вытесняет традиционную телефонию. В первую очередь это касается бизнеса — и неудивительно, ведь она позволяет экономно и быстро обеспечить компанию связью. Рассмотрим плюсы этого вида связи:

  • Дешевле, чем подключение и настройка аналоговой офисной АТС. Вы получите в распоряжение многоканальный номер, который никогда не будет занят (если у вас будет достаточно сотрудников). Также вы можете увеличивать количество операторов в корпоративной сети без значительных затрат.
  • Быстрая телефонизация компании. Если риелторы говорят про хорошие квартиры “заходи и живи”, то SIP-телефония — это “заходи и работай”. Даже если вы только въехали в офис с голыми стенами и в нем нет ничего кроме компьютера и наушников с гарнитурой. У вас может даже не быть интернета — достаточно наличия качественного 3G соединения.
  • Вы платите за звонки по базовым тарифам на услуги телефонной связи — вне зависимости от того, где находится абонент. SIP-номера дешевле, чем установка обычной телефонной линии. Особенно это удобно для телефонизации крупных предприятий с большим количеством филиалов и отделов, которые находятся в разных местах.
  • SIP-телефония позволяет объединить данные о звонках с 1C, CRM, системами аналитики. И сделать ваш бизнес более эффективным с помощью этих данных. Например, благодаря SIP-телефонии возможно отслеживание звонков. А с помощью коллтрекинга вы сможете видеть, из каких рекламных источников к вам приходят клиенты — и принимать правильные решения для повышения продаж.
  • С помощью SIP-телефонии и коллтрекинга, вы можете следить за нагрузкой на отдел продаж, его эффективностью и контролировать каждого менеджера, прослушивая звонки. Все это повысит уровень обслуживания и повлияет на процент закрытия сделок.
  • Нет ограничения по географии. Например, Ringostat позволяет подключить SIP-номера в любой части мира, где есть SIP-телефония. Мы обеспечиваем высокое качество связи в Северной Америке, Европе и большей части Азии.
  • SIP-номера разных стран можно подключить к коллцентру или отделу продаж вне зависимости от его местонахождения. Например для московского офиса можно подключить входящие номера Киева, Минска, Лондона
  • Хорошая защита от прослушивания, в отличие от традиционных телефонных линий.
  • Вы можете создать удаленный коллцентр, выделив для него SIP-номера — так вы сэкономите на оборудовании и аренде офиса.
  • Гибкие настройки — вы можете настроить сложную схему переадресации между отделами и менеджерами, голосовую почту, автоответчик, IVR (голосовое меню). Можно выстраивать очередь звонков, в зависимости от занятости менеджеров, записывать разговоры и т. д.
  • Благодаря SIP-телефонии, можно настроить форму обратного звонка на сайте. Как показывает опыт Ringostat, иногда она позволяет увеличить количество звонков на 48%.
  • Вы можете настроить вашу виртуальную АТС в соответствии с вашим рабочим графиком и выходными днями. Например, она может переадресовывать звонки, поступающие в нерабочее время, на мобильные номера сотрудников. Ниже пример, как выглядит в Ringostat схема переадресации на период нерабочего времени в праздники:

Взаимодействие клиентов SIP. Часть 2


В предыдущей статье мы рассмотрели простое взаимодействие клиентов SIP без использования Proxy-сервера. Такое взаимодействие на практике встречается чрезвычайно редко, но отлично подходит для того, чтобы понять основы SIP.
Теперь, когда мы разобрались с базовыми вещами, предлагаю перейти к реальной работе протокола.
В этой статье я планирую рассмотреть три вопроса:

  1. Выбор транспортного протокола и поиск Proxy;
  2. Работа через Proxy;
  3. Регистрация на Proxy-сервере.

Выбор транспортного протокола и поиск Proxy

Поскольку протокол SIP поддерживает несколько транспортных протоколов (UDP, TCP, SCTP, TLS), необходимо каким-то образом определять, какой протокол использовать. Для этого существет несколько способов.
Первый способ предполагает явное указание транспорта в SIP URI (кроме TLS). Выглядит это вот так:

Если транспорт явно не указан, то действует следующий алгоритм:

  1. Если SIP URI содержит IP-адрес, то для SIP URI используется UDP, для SIPS (Secure SIP) – TCP.
  2. Если IP-адрес не укзаан, но укзаан порт, то для SIP URI используется UDP, для SIPS – TCP.
  3. Если отсутсвует IP-адрес и порт, но в DNS присутствует соответсвующая NAPTR-запись, тогда “SIP+D2U” соответствует UDP, “SIP-D2T” указывает на TCP и “SIP-D2S” — на SCTP. NAPTR содержит ссылку на SRV-запись, которая будет использоваться для поиска Proxy-сервера. Если NAPTR остуствует, то должен быть выполнен запрос на поиск SRV-записи.
  4. Результатом SRV запроса будет имя и порт Proxy-сервера.
  5. Если SRV-запись отсутствует, то выполняется A или AAAA-запрос. При это для SIP URI используется UDP, для SIPS – TCP.

Для того, чтобы лучше разобраться, рассмотрим пример, когда мы хотим связаться с клиентом sip:ivan@domain.ru:

Итак, мы выяснили, параметры Proxy-сервера Ивана. Теперь предлагаю рассмотреть использование Proxy в рамках SIP-диалога.
Ремарка для тех, кто не знает, что такое NAPTR. Я узнал, что есть такой тип DNS-записи только, когда писал эту статью, так что не отчаивайтесь. Чуть подробнее про NAPTR .

Взаимодействие с использованием Proxy

Для чего же нам необходим SIP Proxy? Как я уже сказал, в примере из 1-ой части статьи клиенты знали IP-адреса друг друга и могли общаться напрямую. В реальной жизни клиенты чаще всего получают адреса динамически, поэтому нет смысла «запоминать» тот или иной IP. Первое, что приходит на ум в данной ситуации – использовать A-записи DNS и определить реальный действующий адрес. Однако тут кроется следующая проблема: IP-адрес идентифицирует конкретное устройство, а не пользователя на нем. Особенностью взаимодействия SIP является то, что обмен сообщения происходит не на уровне устройство-устройство, а на пользователь-пользователь. При этом один пользователь может одновременно использовать несколько SIP-клиентов: на мобильном телефоне, на рабочем компьютере, на домашнем компьютере и на SIP-телефоне. Как же быть?
Протокол SIP предлагает следующее решение: создается SIP Proxy и каждый пользователь регистрирует свои устройства на этом Proxy (точнее пользователи регистрируются на сервере регистрации, а Proxy имеет доступ к базе регистрации, но для простоты будем считать, что это один и тот же сервер). Как это делается, я покажу ниже. Пока просто запомните, что Proxy знает, как именно найти тот или иной клиент пользователя.
Когда Петр звонит Ивану, выполняется следующая последовательность действий:

  1. SIP-клиента Петра определяет адрес и протокол SIP Proxy Ивана (как это делается — см. выше)
  2. Клиент отправляет на Proxy запрос INVITE
  3. Proxy-сервер смотрит, на каких устройствах зарегистрировался Иван и отправляет запрос на все эти устройства
  4. Иван отвечает на звонок на одном из устройств и шлет 200 OK на Proxy
  5. Proxy перенаправляет 200 OK Петру
  6. Петр получает SIP-адрес Ивана на конкретном устройстве из поля Contact вответе 200 ОК и шлет ответ напрямую, минуя Prxoy
  7. Все последующее общение идет также напрямую

На схеме это выглядит следующим образом:

Для тех, кто изучил первую часть статьи, все выглядит довольно знакомо; добавился только промежуточный 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 (англ. Session Initiation Protocol — протокол установления сеанса) — протокол передачи данных, описывающий способ установки и завершения пользовательского интернет-сеанса, включающего обмен мультимедийным содержимым (IP-телефония, видео- и аудиоконференции, мгновенные сообщения, онлайн-игры).

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

Пример сети на базе протокола SIP

Принципы протокола

Разработкой занималась организация IETF MMUSIC Working Group. Протокол начал разрабатываться в 1996 году Хенингом Шулзри (Henning Schulzrinne, Колумбийский университет) и Марком Хэндли (Университетский колледж Лондона). В ноябре 2000 года SIP был утверждён как сигнальный протокол проекта 3GPP и основной протокол архитектуры IMS (модификация 3GPP TS.24.229). Наряду c другим распространённым протоколом H.323, SIP — один из протоколов, лежащих в основе Voice over IP.

В основу протокола рабочая группа MMUSIC заложила следующие принципы:

  • Простота: включает в себя только шесть методов (функций)
  • Независимость от транспортного уровня, может использовать UDP, TCP, ATM и т. д.
  • Персональная мобильность пользователей. Пользователи могут перемещаться в пределах сети без ограничений. Это достигается путём присвоения пользователю уникального идентификатора. При этом набор предоставляемых услуг остается неизменным. О своих перемещениях пользователь сообщает с помощью сообщения REGISTER своему серверу.
  • Масштабируемость сети. Структура сети на базе протокола SIP позволяет легко её расширять и увеличивать число элементов.
  • Расширяемость протокола. Протокол характеризуется возможностью дополнять его новыми функциями при появлении новых услуг.
  • Интеграция в стек существующих протоколов Интернет. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом IETF. Кроме SIP, эта архитектура включает в себя протоколы RSVP, RTP, RTSP, SDP.
  • Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с другими протоколами IP-телефонии, протоколами ТфОП, и для связи с интеллектуальными сетям.

Дизайн протокола

Клиенты SIP традиционно используют порт 5060 TCP или UDP для соединения элементов SIP-сети. В основном, SIP используется для установления и разъединения голосовых и видеозвонков. При этом он может использоваться и в любых других приложениях, где требуется установка соединения, таких, как системы оповещения, мобильные терминалы и так далее. Существует большое количество рекомендаций RFC, относящихся к SIP и определяющих поведение таких приложений. Для передачи самих голосовых и видеоданных используют другие транспортные протоколы, чаще всего RTP.

Главной задачей разработки SIP было создание сигнального протокола на базе IP, который мог бы поддерживать расширенный набор функций обработки вызова и услуг, представленных в существующей ТфОП. Сам протокол SIP не определяет этих функций, а сосредоточен только на процедурах регистрации пользователя, установления и завершения вызова и соответствующей сигнализации. При этом он был спроектирован с поддержкой таких функциональных элементов сети, как прокси-серверы (Proxy Servers) и Пользовательские Агенты (User Agents). Эти элементы обеспечивают базовый набор услуг: набор номера, вызов телефонного аппарата, звуковое информирование абонента о статусе вызова.

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

SIP используется вместе с несколькими другими протоколами и участвует только в сигнальной части сессии связи. SIP выполняет роль носителя для SDP, который описывает параметры передачи медиаданных в рамках сессии, например используемые порты IP и кодеки. В типичном применении сессии SIP — это просто потоки пакетов RTP. RTP является непосредственным носителем голосовых и видео данных.

Первая предложенная версия стандарта (SIP 2.0) была определена в RFC 2543. Протокол был дополнительно уточнён в RFC 3261, хотя многие реализации по-прежнему основаны на промежуточных версиях стандарта. Обратите внимание, что номер версии остался 2.0.

Адресация

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

  • логин абонента@,
  • доменное имя устройства@,
  • № телефона@.

Общий стандарт URI определён рекомендацией RFC 3986.

Адрес состоит из двух частей. Первая часть — имя пользователя, зарегистрированного в домене или на рабочей станции. Во второй части адреса указывается имя домена сети, хоста или IP-адрес. Если вторая часть идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента.

Имена пользователей представляют собой обычные алфавитно-цифровые идентификаторы. В IP-телефонии, как правило, используют чисто цифровые идентификаторы («номера») для удобства расширения/замены классических телефонных сетей. Номера местной связи, как правило, 2-3-4-значные.

Номер телефона, передаваемый шлюзу — любой доступный через него, и может быть как номером местной связи, так и номером мобильного или обычного городского телефона. Адрес шлюза (IP-адрес или доменное имя) задаётся в настройках телефона или программы-клиента, а пользователю для совершения звонка достаточно только набора номера.

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

Протокол SIP имеет клиент-серверную архитектуру.

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

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

Терминал

Когда клиент и сервер реализованы в оконечном оборудовании и взаимодействуют непосредственно с пользователем, они называются пользовательским агентским клиентом — User Agent Client (UAC) — и пользовательским агентским сервером — User Agent Server (UAS). Если в устройстве присутствуют и UAC, и UAS, то оно называется пользовательским агентом — User Agent (UA), а по своей сути представляет собой терминальное оборудование SIP.

Сервер UAS и клиент UAC имеют возможность непосредственно взаимодействовать с пользователем. Другие клиенты и серверы SIP этого делать не могут.

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

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

Предусмотрено два типа прокси-серверов

  • с сохранением состояний (stateful). Такой сервер хранит в своей памяти все полученные запросы и связанные с ним новые сформированные запросы до окончания транзакции.
  • без сохранения состояний(stateless). Такой сервер просто обрабатывает получаемые запросы. Но на его базе нельзя реализовать сложные, интеллектуальные услуги.

Прокси может указать пользователю в ответ на первый запрос, на необходимость информации для аутентификации — как минимум логина (ответ 407 Proxy authentification required).

Сервер B2BUA

B2BUA — (англ. back-to-back user agent, буквально: пользовательский агент спина-к-спине) — вариант серверного логического элемента в приложениях, работающих с протоколом SIP. По идеологии работы, B2BUA похож на прокси-сервер SIP, однако есть принципиальные различия. Сервер B2BUA, работает одновременно с несколькими (как правило, двумя) конечными устройствами — терминалами, разделяя вызов или сеанс на разные плечи-участки. С каждым участком B2BUA работает индивидуально, как UAS по отношению к инициатору и как UAC по отношению к терминалу, принимающему вызов. При этом сигнальные сообщения передаются в рамках сеанса в обе стороны синхронно, хотя решение о необходимости передачи сообщения и его формате принимается B2BUA для каждого участка в индивидуальном порядке. Каждый из участников соединения (сеанса связи), на уровне сигнализации взаимодействует с B2BUA, как с оконечным устройством, хотя в действительности, сервер является посредником. Это отражается в адресных полях (таких как From, To и Contact) сообщений, отправляемых сервером B2BUA. Таким образом, ключевое отличие B2BUA — полностью независимая сигнализация всех участков вызова. Это означает, в частности, что для взаимодействия с каждым отдельным пользователем в рамках сеанса связи используются уникальные идентификаторы, а содержимое одних и тех же сообщений для разных участков будет различным. Пользовательские агенты оконечных терминалов могут взаимодействовать с B2BUA и при участии прокси-серверов.

Сервер B2BUA может предоставлять следующие функции:

  • Управление звонками (биллинг, перевод звонка, автоматическое разъединение и т. д.)
  • Сопряжение разных сетей (в частности, для адаптации разных диалектов протокола, зависимых от производителей)
  • Сокрытие структуры сети (частные адреса, сетевая топология и т. п.)

Довольно часто B2BUA является частью медиа-шлюза для того, чтобы полностью контролировать медиа-потоки в рамках сессии. Сигнальный шлюз, являющийся частью пограничного контроллера соединений/сеансов — наглядный пример применения B2BUA.

Сервер переадресации

Сервер переадресации (англ. Redirect Server) используется для перенаправления вызова по адресу текущего местоположения пользователя. Сервер переадресации не терминирует вызовы и не инициирует собственные запросы, а только сообщает адрес необходимого терминала или прокси-сервера при помощи ответов класса 3XX (301 Moved Permanently или 302 Moved Temporarily). Для этих целей сервер переадресации может взаимодействовать с SIP-регистратором или сервером определения местоположения.

Однако, для осуществления соединения пользователь может не использовать сервер переадресации, если он сам знает текущий адрес требуемого пользователя.

Сервер регистрации (регистратор)

Процесс регистрации SIP User Agent на SIP регистраторе с аутентификацией по логину

Протокол SIP подразумевает мобильность пользователя, то есть пользователь может перемещаться в пределах сети, получая новый адрес. Поэтому в SIP существует механизм регистрации — уведомление о новом адресе со стороны пользовательского агента. Сервер регистрации или регистратор (англ. registrar) служит для фиксации и хранения текущего адреса пользователя и представляет собой регулярно обновляемую базу данных адресной информации. В общем случае, пользователь сообщает серверу регистрации свою адресную информацию, такую как IP-адрес или доменное имя и абонентский телефонный номер — при помощи запроса REGISTER. Сервер может подтвердить успешную регистрацию (200 OK) или отклонить, в случае если есть проверка данных и учетная запись пользователя не найдена (404 Not found) или регистрация для пользователя запрещена в данный момент (403 Forbidden). Регистратор может указать на необходимость логина пользователя для проверки (401 Unauthorized), а также предложить цифровую аутентификацию на основе зашифрованного пароля. В качестве источника информации для аутентификации пользователя, может выступать даже устройство или сервер, не работающее по протоколу SIP (например СУБД, MS Exchange, RADIUS-сервер и т. п.). Регистрация пользователя на сервере имеет определённый «срок жизни» и должна подтверждаться новым запросом REGISTER со стороны клиента, в противном случае адресная информация может быть удалена. Клиент может также прислать запрос с нулевым временем жизни регистрации, что рассматривается, как запрос на принудительное удаление адресной информации из сервера.

В различных реализациях SIP-сетей может встречаться сервера регистрации и других серверов в едином приложении или устройстве, работающем через один сокет на одном порту (обычно 5060) — точку получения запросов. Так зачастую регистраторы совмещаются с сервером переадресации, B2BUA или SIP-прокси. Например, многие софтсвичи (Asterisk, Yate, РТУ и др.) содержат функционал SIP-регистратора с проверкой регистрационных данных каждого пользователя. Информация о возможностях пользователя зарегистрироваться и устанавливать соединения, определяются в данном случае его единой учетной записью. В свою очередь абонентское оборудование IP-телефонии — телефоны, абонентские шлюзы, в большинстве случаев требуют обязательной предварительной регистрации на регистраторе для дальнейшей работы в телефонной сети.

В результате система IP-телефонии может выглядеть аналогично системе сотовой связи — все абонентское оборудование при включении регистрируется на коммутаторе (софтсвиче) и после этого может совершать и принимать вызовы посредством этого коммутатора, который либо переадресует запрос другому конечному пользователю, либо выступает посредником.

Сервер определения местоположения пользователей

Пользователь может перемещаться в пределах разных сетей, кроме того, подлинный адрес пользователя может быть и не известным, даже если его номер известен. Это актуально, в частности для услуги переносимости номера (LNP/MNP). Для решения таких задач существует механизм определения местоположения пользователя при помощи сторонних средств, не имеющих прямого отношения к элементам SIP-сети.

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

Пользователь, которому нужна адресная информация другого пользователя для установления соединения не связывается с сервером определения местоположения напрямую. Эту функцию выполняют другие SIP-серверы при помощи протоколов LDAP, RWHOIS, ENUM, RADIUS или других протоколов.

Сообщения протокола SIP

Сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP идентичны используемым в протоколе HTTP. Структура сообщений протокола SIP:

Стартовая строка

Заголовки

Пустая строка

Тело сообщения

  • Стартовая строка — начальная строка любого SIP-сообщения. Если сообщение является запросом, в ней указывается тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в ней указывается номер версии протокола, тип ответа и его короткая расшифровка.
  • Заголовки сообщений содержат информацию, необходимую для обработки сообщения (информация об отправителе, адресате, пути следования и пр.)
  • Тело сообщения содержит описание сеансов связи. Не все запросы содержат тело сообщения (например запрос BYE). Все ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.

Пример запроса INVITE:

INVITE sip:nikolia@example.ru SIP/2.0 Record-Route: <sip:nikolia@10.0.0.10;lr> Via: SIP/2.0/UDP 10.0.0.10;branch=z9hG4bK3af7.0a6e92f4.0 Via: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK12ee92cb;rport=5060 From: «78128210000» <sip:78128210000@neutral.ru>;tag=as149b2d97 To: <sip:nikolia@example.ru> Contact: <sip:78128210000@neutral.ru> Call-ID: 3cbf958e6f43d91905c3fa964a373dcb@example.ru CSeq: 103 INVITE Max-Forwards: 16 Date: Wed, 10 Jan 2001 13:16:23 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: 394 v=0 o=root 3303 3304 IN IP4 10.0.0.10 s=session c=IN IP4 10.0.0.10 t=0 0 m=audio 40358 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off — — — — a=sendrecv

Запросы

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

  1. INVITE — Приглашает пользователя к сеансу связи. Обычно содержит SDP-описание сеанса.
  2. ACK — Подтверждает приём ответа на запрос INVITE.
  3. BYE — Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.
  4. CANCEL — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.
  5. REGISTER — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.
  6. OPTIONS — Запрашивает информацию о функциональных возможностях сервера.

Но в процессе развития, в протокол было добавлено ещё несколько типов запросов, которые дополнили его функциональность:

  1. PRACK — временное подтверждение (RFC 3262)
  2. SUBSCRIBE — подписка на получение уведомлений о событии (RFC 3265)
  3. NOTIFY — уведомление подписчика о событии (RFC 3265)
  4. PUBLISH — публикация события на сервере (RFC 3903)
  5. INFO — передача информации, которая не изменяет состояние сессии (RFC 2976)
  6. REFER — запрос получателя о передаче запроса SIP (RFC 3515)
  7. MESSAGE — передача мгновенных сообщений средствами SIP (RFC 3428)
  8. UPDATE — модификация состояния сессии без изменения состояния диалога (RFC 3311)

Ответы на запросы

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

  1. 1ХХ — Информационные ответы; показывают, что запрос находится в стадии обработки. Наиболее распространённые ответы данного типа — 100 Trying, 180 Ringing, 183 Session Progress.
  2. 2ХХ — Финальные ответы, означающие, что запрос был успешно обработан. В настоящее время в данном типе определены только два ответа — 200 OK и 202 Accepted(прим. 202 кода нет в RFC 3261).
  3. 3ХХ — Финальные ответы, информирующие оборудование вызывающего пользователя о новом местоположении вызываемого пользователя, например, ответ 302 Moved Temporary.
  4. 4ХХ — Финальные ответы, информирующие об отклонении или ошибке при обработке или выполнении запроса, например, 403 Forbidden или классический для протокола HTTP ответ 404 Not Found. Другие примеры: 406 Not Acceptable — неприемлемый (по содержанию) запрос, 486 Busy Here — абонент занят или 487 Request Terminated — вызывающий пользователь разорвал соединение не дожидаясь ответа (отмена запроса).
  5. 5ХХ — Финальные ответы, информирующие о том, что запрос не может быть обработан из-за отказа сервера, 500 Server Internal Error.
  6. 6ХХ — Финальные ответы, информирующие о том, что соединение с вызываемым пользователем установить невозможно, например, ответ 603 Decline означает, что вызываемый пользователь отклонил входящий вызов.

Алгоритмы установления соединения

Протокол SIP является управляющим протоколом для установления, модификации и разрыва соединения, ориентированного на передачу потоковых данных. Параметры передачи медиа-потоков описываются в протоколе SIP посредством SDP (протокол описания сессии). Потоковые медиа-данные могут передаваться различными средствами, среди которых наиболее популярны транспортные протоколы RTP и RTCP.

Протокол SIP определяет 3 основных сценария установления соединения: с участием прокси-сервера, с участием сервера переадресации и непосредственно между пользователями. Сценарии отличаются по тому, как осуществляется поиск и приглашение вызываемого пользователя. Основные алгоритмы установления соединения описаны в RFC 3665.

Пример сценария установления соединения, с участием SIP сервера переадресации и SIP Proxy

Пример сценария установления соединения с участием сервера B2BUA

В примере ниже медиа-трафик проксируется через сервер. Сигнальные сообщения для участков Алиса — B2BUA и B2BUA — Борис являются полностью независимыми и выполняются в рамках разных сессий (изменятся как минимум адреса назначения и отправка, а также Call ID сессий). Терминал Алисы не знает реального местоположения терминала Бориса и наоборот. Так может выглядеть взаимодействие через некоторые софтсвичи или пограничные контроллеры сессий(SBC).

Сравнение с H.323

SIP пригоден для чтения человеком и структурирован в отношении запросов и откликов. Сторонники SIP также заявляют о нём как о более простом, по сравнению с H.323. Однако некоторые склонны считать, что, в то время как первоначально целью SIP была простота, в своём сегодняшнем виде он стал так же сложен, как и H.323. Другие считают, что SIP — протокол без состояний, который тем самым даёт возможность легко реализовать восстановление при отказе и другие возможности, которые затруднены в протоколах с состояниями, таких как H.323. SIP и H.323 не ограничены голосовой связью, они могут обслуживать любой сеанс связи, от голосового до видеосеанса или приложений будущего.

Параметр сравнения SIP H.323
Дополнительные услуги
Набор услуг, поддерживаемых обоими протоколами примерно одинаков
Персональная мобильность пользователей Имеется хороший набор средств поддержки мобильности Персональная мобильность поддерживается, но менее гибко
Расширяемость протокола Удобная расширяемость, простая совместимость с предыдущими версиями Расширяемость поддерживается, но существует ряд сложностей
Масштабируемость сети
Оба протокола обеспечивают хорошую масштабируемость сети
Время установления соединения Достаточно одной транзакции Требуется несколько транзакций.
Сложность протокола Простой, мало запросов, текстовый формат сообщений Сложный, много запросов и протоколов, двоичное представление сообщений
Совместимость оборудования Практически никакой. Каждый производитель SIP устройств соблюдает только тот набор рекомендаций (RFC) который ему нравится, ибо набор этих рекомендаций очень велик. Совместим фактически только базовый вызов Практически полная. Стандарты устоявшиеся и имеют чёткий набор спецификаций

1.Протокол SIP

Один из распространенных протоколов IP-телефонии называется SIP (Session Initiation Protocol); он описан в рекомендациях RFC 2543. SIP регламентирует установление и завершение мультимедийных сессий — сеансов связи, в ходе которых пользователи могут говорить друг с другом, обмениваться видеоматериалами и текстом, совместно работать над приложениями и т.д. SIP очень похож на HTTP, потому что разрабатывался на основе спецификаций HTTP и SMTP.

Рассмотрим архитектуру протокола:

Клиент SIP (SIP user agent) — может быть представлен как устройством (IP-телефон, шлюз или другой пользовательский терминал), так и программным приложением. Обычно SIP-клиент содержит и клиентскую, и серверную часть (User Agent Client, или UAC, и User Agent Server, или UAS). Основные функции данного компонента — инициирование и завершение вызовов.
Прокси-сервер SIP — управляет маршрутизацией вызовов и работой приложения. Прокси-сервер не может инициировать или терминировать вызовы.
Redirect-сервер SIP — перенаправляет звонки согласно заданным условиям.
Сервер регистрации SIP (registrar/location) — осуществляет регистрацию пользователей и ведет базу соответствия имен пользователей их адресам, телефонным номерам и т. д.

С SIP связаны еще три протокола:

RTP (Real Time Transport Protocol) — протокол передачи данных в реальном времени
определяет стандартный формат пакета для доставки звуковых и видеоданных по сети Интернет.
RTCP (Real Time Control Protocol) — протокол, управляющий транспортным протоколом реального времени.
SDP — протокол описания сеанса, описывает исходные параметры потоковых данных.

Отличие между протоколами RTP и RTCP: RTP — его функция доставка фактических данных, а RTCP передает управляющую информацию о качестве работы RTP.

2. Алгоритмы установления SIP соединения

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

На схеме представлен сценарий соединения с использованием прокси-сервера:

Абонент посылает на прокси-сервер запрос на соединение, отправляя сообщение Invite. Прокси-сервер возвращает сообщение Trying и передает сообщение Invite вызываемому абоненту. Вызываемая сторона отвечает сообщением Ringing, которое прокси-сервер пересылает вызывающей стороне. После того как вызываемый абонент снимет трубку, вызывающей стороне отправляется сообщение ОК, которое транслируется прокси-сервером. Вызываемому абоненту возвращается подтверждающее сообщение Ack.C этого момента соединение считается установленным и начинается обмен медиа-трафиком по протоколам RTP/RTCP. Сторона, желающая завершить соединение, посылает сообщение Bye, и после получения подтверждающего ОК соединение разрывается.

5. Проблемы SIP

Протокол SIP рассчитан на то, что между сервером и телефоном не будет NAT, т.е. механизма трансляции портов.
Это вызвано тем, что в SDP-заголовках устройство само назначает порты, на которые будет вестись прием медиапотока,
однако при прохождении NAT сам порт будет подменен, а в SDP останется неверная информация.
Такая ситуация приводит к проблеме односторонней слышимости.

  1. Firewalls. В связи с настройками брандмауэра часто бывает невозможно получение входящего RTP траффика между двумя конечными точками. Но так как мы можем изменять поведение брандмауера, то и существуют решения данной проблемы.
    Часто фаерволы позволяют входящие UDP пакеты (RTP через UDP в IP стеке) с IP-адреса, если конечная точка за брандмауэром послала UDP пакет на этот адрес в первую очередь. В этом случаях нет никаких проблем, одни из первых RTP пакетов могут быть потеряны, но как только обе стороны начнут отправку RTP, они также будут иметь возможность получать данный трафик.
    В других случаях брандмауэр может блокировать трафик на самом деле, в этом случае для маршрутизации трафика между двумя точками необходимо установка так называемого RTP прокси.
  2. NAT. SIP команды содержат IP-адреса в нескольких местах. Так как эти адреса используются для связи RTP, соединение не будет установлено, если конечная точка находится за NAT (Native Address Translation). Это также является серьезной проблемой в Интернете сегодня, и жестким ограничением для SIP. Различные методы были предложены для преодоления проблемы, созданной NAT. Они известны как STUN, ICE и TURN. Основная идея — использовать публичный адрес IP в SIP-сообщениях.NAT может вызвать проблемы в нескольких местах.
    Если одна из АТС находится за NAT, другая АТС не сможет связаться с ней, без проброса портов.
    Если телефон находится за NAT, голосовые пакеты могут быть направлены на немаршрутизируемый адрес в сети, что приведет к потере звука.
    В простейшей ситуации SIP клиент находясь за NAT, обращается к внешнему интерфейсу Asterisk. SIP клиент при регистрации на сервере создает запись в таблице трансляций, которая сохраняется, пока проходит хотя бы один пакет в минуту.
    SIP клиенты и Asterisk за NAT
    Все усложняется если и Asterisk, и клиенты, находятся за NAT. Клиенты с внешней стороны не смогут получать SIP сообщения и принимать звонки. Или в SIP сообщении будет указан локальный IP адрес телефона, что приведет к потере звука.

6. Кодеки в IP телефонии

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

Кодек (кодер/декодер) трансформирует аналоговый голосовой сигнал в цифровой поток битов, а идентичный кодек на другом конце этого соединения делает обратное – трансформирует цифровой поток битов обратно в аналоговый голосовой сигнал.
В мире VOIP, кодек применяется для кодирования передаваемого голоса по IP сетям. Их еще именуют вокодерами (voice coder – голосовой кодер).
Любой кодек кодирует и сжимает голос с определенной интенсивностью. Потому, при его выборе нужно понимать, что чем более кодек сжимает голос, тем меньшая полоса Интернет необходима, однако, в то же время, качество голоса при раскодировании ухудшается. И наоборот, чем меньше сжатие, тем качественнее звучание и тем больше требуется ресурсов Интернет для его передачи.
Важной разработкой в этой сфере является технология подавления молчания. То есть, при молчании одного из собеседников его пакеты не передаются другому, этим достигается экономия полосы пропускания.

Рассмотрим основные кодеки, используемые в устройствах IP-телефонии.
Кодек G.711.
Рекомендация G.711 описывает кодек, использующий преобразование аналогового сигнала с точностью 8 бит, тактовой частотой 8 кГц и простейшей компрессией амплитуды сигнала. Скорость потока данных на выходе преобразователя составляет 64 Кбит/c (8 бит x 8 кГц). Для снижения шума квантования и улучшения преобразования сигналов с небольшой амплитудой при кодировании используется нелинейное квантование по уровню согласно специальному псевдо-логарифмическому закону. Типичная оценка MOS составляет 4.2. Обычно любое устройство VoIP поддерживает этот тип кодирования.
Кодек G.723.1
Своим появлением данные кодеки обязаны системам мобильной связи. Данный алгоритм преобразования позволяет снизить скорость кодированной информации до 5,3 — 6,3 Кбит/с без заметного ухудшения качества речи. Кодек имеет две скорости и два варианта кодирования: 6,3 кбит/c с алгоритмом MP-MLQ (Multi-Pulse — Multi Level Quantization — множественная импульсная, многоуровневая квантизация) и 5,3 кбит/c с алгоритмом CELP (Code-Excited Linear Prediction — кодирование с линейным предсказанием). Первый вариант предназначен для сетей с пакетной передачей голоса и обеспечивает лучшее качество кодирования по сравнению с вариантом CELP, но менее адаптирован к использованию в сетях со смешанным типом трафика (голос/данные). Оценка MOS составляет 3.9 для MP-MLQ, и 3.7 для CELP.
Кодек имеет функцию VAD (Voice Activity Detector — детектор речевой активности), и обеспечивает генерацию комфортного шума на удаленном конце в период молчания.
Кодек G.726
Рекомендация G.726 основана на алгоритме кодирования ADPCM — адаптивная дифференциальная ИКМ. Этот алгоритм даёт практически такое же качество воспроизведения речи, как и ИКМ, однако для передачи информации при его использовании требуется полоса всего 16-32 кбит/c. Кодек предназначен для использования в системах видеоконференций, в приложениях IP-телефонии этот кодек практически не используется. Оценка по MOS составляет 4.3.
Кодек G.728
Кодек G.728 использует оригинальную технологию с малой задержкой LD-CELP (low delay code excited linear prediction) и гарантирует оценки MOS, аналогичные G.726 при скорости передачи 16 Кбит/c. Предназначен для использования, в основном, в системах видеоконференций. В устройствах IP-телефонии данный кодек применяется достаточно редко.
Кодек G.729
Используется технология CS-ACELP (Conjugate Structure v Algebraic Code Excited Linear Prediction). Содержит VAD и генератор комфортного шума. Скорость кодированного речевого сигнала составляет 8 кбит/c. В устройствах VoIP, VoFR данный кодек занимает лидирующее положение, обеспечивая наилучшее качество кодирования речевой информации при достаточно высокой компрессии
Кодеки, стандартизованные ETSI для применения в системах мобильной связи (GSM):
Кодек GSM Full Rate (GSM 06.10), утвержден в 1987 году. Это первый, и, скорее всего, наиболее известный из узкополосных кодеков, применяемых в мобильных телефонах по всему миру. Обеспечивает хорошее качество и устойчивую работу в условиях фонового шума (оценка MOS 3.7 в условиях без шума). Скорость образованного цифрового потока составляет 13 Кбит/c. Кодек очень важен для некоммерческих проектов в области IP-телефонии, особенно v для проектов, связанных с открытым распостранением исходных текстов ПО (open source), благодаря возможности бесплатного лицензирования.

Оценка качества голоса

Качество голоса в IP-телефонии оценивается по пятибальной шкале единицами субъективной оценки MOS (Mean Opinion Score). Суть MOS заключается в следующем: специально собранной группе людей предоставляют возможность воспользоваться системой связи и просят поставить оценку от 1 (ужасно) до 5 (отлично). Средние данные такого исследования и называются MOS.

Качество Оценка MOS
Высокое 4.0 — 5.0
Стандартное телефонное 3.5 — 4.0
Приемлимое 3.0 — 3.5
Синтезированный звук 2.5 — 3.0

Для передачи речи с хорошим качеством целесообразно ориентироваться на MOS не ниже 3,5 баллов.

Кодеки со сжатием и без.

Стандартные голосовые кодеки G.711-ulaw и G.711-alaw не используют сжатия голосового сигнала. При этом ширина канала, которое использует одна голосовая линия составляет 80 кБит/сек. Таким образом, канал в Интернет со скоростью 1 МБит позволит одновременно пропускать до 12-ти одновременных телефонных разговоров.
Кодеки со сжатием, за счет эффективных алгоритмов, позволяют снизить требуемую ширину канала в несколько раз. Например, при использовании кодека G.729 ширина канала для одной линии будет составлять от 25-ти до 35-ти кБит, что в 2-3 раза ниже загрузки линии G.711. Канал в 1 МБит можно будет использовать для пропускания до 25-30-ти одновременных линий.
Кроме того, за счет более низкой требуемой пропускной способности, снижается объем потребления трафика. Это актуально для компаний, где используется канал Интернета с лимитом по объему закачиваемых данных.

7. Протокол IAX2

IAX2 — (Inter-Asterisk eXchange protocol — вторая версия) протокол разработанный компанией Digium, специально для Asterisk, как альтернативный протокол.

IAX2 разработан так, что бы использовать один порт для передачи голоса и сигнализации. Это связано с тем, что при использовании SIP и H.323 двух портов для голоса и сигнализации при длительнои молчании одного абонента брандмакер закрывал порт сигнализации (так как по нему не шли пакеты) и, когда молчавший начинал говорить, то сигнализация не проходила через закрытый порт, а соответственно и его не было слышно собеседнику.

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

Вместо разбора текстовых команд IAX использует двоичные данные, поскольку это — естественный способ связи вычислительных машин друг с другом. Ответы по протоколу IAX отсылаются обратно, откуда бы ни пришли пакеты. IAX передает аудиопакеты лишь с 4 байтами заголовков в каждом, поэтому команды используют очень малую полосу пропускания. Для множества звонков IAX уменьшает объем служебной информации каждого канала, комбинируя данные нескольких каналов в один пакет. Протокол снижает не только число заголовков, но и число пакетов, что особенно важно для беспроводных сетей.

Часто желательно объединить два физических сервера Asterisk по протоколу IAX, чтобы иметь возможность обмениваться вызовами между двумя физическими местоположениями (расстояние между этими точками можем быть ничтожно мало, а может измеряться и километрами). Одно из преимуществ использования протокола IAX для этого -его способность, называемая объединением каналов, в которой используется метод отправки голосовых данных множества звонков под одним заголовком. Для одного или двух одновременных вызовов эффект от этой возможности невелик, но если между двумя точками выполняются десятки или сотни звонков, выигрыш в пропускной способности за счет использования объединения каналов может быть огромным.

Рубрики: IT

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

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