SIP протокол — описание, возможности

IP-телефонией называют голосовую связь, осуществляется которая по сетям, предназначенным для передачи данных, чаще – по IP-сетям (термин IP расшифровывается как «Internet Protocol»). В настоящее время связь с использованием IP-телефонии стала вытеснять традиционные сети телефонной связи благодаря своей низкой стоимости звонков, легкости развертывания, высокого качества соединения и связи, их сравнительной безопасности, простоты конфигурирования. В этой статье изложение материала будет вестись начиная с канального и физического уровней до уровней данных с придерживанием принципов модели OSI (расшифровывается как Open System Interconnection basic reference model).

4. Транспортный уровень (англ. Transport Layer)

Транспортный уровень обеспечивает:

• сквозное соединение;
• сегментацию данных приложений из верхнего уровня;
• надежность данных.

Транспортный уровень в качестве основных использует следующие протоколы:

• UDP (англ. User Datagram Protocol);
• TCP (англ. Transmission Control Protocol);
• RTP (англ. Real-time Transport Protocol).

В работе IP-телефонии непосредственно используются протоколы RTP и UDP, которые в основном отличаются от TCP тем, что не обеспечивают надежности при доставке данных. Для IP-телефонии такая особенность является более приемлемой, чем использование TCP с его контролем за доставкой, потому как телефонная связь очень зависит от задержек при передаче данных, но потеря пакетов для нее не критична.

Протокол UDP

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

Протокол RTP

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

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

Джиттер

Явление, характерное в IP-телефонии – случайная задержка при распространении пакета, называемая джиттером. Обусловить джиттер можно тремя факторами:

• тепловым шумом;
• высокой задержкой при распространении сигнала;
• ограниченной полосой пропускания или же некорректной работой эксплуатируемых сетевых устройств.

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

Джиттер буфер

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

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

Размер джиттер буфера вызывает противоречия между пользователями и провайдерами IP телефонии. При малом размере буфера на стороне пользователя не все отосланные провайдером пакеты могут достигнуть пользовательского кодека, в то время как провайдер будет констатировать доставку всех без исключения пакетов. С практической точки зрения более 1% потерянных данных вызовет неприятные ощущения при разговоре, а при 2% он будет уже затруднен. Значение потерь равное 4% может сделать разговор практически невозможным.

Размер джиттер буфера делают большим, чем значение флуктуации транзитного времени сети. Если для десятка пакетов транзитное время колеблется между 5 и 10 мс, то буфер должен иметь размер до 8 мс, для того, чтобы не утерять ни одного пакета. Если же буфер имеет размер 12 мс, тогда он сможет осуществлять еще и перезапрос потерянных пакетов.

Программно-аппаратные средства для развертывания и использования телефонной сети

Avaya IP Office

Аппаратно-программное решение IP Office – неплохой выбор для телефонной сети среднего размера. Ограничение на количество абонентов здесь связано не только с мощностью сервера, но и приобретенными лицензиями. Лицензии накладываются на практически каждую деталь комплекса, такие как используемые приложения и платы расширения. Настройка оснащения осуществляется через различные программы, самая популярная из которых, а, к тому же, и простая в обращении – IP OfficeManager от той же компании Avaya. Управлять настройками IP Office можно и через консоль при использовании средства Avaya Terminal Emulator.

Компания Avaya кроме IP Office выпускает и другие продукты, а слившись в 2009 году с другим известным производителем Nortel, она стала признанным лидером среди компаний, реализующих оборудование для IP-телефонии.

Хотите знать больше про телефонную связь? Обращайтесь в компанию ИТЕРАНЕТ — мы уже свыше 15 лет реализуем сложные коммуникационные проекты, занимаемся инфраструктурой объектов. Список наших услуг насчитывает перечень высокотехнологичных решений из более чем 100 пунктов.

Прочитайте по теме следующие материалы:

• Аккаунты на Tor Project могут быть…
• Что такое Video Trunk и для чего он…
• Искусственный интеллект от Google тайно…

Протокол запуска сессий SIP

Семенов Ю.А. (ГНЦ ИТЭФ)

