Интернет сети и услуги

Рис.13. Кодеки семейства Н.323.

Основой О.723 является метод сжатия речи MP-MLQ (Multipulse Maximum Likelihood Quantization). Он позволяет добиться весьма существенного сжатия речи при сохранении достаточно высокого качества звучания. В основе метода лежит описанная выше процедура оптимизации; с помощью различных усовершенствований можно сжимать речь до уровня 4,8; 6,4; 7,2 и 8,0 кбит/с. Структура алгоритма позволяет на основе программного обеспечения изменять степень сжатия голоса в ходе передачи. Вносимая кодированием задержка не превышает 20 мс. Повышая эффективность использования полосы пропускания, механизмы сжатия речи в то же время могут привести к ухудшению ее качества и увеличению задержек. Далее рассмотрены некоторые основные кодеки, используемые в шлюзах IP. телефонии операторского уровня.

Кодек G.711

Рекомендация G.711, утвержденная МККТТ в 1984 г., описывает кодек, использующий ИКМ преобразование аналогового сигнала с точностью 8 бит, тактовой частотой 8 кГц и простейшей компрессией амплитуды сигнала. Скорость потока данных на выходе преобразователя составляет 64 кбит/с (8 битх8 кГц). Для снижения шума квантования и улучшении преобразования сигналов с небольшой амплитудой при кодировании используется нелинейное квантование по уровню согласно специальному псевдо-логарифмическому закону: А-закон для европейской системы ИКМ-30/32 или - закон для североамериканской системы ИКМ-24.

Первые ИКМ кодеки с нелинейным квантованием появились уже в 60-х годах. Кодеки G.711 широко распространен в системах традиционной телефонии с коммутацией каналов, Несмотря на то, что рекомендация G.711 в стандарте Н.323 является основной и первичной, в шлюзах IP-телефонии данный кодек применяется редко из-за высоких требований к полосе пропускания и задержкам в канале передачи. Использование G.711 в системах IP-телефонии обосновано лишь в тех случаях, когда требуется обеспечить максимальное качество кодирования речевой информации при небольшом числе одновременных разговоров. Одним из примеров применения кодека G.711 могут послужить IP- телефоны компании Cisco.

Кодек G.726

Один из старейших алгоритмов сжатия речи ADPCM -- адаптивная дифференциальная ИКМ (стандарт G.726 был принят в 1984 г.). Этот алгоритм дает практически такое же качество воспроизведения речи, как и ИКМ, однако для передачи информации при его использовании требуется полоса всего в 16-32 кбит/с. Метод основан на том, что в аналоговом сигнал передающем речь, невозможны резкие скачки интенсивности. Поэтому, если кодировать не саму амплитуду сигнала, а ее изменение по сравнению с предыдущим значением, то можно обойтись меньшим числом разрядов. В ADPCM изменение уровня сигнала кодируется четырехразрядным числом, при этом частота измерения амплитуды сигнала сохраняется неизменной. Процесс преобразования не вносит существенной задержки и требует от DSP 5,5- 6,4 MIPS (Million Instructions Per Second). Кодек может применяться совместно с кодеком G.711 для снижения скорости кодирования последнего. Кодек предназначен для использования в системах видеоконференций.

Кодек G.723.1

Рекомендация G.723.1 описывает гибридные кодеки, использующие технологию кодирования речевой информации, сокращенно называемую -- MP-MLQ (Multy-Pulse -- Multy Level quantization -- множественная импульсная, многоуровневая квантизация), данные кодеки можно охарактеризовать, как комбинацию АЦП/ЦАП и вокодера. Своим возникновением гибридные кодеки обязаны системам мобильной связи. Применение вокодера позволяет снизить скорость передачи данных в канале, что принципиально важно для эффективного использования радиотракта и IP-канала. Основной принцип работы вокодера -- синтез исходного речевого сигнала посредством адаптивной замены его гармонических составляющих соответствующим набором частотных фонем и согласованными шумовыми коэффициентами. Кодек О.723 осуществляет преобразование аналогового сигнала в поток данных со скоростью 64 кбит/с (ИКМ), а затем при помощи многополосного цифрового фильтра/вокодера выделяет частотные фонемы, анализирует их и передает по IP-каналу информацию только о текущем состоянии фонем в речевом сигнале. Данный алгоритм преобразования позволяет снизить скорость кодированной информации до 5,3-6,3 кбит/с без видимого ухудшения качества речи. Кодек имеет две скорости и два варианта кодирования: 6,3 кбит/с с алгоритмом MP-MLQ и 5,3 кбит/с с алгоритмом CELP. Первый вариант предназначен для сетей с пакетной передачей голоса и обеспечивает лучшее качество кодирования по сравнению с вариантом CELP, но менее адаптирован к использованию в сетях со смешанным типом трафика (голос/данные).

