 |
|
|
|
Всё, что вы хотели знать о протоколе SIP
Всё, что вы хотели знать о протоколе SIP Часть 2 Повышение уровня интеллекта устройств, образующих сеть, означает разработку для них ряда специализированных протоколов. Это, а также необходимость реализации логики новых услуг, повышает входной барьер для не знакомого с предметной областью инженера. Протокол описания сеанса SDP Как вы уже знаете, протокол SIP не используется для описания параметров сеанса, таких как вид информации (речь, видео и т. д.), кодек или частота дискретизации. Вместо этого тело сообщения SIP содержит характеристики сеанса, описанные с помощью специального протокола описания сеанса SDP (Session Description Protocol) или (теоретически) другого протокола, выполняющего те же функции. Роль протокола SDP в сети SIP аналогична роли протокола H.245 в сетях H.323. Возможность отделения функций управления установлением сеанса от процесса согласования характеристик сеанса – очень важное свойство протокола SIP, позволяющее использовать для установления сеанса вспомогательный протокол любого типа. SDP – это протокол описания параметров сеанса для передачи потоковых данных. Своё первое применение он нашёл в качестве средства анонсирования информации о мультимедийных конференциях в экспериментальной академической сети Mbone (Multicast backbone). Первое описание протокола было опубликовано Инженерной проблемной группой Интернета (IETF) как RFC 2327 в апреле 1998 года, а на сегодняшний день актуален RFC 4566. Любая реализация протокола SIP обязана поддерживать и SDP. Для договора о характере сеанса SIP использует модель предложения и ответа (offer/answer model). Один агент пользователя (UA) посылает описание сеанса, в котором предлагает желаемый способ коммуникации (аудио, видео, игра) и соответствующие типы кодека (кодер/декодер), а также адреса для принятия определённого вида основной информации (медиа). Другой UA в ответе перечисляет, какие из предложенных средств коммуникации приемлемы, и приводит адреса, на которых будут приниматься эти приемлемые виды информации. В процессе сеанса, используя ту же модель, UA может менять договорённые параметры. Как и в SIP, в протоколе SDP применяется текстовое кодирование информации. Сообщение описания сеанса состоит из набора строк, которые следуют в определённом порядке (в отличие от SIP, порядок здесь имеет значение). Правила, указывающие порядок следования строк, достаточно строгие, но для обеспечения расширяемости протокола неизвестные атрибуты должны игнорироваться. Описание сеанса состоит из описаний уровня сеанса (детали, относящиеся к сеансу в целом и ко всем медиа-потокам) и нескольких необязательных описаний уровня медиа-носителя (детали, относящиеся к отдельному медиа-потоку). Рассмотрим типичный пример SDP-сообщения:
В таблице 1 дано пояснение каждой строки. Каждая строка является обязательной, если не указано обратное. Таблица 1. Список типичных полей SDP в их правильном порядке
Описание сеанса для одновременной передачи голоса и видео может выглядеть следующим образом:
Обратите внимание: первые четыре строки являются описанием уровня сеанса, а строки a= – описаниями уровня медиа-носителя. При этом каждая новая m-строка обозначает начало нового медиа-потока. Использование SDP в SIP Основным документом, нормирующим использование SDP в SIP, является RFC 3264. Упомянем его основные положения:
Протоколы RTP (Real-time Transport Protocol) и RTCP (RTP Control Protocol) В приложениях реального времени отправитель генерирует поток данных с постоянной скоростью, и получатель(-и) должен предоставлять эти данные приложению с той же самой скоростью. Такие приложения включают аудио- и видеоконференции, распространение живого видео (для немедленного воспроизведения), разделяемые рабочие области, удалённую диагностику в медицине, компьютерную телефонию, распределенное интерактивное моделирование, игры и мониторинг в реальном времени. Протокол TCP в таких приложениях не приемлем ввиду своих свойств. TCP не гарантирует время доставки, а повторно переданные пакеты, которые в приложениях реального времени уже не несут актуальной информации, ещё и сужают полосу актуальной передачи, что увеличивает неравномерность передачи потока. Другой широко используемый протокол транспортного уровня, UDP, не имеет этих двух ограничений, но и он не предоставляет критически необходимой для приложений реального времени информации о синхронизации. UDP сам по себе не предоставляет каких-либо инструментов общего назначения для создания приложений реального времени. Несмотря на то что каждое приложение реального времени может иметь свои собственные механизмы для поддержки передачи в реальном времени, они имеют много общих черт, а это делает определение единого протокола весьма желательным. Потому в 1996 году в RFC 1889 были представлены протоколы RTP и RTCP. Актуальные на сегодняшний день версии описаны в RFC 3550. Протокол RTP Это протокол транспортного уровня, который работает поверх UDP (cм. рис. 1) и гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах. Это означает, что данные могут быть воспроизведены в реальном времени.
Рисунок 1. Место RTP в стеке протоколов TCP/IP Функции RTP Протокол RTP предусматривает такие функции:
Таблица 2. Типы полезной нагрузки аудио и видео в RTP
Замечу, что RTP сам по себе не обеспечивает качества услуг (QoS) и не гарантирует корректную доставку данных. Пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка переменной длины и поле данных. Забегая вперёд, скажу, что пакет RTCP имеет следующую структуру: начинается с фиксированной части (подобной фиксированной части информационных пакетов RTP), за которой следуют структурные элементы, имеющие переменную длину согласно типу пакета. В соответствии с протоколом RTP трафик различных типов должен передаваться отдельно, в разных сеансах связи RTP. Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Например, в телеконференции, составленной из звукового и видеосигнала, кодированных отдельно, трафик каждого типа нужно передавать в отдельном сеансе RTP со своим собственным транспортным адресом назначения. Не всегда все участники конференции имеют возможность получать мультимедийные данные в одинаковом формате. Если новая система хочет принять участие в сеансе, но её канал не обладает достаточной пропускной способностью, помочь может специальное устройство, реализующее механизм трансляции RTP и называемое микшером. Микшер повторно синхронизирует входящие звуковые пакеты от одного или более источников для восстановления исходных интервалов голосового потока (см. врезку «Качество голосовой связи в среде IP»), микширует эти восстановленные звуковые потоки в один поток, производит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи одному или более получателям. Чтобы в приёмных узлах можно было иметь правильную индикацию источника сообщений, заголовок RTP включает средства опознавания источников, участвовавших в формировании смешанного пакета. Также микшер может изменять формат данных. Более простое устройство создает один исходящий пакет RTP для каждого поступающего пакета RTP. Этот механизм, называемый транслятором, может изменить формат данных в пакете или использовать иной комплект низкоуровневых протоколов для передачи данных из одного домена в другой. Например, потенциальный получатель может оказаться не в состоянии обрабатывать высокоскоростной видеосигнал, используемый другими участниками сеанса. Транслятор конвертирует видео в формат пониженного качества, требующий не такой высокой скорости передачи данных. Для того чтобы протокол RTP был более гибким и мог применяться для различных приложений, некоторые его параметры сделаны преднамеренно недостаточно строго определёнными, но зато в нём предусмотрено понятие профиля. Профиль – это набор параметров протоколов RTP и RTCP для конкретного класса приложений, определяющий особенности их функционирования. В профиле определяется использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т. д. Каждое приложение обычно работает только с одним профилем, следовательно, полная спецификация RTP для конкретного приложения должна включать дополнительные документы, к которым относятся описание профиля, а также описание формата трафика, определяющее, как трафик конкретного типа, такой как аудио или видео, будет обрабатываться. При этом один и тот же формат трафика может использоваться для множества профилей и может быть определён независимо от профиля. Протоколу RTP не требуется стандартный или статический TCP- или UDP-порт для связи. RFC 3551 указывает, что RTP-подключения осуществляются через UDP-порт с четным номером, а порт с нечётным номером, следующим в порядке возрастания, используется протоколом RTCP. Хотя не существует стандартных назначений диапазона портов для RTP/RTCP, обычно используется диапазон 16384-32767. Протокол RTCP Это протокол, предоставляющий приложениям, работающим по протоколу RTP, механизмы обмена управляющей информацией, подтверждения доставки RTP-пакетов, мониторинга состояния сети и реагирования на изменения в ней. Например, получив информацию о повышении интенсивности трафика в сети и уменьшении выделенной приложению полосы пропускания, приложение может отреагировать и умерить свои требования к полосе пропускания за счёт некоторой потери качества. После снижения нагрузки в сети приложение может восстановить исходную полосу пропускания и продолжить работу с тем качеством, какое оно предоставляло вначале. Сообщение RTCP несёт такую информацию, как число переданных и полученных пакетов, число потерянных пакетов, величины задержки и вариации задержки (джитера). Последний термин нуждается в дополнительном разъяснении. Вариация задержки – это величина, характеризующая неравномерность передачи, выражающуюся в наличии переменной задержки между прибытием и иногда – в нарушении порядка доставки пакетов. Одностороннюю же задержку образуют такие составляющие, как: задержки, вносимые процессами кодирования и декодирования, задержки пакетизации, формирования очереди, задержки при передаче в канал, задержки распространения по каналу и латентность буфера сглаживания вариации задержки (деджитер-буфер, этот механизм описан во врезке «Качество голосовой связи в среде IP»). При этом некоторые составляющие постоянные, а некоторые – переменные. Односторонняя задержка в диапазоне 0-150 миллисекунд, согласно рекомендации ITU-T G.114, является допустимой для большинства приложений. Задержка величиной 150-400 мс ещё не оказывает сильного влияния на качество воспроизведения речи и приемлема для большинства приложений. Что касается количества потерянных пакетов, то для голосовых звонков этот показатель не должен превышать 1%, но при передаче факсимильных сообщений потеря пакетов не допустима вообще. Наконец, допустимые значения вариации задержки – до 30 мс. Функции RTCP Можно выделить три функции протокола RTCP:
Чтобы обеспечить выполнение всех этих функций, участники сеанса обмениваются специальными управляющими сообщениями протокола RTCP. Кратко опишу кратко пять их типов. Пакеты отчёта RTCP, обеспечивающие обратную связь – оценку качества приёма, могут принимать одну из двух форм в зависимости от того, является получатель также и отправителем или нет: Report (RR) или Sender Report (SR). Отчёт отправителя – Receiver Report (RR). Эти пакеты создаются участниками сеанса, не являющимися активными отправителями. Они содержат такую информацию, как подтверждение получения пакетов, данные о рассинхронизации входящих пакетов и задержку, связанную с подтверждением приёма. Отчёт получателя – Sender Report (SR). SR передаётся, если участник сеанса посылал любые пакеты данных в течение интервала, начиная с передачи последнего или предыдущего отчёта, в противном случае передается RR. Единственное отличие между формами отчёта отправителя и отчёта получателя, помимо кода типа пакета, – это то, что отчёт отправителя включает 20-байтовый раздел информации отправителя для использования активными отправителями. Этот раздел включает данные о внутренней аудиовизуальной синхронизации и количестве отправленных пакетов и байтов. Пакет описания источника – Source Description Items (SDES). Пакеты этого типа содержат информацию об участниках сеанса. Пакет завершения связи – BYE. Это «прощальный» пакет, с помощью которого пользователь отключается от сеанса. Пакет, определяемый приложением – APP. Пакет APP предназначен для экспериментального использования при разработке новых приложений и программных средств без регистрации новой величины типа пакета. Пакеты APP с нераспознанными именами должны игнорироваться. После испытания, если оправдано более широкое использование, рекомендуется, чтобы каждый пакет APP был переопределён без полей подтипа и имени и зарегистрирован в IANA с выделением для него нового типа пакета RTCP. В пакет входят сведения о специфических функциях приложения. Заметим, что и здесь есть новые разработки: так, в RFC 3611 описан тип пакетов Extended Report (XR), который предусматривает сбор статистической информации по двадцати параметрам сетей передачи данных и качеству голоса. Реализация расширенных услуг на базе протокола SIP Будучи протоколом эпохи конвергенции онлайновой работы, развлечений и коммуникаций, протокол SIP вобрал в себя множество расширений, делающих возможным предоставление более сложных услуг. В оставшейся части статьи мы кратко рассмотрим базовые свойства и расширения SIP, делающие возможным предоставление как привычных для традиционной телефонии, так и мультимедийных услуг. Удержание вызова и трёхсторонняя конференция На рис. 2 показаны сразу две важные услуги: удержание вызова и трёхсторонняя конференция.
Рисунок 2. Трёхсторонняя конференция через агента Bob Перевод на удержание вызова осуществляется отправкой удерживающим пользовательским агентом сообщения re-INVITE (напомню, что от простого INVITE его отличает наличие тега в поле To и возросший порядковый номер в CSeq), запрашивающего в SDP переключение режима передачи медиа-потока из режима одновременной отправки и приёма «sendrecv» на режим отправки «sendonly». В «200 OK» от второй стороны будет соответственно «recvonly» (только приём). После установления сессии #2 первые два пользовательских агента проводят ещё один цикл пересогласования для перехода в режим «sendrecv». С этого момента конференцию можно считать установленной. Параллельный вызов Следующей расширенной услугой SIP-телефонии, на которой мы остановимся, является «параллельный вызов» (Call Forking). Суть заключается в том, что прокси-сервер «размножает» входящий INVITE на несколько пользовательских агентов (см. рис. 3).
Рисунок 3. Параллельный вызов Например пользователь может захотеть, чтобы входящий вызов посылался на его домашний, а затем мобильный телефон. Разветвление может быть как последовательным, так и параллельным. Значения параметра branch поля заголовка Via уникальны для каждого исходящего INVITE. В ответ может прийти несколько «200 OK»-ответов на один и тот же INVITE, которые имеют один и тот же Call-ID, один и тот же параметр tag в заголовке From, но отличаются параметром tag в заголовке To. Все эти диалоги будут соответствовать одному и тому же звонку. Сеанс устанавливается с первым агентом, ответившим «200 OK», а остальным агентам для завершения диалога отправляется запрос CANCEL (если диалог находится в ранней стадии установления), или же ACK и BYE, если диалог уже установлен. Эта услуга может предоставляться прокси-сервером с хранением состояния транзакции или состояния диалога, но не прокси-сервером без хранения состояния, поскольку сервер должен «следить» за состоянием запросов, которые он разослал по нескольким пунктам назначения, и направить пользовательскому агенту, который инициировал запрос, только один окончательный ответ. Перевод вызова Для осуществления перевода вызова используется метод REFER (RFC 3515) – запрос от одного UA для приглашения к сеансу другого пользовательского агента. Обязательный заголовок Refer-To указывает цель запроса – UA, с которым необходимо установить связь. Запрос REFER может содержать также опциональный заголовок Referred-By, указывающий на инициатора запроса. Адресат запроса (обычно после осуществления аутентификации и авторизации) решает, принимать ли REFER, и в случае успеха немедленно отвечает «202 Accepted». Промежуточные ответы в REFER-транзакции не допустимы. На рис. 4 показан поток сообщений для случая перевода вызова.
Рисунок 4. Перевод вызова Ниже показано содержимое сообщений REFER и следующего за ним INVITE (здесь и далее заголовки с интересующей нас информацией выделены красным цветом):
Информация о присутствии Одной из примечательных особенностей SIP является его способность определить присутствие, т.е. найти не только место, где физически находится пользователь, но и возможность коммуникаций с ним и тип последних, например голосовая связь или мгновенные сообщения. SIP определяет статус присутствия посредством мониторинга и уведомления о событиях. Это позволяет устройству подписаться на пакет событий, который поддерживается другим устройством, и получать от него уведомление об изменениях состояния. Данный механизм реализуется с помощью сервера присутствия (Presence Server). Физически он обычно совмещён с сервером регистрации или одним из других элементов сети SIP. Служба присутствия включает два различных набора клиентов. Один набор клиентов, называемых presentities (например, производители информации), предоставляет информацию о присутствии, которая распределяется и сохраняется. Другой набор клиентов, именуемых watchers (например, потребители информации), получает данные о присутствии от соответствующей службы. При реализации эти клиенты обычно объединяются, однако обсуждаются отдельно. Метод SUBSCRIBE (RFC 3265) используется для того, чтобы запросить асинхронное уведомление о наступлении события или группы событий на удалённом узле. В запросе присутствует заголовок Expires, обозначающий длительность подписки на уведомления. Запросы должны иметь только одно значение в заголовке Event, т.е. подписку запрашивать можно только на одно событие за один раз. Собственно уведомление подписчика об изменениях в состоянии, на которые тот подписан, происходит при помощи запроса NOTIFY (также RFC 3265).
Рисунок 5. Услуга присутствия На рис. 5 показан процесс подписки на информацию о регистрации. Рассмотрим вид запросов SUBSCRIBE и NOTIFY:
Ответы 2xx на запрос SUBSCRIBE показывают, что подписка принята и что запрос NOTIFY будет отправлен немедленно при наступлении события. Заголовок же Event запроса NOTIFY должен совпадать с заголовком Event из SUBSCRIBE.
В базовой для SIP рекомендации RFC 3261 определено 6 типов запросов: REGISTER, INVITE, ACK, CANCEL, BYE и OPTIONS. Ниже мы рассмотрим OPTIONS и остановимся на некоторых других методах SIP, применяемых при реализации дополнительных услуг. Другие методы SIP Метод OPTIONS даёт возможность узнать у UA, какие кодеки, методы, типы контента, расширения им поддерживаются, а также известные агенту контакты, ещё до попытки установления диалога. Рассмотрим пример такого взаимодействия.
Целевой UA отвечает на запрос OPTIONS так, как бы он ответил на INVITE (откликом класса 2хх), но с включением вышеупомянутой информации в заголовки Allow, Accept, Accept-Encoding, Accept-Language, Supported и (когда речь идёт о списке кодеков) SDP-часть. Тело SDP здесь не показано для экономии места:
Метод MESSAGE(RFC 3428) используется для передачи мгновенных сообщений между пользователями. Содержимое сообщения помещается в тело приложения MIME. Размер тела сообщения не должен превышать 1300 байт. Метод MESSAGE примечателен тем, что он не образует диалоги. Ответ «200 OK» на MESSAGE означает, что сообщение было доставлено. Ответы 4xx и 5xx показывают, что сообщение не могло быть успешно доставлено, а ответы группы 6xx – что сообщение было успешно доставлено, но отвергнуто. Метод INFO (RFC 2976) применяется для передачи управляющей информации, относящейся к сеансу и генерируемой в процессе сеанса, как то: сигнальных сообщений ТфОП между шлюзами в течение вызова, цифр тонового набора (DTMF), информации об уровне сигнала в беспроводной сети, состоянии баланса, изображений и т. д. Если INFO не может быть принят, UA шлёт в ответ «487 Request Terminated». Наконец, метод UPDATE (RFC 3311) позволяет агенту изменять параметры сеанса, например, используемый кодек. UPDATE может быть использован после того, как принят окончательный ответ на INVITE, однако использование re-INVITE предпочтительно. Заключение Итак, наш экскурс в протокольную часть завершен. Изложенных в этой и предыдущей статье цикла сведений достаточно для того, чтобы пуститься в самостоятельные поиски или задуматься о применении полученных базовых знаний, но нас ждёт заключительная часть, в которой мы поговорим о сугубо практических проблемах: обходе NAT и обеспечении безопасности в сетях на основе протокола SIP. Приложение Качество голосовой связи в среде IP На качество аудиотракта оказывают влияние следующие факторы: выбор кодека, выбор параметров пакетизации голосовой информации и качественные показатели каналов передачи данных. Таблица 3. Типы кодеков и их параметры
В таблице 3 представлены типы кодеков и их параметры. Естественно, что большое значение имеет экономия полосы, но кроме этого необходимо помнить о качестве голоса. В таблице также представлен параметр средней экспертной оценки (Mean Opinion Score, MOS), который определяет среднюю оценку качества голоса, полученную экспертным путем. Наивысший балл – 5, низший балл – 1, при этом:
Параметр MOS дает субъективную оценку, но эта методика является официальной, она описывается в документах ITU. В IP-телефонии чаще других используются кодеки G.711 (64 Кбит/с), G.729 (8 Кбит/с) и G.723 (5,3 Кбит/с). В лабораторных условиях G.711 обеспечивает наилучшее качество голоса, но в IP-среде занимает с учётом накладных расходов RTP/UDP/IPv4 полосу пропускания 80-120 Кбит/с. Кодек G.729 делает возможным более эффективное цифровое представление речи, передавая в цифровом виде не сам сигнал, а его параметры (количество переходов через ноль, спектральные характеристики и др.), чтобы затем по этим параметрам выбирать модель голосового тракта и синтезировать исходный сигнал. Кодер оперирует с кадрами речевого сигнала длиной 10 мс, дискретизованными с частотой 8 КГц. Восстановленная речь достаточно хорошо соответствует оригиналу. По методу MOS при существенном сжатии его качество воспроизводимого голоса оценивается лишь на 0,2 балла ниже, чем G.711. G.729 сегодня является доминирующим в использовании типом кодека. Значительное влияние на используемую полосу оказывает параметр пакетизации, или временной интервал речевого сигнала, который будет передаваться в одном IP-пакете. При меньшем значении параметра увеличиваются устойчивость качества восстановления речи при пропадании пакетов и уменьшаются задержки, но значительно увеличивается полоса. При использовании большего значения потребляемая полоса уменьшается, но ухудшается качество речи после восстановления от потери пакетов. Оптимальные значения интервала пакетизации находятся в пределах 20-30 мс. Для ликвидации вариации задержки на приёмной стороне организуется деджитер-буфер. В результате IP-пакеты, пришедшие с задержкой, в рамках величины деджитер-буфера (например, 80 мс), занимают своё место и, таким образом, не теряются. Этот способ используется практически всеми производителями VoIP-оборудования, а многие из них предлагают динамически изменяемый деджитер-буфер. Пожалуй, самым важным фактором, влияющим на качество передачи голоса через IP, является качество каналов передачи. Достичь хороших показателей качества обслуживания (QoS) позволяют маркировка трафика (IP precedence, DSCP), классификация пакетов, механизмы: очередей с низкой задержкой (Low Latency Queuing, LLQ), фрагментации и чередования пакетов (Link Fragmentation and Interleaving, LFI), сглаживания трафика (traffic shaping), обнаружения речевой активности (Voice Activity Detection, VAD), сжатия RTP-заголовков. О сжатии RTP-заголовков следует сказать следующее. Цепочка инкапсуляций RTP/UDP/IPv4 приводит к существенным накладным расходам. Кодек G.729 генерирует пакеты размером в 10 байт (80 битов каждые 10 мс). Один RTP-заголовок, размером в 12 байтов, больше, чем весь этот пакет. К нему, кроме того, должен быть добавлен 8-байтовый UDP-заголовок и 20-байтовый IPv4-заголовок, что создает заголовок, в четыре раза превосходящий по размеру передаваемые данные. Только 20% фактически переданных битов – данные пользователя. Предложенный IETF-алгоритм сжатия заголовков cRTP (compressed RTP) при передаче речи по IP способен сжимать 40-байтовые заголовки RTP/UDP/IPv4 до 2 или 4 байт. Его принцип действия основывается на том факте, что многие поля заголовков в передаваемых пакетах повторяются от пакета к пакету.
|
Андрей Погребенник
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
