12
Архитектуру технологии VoIP можно представить в упрощенной
форме в виде двух плоскостей, где нижнюю плоскость составит базовая сеть
с марщрутизацией пакетов IР, а верхнюю плоскость образуют программные
средства регулирования обслуживания вызовов. Нижняя плоскость – это
некоторое сочетание координированных протоколов сети Интернет, а именно
RTP (Real Time Protocol), осуществляющего свою деятельность поверх
протокола UDP (User Datagram Protocol), который, в свою очередь, размещен
в стеке протоколов TCP/IP (Transport Control Protocol) над протоколом IР.
То есть можно заключить, что иерархия протоколов RTP/UDP/IP является
определенным транспортным механизмом для речевого трафика.
Важнейший аспект функционирования сети Интернет - Internet
Protocol (IP), который представляет собой протокол сетевого уровня,
гарантирующий маршрутизацию пакетов в сети. Однако данный пакет не
обеспечивает безошибочную доставку пакетов. Таким образом, пакеты могут
быть изменены, могут быть доставлены с задержкой по времени, могут
пересылаться по разнообразным маршрутам, то есть обладать различным
временем передачи и т.д. На базе IP функционируют протоколы
транспортного уровня Transport TCP и UDP.
Главное требование к пересылке командных данных заключается в
исключении ошибок передачи. Для достижения этой цели принципиально
важно применять аподиктический протокол доставки сообщений. Как
правило, в качестве такого протокола может применяться протокол TCP,
гарантирующий качественную доставку сообщений. В рассматриваемом
случае время доставки сообщений также является очень значимым.
Рассматриваемый параметр, к сожаленю, нельзя назвать стабильным,
поскольку при возникновении ошибок передачи сообщение пересылается
еще раз. Пересылка повторяется до тех пор, пока сообщение не будет
благополучно доставлено. Таким образом, продолжительность служебных
процедур способна бесконтрольно расти, что является абсолютно
недопустимым для многих этапов соединения, таких, например, как этап
13
установления соединения, а также для определенных процедур, связанных с
пересылкой по сети телефонной сигнализации. В настоящее время до сих
пор неразрешенной проблемой в этой области служит формирование
достоверного механизма передачи, который не только будет осуществлять
качественную и безошибочную доставку информации, но и сводить к
минимуму время доставки при возникновении ошибок передачи [12].
Фальсифицирование потока пакетов обусловлено загруженностью
сети. В отсутствии перегрузок подобные переиначивания крайне малы, а
зачастую и совсем отсутствуют. Поток речевых пакетов способен
существенным образом занимать сеть, в особенности при использовании
многоканальных систем. Подобная ситуация объясняется значительной
интенсивностью потока (кадры небольшого размера передаются через малые
промежутки времени 20байт/30мс) и существенным масштабом
пересылаемых служебных данных. Зная размеры заголовков сетевых
протоколов (IP - 20 байт, UDP - 8 байт, RTP - 12 байт), можно без
особого труда определить совокупный объем заголовка речевого пакета -
40 байт. Эта цифра вдвое превышает размер самого пакета. Пересылка
подобного объема служебных данных непозволительна, особенно, при
организации многоканальных систем. Таким образом, настоятельно
рекомендуется исследовать и использовать пути снижения объема
служебных данных, передаваемых по сети Интернет. В настоящее время
имеются два доступных способа урегулирования данного вопроса. Первый
способ предусматривает реализацию особых транспортных протоколов для
IP-телефонии, способных снизить заголовок протокола транспортного
уровня. Второй вариант заключается в мультиплексировании каналов в
многоканальных системах. В данной ситуации речевые пакеты от
различных каналов пересылаются под одним сетевым заголовком, что не
только снижает объем передаваемых служебных данных, но и уменьшает
интенсивность потока.
14
1.2. Стандарты IP-телефонии
В действующих сегодня сетях IP-телефонии нет единого стандарта,
регламентирующего передачу аудио- и видеотрафика. Существуют три
основных конкурирующих между собой семейства протоколов, реализующих
свой подход к построению IP-сети. Рассмотрим их более подробно.
1.2.1. Стандарт H.323
В 1996 году Международным союзом электросвязи TU (International
Telecommunication Union) принят первый и самый распространенный
протокол - набор рекомендаций мультимедийных приложений в
вычислительных сетях. Прародителем стандарта H.323 считается
спецификация H.320 и последовавшая серия H.32x, которая была разработана
задолго до появления IР-телефонии в 1990 г. Спецификации H.320 и H.32x
регламентировали в сетях SDN видеоконференцсвязь. Серия рекомендаций
H.32x, кроме H.320, включает стандарты для различных типов сетей, такие
как H.321 - H.324 [6].
Протокол H.323 на сегодняшний день это стандарт де-факто для
междугородной и международной телефонии, для регистрации терминалов
на гейткипере сигнализация по порту 1720 TCP и 1719 TCP.
В стандарте Н.323 сформулированы технические требования для
передачи видео- и аудиоданных, передаваемым по сетям передачи данных.
Данный протокол содержит следующие стандарты:
стандарты на видео кодеки;
стандарты на голосовые кодеки;
стандарты на общедоступные приложения;
стандарты на управление вызовами;
стандарты на управление системой.
15
Для обработки телефонных звонков не требуются стандарты на видео
кодеки, однако они существуют в этой системе стандартов.
В режиме реального времени возможна потеря или опоздание до 30%
пакетов при передаче (что в режиме реального времени одно и то же).
Данную потерю и нехватку пакетов должно возместить хорошее приложение
IP-телефонии посредством восстановления. На восстановление данных
влияет и сам алгоритм кодировки, а их сложность повышает стоимость
требуемого оборудования. Одним из самых распространенных алгоритмов
планирования считается G.723.1.
Кроме G.711 стандарт H.323 определяет звуковые кодеки G.722,
G.723,G.723.1, MPEG1, G.728, и G.729. Кодеры с низкой шириной полосы
частот - G.729 в 8 kbps и G.723 в 5.3/6.3 kbps - вполне подходят для
использования в Интернет. В частности, G.723 является одним из нескольких
«стандартных» кодеров для IP-телефонии, особенно после того, как ntel,
Microsoft и Netscape объявили о поддержке этого кодера.
1.2.2. Архитектура стандарта H.323
Стандарт H.323 определяет базовую архитектуру сети передачи
мультимедиаданных. На рисунке 2 изображена структура H.323-сети [6].
Рисунок 2 - Структура H.323-сети
G
ateke
H323
Termi
H323
Termi
M
H323
Termi
Шл
юз
Абон
ент
Абон
ент
Абон
ент
G
ateke
G
ateke
H323
16
Объекты стандарта H.323:
терминал (Terminal);
шлюз (Gateway);
гейткипер (gatekeeper, контроллер зоны, привратник, конференц-
менеджер);
устройство управления конференциями (Multipoint Control Unit -
MCU).
Конечное H.323-устройство пользователя может быть как
программным (приложение на компьютере), так и аппаратным (телефонный
аппарат). Терминалам могут назначаться один или несколько псевдонимов
(номера телефонов, названия). Терминал обязан обеспечивать звуковую
связь и может дополнительно поддерживать передачу видео или данных.
Вследствие того, что основной функцией терминала H.323 является передача
звука, он играет ключевую роль в предоставлении сервиса IP-телефонии.
H.323-терминал должен поддерживать протоколы:
H.245 - согласование параметров соединения;
Q.931 - для установления соединения и согласования параметров
этого соединения;
RAS (Registration/Admission/Status) - взаимодействия с
гейткипером;
RTP/RTCP - для работы с потоками аудио и видео пакетов;
семейство протоколов Н.450.
H.323-терминал также должен включать в себя аудиокодек G.711 для
сжатия аудиопотока. Его дополнительными компонентами могут быть
другие аудиокодеки и видеокодеки H.261 и/или H.263.
Аудиокодек предназначен для оцифровки аналогового звукового
сигнала и сжатия полученного цифрового сигнала, а также проведения
обратной операции. Стандартом H.323 предусмотрена возможность
использования пяти кодеков — G.711 (преобразование 3,1-кГц аналогового
17
сигнала для передачи в цифровой форме на скоростях 48, 56 или 64 кбит/с),
G.722 (7 кГц; 48, 56 или 64 кбит/с), G.723 (3,1 кГц; 5,3 или 6,3 кбит/с), G.728
(3,1 кГц; 16 кбит/с) и G.729 (3,1 кГц; 8 кбит/с). Каждый терминал должен
поддерживать по крайней мере один аудиокодек.
1.2.3. Стандарт SIP
SIP (Session nitiation Protocol - протокол управления сессиями)
является протоколом прикладного уровня, используется для создания,
изменения и разрыва «сессий» между одним или несколькими участниками.
Понятие «сессии» в протоколе SIP достаточно широкое. Под «сессией»
подразумеваются не только телефонные звонки, но и передача данных,
конференции, децентрализованные игры и т. д. [11]
В SIP за основу были взяты протоколы, применяемые в самых
популярных на сегодняшний день IP-сервисах, такие, как HTTP (Web) и
SMTP (обмен почтовыми сообщениями). Идейно SIP основан на том же
подходе, что HTTP: запрос - ответ (request - reply). Все сообщения SIP
текстовые, и их можно читать глазами, а коды возврата - такие же, как в
HTTP, поэтому некоторые из них покажутся хорошо знакомыми не только
сетевым администраторам, но и многим «продвинутым» пользователям
интернета (404 - абонент не найден, 200 – OK, 403 - ошибка авторизации).
Однако после апробирования протокола на реальных сетях и благодаря
интенсивному развитию этого направления первоначальная версия
претерпела ряд изменений. Часть требований к реализациям, построенным по
обновлённой версии протокола SIP, не поддерживает обратной
совместимости с реализациями, выполненными по изначальной версии. В
связи с этим могут возникнуть сложности при попытке установления
взаимодействия между устройствами, выполненным по разным версиям
рекомендаций.
SIP регламентирует только процедуру установки соединения между
устройствами, поэтому обычно наряду с SIP используется протокол передачи
18
информации. В случае IP-телефонии в качестве таких протоколов выступают
RTP и SDP (session description protocol - протокол описания сеанса)
Ключевые возможности протокола SIP:
персональная мобильность пользователей. Пользователи могут
перемещаться без ограничений в пределах сети, поэтому услуги связи
должны предоставляться им в любом месте этой сети;
масштабируемость сети. Она характеризуется возможностью
увеличения количества элементов сети при её расширении;
открытость и простота. Так, разговор по протоколу SIP свободно
дополняется передачей данных от одного абонента другому, например,
электронной визитки, цифровых фотографий или даже файла MP;
возможность реакции на события. Так, клиент может
«подписаться» на определенное событие (например, обновление статуса
пользователя), и как только оно наступит, сервер вышлет соответствующее
обновление;
расширяемость протокола характеризуется возможностью
дополнения протокола новыми функциями при введении новых услуг и его
адаптации к работе с различными приложениями;
взаимодействие с другими протоколами сигнализации. Протокол
SIP может быть использован совместно с протоколом Н.323. Возможно также
взаимодействие протокола SIP с системами сигнализации ТфОП - DSS1 и
ОКС7. Кроме того, протокол SIP, наравне с протоколами H.323 и SUP/IP,
может применяться для синхронизации работы устройств управления
шлюзами; в этом случае он должен взаимодействовать с протоколом MGCP.
Клиенты SIP-сети идентифицируются по универсальным
идентификаторам SIP-URL (Universal Resource Locators)
SIP-адреса бывают четырех типов [11]:
имя@домен;
имя@хост;
19
имя@IР-адрес;
№телефона@шлюз.
Адрес состоит из двух частей. Первая часть – это имя пользователя,
зарегистрированного в домене или на рабочей станции. Если вторая часть
адреса идентифицирует какой-либо шлюз, то в первой указывается
телефонный номер абонента.
Во второй части адреса указывается имя домена, рабочей станции или
шлюза. Для определения IP-адреса устройства необходимо обратиться к
службе доменных имен - Domain Name Service (DNS). Если же во второй
части IP-адреса размещается IP-адрес, то с рабочей станцией можно
связаться напрямую.
В начале SIP-адреса ставится слово «sip:», указывающее, что это
именно SIP-адрес. Приведём несколько примеров SIP-адресов:
sip: romadanov@.alex.samlist.ru;
sip: user@183.158.100.152;
sip: 555-44-33@gateway.ru.
1.2.4. Архитектура стандарта SIP
Стандарт SIP выделяет следующие типы объектов сети:
агенты;
прокси-серверы;
серверы регистрации;
серверы перенаправления.
Под агентами подразумеваются конечные устройства пользователя
(телефоны, программные телефоны, мобильные телефоны, шлюзы в ТФОП,
системы голосовых меню и т. д.)
Выделим в составе агентов две логические составляющие: агент-клиент
(UAC) и агент-сервер (UAS) (рисунок 3) [11]:
UAC (user agent client) - посылает запросы и получает ответы;
20
UAS (user agent server) - принимает запросы и посылает ответы.
Рисунок 3 - Взаимодействие UAC и UAS
Большинство устройств используется как для перечи, так и для
приёма данных, в реальных устройствах присутствует как UAC, так и UAS.
Неотъемлемой частью SIP-сети являются прокси-серверы, отвечающие
за маршрутизацию сообщений, а также аутентификацию и авторизацию
пользователей. В стандарте определяется два типа SIP-прокси-серверов:
без учета состояния (stateless). Такие серверы не отслеживают
состояния SIP-сессий и передают сообщения, используя внутренние правила
маршрутизации. Их основное применение - распределение нагрузки и
маршрутизация. Примером SIP-прокси-сервера без учёта состояния является
SER (SIP Express Router);
с учетом состояния (stateful). Эти серверы отслеживают состояние
каждой SIP-сессии от момента ее создания до завершения. Могут
использоваться для более интеллектуальной маршрутизации
(перенаправление вызовов, голосовая почта, дополнительная обработка
вызовов и т. д.), могут самостоятельно повторно пересылать пакеты (в случае
если они были потеряны при передаче). Платой за дополнительные
возможности является более сложная реализация и большие требования в
вычислительной мощности сервера (из-за необходимости хранить
информацию о каждой SIP-сессии). На рисунке 4 изображена схема сети, в
которой запросы передаются через SIP-прокси-сервер [11].
bye
Абонент А
UAC
UAS
Абонент В
UAS
UAC
invite
21
Рисунок 4 - Схема использования SIP-прокси-сервера
В протоколе SIP определены два вида сигнальных сообщений – запрос
и ответ. Они имеют текстовый формат, что дает SIP некоторые
преимущества, например, если устройству неизвестен тип заголовка, такое
сообщение пропускается, что не может позволить себе сеть на основе H.323,
где сообщения имеют бинарную форму и все устройства жестко
стандартизированы. В запросах указываются процедуры, вызываемые для
выполнения требуемых операций, а в ответах результаты их выполнения.
1.2.5. Протоколы MGCP и MEGACO
Протокол MGCP появился в октябре 1999 года в результате
объединения двух протоколов - SGCP (Simple Gateway Control Protocol)
и PDC (Internet Protocol for Device Control), за созданием которых
стояли компании Bellcore, Cisco Systems и Level 3. Отметим интересный
факт, TU и ETF, развивающие свои протоколы - H.323 и SIP,
плодотворно сотрудничая в работе над MGCP, создали протоколы
MEGACO (в рамках ETF) и H.248 (в рамках TU). У Cisco Systems так
же есть своя реализации MGCP-подобного протокола – SSCP (Skinny
Station Control Protocol).
Протокол регулирования работы шлюзов MGCP (Media Gateway
1
2
3
4
5
6
7
8
9
0
*
#
1
2
3
4
5
6
7
8
9
0
*
#
1
2
3
4
5
6
7
8
9
0
*
#
1
2
3
4
5
6
7
8
9
0
*
#
A1
A2
A3
A4
Sip-
сервер
invite
Sip-
сервер
B.com
1
2
3
4
5
6
7
8
9
0
*
#
B1
1
2
3
4
5
6
7
8
9
0
*
#
B2
1
2
3
4
5
6
7
8
9
0
*
#
B3
invite
invite