Протокол SIP (Session Initiation Protocol) описан в документе RFC 3261 и служит для запуска, модификации и завершения сессий реального времени между партнерами IP-сети. SIP может поддерживать как моно так и мультимедийные приложения, включая видеоконференции.

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

Собственно транспортировка мультимедиа данных обычно осуществляется с помощью протокола RTP (Real-Time Transport Protocol).

Базовым стимулом создания протокола SIP являлась необходимость реализации работы с VoIP (Voice over IP). Протокол поддерживает пять аспектов, сопряженных с установлением и завершением мультимедийных коммуникаций:

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

SIP базируется на модели транзакций, сходных с запросами/откликами в протоколе HTTP. Каждая транзакция состоит из запроса клиента, который включает в себя определенный метод, или функцию, для сервера и, по крайней мере, один отклик. SIP использует большинство полей заголовков, правил кодирования и коды статуса протокола HTTP. Это позволяет работать с данными легко читаемого и отображаемого формата. SIP использует протокол SDP (Session Description Protocol), который с помощью набора типов данных, используемых в MIME (Multipurpose Internet Mail Extensions), определяет содержимое сессии.

Компоненты и протоколы SIP

Система, использующая SIP, может рассматриваться состоящей из клиентов, серверов и индивидуальных сетевых элементов. RFC 3261 определяет клиента и сервер следующим образом:

• Клиент:Клиент является субъектом сети, который посылает SIP запросы и получает SIP отклики. Клиенты, если это требуется, могут непосредственно взаимодействовать с человеком. Агент пользователя клиента и прокси являются клиентами

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

Индивидуальные элементы стандартной конфигурации включают в себя:

• Агент пользователя: Агент пользователя резидентно присутствует в каждой конечной станции SIP. Он выполняет две роли.

Агент пользователя клиента UAC (User Agent Client): Посылает запросы SIP. Агент пользователя сервера UAS (User Agent Server): получает SIP-запросы, генерирует отклики, принимает, отклоняет или перенаправляет запросы

• Сервер переадресации: Сервер переадресации используется во время инициализации сессии, чтобы определить адрес запрашиваемого устройства. Сервер переадресации отсылает полученную информацию устройству, инициировавшему запрос, направляя UAC, который может использоваться для контакта с альтернативным URI (Universal Resource Identifier). URI является универсальным идентификатором, используемым для именования любого ресурса в Интернет. URL, используемое для Web адресов имеет тип URI. Подробнее это рассмотрено в RFC 3986 [1].

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

• Регистратор: Регистратор является сервером, который принимает запросы REGISTER и помещает информацию, которую он получает (SIP-адрес и ассоциированный IP-адрес регистрирующего устройства) из этих запросов, в службу локализации для домена, который им обслуживается.

• Служба локализации: Служба локализации используется серверами переадресации SIP или прокси, чтобы получить информацию о возможном положении источника запроса. Для этой цели служба локализации поддерживает базу данных SIP-адресов/ IP-адресов.

В RFC 3261 в качестве логических устройств определены различные серверы. Они могут быть использованы в качестве отдельных серверов в Интернет или они могут объединяться в рамках одного приложения, которое работает резидентно на определенном физическом сервере.

Рис. 1. Протоколы и компоненты SIP

На рис. 1 показано, как некоторые SIP компоненты связаны друг с другом и с протоколами, которые они используют. Агент пользователя А использует SIP для установления сессии с другим агентом пользователя B, который выступает в роли сервера. Диалог запуска сессии использует SIP и включает один или более прокси серверов, чтобы переадресовать запросы и отклики между двумя агентами пользователя. Агенты пользователя используют также протокол SDP (Session Description Protocol), который служит для описания медийной сессии.

Прокси серверы могут, если это требуется, работать в качестве серверов переадресации. Система DNS (Domain Name System) является важной частью, реализующей протокол SIP. Обычно, UAC осуществляет запрос, используя доменное имя UAS, а не IP-адрес. Прокси сервер вынужден консультироваться у DNS-сервера, чтобы найти прокси сервер для зоны места назначения.

Из эксплуатационных соображений SIP часто работает поверх UDP (User Datagram Protocol), и обеспечивает свои собственные механизмы обеспечения надежности доставки, но может использовать и TCP. Если необходим безопасный или криптографический транспортный механизм, сообщения SIP могут передаваться посредством протокола TLS (Transport Layer Security).