Процесс преобразования требует от DSP 16,4-16,7 MIPS и вносит задержку 37 мс. Кодек G.723.1 широко применяется в голосовых шлюзах и прочих устройствах IP-телефонии. Кодек уступает по качеству кодирования речи кодеку G.729а, но менее требователен к ресурсам процессора и пропускной способности канала.

Кодеки G.729

Семейство включает кодеки G.729, G.729 Аппех А, G.729 Аппех В (содержит VAD , и генератор комфортного шума). Кодеки G.729 сокращенно называют CS-ACELP Conjugate Structure -- Algebraic Code Excited Linear Prediction -- сопряженная структура с управляемым алгебраическим кодом линейным предсказанием. Процесс преобразования "использует DSP 21,5 MIPS и вносит задержку 15 мс. Скорость кодированного речевого сигнала составляет 8 кбит/с. В устройствах VoIP данный кодек занимает лидирующее положение, обеспечивая наилучшее качество кодирования речевой информации при достаточно высокой компрессии.

Кодек G.728

Гибридный кодек, описанный в рекомендации G.728 в 1992 г. относится к категории LD-CELP -- Low Delay -- Соде Excited Linear Prediction -- кодек с управляемым кодом линейным предсказанием и малой задержкой. Кодек обеспечивает скорость преобразована 16 кбит/с, вносит задержку при кодировании от 3 до 5 мс и для реализации необходим процессор с быстродействием более 40 MIPS. Кодек предназначен для использования, в основном, в системах видеоконференций. В устройствах IP-телефонии данный кодек применяется достаточно редко.



Практическая работа № 16

Протокол SIP

Цель работы

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

Задание

При подготовке к практическому занятию изучить вопросы: запросы протокола SIP, группы ответов протокола SIP, сценарии установления соединения между элементами сети SIP. Выполнить практическую часть. Ответить на контрольные вопросы.

Контрольные вопросы

1. С какими видами терминалов ТфОП может взаимодействовать сеть SIP?

2. Какие типы адресов используются в сети IP-телефонии на базе протокола SIP?

3. Каким образом стыкуется нумерация в ТфОП с адресацией в IP-сетях?

4. Что обеспечивают протоколы сигнализации?

5. На какие фазы делится процедура установления соединения?

6. Зачем нужен протокол SIP?

7. Основные принципы, положенные в основу протокола SIP, кто его стандартизировал?

8. Какое место занимает протокол SIP в стеке протоколов TCP/IP.

9. С помощью какого протокола терминалы обмениваются информацией о своих функциональных возможностях?

10. Перечислить основные элементы SIP-сети.

11. Какой тип адресации используется в протоколе SIP?

12. Перечислить типы SIP-адресов, что значат их элементы?

13. Описать принцип «клиент-сервер».

14. Какой формат сообщений и структуру имеют сообщения протокола SIP?

15. Какие существуют виды сообщений?

16. Каково назначение запросов протокола SIP?

17. Каково назначение ответов протокола SIP?

18. В чем разница двух сценариев установления соединения (с участием сервера переадресации и с участием прокси-сервера)?

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

20. Какое минимальное число сообщений необходимо для установления соединения?

Литература

1. А.В. Росляков, М.Ю. Самсонов, И.В. Шибаева. IP-телефония. ИТЦ Эко-Трендз. 2002.

2. Б.С. Гольштейн, А.В. Пинчук, А.Л. Суховицкий. IP-телефония. Москва. Радио и связь. 2003.

3. Материалы курса «IP-телефония» сайта Интранет ТУИТ http://www.teic.uz/dlnet

4. А.Б. Гольдштейн, В.В. Саморезов. Методические указания по проведению лабораторных работ и практических занятий по курсу «IP-телефония» для студентов, обучающихся специальности 2009 - Сети связи и системы коммутации. Санкт-Петербург. 2002

5. Мюнх Б., Скворцова С. Сигнализация в сетях IP-телефонии. - Часть I, II / Сети и системы связи, 1999. - №13(47), 14(48).

6. Садчикова С.А. IP-телефония. Учебное пособие для студентов специальностей 5А522202, 5А522203, 5А522205, 5А522216. ТУИТ. 2008.

Теоретические сведения

Вторым вариантом построения сетей стал протокол SIP, разработанный группой MMUSIC (Multiparty Multime-dia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543.

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

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

· Масштабируемость сети характеризуется, в первую очередь, возможностью увеличения количества элементов сети при ее расширении. Серверная структура сети, построенной на базе протокола SIP, в полной мере отвечает этому требованию.

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

· Интеграция в стек существующих протоколов Интернет. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF).

· Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323. Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП - DSS1 и ОКС7. Для упрощения такого взаимодействия сигнальные сообщения протокола SIP могут переносить не только специфический SIP-адрес, но и телефонный номер формата Е.164 или любого другого формата. Кроме того, протокол SIP, наравне с протоколами Н.323 и ISUP/IP, может применяться для синхронизации работы устройств управления шлюзами, в этом случае он должен взаимодействовать с протоколом MGCP. Другой важной особенностью протокола SIP является то, что он приспособлен к организации доступа пользователей сетей IP-телефонии к услугам интеллектуальных сетей, и существует мнение, что именно этот протокол станет основным при организации связи между указанными сетями.

Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов - URL (Universal Resource Locators), так называемые SIP URL

SIP-адреса бывают четырех типов:

* имя@домен;

* имя@хост,

* имя@IР-адрес;

* №телефона@шлюз.

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

Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP-адреса устройства необходимо обратиться к службе доменных имен - Domain Name Service (DNS). Если же во второй части SIP-адреса размещается IP-адрес, то с рабочей станцией можно связаться напрямую.

В начале SIP-адреса ставится слово «sip:», указывающее, что это именно SIP-адрес, т.к. бывают и другие (например, «mailto:»). Ниже приводятся примеры SIP-адресов:

sip: student@sk.niis.uz

sip: userTUIT@192.168.100.152

sip: 294-75-47@gateway.ru

Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF). Эта архитектура включает в себя также протокол резервирования ресурсов (Resource Reservation Protocol - RSVP), транспортный протокол реального времени (Real-Time Transport Protocol - RTP), протокол передачи потоковой информации в реальном времени (Real-Time Streaming Protocol - RTSP), протокол описания параметров связи (Session Description Protocol -SDP). Однако функции протокола SIP не зависят ни от одного из этих протоколов.

Одной из важнейших особенностей протокола SIP является его независимость от транспортных технологий. В качестве транспорта могут использоваться протоколы Х.25, Frame Relay, AAL5, IPX и др. Структура сообщений SIP не зависит от выбранной транспортной технологии. Но в то же время предпочтение отдается технологии маршрутизации пакетов IP и протоколу UDP.

Здесь же следует отметить, что сигнальные сообщения могут переноситься не только протоколом транспортного уровня UDP, но и протоколом ТСР. По сети с маршрутизацией пакетов IP может передаваться пользовательская информация практически любого вида: речь, видео и данные, а также любая их комбинация, называемая мультимедийной информацией. При организации связи между терминалами пользователей необходимо известить встречную сторону, какого рода информация может приниматься (передаваться), алгоритм ее кодирования и адрес, на который ее следует передавать. Таким образом, одним из обязательных условий организации связи при помощи протокола SIP является обмен между предполагаемыми участниками этой связи данными об их функциональных возможностях. Для этой цели чаще всего используется протокол описания сеансов связи SDP (Session Description Protocol). В течение сеанса связи может производиться его модификация, поэтому предусмотрена передача средствами SDP сообщений SIP с новыми описаниями сеанса.

Протокол инициирования сеансов связи ( SIP )	Прикладной уровень
Протоколы TCP и UDP	Транспортный уровень
Протоколы IPv4 и IPv6	Сетевой уровень
PPP,AAL5. ATM, Ethernet, V.34.	Уровень звена данных
UTP5, ВОЛС и др.	Физический уровень

Рис. 1. Место протокола SIP в стеке протоколов TCP/IP

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

Для передачи речевой информации комитет IETF предлагает использовать протокол RTP, но сам протокол SIP не исключает возможность применения для этих целей других протоколов.

Протокол SIP предусматривает организацию конференций трех видов:

· в режиме многоадресной рассылки (multicasting), когда информация передается на один multicast-адрес, а затем доставляется сетью конечным адресатам;

· при помощи устройства управления конференции (MCU), к которому участники конференции передают информацию в режиме точка-точка, а оно, в свою очередь, обрабатывает ее (т.е. смешивает или коммутирует) и рассылает участникам конференции;

· путем соединения каждого пользователя с каждым в режиме точка-точка.

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

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

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

Рис.2. Схема "клиент-сервер"

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

Таким образом сеть SIP содержит основные элементы трех видов: агенты пользователя, прокси-серверы и серверы переадресации.

Рис. 3 Архитектура SIP сети

Агенты пользователя (User Agent или SIP client) являются приложениями терминального оборудования и включают в себя две составляющие: агент пользователя - клиент (User Agent Client - UAC) и агент пользователя - сервер (User Agent Server - UAS), иначе известные как клиент и сервер соответственно. Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и возвращает ответы, т.е. выступает в качестве вызываемой стороны.

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

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

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

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

Предусмотрено режима работы прокси-серверов - с сохранением состояний (stateful) и без сохранения состояний (stateless).

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

Сервер первого типа позволяет предоставить большее количество услуг, но работает медленнее, чем сервер второго типа.

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

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

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

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

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

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

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

Сеть SIP содержит пользователей (правильно сказать UAS), прокси-серверы и серверы переадресации. Перед началом сеанса связи вызывающий пользователь должен знать либо адрес вызываемого пользователя, либо адрес SIP-сервера. Адрес может быть в виде 'user@domain', тогда необходимо преобразовать его в IP-адрес с помощью услуг DNS.

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

Сценарий установления соединения через сервер переадресации

Вызывающему пользователю требуется вызвать другого пользователя. Он передает запрос INVITE (1) на известный ему адрес сервера переадресации и на порт 5060, используемый по умолчанию. В запросе вызывающий пользователь указывает адрес вызываемого пользователя. Сервер переадресации запрашивает текущий адрес нужного пользователя у сервера определения местоположения (2), который сообщает ему этот адрес (3). Сервер переадресации в своем ответе 302 Moved temporarily передает вызывающей стороне текущий адрес вызываемого пользователя (4), или сообщает список зарегистрированных адресов вызываемого пользователя, предлагая вызывающему самому выбрать один из них. Вызывающая сторона подтверждает прием ответа 302 передачей сообщения ACK (5).

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

Вызываемая сторона принимает запрос INVITE и начинает его обработку, о чем сообщает ответом 100 Trying (7) встречному оборудованию для перезапуска его таймеров. После завершения обработки поступившего запроса оборудование вызываемой стороны сообщает своему пользователю о входящем вызове, а встречной стороне передает ответ 180 Ringing (8). После приема вызываемым пользователем входящего вызова встречной стороне передается сообщение 200 ОК (9), в котором содержатся данные о функциональных возможностях вызываемого терминала в формате протокола SDP.

Терминал вызывающего пользователя подтверждает прием ответа запросом АСК (10). На этом фаза установления соединения заканчивается, и начинается разговорная фаза.

По завершении разговорной фазы любая из сторон передает запрос BYE (11), который подтверждается ответом 200 ОК (12).

Рис. 4. Сценарий установления соединения через сервер переадресации

Сценарий установления соединения через прокси-сервер

В этом случае действия 1-3 такие же, как и при использовании сервера

переадресации. После выяснения адреса (на сервере определения местоположения) прокси-сервер передает по этому адресу запрос INVITE (4). Вызываемый пользователь В оповещается акустическим или визуальным сигналом о том, что его вызывают (5); он поднимает трубку, и ответ 200 ОК отправляется к прокси-серверу (6). Прокси-сервер переправляет этот ответ вызвавшему пользователю А (7), последний подтверждает правильность приема, передавая запрос АСК (8), который переправляется к вызванному пользователю В (9). Соединение установлено, идет разговор. Вызванный пользователь В кладёт трубку, передается запрос BYE (10), прием которого подтверждается ответом 200 ОК (11).

Рис. 5. Сценарий установления соединения через прокси сервер

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

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

Запросы SIP

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

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

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

Запрос CANCEL отменяет обработку ранее переданных запросов с теми же, что и в запросе CANCEL, значениями полей Call-ID, To, From и CSeq, но не влияет на те запросы, обработка которых уже завершена. Например, запрос CANCEL применяется тогда, когда прокси-сервер размножает запросы для поиска пользователя по нескольким направлениям и в одном из них его находит. Обработку запросов, разосланных во всех остальных направлениях, сервер отменяет при помощи сообщения CANCEL.

Запросом BYE оборудование вызываемого или вызывающего пользователя завершает соединение. Сторона, получившая запрос BYE, должна прекратить передачу речевой (мультимедийной) информации и подтвердить его выполнение ответом 200 ОК.

При помощи запроса типа REGISTER пользователь сообщает свое текущее местоположение. В этом сообщении содержатся следующие поля:

· Поле То содержит адресную информацию, которую надо сохранить или модифицировать на сервере;

· Поле From содержит адрес инициатора регистрации. Зарегистрировать пользователя может либо он сам, либо другое лицо, например, секретарь может зарегистрировать своего начальника;

· Поле Contact содержит новый адрес пользователя, по которому должны передаваться все дальнейшие запросы INVITE. Если в запросе REGISTER поле Contact отсутствует, то регистрация остается прежней. В случае отмены регистрации здесь помещается символ <*>;

