К какой плоскости архитектуры voip относится протокол mgcp
Короткая, но богатая событиями история развития IP-телефонии привела к тому, что сегодня в реальных сетях VoIP сосуществуют и конкурируют между собой три основных семейства протоколов - H.323, SIP и MGCP. Протоколы всех трех перечисленных семейств регламентируют управление мультимедиа-вызовами и передачу медиа-трафика в IP-сетях, но при этом реализуют три различных подхода к построению систем телефонной сигнализации. Попробуем разобраться, почему сложилась такая ситуация, что представляют собой эти протоколы и каковы перспективы развития каждого из них.
Набор рекомендаций Н.323
Исторически первый и самый распространенный в настоящее время - это введенный Международным союзом электросвязи (МСЭ) набор рекомендаций Н.323 (для простоты будем называть его протоколом). Н.323 стал плодом деятельности разработчиков протоколов мультимедийной связи в сетях ISDN (H.320). Соответствующие работы велись еще c начала 90-х годов, когда никакой IP-телефонии и в помине не было. Первая версия этого протокола была принята МСЭ в 1996 г. и по сути была попыткой перенести телефонную сигнализацию ISDN Q.931 на IP-соединения, т. е. как бы "наложить" традиционную телефонию на сети передачи данных. Рекомендации H.323 достаточно подробно описывают способы организации мультимедийных конференций, охватывая сервисы передачи голоса, видео и компьютерных данных в пакетных сетях с негарантированной доставкой. К настоящему времени принята уже четвертая версия этого набора рекомендаций. К основным компонентам набора относятся описанные ниже протоколы.
RAS (Registration, Admission, Status) - отвечает за регистрацию устройств в сети, контроль доступа к ресурсам, контроль полосы пропускания, необходимой для сеанса связи, и контроль состояния устройств в сети. Работает по протоколу UDP.
H.245 - отвечает за обмен информацией, необходимой для согласования параметров логических каналов для передачи медиа-потоков, т. е. собственно голоса или видео. Сюда входит, к примеру, согласование кодеков, номеров UDP-портов и т. д. Обмен происходит по протоколу TCP.
H.450.x (появившийся в четвертой версии H.323) - отвечает за обеспечение таких дополнительных или интеллектуальных функций, как Hold, Transfer и т. д.
Архитектура H.323 (рис. 1) весьма проста и состоит всего из четырех функциональных компонентов, ни один из которых не является обязательным.
Рис. 1. Архитектура Н.323. |
Терминал (H.323 Terminal) - абонентское устройство, способное обеспечивать связь (голосовую, видео- и т. д.) с другими терминалами, шлюзами или устройствами многопользовательских конференций.
Шлюз (H.323 Gateway) - центральное понятие сегодняшней IP-телефонии. Данное устройство обеспечивает взаимное сопряжение телефонной сети с IP-сетью. При этом предоставляется поддержка разных протоколов и интерфейсов сетей обоих типов. Если выход в телефонную сеть не требуется, то данный компонент не нужен, а терминалы могут связываться друг с другом напрямую.
Привратник (H.323 Gatekeeper, GK) - управляющий элемент, "интеллект" H.323 сети, обеспечивающий ее масштабируемость, централизацию управления и настроек, а также трансляцию телефонных префиксов и идентификаторов (H.323 ID) в IP-адреса шлюзов или H.323 терминалов. Кроме того, привратник отвечает за управление доступом (Admission Сontrol) при регистрации шлюзов и терминалов, авторизацию звонков (Call Admission Control), управление полосой пропускания и маршрутизацию вызовов. Привратник управляет подчиненной ему частью сети (зоной) через RAS - протокол общения шлюзов с ним. Предусмотрено объединение привратников в группы, управлять которыми можно с помощью выделенного привратника - Directory Gatekeeper.
Устройство многопользовательских конференций (H.323 Multipoint Conference Unit, MCU) - управляет проведением многопользовательских конференций, согласует параметры соединения всех участников в режиме централизованной, децентрализованной или комбинированной конференции. Возможно переключение или смешивание медиа-потоков.
В наиболее общей форме сценарий соединения по протоколу H.323 выглядит как ряд последовательных шагов (рис. 2). Вначале для установления соединения терминал обнаруживает привратника и регистрируется у него по протоколу RAS. Затем происходит установление сигнального канала по протоколам RAS и H.225. На следующем этапе выполняется согласование параметров оборудования, обмен информацией о его функциональных возможностях и открытие логических каналов по протоколу H.245. Только после этого происходит передача медиа-трафика по протоколам RTP/RTCP, а по ее окончании - завершение соединения.
Рис. 2. Сценарий соединения по протоколу H.323. |
Протокол SIP
Следующий по распространенности протокол IP-телефонии называется SIP (Session Initiation Protocol); он описан в рекомендациях RFC 2543. SIP регламентирует установление и завершение мультимедийных сессий - сеансов связи, в ходе которых пользователи могут говорить друг с другом, обмениваться видеоматериалами и текстом, совместно работать над приложениями и т. д. SIP и сопутствующие ему протоколы родились и развиваются в рамках IETF - главного органа стандартизации Интернета. Первая версия протокола SIP была принята в марте 1999 г., на три года позже, чем H.323, но благодаря интенсивному развитию этого направления сегодня набор рекомендаций RFC (базовых официальных документов IETF), имеющих отношение к SIP-архитектуре, насчитывает десятки, если не сотни документов.
Архитектура SIP (рис. 3) также очень проста и состоит из нескольких необязательных компонентов.
Рис. 3. Архитектура SIP. |
Клиент SIP (SIP user agent) - может быть представлен как устройством (IP-телефон, шлюз или другой пользовательский терминал), так и программным приложением для ПК, PDA и т. д. Обычно SIP-клиент содержит и клиентскую, и серверную часть (User Agent Client, или UAC, и User Agent Server, или UAS). Основные функции данного компонента - инициирование и завершение вызовов.
Прокси-сервер SIP - управляет маршрутизацией вызовов и работой приложения. Прокси-сервер не может инициировать или терминировать вызовы.
Redirect-сервер SIP - перенаправляет звонки согласно заданным условиям.
Сервер регистрации SIP (registrar/location) - осуществляет регистрацию пользователей и ведет базу соответствия имен пользователей их адресам, телефонным номерам и т. д.
Еще один важный компонент реальных SIP-сетей, хотя и не входящий формально в архитектуру SIP, - Back-to-Back User Agent (B2BUA). Это своеобразный сервер, представляющий собой два соединенных друг с другом SIP-клиента и поэтому способный инициировать и завершать вызовы.
Из этих компонентов, как из функциональных "кирпичиков", можно строить сети VoIP любой топологии, сложности и масштаба, вплоть до сетей, полностью замещающих функции современных АТС. Можно также создавать совершенно новые сервисы - интеграцию Интернет- и бизнес-приложений, программируемые службы, многоадресный поиск абонента, мультимедийные сервисы, уведомления о событиях и т. д.
Рис. 4. Сценарий соединения по протоколу SIP. |
Этот сценарий очень прост, в нем не участвуют никакие другие серверы (Redirection, Registrar, Location), но он дает представление о схеме взаимодействия функциональных элементов SIP-сети.
Протокол MGCP
Последний из рассматриваемых протоколов IP-телефонии - MGCP (Media Gateway Control Protocol). Точнее, речь здесь идет не об одном протоколе, а о целой группе - SGCP, IPDC, MGCP, MEGACO, H.248. Эти спецификации не только очень схожи концептуально, но и являются "близкими родственниками".
История формирования MGCP началась с создания двух протоколов - SGCP (Simple Gateway Control Protocol, разработка Bellcore и Cisco Systems) и IPDC (Internet Protocol for Device Control, разрабатывался компанией Level 3 при участии многих производителей). Затем SGCP и IPDC были объединены в один протокол, получивший название MGCP. В дальнейшем эволюция MGCP привела к появлению протоколов MEGACO (в рамках IETF) и H.248 (в рамках МСЭ).
Первая версия протокола MGCP (RFC 2705) датирована октябрем 1999 г. Интересно отметить, что MGCP - единственный из трех описываемых здесь протоколов, в работе над которым IETF и МСЭ сотрудничают; именно в результате этого взаимодействия и были созданы протоколы MEGACO и H.248. В то же время существуют и другие реализации MGCP-подобных протоколов, например, фирменный протокол Cisco Systems SSCP (Skinny Station Control Protocol), с помощью которого УАТС Cisco Call Manager управляет IP-телефонами.
Основная идея MGCP очень проста. Она состоит в том, что управление сигнализацией (Call Control) сосредоточено на центральном управляющем устройстве, называемом контроллером сигнализаций (Call Agent, CA), и полностью отделено от медиа-потоков (bearer). Эти потоки обрабатываются "тупыми" шлюзами или абонентскими терминалами, которые способны исполнять лишь ограниченный набор команд, исходящих от управляющего устройства. Архитектура протокола MGCP-сети также очень проста (рис. 5), в ней выделяются всего два функциональных компонента. Первый может быть представлен шлюзом (Media Gateway, MG) или IP-телефоном, а второй - устройством управления вызовами, которое может называться контроллером сигнализаций (CA), контроллером шлюза (Media Gateway Controller, MGC) или программным контроллером (Softswitch, SS). Иногда контроллер сигнализаций представляют в виде двух компонентов - собственно контроллера (Call Agent), выполняющего функции управления шлюзами, и шлюза сигнализации (Signaling Gateway), обеспечивающего обмен сигнальной информацией и согласование между традиционной телефонной сетью и сетью IP.
Рис. 5. Архитектура MGCP. |
Контроллеры обмениваются со шлюзами (или IP-телефонами) данными в простом текстовом формате (в случае H.248 возможен и бинарный обмен), а функциональное назначение каждого шлюза определяется набором команд, которые он "понимает". Манипулируя наборами команд, можно получать специализированные шлюзы: транковые (Trunking gateways, TGW), абонентские (Residential gateways, RGW), шлюзы доступа (Access gateways, AGW) и т. д.
Рис. 6. Сценарий соединения по протоколу МGCP. |
Резюме
Сравнивая "биографические данные" и функциональные особенности трех видов протоколов (см. таблицу), мы видим, что их различия обусловлены историческими причинами, в частности, изменениями представлений о пути развития телекоммуникаций в разное время. При этом H.323 - это технологически устоявшийся, широко распространенный протокол IP-телефонии для операторских сетей и межоператорского обмена, можно сказать, "транзитный" протокол. В свою очередь, SIP - протокол предоставления расширенных голосовых услуг в IP-сетях, который продолжает быстро развиваться, иначе говоря, "абонентский" протокол. Что касается MGCP, то он ориентирован прежде всего на организацию больших операторских узлов сопряжения IP-сетей с ТфОП и сетями SS7.
Сравнение протоколов VoIP-сети
Эволюция H.323 позволяет предположить, что будущее развитие IP-телефонии связано не столько с замещением традиционной телефонии, сколько с появлением новых сервисов, которые невозможны в рамках обычной телефонной сети. Однако создавать такие сервисы, используя лишь семейство протоколов H.323, достаточно сложно по сравнению, например, с Интернет-сервисами. Сам процесс разработки на базе H.323, доступный только "телефонным гуру", подчиняется традиционным канонам мира обычной телефонии.
Поэтому весьма вероятно, что протокол SIP, гораздо более понятный и удобный для инженеров-сетевиков и программистов, через некоторое время превратится в протокол некоей новой службы, функции которой далеко выходят за пределы передачи голоса по пакетным сетям. Термин "IP-коммуникации" сейчас можно услышать все чаще. Отличие IP-коммуникаций от телефонии (в том числе от сегодняшней IP-телефонии) как раз и будет состоять в обилии сервисов, о возможности которых мы пока просто не догадываемся.
Как сложится судьба представителей семейства MGCP, пока сказать трудно. Эти протоколы, очевидно, будут востребованы на протяжении переходного периода - от сетей с коммутацией каналов и TDM-сетей к сетям пакетной коммутации (точнее, к IP-сетям). В первую очередь такая востребованность обусловлена возможностью прозрачной интеграции телефонных сетей (особенно SS7) с сетями IP-телефонии. Но дальнейшая перспектива развития протоколов семейства MGCP будет зависеть от того, по какому пути пойдет процесс конвергенции телекоммуникаций - по "интернетному", подразумевающему равноправие сетевых узлов, наличие "умных клиентов" и инновационных сервисов, или по "телефонному", с жесткой иерархией, при которой новые сервисы вводятся только централизованно, и неписаным правилом: чем "тупее" клиент, тем проще жить оператору.
Но в любом случае нас ожидает довольно долгий переходный период, в течение которого и Н.323, и SIP, и MGCP, и какие-то новые, еще не родившиеся протоколы будут сосуществовать в реальных операторских и корпоративных сетях. Практика их использования может меняться со временем, и мы обязательно увидим много интересного и неожиданного на телекоммуникационной сцене в ближайшие годы.
Другие статьи из раздела
Chloride
Демонстрация Chloride Trinergy
Впервые в России компания Chloride Rus провела демонстрацию системы бесперебойного электропитания Chloride Trinergy®, а также ИБП Chloride 80-NET™, NXC и NX для своих партнеров и заказчиков.
NEC Нева Коммуникационные Системы
Завершена реорганизация двух дочерних предприятий NEC Corporation в России
С 1 декабря 2010 года Генеральным директором ЗАО «NEC Нева Коммуникационные Системы» назначен Раймонд Армес, занимавший ранее пост Президента Shyam …
компания «Гротек»
С 17 по 19 ноября 2010 в Москве, в КВЦ «Сокольники», состоялась VII Международная выставка InfoSecurity Russia. StorageExpo. Documation’2010.
Новейшие решения защиты информации, хранения данных и документооборота и защиты персональных данных представили 104 организации. 4 019 руководителей …
Adaptec by PMC
RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша
Опытные сетевые администраторы знают, что задействование в работе кэш-памяти RAID-контроллера дает серьезные преимущества в производительности …
Chloride
Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy
Trinergy — новое решение на рынке ИБП, впервые с динамическим режимом работы, масштабируемостью до 9.6 МВт и КПД до 99%. Уникальное сочетание …
Архитектура технологии Voice over IP может быть упрощенно представлена в виде двух плоскостей. Нижняя плоскость – это базовая сеть с маршрутизацией пакетов IP, верхняя плоскость – это открытая архитектура управления обслуживанием вызовов (запросов связи).
Нижняя плоскость представляет собой комбинацию известных протоколов Интернет: это – RTP (Real Time Transport Protocol), который функционирует поверх протокола UDP (User Datagram Protocol), расположенного, в свою очередь, в стеке протоколов TCP/IP над протоколом IP. Таким образом, иерархия RTP/UDP/IP представляет собой своего рода транспортный механизм для речевого трафика. Отметим, что в сетях с маршрутизацией пакетов IP для передачи данных всегда предусматриваются механизмы повторной передачи пакетов в случае их потери. При передаче информации в реальном времени использование таких механизмов только ухудшит ситуацию, поэтому для передачи информации, чувствительной к задержкам, но менее чувствительной к потерям, такой как речь и видеоинформация, используется механизм негарантированной доставки информации RTP/UDP/IP.
В сетях IP потеря пакетов – обычное и вполне нормальное явление. Фактически протокол управления передачей (TCP) был изначально спроектирован с учетом потери пакетов при передаче. Если пакет теряется в сети TCP/IP, он передается повторно. Во многих приложениях реального масштаба времени повторная передача пакетов является скорее недостатком, в связи с их чувствительностью к времени получения информации.
Рекомендации ITU-Т допускают задержки в одном направлении не превышающие 150 мс. В сети VoIP Cisco односторонняя задержка может составлять 120 мс (задержку от 65мс до 85 мс вносят два шлюза VoIP, при использовании кодека G.729). Если приемная станция запросит повторную передачу пакета IP, то задержка при этом будет слишком велика и произойдет прерывание диалога.
Верхняя плоскость управления обслуживанием запросов связи. Предусматривает принятие решений о том, куда вызов должен быть направлен, и каким образом должно быть установлено соединение между абонентами. Инструмент такого управления – телефонные системы сигнализации, начиная с систем, поддерживаемых декадно-шаговыми АТС и предусматривающих объединение функций маршрутизации и функций создания коммутируемого разговорного канала в одних и тех же декадно-шаговых искателях. Далее принципы сигнализации эволюционировали к системам сигнализации по выделенным сигнальным каналам, к многочастотной сигнализации, к протоколам общеканальной сигнализации №7 и к передаче функций маршрутизации в соответствующие узлы обработки услуг Интеллектуальной сети.
В сетях с коммутацией пакетов ситуация более сложна. Сеть с маршрутизацией пакетов IP принципиально поддерживает одновременно целый ряд разнообразных протоколов маршрутизации и сигнализации.
Наиболее распространенным является протокол, специфицированный в рекомендации Н.323 ITU-T, который стал применяться раньше других протоколов.
Другой протокол плоскости управления обслуживанием вызова – SIP – ориентирован на то, чтобы сделать оконечные устройства и шлюзы более интеллектуальными и поддерживать дополнительные услуги для пользователей.
Протокол – SGCP – разрабатывался, для того, чтобы уменьшить стоимость шлюзов за счет реализации функций интеллектуальной обработки вызова в централизованном оборудовании. В конце 1998 года рабочая группа MEGACO комитета IETF разработала протокол MGCP, базирующийся, в основном, на протоколе SGCP.
Рабочая группа MEGACO не остановилась на достигнутом, продолжала совершенствовать протокол управления шлюзами и разработала более функциональный, чем MGCP, протокол MEGACO/H.248. Его адаптированный к Н.323 вариант (под названием Gateway Control Protocol) ITU-T предлагает в рекомендации Н.248.
Третий подход к построению сетей IP-телефонии, основанный на использовании протокола MGCP [56], также предложен комитетом IETF, рабочей группой MEGACO.
При разработке этого протокола рабочая группа MEGACO опиралась на сетевую архитектуру, содержащую основные функциональные блоки трех видов (рис. 1.12):
• шлюз - Media Gateway (MG), который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью передачи, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP (кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование);
• контроллер шлюзов - Call Agent, которой выполняет функции управления шлюзами;
• шлюз сигнализации - Signaling Gateway (SG), который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к контроллеру шлюзов и перенос сигнальной информации в обратном направлении.
Рис. 1.12 Архитектура сети на базе протокола MGCP
Таким образом, весь интеллект функционально распределенного шлюза сосредоточен в контроллере, функции которого могут быть распределены между несколькими компьютерными платформами.
Шлюз сигнализации выполняет функции STP-транзитного пункта сети сигнализации ОКС7. Сами шлюзы выполняют только функции преобразования речевой информации. Один контроллер управляет одновременно несколькими шлюзами. В сети могут присутствовать несколько контроллеров. Предполагается, что они синхронизованы между собой и согласованно управляют шлюзами, участвующими в соединении.
Рабочая группа SIGTRAN предлагает использовать для передачи сигнальной информации протокол Stream Control Transport Protocol (SCTP), имеющий ряд преимуществ перед протоколом ТСР, основным из которых является значительное снижение времени доставки сигнальной информации и, следовательно, времени установления соединения - одного из важнейших параметров качества обслуживания.
Если в ТфОП используется сигнализация по выделенным сигнальным каналам (ВСК), то сигналы сначала поступают вместе с пользовательской информацией в транспортный шлюз, а затем передаются в контроллер шлюзов без посредничества шлюза сигнализации.
Отметим, что протокол MGCP является внутренним протоколом для обмена информацией между функциональными блоками распределенного шлюза, который извне представляется одним шлюзом. Протокол MGCP является master/slave протоколом. Это означает, что контроллер шлюзов является ведущим, а сам шлюз – ведомым устройством, которое должно выполнять все команды, поступающие от контроллера Call Agent.
Вышеописанное решение обеспечивает масштабируемость сети и простоту управления сетью через контроллер шлюзов. Шлюзы не должны быть интеллектуальными устройствами, требуют меньшей производительности процессоров и, следовательно, становятся менее дорогими. Кроме того, очень быстро вводятся новые протоколы сигнализации или дополнительные услуги, так как эти изменения затрагивают только контроллер шлюзов, а не сами шлюзы.
Третий подход, предлагаемый IETF (рабочая группа MEGACO), хорошо подходит для развертывания глобальных сетей IP-телефонии, приходящих на смену традиционным телефонным сетям. Рабочая группа MEGACO комитета IETF продолжает работу по усовершенствованию протокола управления шлюзами, в рамках которой разработан более функциональный, чем MGCP, протокол MEGACO.
Международный союз электросвязи в проекте версии 4 рекомендации Н.323 ввел принцип декомпозиции шлюзов. Управление функциональными блоками распределенного шлюза будет осуществляться контроллером шлюза - Media Gateway Controller - при помощи адаптированного к Н.323 протокола MEGACO, который в рекомендации Н.248 назван Gateway Control Protocol.
Технология Voice over IP (VoIP), называемая также IP-телефонией, предусматривает взаимодействие сети TDM с коммутацией каналов и сети IP с коммутацией пакетов, а также обеспечивает эволюционное движение телекоммуникационных сетей TDM к сетям IP. Появившись немногим более десяти лет назад, она считается самой перспективной телекоммуникационной технологией, обеспечивающей внедрение такого оборудования как IP телефоны, IP-АТС и т.п., а группу протоколов VoIP можно без преувеличения назвать ключевой среди других телекоммуникационных протоколов.
Согласно принятому определению, IP-телефония - это передача речевого сигнала по сети с пакетной коммутацией в режиме реального времени. При этом телефонный номер преобразуется в IP-адрес, а аналоговый речевой сигнал - в цифровую форму.
Годом рождения Internet-телефонии считают 1995-й, когда компания Vocaltec опубликовала программное обеспечение Internet Phone для системы телефонной передачи с использованием протокола IP. Для сетевой реализации Internet Phone до середины 1990-х были доступны только телефонные модемы, поэтому передача речи посредством Internet Phone значительно уступала по качеству традиционной телефонной связи. Однако первый камень в основание здания VoIP был тем не менее заложен.
Между тем события стали развиваться столь стремительно, что сейчас реальные возможности технологии VoIP значительно шире ее формального названия. По существу эта технология представляет собой средство для передачи не только речи, но и произвольной информации с использованием протокола IP, а обобщающим термином стало определение «мультимедийная». Соответствующая структура данных может включать речь, изображение и данные в любых комбинациях. Эту триаду обычно называют Triple Play.
Архитектура сети VoIP может быть представлена в виде двух плоскостей. Нижняя отображает транспортный механизм негарантированной доставки мультимедийного трафика в виде иерархии протоколов RTP/UDP/IP, а верхняя - механизм управления обслуживанием вызовов. Ее ключевыми протоколами являются H.323 ITU-T, SIP, MGCP и MEGACO, представляющие собой различные реализации обслуживания вызовов в сетях IP-телефонии.
Транспортный протокол реального времени (Real-time Transport Protocol, RTP) предоставляет транспортные услуги мультимедийным приложениям. Он не гарантирует доставку и правильный порядок пакетов, но позволяет приложениям обнаружить потерю или нарушение порядка следования пакетов за счет присвоения каждому из них номера. Протокол предназначен для работы в режимах передачи «точка–точка» или «точка–множество точек» и не зависит от транспортного механизма. Однако в качестве такового обычно используется протокол UDP.
RTP работает совместно с протоколом управления реального времени (Real Time Control Protocol, RTСP), обеспечивающим управление потоком данных и контроль перегрузки канала. Участники сеанса RTP периодически обмениваются пакетами RTCP со статистическими данными (количество отправленных пакетов, число потерянных и т. д.), которые могут быть использованы отправителем мультимедиа, например, для динамической коррекции скорости передачи и даже изменения типа нагрузки.
Среди мультимедийных стандартов наиболее освоен стандарт H.323 ITU-T, к тому же он постоянно совершенствуется и имеет пять версий. Рекомендация H.323, исторически первый способ осуществления вызовов в сети IP, предусматривает следующие виды информационного обмена:
- «цифровизованное» аудио;
- «цифровизованное» видео;
- данные (обмен файлами или изображениями);
- управление соединением (обмен информацией о поддерживаемых функциях, управление логическими каналами и т. д.);
- управление установлением и разъединением соединений и сеансов связи.
Основными элементами сети стандарта H.323 являются терминалы (terminal), шлюзы (gateway), привратники (gatekeeper) и устройства управления конференциями (Multipoint Control Units, MCU).
Терминал обеспечивает двухстороннюю связь в реальном времени с другим терминалом H.323, шлюзом или MCU.
Шлюзы устанавливают соединение между терминалами сети H.323 и терминалами, находящимися в сетях, где используются другие протоколы. Главная задача шлюзов заключается во взаимном преобразовании информации между сетями разных протоколов (например, IP и ТфОП).
Привратники участвуют в управлении соединением, отвечая за взаимное преобразование телефонных номеров и IP-адресов.
Еще один элемент сети H.323, называемый proxy-сервером (т. е. посредником), работает на прикладном уровне, он определяет тип приложения и выполняет нужное соединение.
Рекомендация H.245 описывает процедуры управления информационными каналами: определение ведущего и ведомого устройств, а также обмен данными о функциональных возможностях терминалов и открытии и закрытии однонаправленных и двунаправленных каналов, вносимой задержке, режиме обработки информации, состоянии информационных каналов путем организации шлейфов.
Второй способ обслуживания вызовов в сети VoIP предполагает использование протокола инициирования сеансов (Session Initiation Protocol, SIP), его спецификации представлены в документе RFC 2543 комитета IETF. Как протокол прикладного уровня, он предназначен для организации мультимедийных конференций, распределения мультимедийной информации и телефонных соединений. SIP менее приспособлен для взаимодействия с ТфОП, но проще в реализации. Он лучше подходит провайдерам Internet для организации услуги IP-телефонии в рамках предлагаемого ими пакета услуг.
Ключевыми особенностями протокола SIP являются поддержка персональной мобильности пользователя, обеспечение масштабируемости сети, возможность дополнения новыми функциями, интеграция в стек существующих протоколов Internet, взаимодействие с другими протоколами сигнализации (например, H.323), организация доступа пользователей сетей VoIP к услугам интеллектуальных сетей, независимость от транспортных технологий.
Следует отметить, что поддержка мобильности пользователя уже не является прерогативой исключительно SIP. Теперь это характерно и для Н.323 (см. H.510 ITU-T «Mobility for H.323 Multimedia Systems and Services»).
Сеть SIP содержит агенты пользователя (User Agents или SIP Сlients), proxy-серверы и серверы переадресации.
Агенты пользователя - это приложения терминального оборудования, они включают собственно клиент (User Agent Сlient, UAC) и сервер (User Agent Server, UAS). UAC инициирует запрос услуги, а UAS выступает в качестве вызывающей стороны.
Proxy-сервер (Proxy Server) объединяет в себе функции UAC и UAS. Он интерпретирует и, если надо, перезаписывает заголовки запросов перед отправкой их другим серверам.
Сервер переадресации (Redirect Server) определяет положение вызываемого абонента и сообщает его вызывающему пользователю.
Третий способ построения сети IP-телефонии опирается на протокол Media Gateway Control Protocol (MGCP), предложенный рабочей группой MEGACO комитета IETF. Архитектура этого протокола, пожалуй, наиболее проста с точки зрения функциональности. Сеть MGCP содержит шлюз (Media Gateway, MG), выполняющий преобразование речевой информации между сетями ТфОП и IP-телефонии, шлюз сигнализации (Signaling Gateway, SG), обеспечивающий обработку сигнальной информации, а также схожий с привратником сети H.323 контроллер шлюзов (Call Agent), осуществляющий функции управления шлюзами.
Четвертый способ построения сети IP, представляющий собой усовершенствование MGCP, разработан группой MEGACO комитета IETF вместе с 16 SG ITU-T, поэтому его называют протоколом MEGACO/H.248. От своего старшего брата он отличается прежде всего иной схемой организации связи. Благодаря ей контроллер MEGACO/H.248 способен изменять топологию связи портов, что позволяет гибко управлять конференциями. Протокол MEGACO поддерживает два способа бинарного кодирования.
Если в один прекрасный день вам придется на скорую руку разобраться, что есть VoIP (voice over IP) и что значат все эти дикие аббревиатуры, надеюсь, эта методичка поможет. Сразу замечу, что вопросы конфигурирования дополнительных видов обслуживания телефонии (такие как перевод вызова, голосовая почта, конференц-связь и т.п.) здесь не рассматриваются.
- Базовые понятия телефонии: типы аппаратов, схемы подключения
- Связка SIP/SDP/RTP-протоколов: как это работает
- Как передается информации о нажатых кнопках
- Как происходит передача голоса и факсов
- Цифровая обработка сигналов и обеспечение качества звука в IP-телефонии
1. Базовые понятия телефонии
В общем виде схема подключения локального абонента к телефонному провайдеру по обычной телефонной линии выглядит следующим образом:
На стороне провайдера (АТС) установлен телефонный модуль с портом FXS (Foreign eXchange Subscriber). Дома или в офисе установлен телефон или факс с портом FXO (Foreign eXchange Office) и модуль номеронабирателя.
По внешнему виду порты FXS и FXO никак не отличаются, это обычные 6-выводные RJ11-разъемы. Но с помощью вольтметра отличить их очень просто — на FXS-порте всегда будет какое-то напряжение: 48/60 В, когда трубка положена, или 6–15 В во время разговора. На FXO, если он не подключен к линии, напряжение всегда 0.
Для передачи данных по телефонной линии на стороне провайдера нужна дополнительная логика, которую можно реализовать на модуле SLIC (subscriber line interface circuit), а на стороне абонента — с помощью модуля DAA (Direct Access Arrangement).
Сейчас довольно популярны беспроводные DECT-телефоны (Digital European Cordless Telecommunications). По устройству они аналогичны обычным телефонным аппаратам: в них тоже есть FXO-порт и модуль номеронабирателя, но еще добавлен модуль беспроводной связи станции и трубки на частоте 1,9 ГГц.
Абоненты подключаются к PSTN-сети (Public Switched Telephone Network) — телефонной сети общего пользования, она же ТСОП, ТфОП. PSTN-сеть может быть организована с использованием разных технологий: ISDN, оптики, POTS, Ethernet. Частный случай PSTN, когда используется обычная аналоговая/медная линия — POTS (Plain Old Telephone Service) — простая старая телефонная система.
С развитием Интернета телефонная связь перешла на новый уровень. Стационарные телефонные аппараты все реже используются, в основном по служебным нуждам. DECT-телефоны немного удобнее, но ограничены периметром дома. GSM-телефоны еще удобнее, но ограничены пределами страны (роуминг — дело дорогое). А вот для IP-телефонов, они же cофтфоны (SoftPhone), никаких ограничений, кроме доступа к интернету, нет.
Skype — самый известный пример софтфона. Он может много чего, но имеет два важных недостатка: закрытая архитектура и прослушка известно какими органами. Из-за первого нет возможности создать свою телефонную микросеть. А из-за второго — не очень приятно, когда за вами подсматривают, особенно при личных и коммерческих разговорах.
К счастью есть открытые протоколы для создания своих коммуникационных сетей с плюшками — это SIP и H.323. Софтфонов на SIP-протоколе несколько больше чем на H.323, что можно объяснить его сравнительной простотой и гибкостью. Но иногда эта гибкость может вставлять большие палки в колёса. Оба протокола SIP и H.323 используют RTP-протокол для передачи медиаданных.
Рассмотрим базовые принципы протокола SIP, чтобы разобраться, как происходит соединения двух абонентов.
2. Описание связки SIP/SDP/RTP-протоколов
SIP (Session Initiation Protocol) — протокол установления сессии (не только телефонной) — это текстовый протокол поверх UDP. Также есть возможность использовать SIP поверх TCP, но это редкие случаи.
SDP (Session Description Protocol) — протокол согласования типа передаваемых данных (для звука и видео это кодеки и их форматы, для факсов — скорость передачи и коррекция ошибок) и адреса их назначения (IP и порт). Это также текстовый протокол. Параметры SDP передаются в теле SIP-пакетов.
RTP (Real-time Transport Protocol) — протокол передачи аудио/видеоданных. Это бинарный протокол поверх UDP.
Общая структура SIP-пакетов:
Вот пример двух SIP-пакетов для одной частой процедуры — установления вызова:
Слева изображено содержимое пакета SIP INVITE, справа — ответ на него — SIP 200 OK.
Основные поля выделены рамками:
- o — Origin, имя организатора сессии и идентификатор сессии.
- с — Connection Information, поле описано ранее.
- m — Media Description, поле описано ранее.
- a — медиа-атрибуты, уточняют формат передаваемых данных. Например, указывают направление звука — прием или передача (sendrecv), для кодеков указывают частоту дискретизации и номер привязки (rtpmap).
Также в RTP-пакетах указывается уникальный SSRC-идентификатор (определяет источник RTP-потока) и метка времени (timestamp, используется для равномерного проигрывания звука или видео).
Пример взаимодействия двух SIP-абонентов через SIP-сервер (Asterisk):
Если полученные параметры SDP нас не устроили, или промежуточный SIP-сервер решил не пропускать через себя RTP-трафик, то выполняется процедура повторного согласования SDP, так называемый REINVITE. Кстати, именно из-за этой процедуры у бесплатных SIP-прокси-серверов есть один недостаток — если оба абонента находятся в одной локальной сети, а прокси-сервер находится за NAT'ом, то после перенаправления RTP-трафика ни один из абонентов не будет слышать другого.
3. Передача информации о нажатых кнопках
Иногда после установления сессии, во время разговора, требуется доступ к дополнительным видам обслуживания (ДВО) — удержание вызова, перевод, голосовая почта и т.п. — которые реагируют на определенные сочетания нажатых кнопок.
Так, в обычной телефонной линии есть два способа набора номера:
- Импульсный — исторически первый, использовался в основном в телефонах с дисковым номеронабирателем. Набор происходит за счет последовательного замыкания и размыкания телефонной линии согласно набираемой цифре.
- Тоновый — набор номера DTMF-кодами (Dual-Tone Multi-Frequency) — каждой кнопке телефона соответствует своя комбинация двух синусоидальных сигналов (тонов). Выполняя алгоритм Гёрцеля можно довольно просто определить нажатую кнопку.
Во время разговора импульсный способ неудобен для передачи нажатой кнопки. Так, на передачу «0» требуется приблизительно 1 секунда (10 импульсов по 100 мс: 60 мс — разрыв линии, 40 мс — замыкание линии) плюс 200 мс на паузу между цифрами. К тому же во время импульсного набора будут часто слышны характерные щелчки. Поэтому в обычной телефонии используется только тоновый режим доступа к ДВО.
В VoIP-телефонии информация о нажатых кнопках может передаваться тремя способами:
Передача DTMF внутри аудиоданных(Inband) имеет несколько недостатков — это накладные ресурсы при генерации/встраивании тонов и при их детектировании, ограничения некоторых кодеков, которые могут исказить DTMF-коды, и слабая надежность при передаче (если потеряется часть пакетов, то может произойти детектирование двойного нажатия одной и той же клавиши).
Главное различие между DTMF RFC2833 и SIP INFO: если на SIP-прокси-сервере включена возможность передачи RTP непосредственно между абонентами минуя сам сервер (например, canreinvite=yes в asterisk), то сервер не заметит RFC2833-пакеты, вследствие чего становятся недоступными сервисы ДВО. Передача SIP-пакетов всегда осуществляется через SIP-прокси-серверы, поэтому ДВО всегда будут работать.
4. Передача голоса и факсов
Как уже упоминалось, для передачи медиаданных используются RTP-протокол. В RTP-пакетах всегда указывается формат передаваемых данных (кодек).
Для передачи голоса существует много разнообразных кодеков, с разными соотношениями битрейт/качество/сложность, есть открытые и закрытые. В любом софтфоне обязательно есть поддержка G.711 alaw/ulaw-кодеков, их реализация очень простая, качество звука неплохое, но они требуют пропускной способности в 64 кбит/с. Например, G.729-кодек требует только 8 кбит/с, но очень сильно загружает процессор, к тому же он не бесплатный.
Для передачи команд T.38 используется UDPTL-протокол, это протокол на базе UDP, он используется только для T.38. Для передачи комманд T.38 можно ещё использовать протоколы TCP и RTP, но они используются гораздо реже.
Основные достоинства T.38 — снижение нагрузки на сеть и большая надежность по сравнению с Inband-передачей факса.
Процедура передачи факса в режиме T.38 выглядит следующим образом:
Передавать факсы по интернету желательно в T.38. Если же факс нужно передать внутри офиса или между объектами, имеющими стабильное соединение, то можно использовать передачу факса Inband T.30. При этом перед передачей факса обязательно должна быть отключена процедура эхоподавления, чтобы не вносить дополнительные искажения.
Очень подробно про передачу факсов написано в книге «Fax, Modem, and Text for IP Telephony», авторы — David Hanes и Gonzalo Salgueiro.
5. Цифровая обработка сигналов (ЦОС). Обеспечение качества звука в IP-телефонии, примеры тестирования
С протоколами установления сеанса разговора (SIP/SDP) и методе передачи звука по RTP-каналу мы разобрались. Остался один немаловажный вопрос — качество звука. С одной стороны, качество звука определяется выбранным кодеком. Но с другой, необходимы еще дополнительные процедуры DSP (ЦОС — цифровой обработки сигналов). Данные процедуры учитывают особенности работы VoIP-телефонии: не всегда используется качественная гарнитура, в интернете бывают пропадания пакетов, иногда пакеты приходят неравномерно, пропускная способность сети тоже не резиновая.
Основные процедуры, улучшающие качество звука:
VAD (Voice activity detector) — процедура определения фреймов, которые содержат голос (активный голосовой фрейм) или тишину (неактивный голосовой фрейм). Такое разделение позволяет заметно снизить загрузку сети, поскольку передача информации о тишине требует гораздо меньше данных (достаточно лишь передать уровень шума или вообще ничего не передавать).
Некоторые кодеки уже содержат внутри себя процедуры VAD (GSM, G.729), для других же (G.711, G.722, G.726) нужно их реализовывать.
Если VAD настроен на передачу информации об уровне шума, то передаются специальные SID-пакеты (Silence Insertion Descriptor) в 13м RTP-формате CN (Comfort Noise).
Стоит заметить, что SID-пакеты могут быть отброшены SIP-прокси-серверами, поэтому для проверки желательно настраивать передачу RTP-трафика мимо SIP-серверов.
CNG (сomfort noise generation) — процедура генерации комфортного шума на базе сведений из SID-пакетов. Таким образом, VAD и CNG работают в связке, но CNG-процедура гораздо менее востребована, поскольку заметить работу CNG-можно не всегда, особенно при малой громкости.
PLC (packet loss concealment) — процедура восстановления звукового потока при потере пакетов. Даже при 50% потере пакетов хороший алгоритм PLC позволяет добиться приемлемого качества речи. Искажения, конечно, будут, но слова разобрать можно.
Простейший способ эмуляции потери пакетов (в Linux) — воспользоваться утилитой tc из пакета iproute с модулем netem. Она выполняет шейпинг только исходящего трафика.
Пример запуска эмуляции сети с потерей 50% пакетов:
Jitter buffer — процедура избавления от jitter-эффекта, когда интервал между принятыми пакетами очень сильно меняется, и что в худшем случае ведет к неверному порядку принимаемых пакетов. Также данный эффект приводит к прерываниям речи. Для устранения jitter-эффекта необходимо на принимаемой стороне реализовать буфер пакетов с размером, достаточным для восстановления исходного порядка отправления пакетов с заданным интервалом.
Эмулировать jitter-эффект также можно с помощью утилиты tc (интервал между ожидаемым моментом прихода пакета и фактическим может достигать 500 мс):
LEC (Line Echo Canceller) — процедура устранения локального эха, когда удаленный абонент начинает слышать собственный голос. Ее суть заключается в том, чтобы вычесть из передаваемого сигнала принимаемый сигнал с некоторым коэффициентом.
Эхо может возникать по нескольким причинам:
- акустическое эхо из-за некачественного аудиотракта (звук из динамика попадает в микрофон);
- электрическое эхо из-за несогласованности импедансов между телефонным аппаратом и SLIC-модулем. В большинстве случаев это происходит в цепях преобразования 4-проводной телефонной линии в 2-проводную.
Выяснить причину (акустическое или электрическое эхо) несложно: абоненту, на чьей стороне создается эхо, необходимо отключить микрофон. Если эхо все равно возникает — значит оно электрическое.
Более подробно о VoIP и процедурах ЦОС написано в книге VoIP Voice and Fax Signal Processing. Предпросмотр доступен на Google Books.
На этом поверхностный теоретический обзор VoIP завершен. Если интересно, то пример практической реализации мини-АТС на реальной аппаратной платформе можно будет рассмотреть в следующей статье.
[!?] Вопросы и комментарии приветствуются. На них будет отвечать автор статьи Дмитрий Валенто, инженер-программист дизайн-центра электроники Promwad.
Читайте также: