Всё, что вы хотели знать о протоколе SIP::Журнал СА 8.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5400
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6594
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7877
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 8169
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 7165
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Всё, что вы хотели знать о протоколе SIP

Архив номеров / 2007 / Выпуск №8 (57) / Всё, что вы хотели знать о протоколе 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-сообщения:

v=0

0=CiscoSystemsSIP-GWUserAgent 762 3453 IN IP4 10.15.1.6

s=SIP Call

c=IN IP4 10.15.1.6

t=0 0

m=audio 16952 RTP/AVP 18 100

a=rtmap:18 G729/8000

a=rtmap:100 X-NSE/8000

a=ptime:10

В таблице 1 дано пояснение каждой строки. Каждая строка является обязательной, если не указано обратное.

Таблица 1. Список типичных полей SDP в их правильном порядке

Атрибут

Назначение атрибута

v=0

Используемая версия протокола SDP

0=CiscoSystemsSIP-GWUserAgent 762 3453 IN IP4 10.15.1.6

Информация об инициаторе вызова, включая тип агента UA, тип сети и контактное имя

s=SIP Call

Имя сеанса

c=IN IP4 10.15.1.6

Информация о типе среды – используемом типе протокола и адресе соединения. Под адресом соединения понимается адрес отправляющего агента UA

t=0 0

Время начала и остановки сеанса

m=audio 16952 RTP/AVP 18 100

Описание медиа-потока: тип среды и транспортный порт (16952), которые будут использоваться для вызова. Всё, что следует ниже, касается только этого медиа-потока

a=rtmap:18 G729/8000

a=rtmap:100 X-NSE/8000

a=ptime:10

Необязательные атрибуты медиа-потока. В данном случае одним из таких атрибутов является кодек (G729)

Описание сеанса для одновременной передачи голоса и видео может выглядеть следующим образом:

v=0

o=alice 2890844526 2890844526 IN IP4 10.1.3.33

c=IN IP4 10.1.3.33

t=0 0

m=audio 49172 RTP/AVP 0

a=rtpmap:0 PCMU/8000

m=video 51172 RTP/AVP 31 34

a=rtpmap:31 H.261/90000

a=rtpmap:34 H.263/90000

Обратите внимание: первые четыре строки являются описанием уровня сеанса, а строки a= – описаниями уровня медиа-носителя. При этом каждая новая m-строка обозначает начало нового медиа-потока.

Использование SDP в SIP

Основным документом, нормирующим использование SDP в SIP, является RFC 3264. Упомянем его основные положения:

  • Вызывающий абонент включает SDP-описание в запросы INVITE или ACK. Вызываемый абонент обязан включить SDP-описание в тело отклика «200 OK» или промежуточных откликов 180/183. В общем случае SDP-описания могут содержаться также и в запросах UPDATE (RFC 3311) и надёжных промежуточных ответах PRACK (RFC 3262). Модель взаимодействия (описываемая как offer/answer-модель) предусматривает возможности как подтверждения SDP-описания, предложенного другой стороной, так и отказа от него, что не нарушает целостность сеанса.
  • Модель взаимодействия налагает жёсткие ограничения на использование и изменение потоков. В частности, новые потоки могут порождаться в новых запросах, но потоки не могут удаляться. Это вызвано тем, что нет средства определения потоков по их наименованию, а их однозначная идентификация возможна только порядковым номером в пределах описания. С другой стороны, поток может замещаться другим потоком с тем же порядковым номером. RFC явно рекомендует связывать потоки с их применением, а не с форматом данных или другими параметрами.
  • Принимающая сторона, если она приняла описание потоков в виде SDP, должна использовать тот же состав потоков. Есть и другие ограничения.

Протоколы 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

Рисунок 1. Место RTP в стеке протоколов TCP/IP

Функции RTP

Протокол RTP предусматривает такие функции:

  • Идентификация отправителя – каждый RTP-пакет содержит идентификатор отправителя, указывающий, кто из участников генерирует данные.
  • Идентификация типа полезной нагрузки – специальное поле идентифицирует формат трафика RTP и определяет его интерпретацию приложением. Типы полезной нагрузки RTP приведены в таблице 2.

Таблица 2. Типы полезной нагрузки аудио и видео в RTP

Идентификатор типа

Кодек

Частота дискретизации, Гц

Описание

0

PCMU

8000

ITU G.711 PCM µ-Law Audio 64 Kbps

1

1016

8000

CELP Audio 4.8 Kbps

2

G721

8000

ITU G721 ADPCM Audio 32 Kbps

3

GSM

8000

European GSM Audio 13 Kbps

5

DVI4

8000

DVI ADPCM Audio 32 Kbps

6

DVI4

16000

DVI ADPCM 64 Kbps

7

LPC

8000

Experimental LPC Audio

8

PCMA

8000

ITU G.711 PCM A-Law Audio 64 Kbps

9

G722

8000

ITU G.722 Audio

10

L16

44100

Linear 16-bit Audio 705.6 Kbps

11