· В поле Expires указывается время в секундах, в течение которого регистрация действительна. Если данное поле отсутствует, то по умолчанию назначается время - 1 час, после чего регистрация отменяется. Регистрацию можно также отменить, передав сообщение REGISTER с полем Expires, которому присвоено значение О, и с соответствующим полем Contact.

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

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

· Для переноса сигнальных сообщений ТФОП/ISDN/сотовых сетей между шлюзами в течение разговорной сессии;

· Для переноса сигналов DTMF в течение разговорной сессии;

· Для переноса биллинговой информации.

Завершив описание запросов протокола SIР, рассмотрим, в качестве примера, типичный запрос типа INVITE (рис. 6).

INVITE sip: watson@boston.bell-tel.com SIP/2.0

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell

To: T. Watson

Call-ID: 3298420296@kton.bell-tel.com

Cseq: 1 INVITE

Content-Type: application/sdp

Content-Length: ...

v=0

o=bell 53655765 2353687637 IN IР4 12&.3.4.5

C=IN IP4 kton.bell-tel.com

m=audio 3456 RTP/AVP 0345

В этом примере пользователь Bell (a.g.bell@bell-tel.com) вызывает пользователя Watson (watson@bell-tel.com). Запрос передается к прокси-серверу (boston.bell-tel.com). В полях То и From перед адресом стоит запись, которую вызывающий пользователь желает вывести на дисплей вызываемого пользователя. В теле сообщения оборудование вызывающего пользователя указывает в формате протокола SDP, что оно может принимать в порту 3456 речевую информацию, упакованную в пакеты RTP и закодированную по одному из следующих алгоритмов кодирования: 0 - PCMU, 3 - GSM, 4 - G.723 и 5 - DVI4.

При передаче сообщений протокола SIP, упакованных в сигнальные сообщения протокола UDP, существует вероятность того, что размер запроса или ответа окажется больше максимально допустимого для данной сети, и произойдет фрагментация пакета. Чтобы избежать этого, используется сжатый формат имен основных заголовков, подобно тому, как это делается в протоколе SDP, Ниже приведен список таких заголовков (Таблица 3).

Таблица 1. Сжатые имена заголовков SIP

Сжатая форма имени Полная форма имени

c Content-Type

e Content- Encoding

f From

i Call-ID

m Contact ( от "moved")

l Content-Length

s Subject

t To

v Via

При написании имен заголовков в сжатом виде сообщение INVITE, показанное ранее на рисунке 6, будет выглядеть следующим образом (рис. 7):

INVITE sip: watson@boston.bell-tel.com SIP/2.0

v: SIP/2.0/UDP kton.bell-tel.com

f: A. Bell

t: T. Watson

i: 3298420296@kton.bell-tel.com

Cseq: 1 INVITE

с: application/sdp

l: ...

v=0

o=bell 53655765 2353687637 IN IP4 128.3.4.5

C=IN IP4 kton.bell-tel.com

m=audio 3456 RTP/AVP 0345

Таблица 2. Запросы SIP

Тип запроса	Описание запроса
INVITE	Приглашает пользователя к сеансу связи. Содержит SDP-описание сеанса
АСК	Подтверждает прием окончательного ответа на запрос INVITE
BYE	Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе
CANCEL	Отменяет обработку запросов с теми же заголовками Call-ID, То, From и CSeq, что и в самом запросе CANCEL
REGISTER	Переносит адресную информацию для регистрации пользователя на сервере определения местоположения
OPTION	Запрашивает информацию о функциональных возможностях терминала

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

После приема и интерпретации запроса, адресат (прокси-сервер) передает ответ на этот запрос. Содержание ответов бывает разным: подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях и т.д. Структуру ответов и их виды протокол SIP унаследовал от протокола HTTP.

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

Все ответы делятся на две группы: информационные и финальные. Информационные ответы показывают, что запрос находится в стадии обработки. Они кодируются трехзначным числом, начинающимся с единицы, - 1хх. Некоторые информационные ответы, например, 100 Trying, предназначены для установки на нуль таймеров, которые запускаются в оборудовании, передавшем запрос. Если к моменту срабатывания таймера ответ на запрос не получен, то считается, что этот запрос потерян и может (по усмотрению производителя) быть передан повторно. Один из распространенных ответов - 180 Ringing; по назначению он идентичен сигналу <Контроль посылки вызова> в ТфОП и означает, что вызываемый пользователь получает сигнал о входящем вызове.

Финальные ответы кодируются трехзначными числами, начинающимися с цифр 2, 3, 4, 5 и 6. Они означают завершение обработки запроса и содержат, когда это нужно, результат обработки запроса. Назначение финальных ответов каждого типа рассматривается ниже.

Ответы 2хх означают, что запрос был успешно обработан. В настоящее время из всех ответов типа 2хх определен лишь один -200 ОК. Его значение зависит от того, на какой запрос он отвечает:

· ответ 200 OK на запрос INVITE означает, что вызываемое оборудование согласно на участие в сеансе связи; в теле ответа указываются функциональные возможности этого оборудования;

· ответ 200 OK на запрос BYE означает завершение сеанса связи, в теле ответа никакой информации не содержится;

· ответ 200 OK на запрос CANCEL означает отмену поиска, в теле ответа никакой информации не содержится;

· ответ 200 OK на запрос REGISTER означает, что регистрация прошла успешно;

· ответ 200 OK на запрос OPTION служит для передачи сведений о функциональных возможностях оборудования, эти сведения содержатся в теле ответа.

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

· в ответе 300 Multiple Choices указывается несколько SIP-адресов, по которым можно найти вызываемого пользователя, и вызывающему пользователю предлагается выбрать один из них;

· ответ 301 Moved Permanently означает, что вызываемый пользователь больше не находится по адресу, указанному в запросе, и направлять запросы нужно на адрес, указанный в поле Contact;

· ответ 302 Moved Temporary означает, что пользователь временно (промежуток времени может быть указан в поле Expires) находится по другому адресу, который указывается в поле Contact.

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

· ответ 400 Bad Request означает, что запрос не понят из-за наличия в нем синтаксических ошибок;

· ответ 401 Unauthorized означает, что запрос требует проведения процедуры аутентификации пользователя. Существуют разные варианты аутентификации, и в ответе может быть указано, какой из них использовать в данном случае;

· ответ 403 Forbidden означает, что сервер понял запрос, но отказался его обслуживать. Повторный запрос посылать не следует. Причины могут быть разными, например, запросы с этого адреса не обслуживаются и т.д.;

· ответ 485 Ambiguous означает, что адрес в запросе не определяет вызываемого пользователя однозначно;

· ответ 486 Busy Here означает, что вызываемый пользователь в настоящий момент не может принять входящий вызов по данному адресу. Ответ не исключает возможности связаться с пользователем по другому адресу или, к примеру, оставить сообщение в речевом почтовом ящике.

Ответы 5хх информируют о том, что запрос не может быть обработан из-за отказа сервера:

· ответ 500 Server Internal Error означает, что сервер не имеет возможности обслужить запрос из-за внутренней ошибки. Клиент может попытаться повторно послать запрос через некоторое время;

· ответ 501 Not Implemented означает, что в сервере не реализованы функции, необходимые для обслуживания этого запроса. Ответ передается, например в том случае, когда сервер не может распознать тип запроса;

· ответ 502 Bad Gateway информирует о том, что сервер, функционирующий в качестве шлюза или прокси-сервера, принял некорректный ответ от сервера, к которому он направил запрос;

· ответ 503 Service Unavailable говорит от том, что сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.

Ответы 6хх информируют о том, что соединение с вызываемым пользователем установить невозможно:

· ответ 600 Busy Everywhere сообщает, что вызываемый пользователь занят и не может принять вызов в данный момент ни по одному из имеющихся у него адресов. Ответ может указывать время, подходящее для вызова пользователя;

· ответ 603 Decline означает, что вызываемый пользователь не может или не желает принять входящий вызов. В ответе может быть указано подходящее для вызова время;

· ответ 604 Does Not Exist Anywhere означает, что вызываемого пользователя не существует.

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

На рисунке 8 представлен пример ответа на запрос INVITE:

SIP/2.0 200 OK

Via: SIP/2.0/UDP kton.bell-tel.соm

From: A. Bell

To: ;

Call-ID: 3298420296@kfcon.bell-fcel.com Cseq: 1 INVITE

Content-Type: application/sdp Content-Length: ...

v=0

o=watson 4858949 4858949 IN IP4 192.1.2.3

t=3149329600 0

c=IN IP4 bostcon.bell-tel.com

m=audio 5004 RTP/AVP 0 3

a=rtpmap:0 PCMU/8000

a=rtpmap:3 GSM/8000

В этом примере приведен ответ пользователя Watson на приглашение принять участие в сеансе связи, полученное от пользователя Bell. Наиболее вероятный формат приглашения рассмотрен нами ранее (рис. 7). Вызываемая сторона информирует вызывающую о том, что она может принимать в порту 5004 речевую информацию, закодированную в соответствии с алгоритмами кодирования PCMU, GSM. Поля From, To, Via, Call-ID взяты из запроса, показанного на рисунке 7. Из примера видно, что это ответ на запрос INVITE с полем CSeq:1.

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