С протоколом SIP ассоциирован SDP, описанный в RFC 4566 [4]. SIP используется для приглашения одного или более партнеров для участия в сессии, в то время как кодированные SDP тела сообщений содержат информацию о типе медиа данных (например, голос, видео). После того как эта информация отправлена и подтверждена, все участники знают IP-адреса, доступную полосу и тип данных. Затем начинается передача информации, с использованием соответствующего транспортного протокола. Обычно используется RTP. Во время сессии участники, используя сообщения SIP, могут изменить параметры сессии, такие как новые медиа типы или новые участники сессии.

Универсальные локаторы ресурсов SIP

Ресурсы в конфигурации SIP идентифицируются URI. Примерами ресурсов могут служить:

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

URI SIP имеют формат, базирующийся на формате адресов e-mail, в частности user@domain. Существует две общие схемы. Обычные URI имеют форму:

sip:ааа@itep.com

URI могут также включать пароль, номер порта, и сопряженные параметры. Если требуется безопасная передача, sip: заменяется на sips:. В последнем случае сообщения SIP передаются с привлечением протокола TLS…

Полная версия этой статьи находится на [1]см, также [2]

• Курс изучения SIP от авторов очень популярного прокси SIP с открытым исходным кодом
• Страница форума SIP
• Обзор Протокола SIP
• Asterisk и SIP wiki

Спецификации

• RFC 2543 — спецификация первой версии протокола
• RFC 3261 — спецификация второй версии протокола
• другие сопутствующие RFC — в разделе Справочная информация.

SIP-протокол – что это такое

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

Использование SIP-протокола в IP-телефонии обеспечивает:

• Полную мобильность пользователей – они могут находиться в любой точке мира.
• Возможность масштабирования сети – используя соответствующие технические мощности, можно значительно увеличить количество абонентов без дополнительных сложностей и расходов.
• Расширяемость – с помощью SIP-протокола организуются сеансы передачи мультимедийной информации. Также он позволяет передавать файлы, проводить видеоконференции и видеосеансы между двумя пользователями, обеспечивает взаимодействие с бизнес-софтом.

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

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

История разработки

Данный протокол появился на свет в середине 90-х годов, причём в 2000 году он был принят в качестве основного сигнального протокола в мобильной связи. Ещё через два года появляется его вторая версия (SIP 2.0). С той поры он активно используется в IP-телефонии. Тем самым он почти полностью похоронил устаревший протокол H.323, используемый для организации телефонии и сеансов видеосвязи. Долгое время тот был безусловным лидером, но впоследствии его заменил SIP. Что касается H.323, то он используется и сегодня, но вытесняется всё больше и больше.

Аббревиатура SIP расшифровывается как Session Initiation Protocol. Он обеспечивает инициализацию и установление сеансов связи, отличаясь от H.323 своей гибкостью. Но если в H.323 была заложена экономия трафика, то для SIP это не характерно – существующие сегодня каналы связи характеризуются высокой производительностью, что позволяет не экономить трафик. SIP получился более перспективным, он активно используется в IP-телефонии, на его основе работают офисные облачные АТС.

Описание и операции

Основу протокола составляют шесть типов запросов. Первый – INVITE, он является инициирующим, вызывая другой терминал. В описании запроса содержится список сервисов, необходимых для данного сеанса связи. Установка связи подтверждается запросом ACK, в то время как для завершения текущего сеанса используется запрос BYE. Неактуальные в данный момент запросы отменяются запросом Cancel.

Что касается Register, то он определяет местоположение вызываемого терминала. А запрос OPTIONS является предшествующим запросам INVITE и ACK. Он запрашивает функциональные возможности терминала вызываемого пользователя.

SIP-протокол, наряду с абонентскими терминалами, подразумевает использование промежуточных серверов:

• Прокси-сервера – обеспечивает приём и обработку вышеуказанных запросов.
• Сервера местоположений – обеспечивает мобильность пользователей IP-телефонии.
• Сервера переадресации – хранит записи о прокси-серверах и абонентских терминалах.

Все эти устройства взаимодействуют с помощью запросов, приведённых выше. На каждый запрос высылается тот или иной ответ:

• 1xx – класс информационных ответов, не являющихся завершающими;
• 2xx – ответы об успешном завершении того или иного запроса;
• 3xx – абонент изменил местоположение;
• 4хх – категория сообщений о каких-либо ошибках;
• 5хх – категория серверных ошибок;
• 6хх – ответы, связанные с невозможностью вызова абонента.

Иными словами, каждый сеанс установления связи – это обмен запросами с отправкой ответов. Причём SIP-протокол работает поверх транспортных протоколов (чаще всего это TCP и UDP с портами 5060 и 5061).

Для чего используется

Данный протокол активно используется в IP-телефонии, в том числе для работы виртуальных АТС. Пользователи могут вызывать друг друга, обмениваться файлами и мультимедийной информацией, привлекать к установленному сеансу других участников, управлять переводом звонков. Также он используется при проведении сеансов видеосвязи и видеоконференций. Нельзя не отметить и его применение в онлайн-играх, где нужно соединить двух и более игроков. Благодаря гибкости он нашёл своё место в бизнес-процессах, обеспечивая взаимодействие телефонии и бизнес-приложений.

Куда можно звонить

IP-телефония с использованием SIP-протокола позволяет совершать вызовы в любых направлениях:

• Внутри сети между двумя и более абонентами.
• Между сетями, с использованием полного адреса.
• На стационарные и мобильные номера по всему миру.

Также можно позвонить непосредственно SIP-абоненту, используя для этого городские шлюзы – звоним на номер провайдера, далее набираем внутренний номер абонента. Кстати, самим номером является SIP ID – это внутренний идентификатор абонента. Полный номер выглядит как имя@домен. Например, 111111@sip.zadarma.com – это полный идентификатор абонента у VoIP-провайдера Zadarma.

VoIP-оператор Zadarma обеспечивает и качественную передачу голоса, даря абонентам денежный бонус для тестирования качества связи.

Плюсы и минусы

Положительные черты SIP-протокола:

• Лёгкость в расширении – при необходимости сюда можно внедрить новые сервисы.
• Быстрая установка соединений между абонентами.
• Лёгкость в освоении – описание спецификаций занимает 150 листов против 700 листов у протокола H.323;
• Отсутствие привязки абонентов к определённому местоположению – абонент с терминалом может перемещаться по всему миру, оставаясь на связи по прежнему адресу.
• Применение SIP-протокола позволяет с лёгкостью расширять сети на тысячи и десятки тысяч абонентов.

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

За SIP-протоколом будущее – это стало известно ещё в середине 90-х годов, когда многочисленные эксперименты показали его превосходство над H.323. Сегодня он используется почти всеми VoIP-провайдерами, обеспечивая абонентов качественной связью и почти мгновенным соединением. Не является исключением и вышеупомянутый провайдер Zadarma – лёгкий в подключении, с качественной связью и низкими тарифами.

2. Описание связки SIP/SDP/RTP-протоколов

SIP (Session Initiation Protocol) — протокол установления сессии (не только телефонной) — это текстовый протокол поверх UDP. Также есть возможность использовать SIP поверх TCP, но это редкие случаи.

SDP (Session Description Protocol) — протокол согласования типа передаваемых данных (для звука и видео это кодеки и их форматы, для факсов — скорость передачи и коррекция ошибок) и адреса их назначения (IP и порт). Это также текстовый протокол. Параметры SDP передаются в теле SIP-пакетов.

RTP (Real-time Transport Protocol) — протокол передачи аудио/видеоданных. Это бинарный протокол поверх UDP.

Общая структура SIP-пакетов:

• Start-Line: поле, указывающее SIP-метод (команду) при запросе или результат выполнения SIP-метода при ответе.
• Headers: дополнительная информация к Start-Line, оформленная в виде строк, содержащих пары АТТРИБУТ: ЗНАЧЕНИЕ.
• Body: бинарные или текстовые данные. Обычно используется для передачи SDP-параметров или сообщений.

Вот пример двух SIP-пакетов для одной частой процедуры — установления вызова:

Слева изображено содержимое пакета SIP INVITE, справа — ответ на него — SIP 200 OK.

Основные поля выделены рамками:

• Method/Request-URI содержит SIP-метод и URI. В примере происходит установление сессии — метод INVITE, вызов абонента 555@192.168.1.200.
• Status-Code — код ответа на предыдущую SIP-команду. В данном примере команда выполнилась успешно — код 200, т.е. абонент 555 поднял трубку.
• Via — адрес, на котором абонент 777 ждет ответа. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
• From/To — отображаемые имя и адрес отправителя и получателя сообщения. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
• Cseq содержит порядковый номер команды и название метода, к которому относится данное сообщение. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
• Content-Type — тип данных, которые передаются в блоке Body, в данном случае — SDP-данные.
• Connection Information — IP-адрес, на который второму абоненту необходимо отправлять пакеты RTP (или UDPTL пакеты в случае передачи факса по T.38).
• Media Description — порт, на который второй абонент должен передавать указанные данные. В данном случае это звук (audio RTP/AVP) и список поддерживаемых типов данных — PCMU, PCMA, GSM-кодеки и DTMF-сигналы.

SDP-сообщение состоит из строк, содержащих пары ПОЛЕ=ЗНАЧЕНИЕ. Из основных полей можно отметить:

• o — Origin, имя организатора сессии и идентификатор сессии.
• с — Connection Information, поле описано ранее.
• m — Media Description, поле описано ранее.
• a — медиа-атрибуты, уточняют формат передаваемых данных. Например, указывают направление звука — прием или передача (sendrecv), для кодеков указывают частоту дискретизации и номер привязки (rtpmap).

RTP-пакеты содержат аудио/видеоданные, закодированные в определенном формате. Данный формат указывается в поле PT (payload type). Таблица соответствия значения данного поля конкретному формату приведена в ]]>https://en.wikipedia.org/wiki/RTP_audio_video_profile]]>.

Также в RTP-пакетах указывается уникальный SSRC-идентификатор (определяет источник RTP-потока) и метка времени (timestamp, используется для равномерного проигрывания звука или видео).

Пример взаимодействия двух SIP-абонентов через SIP-сервер (Asterisk):

Как только запускается SIP-телефон, первым делом он регистрируется на удаленном сервере (SIP Registar), отправляет ему сообщение SIP REGISTER.

При вызове абонента отправляется сообщение SIP INVITE, в теле которого вложено SDP-сообщение, в котором указываются параметры передачи звука/видео (какие кодеки поддерживаются, на какой IP и порт отправлять звук и др.).

Когда удаленный абонент поднимает трубку, нам приходит сообщение SIP 200 OK также с параметрами SDP, только удаленного абонента. Используя отправленные и полученные SDP-параметры можно устанавливать RTP-сессию передачи звука/видео или T.38-сессию передачи факсов.

Если полученные параметры SDP нас не устроили, или промежуточный SIP-сервер решил не пропускать через себя RTP-трафик, то выполняется процедура повторного согласования SDP, так называемый REINVITE. Кстати, именно из-за этой процедуры у бесплатных SIP-прокси-серверов есть один недостаток — если оба абонента находятся в одной локальной сети, а прокси-сервер находится за NAT’ом, то после перенаправления RTP-трафика ни один из абонентов не будет слышать другого.

После окончания разговора, абонент положивший трубку, отправляет сообщение SIP BYE.

3. Передача информации о нажатых кнопках

Иногда после установления сессии, во время разговора, требуется доступ к дополнительным видам обслуживания (ДВО) — удержание вызова, перевод, голосовая почта и т.п. — которые реагируют на определенные сочетания нажатых кнопок.

Так, в обычной телефонной линии есть два способа набора номера:

• Импульсный — исторически первый, использовался в основном в телефонах с дисковым номеронабирателем. Набор происходит за счет последовательного замыкания и размыкания телефонной линии согласно набираемой цифре.
• Тоновый — набор номера DTMF-кодами (Dual-Tone Multi-Frequency) — каждой кнопке телефона соответствует своя комбинация двух синусоидальных сигналов (тонов). Выполняя алгоритм Гёрцеля можно довольно просто определить нажатую кнопку.

Во время разговора импульсный способ неудобен для передачи нажатой кнопки. Так, на передачу «0» требуется приблизительно 1 секунда (10 импульсов по 100 мс: 60 мс — разрыв линии, 40 мс — замыкание линии) плюс 200 мс на паузу между цифрами. К тому же во время импульсного набора будут часто слышны характерные щелчки. Поэтому в обычной телефонии используется только тоновый режим доступа к ДВО.

В VoIP-телефонии информация о нажатых кнопках может передаваться тремя способами:

1. DTMF Inband — генерация звукового тона и передача его внутри аудиоданных (текущего RTP-канала) — это обычный тоновый набор.
2. RFC2833 — генерируется специальный RTP-пакет telephone-event, в котором содержится информация о нажатой клавише, громкость и длительность. Номер RTP-формата, в котором будут передаваться пакеты DTMF RFC2833, указывается в теле SDP-сообщения. Например: a=rtpmap:98 telephone-event/8000.
3. SIP INFO — формируется пакет SIP INFO c информацией о нажатой клавише, громкости и длительности.

Передача DTMF внутри аудиоданных(Inband) имеет несколько недостатков — это накладные ресурсы при генерации/встраивании тонов и при их детектировании, ограничения некоторых кодеков, которые могут исказить DTMF-коды, и слабая надежность при передаче (если потеряется часть пакетов, то может произойти детектирование двойного нажатия одной и той же клавиши).

Главное различие между DTMF RFC2833 и SIP INFO: если на SIP-прокси-сервере включена возможность передачи RTP непосредственно между абонентами минуя сам сервер (например, canreinvite=yes в asterisk), то сервер не заметит RFC2833-пакеты, вследствие чего становятся недоступными сервисы ДВО. Передача SIP-пакетов всегда осуществляется через SIP-прокси-серверы, поэтому ДВО всегда будут работать.

4. Передача голоса и факсов

Как уже упоминалось, для передачи медиаданных используются RTP-протокол. В RTP-пакетах всегда указывается формат передаваемых данных (кодек).

Для передачи голоса существует много разнообразных кодеков, с разными соотношениями битрейт/качество/сложность, есть открытые и закрытые. В любом софтфоне обязательно есть поддержка G.711 alaw/ulaw-кодеков, их реализация очень простая, качество звука неплохое, но они требуют пропускной способности в 64 кбит/с. Например, G.729-кодек требует только 8 кбит/с, но очень сильно загружает процессор, к тому же он не бесплатный.

Для передачи факсов обычно используется либо G.711-кодек, либо T.38-протокол. Передача факсов по G.711-кодеку соответствует передаче факса по T.30-протоколу, как будто факс передается по обычной телефонной линии, но при этом аналоговый сигнал с линии оцифровывается по alaw/ulaw-закону. Это также называется передачей факса Inband T.30.

Факсы по T.30-протоколу выполняют согласование своих параметров: скорости передачи, размера дейтаграмм, тип коррекции ошибок. T.38-протокол базируется на протоколе T.30, но в отличие от Inband-передачи, происходит анализ генерируемых и принятых T.30-команд. Таким образом передаются не сырые данные, а распознанные команды управления факсом.

Для передачи команд T.38 используется UDPTL-протокол, это протокол на базе UDP, он используется только для T.38. Для передачи комманд T.38 можно ещё использовать протоколы TCP и RTP, но они используются гораздо реже.

Основные достоинства T.38 — снижение нагрузки на сеть и большая надежность по сравнению с Inband-передачей факса.

Процедура передачи факса в режиме T.38 выглядит следующим образом:

1. Устанавливается обычное голосовое соединение по любому кодеку.
2. Когда бумага загружена в отправляющий факс, он периодически шлет T.30-сигнал CNG (Calling Tone), что означает готовность к передаче факса.
3. На принимающей стороне генерируется T.30-сигнал CED (Called Terminal Identification) — это готовность принять факс. Данный сигнал отправляется либо после нажатия кнопки «Получить факс» либо факс делает это автоматически.
4. На отправляющей стороне обнаруживается CED-сигнал и происходит процедура SIP REINVITE, а в SDP-сообщении указывается T.38 тип: m=image 39164 udptl t38.

Передавать факсы по интернету желательно в T.38. Если же факс нужно передать внутри офиса или между объектами, имеющими стабильное соединение, то можно использовать передачу факса Inband T.30. При этом перед передачей факса обязательно должна быть отключена процедура эхоподавления, чтобы не вносить дополнительные искажения.

Очень подробно про передачу факсов написано в книге «Fax, Modem, and Text for IP Telephony», авторы — David Hanes и Gonzalo Salgueiro.

5. Цифровая обработка сигналов (ЦОС). Обеспечение качества звука в IP-телефонии, примеры тестирования

С протоколами установления сеанса разговора (SIP/SDP) и методе передачи звука по RTP-каналу мы разобрались. Остался один немаловажный вопрос — качество звука. С одной стороны, качество звука определяется выбранным кодеком. Но с другой, необходимы еще дополнительные процедуры DSP (ЦОС — цифровой обработки сигналов). Данные процедуры учитывают особенности работы VoIP-телефонии: не всегда используется качественная гарнитура, в интернете бывают пропадания пакетов, иногда пакеты приходят неравномерно, пропускная способность сети тоже не резиновая.

Основные процедуры, улучшающие качество звука:

VAD (Voice activity detector) — процедура определения фреймов, которые содержат голос (активный голосовой фрейм) или тишину (неактивный голосовой фрейм). Такое разделение позволяет заметно снизить загрузку сети, поскольку передача информации о тишине требует гораздо меньше данных (достаточно лишь передать уровень шума или вообще ничего не передавать).

Некоторые кодеки уже содержат внутри себя процедуры VAD (GSM, G.729), для других же (G.711, G.722, G.726) нужно их реализовывать.

Если VAD настроен на передачу информации об уровне шума, то передаются специальные SID-пакеты (Silence Insertion Descriptor) в 13м RTP-формате CN (Comfort Noise).

Стоит заметить, что SID-пакеты могут быть отброшены SIP-прокси-серверами, поэтому для проверки желательно настраивать передачу RTP-трафика мимо SIP-серверов.

CNG (сomfort noise generation) — процедура генерации комфортного шума на базе сведений из SID-пакетов. Таким образом, VAD и CNG работают в связке, но CNG-процедура гораздо менее востребована, поскольку заметить работу CNG-можно не всегда, особенно при малой громкости.

PLC (packet loss concealment) — процедура восстановления звукового потока при потере пакетов. Даже при 50% потере пакетов хороший алгоритм PLC позволяет добиться приемлемого качества речи. Искажения, конечно, будут, но слова разобрать можно.

Простейший способ эмуляции потери пакетов (в Linux) — воспользоваться утилитой tc из пакета iproute с модулем netem. Она выполняет шейпинг только исходящего трафика.

Пример запуска эмуляции сети с потерей 50% пакетов:

tc qdisc change dev eth1 root netem loss 50%

Отключение эмуляции:

tc qdisc del dev eth1 root

Jitter buffer — процедура избавления от jitter-эффекта, когда интервал между принятыми пакетами очень сильно меняется, и что в худшем случае ведет к неверному порядку принимаемых пакетов. Также данный эффект приводит к прерываниям речи. Для устранения jitter-эффекта необходимо на принимаемой стороне реализовать буфер пакетов с размером, достаточным для восстановления исходного порядка отправления пакетов с заданным интервалом.

Эмулировать jitter-эффект также можно с помощью утилиты tc (интервал между ожидаемым моментом прихода пакета и фактическим может достигать 500 мс):

tc qdisc add dev eth1 root netem delay 500ms reorder 99%

LEC (Line Echo Canceller) — процедура устранения локального эха, когда удаленный абонент начинает слышать собственный голос. Ее суть заключается в том, чтобы вычесть из передаваемого сигнала принимаемый сигнал с некоторым коэффициентом.

Эхо может возникать по нескольким причинам:

• акустическое эхо из-за некачественного аудиотракта (звук из динамика попадает в микрофон);
• электрическое эхо из-за несогласованности импедансов между телефонным аппаратом и SLIC-модулем. В большинстве случаев это происходит в цепях преобразования 4-проводной телефонной линии в 2-проводную.

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

Более подробно о VoIP и процедурах ЦОС написано в книге VoIP Voice and Fax Signal Processing. Предпросмотр доступен на ]]>Google Books.]]>

Источник: tarifprofy.com