L16

44100

Linear 16-bit Stereo Audio 1411.2 Kbps

14

MPA

90000

MPEG-I or MPEG-II Audio Only

15

G728

8000

ITU G.728 Audio 16 Kbps

25

CELB

90000

CelB Video

26

JBEG

90000

JBEG Video

28

NV

90000

nv Video

31

H261

90000

ITU H.261 Video

32

MPV

90000

MPEG-I and MPEG-II Video

33

MP2T

90000

MPEG-II transport stream Video

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

Замечу, что 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 содержат стандартное текстовое описание отправителя. Это даёт пользователю возможность идентифицировать потоки, относящиеся к различным сеансам.
  • Оценка размеров сеанса. Для обеспечения обратной связи все участники конференции периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников. При небольшом числе участников один пакет RTCP посылается максимум каждые 5 секунд.

Чтобы обеспечить выполнение всех этих функций, участники сеанса обмениваются специальными управляющими сообщениями протокола 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

Рисунок 2. Трёхсторонняя конференция через агента Bob

Перевод на удержание вызова осуществляется отправкой удерживающим пользовательским агентом сообщения re-INVITE (напомню, что от простого INVITE его отличает наличие тега в поле To и возросший порядковый номер в CSeq), запрашивающего в SDP переключение режима передачи медиа-потока из режима одновременной отправки и приёма «sendrecv» на режим отправки «sendonly». В «200 OK» от второй стороны будет соответственно «recvonly» (только приём).

После установления сессии #2 первые два пользовательских агента проводят ещё один цикл пересогласования для перехода в режим «sendrecv».

С этого момента конференцию можно считать установленной.

Параллельный вызов

Следующей расширенной услугой SIP-телефонии, на которой мы остановимся, является «параллельный вызов» (Call Forking). Суть заключается в том, что прокси-сервер «размножает» входящий INVITE на несколько пользовательских агентов (см. рис. 3).

Рисунок 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. Перевод вызова

Рисунок 4. Перевод вызова

Ниже показано содержимое сообщений REFER и следующего за ним INVITE (здесь и далее заголовки с интересующей нас информацией выделены красным цветом):

REFER sip:alice@atlanta.com SIP/2.0

Via: SIP/2.0/UDP swp34.biloxi.com;branch=z9hG4bKna9

Max-Forwards: 70

To: <sip:alice@atlanta.com>;tag=a6c85cf

From: <sip:bob@biloxi.com>;tag=1928301774

Call-ID: a84b4c76e66710@pc33.atlanta.com

CSeq: 10187 REFER

Allow: INVITE, ACK, CANCEL, OPTIONS,

BYE, REFER, NOTIFY, UPDATE

Supported: replaces

Refer-To: <sip:carol@chicago.com>

Contact: <sip:bob@swp34.biloxi.com>

Content-Length: 0

 

INVITE sip:carol@chicago.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9VHJ23J41

Max-Forwards: 70

To: <sip:carol@chicago.com>

From: <sip:alice@atlanta.com>;tag=0616052ue

Call-ID: a84b4c76p0lk234@pc33.atlanta.com

CSeq: 6187 INVITE

Contact: <sip:bob@swp34.biloxi.com>

Content-Length: 147

Информация о присутствии

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

Данный механизм реализуется с помощью сервера присутствия (Presence Server). Физически он обычно совмещён с сервером регистрации или одним из других элементов сети SIP.

Служба присутствия включает два различных набора клиентов. Один набор клиентов, называемых presentities (например, производители информации), предоставляет информацию о присутствии, которая распределяется и сохраняется. Другой набор клиентов, именуемых watchers (например, потребители информации), получает данные о присутствии от соответствующей службы. При реализации эти клиенты обычно объединяются, однако обсуждаются отдельно.

Метод SUBSCRIBE (RFC 3265) используется для того, чтобы запросить асинхронное уведомление о наступлении события или группы событий на удалённом узле. В запросе присутствует заголовок Expires, обозначающий длительность подписки на уведомления. Запросы должны иметь только одно значение в заголовке Event, т.е. подписку запрашивать можно только на одно событие за один раз. Собственно уведомление подписчика об изменениях в состоянии, на которые тот подписан, происходит при помощи запроса NOTIFY (также RFC 3265).

Рисунок 5. Услуга присутствия

Рисунок 5. Услуга присутствия

На рис. 5 показан процесс подписки на информацию о регистрации. Рассмотрим вид запросов SUBSCRIBE и NOTIFY:

SUBSCRIBE sip:alice@atlanta.com SIP/2.0

Via: SIP/2.0/TCP app_IM.atlanta.com;branch=z9hG4bKnashds7

From: sip:app_IM.atlanta.com ;tag=123aa9

To: sip:alice@atlanta.com

Call-ID: 9987@app_IM.atlanta.com

CSeq: 9887 SUBSCRIBE

Contact: sip:app_IM.atlanta.com

Event: reg

Max-Forwards: 70

Expires: 21600

Accept: application/reginfo+xml