Таблица 3. Ответы на Запросы SIP

Код ответа	Пояснение	Назначение
100	Trying	Запрос обрабатывается, например, сервер обращается к базам данных, но местоположение вызываемого пользователя в настоящий момент не определено
180	Ringing	Местоположение вызываемого пользователя определено. Ему дается сигнал о входящем вызове
181	Call Is Being Forwarded	Прокси-сервер переадресует вызов к другому пользователю
182	Queued	Вызываемый пользователь временно не доступен, но входящий вызов поставлен в очередь. Когда вызываемый пользователь станет доступным, он передаст финальный ответ
200	OK	Команда успешно выполнена
300	Multiple Choices	Вызываемый пользователь доступен по нескольким адресам. Вызывающий пользователь может выбрать любой из них
301	Moved Permanently	Пользователь изменил свое местоположение, его новый адрес указан в поле Contact
302	Moved Temporarily	Пользователь временно изменил свое местоположение, его новый адрес указан в поле Contact
305	Use Proxy	Вызываемая сторона может принять входящий вызов только в том случае, когда он проходит через прокси-сервер. Вызывающей стороне рекомендуется обратиться к прокси-серверу, адрес которого указан в поле Contact. Ответ передается только терминальным оборудованием (UAS)
380	Alternative Service	Вызов не достиг адресата, но существует альтернативный вариант обслуживания, который указан в теле ответа. Например, вызов может быть переадресован к речевому почтовому ящику
400	Bad Bequest	В запросе обнаружена синтаксическая ошибка
401	Unauthorised	Требуется проведение процедуры авторизации пользователя
402	Payment Required	Требуется предварительная оплата услуг
403	Forbidden	Запрос не будет обслуживаться сервером и не должен передаваться повторно
404	Not Found	Сервер не обнаружил вызываемого пользователя в домене, указанном в поле Request-URI
405	Method Not Allowed	Не разрешается передавать запрос этого типа на адрес, указанный в поле Request-URI. В поле Allow ответа указываются разрешенные типы запросов
406	Not Acceptable	Ответы, генерируемые вызываемой стороной, не будут поняты вызывающей стороной
407	Proxy Authentication Required	Клиент должен подтвердить свое право доступа к прокси-серверу
408	Request Timeout	Сервер не может передать ответ, например, указать местоположение вызываемого пользователя, в течение промежутка времени, специфицированного в поле Expires запроса. Вызывающий пользователь может повторно передать запрос через некоторое время
409	Conflict	Обработка запроса REGISTER не может быть завершена из-за конфликта между действием, определенным в параметре action запроса, и текущим состоянием ресурсов
410	Gone	Сервер больше не имеет доступа к запрашиваемому ресурсу и не знает, куда переадресовать запрос
411	Length Required	Требуется указать длину тела сообщения в поле Content-Length
413	Request Entity Too Large	Размер запроса слишком велик для обработки
414	Request-URI Too Large	Адрес, указанный в поле Request-URI, оказался слишком большим, поэтому его интерпретация невозможна
415	Unsupported Media Type	Запрос содержит не поддерживаемый формат тела сообщения
420	Bad Extension	Сервер не понял расширение протокола, специфицированное в поле Require
480	Temporarily not available	Вызываемый пользователь временно недоступен
481	Call Beg/Transaction Does Not Exist	Посылается в ответ на получение запроса ВYЕ, не относящегося к текущим соединениям, или запроса CANCEL, не относящегося к текущим запросам
482	Loop Detected	Сервер обнаружил, что принятый им запрос передается по замкнутому маршруту (в поле Via уже имеется адрес этого сервера)
483	Too Many Hops	Сервер обнаружил в поле Via, что принятый им запрос прошел через большее количество прокси-сервером, чем разрешено в поле Max-Forwards
484	Address Incomplete	Сервер принял запрос с неполным адресом в поле То или Request-URI. Требуется дополнительная адресная информация
485	Ambiguous	Адрес вызываемого пользователя неоднозначен. В заголовке Contact ответа может содержаться список адресов, по которым этот запрос можно передать
486	Busy Here	В настоящий момент вызываемый пользователь не желает или не может принять вызов на этот адрес. Ответ не исключает возможности связаться с пользователем по другому адресу
500	Internal Server Error	Внутренняя ошибка сервера
501	Not Implemented	В сервере не реализованы функции, необходимые для обслуживания запроса. Ответ передается в том случае, когда сервер не может распознать тип полученного им запроса
502	Bad Gateway	Сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос
503	Service Unavailable	Сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания
504	Gateway Timeout	Сервер, функционирующий в качестве шлюза или прокси-сервера, в течение установленного интервала времени не получил ответ от сервера (например, от сервера определения местоположения), к которому он обратился для завершения обработки запроса
505	SIP Version not supported	Сервер не поддерживает данную версию протокола SIP
600	Busy Everywhere	Вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может указывать подходящее для вызова время
603	Decline	Вызываемый пользователь не может или не желает принимать входящие вызовы. В ответе может быть указано подходящее для вызова время
604	Does not exist anywhere	Вызываемого пользователя не существует
606	Not Acceptable	Вызываемый пользователь не может принять входящий вызов из-за того, что вид информации, указанный в описании сеанса связи в формате SDP, полоса пропускания и т.д. неприемлемы



Практическая работа № 17

ПРОЦЕСС ПРОВЕДЕНИЯ РЕГИСТРАЦИИ SIP ТЕРМИНАЛОВ

Цель работы

Изучить процесс проведения регистрации SIP терминалов с помощью программного обеспечения Netnumen U31.

Задание к работе

Изучить теоретический материал работы и праткически выполнить процесс проведения регистрации SIP терминалов с помощью программного обеспечения Netnumen U31.

Список литературы

1. Ломовицкий и др. Основы построения систем и сетей передачи информации. - М.: Горячая линия - Телеком, 2005.

2. Гольдштейн Б.С., Соколов Н.А., Яновский Г.Г.. Сети связи. Учебник для вузов. - СПб.: БХВ - Санкт­Петербург, 2009

3. Витченко А.И., Пинчук А.В., Соколов Н.А. Опыт создания NGN в ОАО "Ленсвязь". - Вестник связи, 2005, №10, с. 32 - 36.

4. Пинчук А.В., Соколов Н.А. Прагматическая стратегия перехода к NGN. - Вестник связи, 2006, №6, с. 66 - 72.

5. Шелухин О.И., Тепякшев A.M., Осин А.В. Фрактальные процессы в телекоммуникациях. -М.: Радиотехника, 2003.

Контрольные вопросы

1. Какой терминал называется SIP- терминалом.

2. Основные параметры и технические характеристики SIP- терминалов.

3. Как осуществляется процесс проведения регистрации SIP терминалов с помощью программного обеспечения Netnumen U31.

4. Назначение протокола SIP.

5. Основное оборудование протокола SIP.

Теоретические сведения

Вторым вариантом построения сетей стал протокол SIP, разработанный группой MMUSIC (Multiparty Multime-dia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543.

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

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

· Масштабируемость сети характеризуется, в первую очередь, возможностью увеличения количества элементов сети при ее расширении. Серверная структура сети, построенной на базе протокола SIP, в полной мере отвечает этому требованию.

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

· Интеграция в стек существующих протоколов Интернет. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF).

· Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323. Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП - DSS1 и ОКС7. Для упрощения такого взаимодействия сигнальные сообщения протокола SIP могут переносить не только специфический SIP-адрес, но и телефонный номер формата Е.164 или любого другого формата. Кроме того, протокол SIP, наравне с протоколами Н.323 и ISUP/IP, может применяться для синхронизации работы устройств управления шлюзами, в этом случае он должен взаимодействовать с протоколом MGCP. Другой важной особенностью протокола SIP является то, что он приспособлен к организации доступа пользователей сетей IP-телефонии к услугам интеллектуальных сетей, и существует мнение, что именно этот протокол станет основным при организации связи между указанными сетями.

Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов - URL (Universal Resource Locators), так называемые SIP URL

SIP-адреса бывают четырех типов:

* имя@домен;

* имя@хост,

* имя@IР-адрес;

* №телефона@шлюз.

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

Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP-адреса устройства необходимо обратиться к службе доменных имен - Domain Name Service (DNS). Если же во второй части SIP-адреса размещается IP-адрес, то с рабочей станцией можно связаться напрямую.

В начале SIP-адреса ставится слово «sip:», указывающее, что это именно SIP-адрес, т.к. бывают и другие (например, «mailto:»). Ниже приводятся примеры SIP-адресов:

sip: student@sk.niis.uz

sip: userTUIT@192.168.100.152

sip: 294-75-47@gateway.ru

Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF). Эта архитектура включает в себя также протокол резервирования ресурсов (Resource Reservation Protocol - RSVP), транспортный протокол реального времени (Real-Time Transport Protocol - RTP), протокол передачи потоковой информации в реальном времени (Real-Time Streaming Protocol - RTSP), протокол описания параметров связи (Session Description Protocol -SDP). Однако функции протокола SIP не зависят ни от одного из этих протоколов.

...