Ответы 2xx на запрос SUBSCRIBE показывают, что подписка принята и что запрос NOTIFY будет отправлен немедленно при наступлении события. Заголовок же Event запроса NOTIFY должен совпадать с заголовком Event из SUBSCRIBE.

NOTIFY sip:app_IM.atlanta.com SIP/2.0

Via: SIP/2.0/TCP server1.atlanta.com;branch=z9hG4bKnasaii

From: sip:alice@atlanta.com ;tag=xyzygg

To: sip:app_IM.atlanta.com ;tag=123aa9

Max-Forwards: 70

Call-ID: 9987@app_IM.atlanta.com

CSeq: 1288 NOTIFY

Contact: sip:server19.atlanta.com

Event: reg

 

Content-Type: application/reginfo+xml

Content-Length: 223

<?xml version="1.0"?>

<reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full">

<registration aor="sip:alice@atlanta.com" id="a7" state="init" />

</reginfo>

В базовой для SIP рекомендации RFC 3261 определено 6 типов запросов: REGISTER, INVITE, ACK, CANCEL, BYE и OPTIONS. Ниже мы рассмотрим OPTIONS и остановимся на некоторых других методах SIP, применяемых при реализации дополнительных услуг.

Другие методы SIP

Метод OPTIONS даёт возможность узнать у UA, какие кодеки, методы, типы контента, расширения им поддерживаются, а также известные агенту контакты, ещё до попытки установления диалога. Рассмотрим пример такого взаимодействия.

OPTIONS sip:bob@192.168.10.20 SIP/2.0

Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK77i832k9 ;received=10.1.3.33

Max-Forwards: 70

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e6Kr456@pc33.atlanta.com

CSeq: 22756 OPTIONS

Contact: <sip:alice@pc33.atlanta.com>

Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, SUBSCRIBE, NOTIFY, MESSAGE, UPDATE

Accept: application/sdp, application/pidf-xml

Content-Length: 0

Целевой UA отвечает на запрос OPTIONS так, как бы он ответил на INVITE (откликом класса 2хх), но с включением вышеупомянутой информации в заголовки Allow, Accept, Accept-Encoding, Accept-Language, Supported и (когда речь идёт о списке кодеков) SDP-часть. Тело SDP здесь не показано для экономии места:

SIP/2.0 200 OK

Via: SIP/2.0/TCP sip:alice@atlanta.com;branch=z9hG4bK77i832k9;received=10.1.3.33

To: Bob <sip:bob@biloxi.com>; tag=a6c85e3

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e6Kr456@pc33.atlanta.com

CSeq: 22756 OPTIONS

Contact: <sip:bob@biloxi.com>

Contact: <sip:bob_home@biloxi.com>

Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, MESSAGE

Accept: application/sdp, text/plain, image/jpeg

Accept-language: en, fr

Content-Type: application/sdp

Content-Length: 274

Метод 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. Типы кодеков и их параметры

Методы компрессии

Стандарт ITU

Полоса, Кбит/с

Оценка MOS

Величина кадра, мс

PCM

G.711

64 (DS0)

4.1

0.75

ADPCM

G.726

32

3.85

1

LD-CELP

G.728

16

3.61

3-5

CS-ACELP

G.729

8

3.9

10

CS-ACELP

G.729a

8

3.85

10

MP-MLQ / ACELP

G.723.1

6.3/5.3

3.8/3.75

10

В таблице 3 представлены типы кодеков и их параметры. Естественно, что большое значение имеет экономия полосы, но кроме этого необходимо помнить о качестве голоса. В таблице также представлен параметр средней экспертной оценки (Mean Opinion Score, MOS), который определяет среднюю оценку качества голоса, полученную экспертным путем. Наивысший балл – 5, низший балл – 1, при этом:

  • баллы 4-5 показывают эталон качества, так называемое, toll-quality;
  • баллы 3-4 – уровень приемлемого коммуникационного качества;
  • баллы ниже 3 – это синтетическое качество.

Параметр 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 байт. Его принцип действия основывается на том факте, что многие поля заголовков в передаваемых пакетах повторяются от пакета к пакету.

  1. RFC 4566 – SDP: Session Description Protocol.
  2. RFC 3264 – An Offer/Answer Model with SDP.
  3. RFC 3550 – RTP: A Transport Protocol for Real-Time Applications.
  4. RFC 3551 – RTP Profile for Audio and Video Conferences with Minimal Control.
  5. RFC 3611 – RTP Control Protocol Extended Reports (RTCP XR).
  6. RFC 3311 – SIP UPDATE Method.
  7. RFC 3515 – SIP Refer Method.
  8. RFC 2976 – The SIP INFO Method.
  9. RFC 3265 – SIP-Specific Event Notification.
  10. RFC 3428 – SIP Extension for Instant Messaging.
  11. Погребенник А. «Всё, что вы хотели знать о протоколе SIP. Часть 1». //Системный администратор, №5, 2007 г. – С. 78-86.

Комментарии отсутствуют

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

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru