Меню
Главная
Авторизация/Регистрация
 
Главная arrow Техника arrow IP-телефония в основе сети будущего поколения NGN

Общие принципы сигнализации в сетях IP-телефонии

Для обеспечения широкомасштабного внедрения IP-телефонии одним из самых важных факторов является обеспечение совместимости систем разных фирм. Достижение совместимости возможно только на базе стандартных протоколов сигнализации. Протоколы сигнализации обеспечивают установление, администрирование и завершение сеанса связи между конечными точками (пользователями), однозначно идентифицируемыми заданной схемой адресации. Понятие «сигнализация» относится ко всей информации, связанной с вызовами и необходимой для их установления, маршрутизации, мониторинга и завершения как на физическом, так и на логическом уровне.

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

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

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

В системах IP-телефонии процедуры управления вызовами выполняются протоколами сигнализации, а непосредственная маршрутизация трафика через IP-сеть обеспечивается протоколами: OSPF или ВGР (резервирование сетевых ресурсов возможно, например, при помощи протокола RSVP). Таким образом, архитектура сети IP-телефонии предусматривает разделение плоскостей управления и передачи пользовательской информации, что является наиболее благоприятным условием для внедрения новых услуг.

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

В обычной телефонной сети общего пользования (ТфОП) абонент подключается к АТС через фиксированный местный шлейф, поэтому идентифицировать его телефонный аппарат очень просто. В сети IP-телефонии все гораздо сложнее, поскольку существует множество разных способов доступа к ней: с обычного телефона через ТфОП, по модемному соединению через сервер удаленного доступа, через ЛВС и территориально распределенную сеть и т.д. Кроме этого, пользователи могут перемещаться между различными сетями, таким образом, абонента нельзя идентифицировать по используемой им линии доступа.

Управление вызовами в сети IP-телефонии

Рис 7 Управление вызовами в сети IP-телефонии

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

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

В общем случае для установления соединения между вызываемым и вызывающим абонентом шлюзы IP-телефонии должны:

  • - найти gatekeeper, на котором возможна регистрация оконечного устройства;
  • - зарегистрировать свой мнемонический адрес на gatekeeper;
  • - указать требуемую полосу пропускания;
  • - передать запрос на установление соединения;
  • - установить соединение;
  • - в процессе вызова управлять параметрами соединения;
  • - разъединить соединение.
Механизмы сигнализации IP-телефонии в протокольном стеке

Рис. 8 Механизмы сигнализации IP-телефонии в протокольном стеке

Для выполнения этих операций в настоящее время могут использоваться различные протоколы сигнализации

Сигнализация по стандарту Н.323. Рекомендация Международного союза электросвязи (МСЭ-Т) Н.323 определяет основы процесса передачи аудио, видео и данных по сетям с коммутацией пакетов, например по сетям IP. В ней описаны объекты, необходимые для мультимедийной связи, их функции и способы взаимодействия, в частности алгоритмы формирования пакетов, сжатия аудио- и видеоинформации. Кроме того, рекомендация Н.323 нацелена на решение задач администрирования конечных пользователей, адресации, контроля за использованием полосы пропускания сети и сетевых объектов. В настоящее время действительна версия 2 Н.323 - это зонтичная рекомендация, в которой описаны компоненты сети и даны рекомендации к применению множества дополнительных рекомендаций. Все вместе эти рекомендации часто называют семейством Н.323

Сейчас готовится следующая версия стандарта. В ней будут описаны: создание пакетных сетей факсимильной связи и организация связи между Н.323-шлюзами. Речь идет и о таких функциях, распространенных в современной телефонии, включая уведомление о поступлении второго вызова и режим справки. Некоторые компании добиваются включения в Н.323 поддержки мультимедиа-возможностей, основанных на предложенном IETF протоколе Session Initiation Protocol. Помимо «телефонных» функций, новая версия будет дополнена средствами, позволяющими учитывать параметры сеансов для целей тарификации, а также поддержкой каталогов - вместо цифровых IP-адресов можно будет пользоваться именами абонентов.

Для выполнения действий сигнализации между шлюзами и gatekeeper в соответствии с Рекомендацией МСЭ-Т Н.323 должны использоваться следующие протоколы:

  • - сигнализация RAS (Registration, Admission, Status);
  • - сигнализация Q.931 (согласно Н.225.0);
  • - протокол управления Н.245.

Сигнализация RAS. Протокол сигнализации RAS (регистрации, подтверждения и состояния) применяется для передачи служебных сообщений между терминалами и контроллером зоны Н.323. RAS-сообщения служат для регистрации терминалов, допуска их к сеансу связи, изменения используемой полосы пропускания, информирования о состоянии сеанса и его прекращении. В отсутствии контроллера зоны (gatekeeper) протокол RAS не задействуется.

Функции сигнализации RAS используют сообщения протокола Н.225.0. Канал сигнализации RAS не зависит от канала управления вызовом и канала управления Н.245.

С помощью сигнализации RAS должно осуществляться:

  • - нахождение gatekeeper, на котором возможна регистрация оконечного оборудования;
  • - регистрация оконечного устройства;
  • - определение географического положения оконечного устройства;
  • - указание необходимой полосы пропускания;
  • - изменение полосы пропускания.

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

  • - сетевой адрес оборудования;
  • - идентификатор TSAP (Transport Layer Service Access Point);
  • - мнемонический адрес (Alias Address).

Сетевой адрес является адресом в формате, используемом в сети с коммутацией пакетов, например, адрес в форматах IPv4, IPv6, IPX, NetBIOS.

Идентификатор TSAP используется для идентификации информационных потоков, отправленных с одного сетевого адреса. Для gatekeeper выделены постоянные значения идеyтификатора TSAP: 1718 (для поиска gatekeeper) и 1719 (для передачи сообщений сигнализации RAS).

Этапы прохождения вызова в среде Н.323

Рис. 9. Этапы прохождения вызова в среде Н.323

Мнемонический адрес служит для адресации оконечного оборудования в удобной пользователю форме. Адресом может быть телефонный номер в формате ЕЛ 64, телефонный номер в корпоративной сети, адрес электронной почты и т.д. Gatekeeper не имеет мнемонического адреса.

Совокупность рекомендаций Н.323

Рис. 11. Совокупность рекомендаций Н.323

Нахождение gatekeeper должно осуществляться с помощью широковещательного запроса GRQ (Gatekeeper Request), передаваемого оконечным оборудованием с идентификатором TSAP, равным 1718. Если gatekeeper найден, и он готов обслужить запрос от оконечного оборудования, в ответ оно должно получить сообщение GCF (Gatekeeper Confirm). Если оконечное оборудование получило ответ от нескольких gatekeeper, выбор одного из них должен осуществляться оконечным оборудованием произвольным образом. Если gatekeeper не может обслужить запрос от оконечного оборудования, то в ответ он должен передать сообщение GRJ (Gatekeeper Reject), в котором должна сообщаться причина отказа, и может содержаться адрес альтернативного gatekeeper. При нахождении gatekeeper между ним и оконечным оборудованием осуществляется установление логического канала сигнализации, по которому будут передаваться остальные сообщения RAS.

После нахождения gatekeeper оконечное оборудование в сообщении RRQ (Registration Request) должно сообщить gatekeeper свой сетевой и мнемонический адрес. В ответ gatekeeper должен передать сообщение RCF (Registration Confirm) для подтверждении регистрации оконечного оборудования, либо RRJ (Registration Reject) в случае отказа от регистрации. Сообщение RRQ может передаваться при включении оконечного оборудования. Если при повторной регистрации мнемонический и сетевой адреса, переданные gatekeeper оконечным оборудованием, совпадают с ранее переданными, то gatekeeper должен передать сообщение RCF. Если при повторной регистрации мнемонический адрес равен ранее указанному, а сетевые отличаются, должно быть передано сообщение RRJ с причиной отказа «duplicate registration». Для отмены регистрации используются сообщения URQ (Unregistered Request), передаваемое оконечным оборудованием, и UCF (Unregistered confirm), URJ (Unregistered reject), передаваемые gatekeeper оконечному оборудованию.

Регистрация оконечного оборудования на gatekeeper может осуществляться один раз и не повторяться при включении оконечного оборудования. В этом случае gatekeeper должен определять состояние оконечного оборудования. Для этого gatekeeper должен периодически передавать сообщение IRQ (Information Request). Интервал определяется производителем оборудования и должен быть не менее 10 секунд.

После регистрации оконечного оборудования на gatekeeper оно может установить соединение с вызываемым оконечным оборудованием. Для этого оконечное оборудование-инициатор должно передать сообщение ARQ (Admissions Request) и установить логический канал для передачи сообщений Q.931. В сообщении ARQ указываются скорость передачи, кратная 100 бит/с, и количество каналов, необходимых для передачи речевой информации.

Например, при использовании интерфейсов ISDN для выделения полосы 192 кбит/с необходимо указать значения соответственно 640 и 3. Скорость указывается без учета размеров заголовков пакетов и блоков данных транспортных протоколов. Если сеть может обеспечить требуемые параметры, то gatekeeper должен передать подтверждение ACF (Admissions Confirm), в противном случае передается сообщение ARJ (Admissions Reject) с указанием причины отказа.

После получения подтверждения оконечное оборудование устанавливает соединение с вызываемым оконечным оборудованием с использованием сигнализации Q.931 (в соответствии с Н.225.0). Сообщения сигнализации Q.931 могут передаваться по логическому каналу через gatekeeper или непосредственно между двумя оконечными устройствами. Выбор способа осуществляет gatekeeper и сообщает об этом оконечному оборудованию в сообщении ACF.

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

Сигнализация по концепции TIPHON. Базируясь на стандарте Н.323 для IP-сети, спецификация TIPHON дополняет его некоторыми обязательными процедурами, а также механизмами взаимодействия с сетями коммутации каналов. Функциональная модель TIPHON состоит из тех же компонентов -gatekeeper, шлюза и терминала, - что и модель Н.323, однако в ней предусмотрено разделение шлюза на три функциональных объекта. Это шлюз сигнализации (SG - Signalling Gate- way), транспортный шлюз (MG - Media Gateway) и контроллер транспортного шлюза (MGC - Media Gateway Controller).

Функциональная модель сети по проекту TIPHON

Рис. 12. Функциональная модель сети по проекту TIPHON

Шлюз сигнализации .служит промежуточным звеном сигнализации между сетями с пакетной и канальной коммутацией. В задачи транспортного шлюза входит преобразование и/или перекодирование передаваемой информации; он обеспечивает терминирование ИКМ-трафика телефонных сетей и пакетного трафика, транслирует адреса, подавляет эхо, воспроизводит различные сообщения для абонентов, принимает и передает цифры кодом DTMF и т.д. Контроллер сигнализации MGC выполняет процедуры сигнализации Н.323, которые определены в рекомендациях Н.323, Н.225 (RAS и Q.931) и Н.245, и преобразует сообщения сигнализации телефонных сетей в сообщения сигнализации Н.323. Основная его задача -управлять работой транспортного шлюза, т.е. осуществлять контроль за соединениями, использованием ресурсов, трансляцией протоколов и т.п. Следует отметить, что MGC не обеспечивает управление вызовами. Это задачи gatekeeper, который выполняет их в соответствии с рекомендациями Н.323.

При использовании сигнализации ОКС №7 в контроллер MGC по IP-сети будут передаваться сообщения ISUP (подсистемы обслуживания вызовов сети ISDN). Если же применяется сигнализация по выделенному каналу (CAS), сигнальные сообщения сначала вместе с информацией абонента поступят в транспортный шлюз, а затем уже будут выделены в контроллер MGC. При этом предполагается использовать протокол MDTP (Multi-Network Datagram Transmission Protocol), который служит для инкапсуляции телефонных протоколов сигнализации (ISUP, CAS, PRI) и передачи переносимой ими информации в контроллер транспортного шлюза.

MGC анализирует информацию сигнализации и передает управляющую информацию в транспортный шлюз посредством специального протокола управления, в задачи которого входит обеспечение управления различными ресурсами (системой интерактивного речевого отклика, мостами конференцсвязи и т.д.), приемом и формированием сигналов DTMF, формированием тональных сигналов (готовности к набору номера, контроля посылки вызова, «занято» и пр.), эхо-подавлением, использованием кодеков (G.711, G.723.1, G.729, GSM и т.д.), сбором статистики, тестированием конечных точек (например, испытания по шлейфу), резервированием, разъединением и блокировкой конечных точек, шифрованием.

Протокол управления транспортными шлюзами MGCP представляет собой достаточно простой протокол клиент-сервер. Логика управления вызовами выполняется агентом (Call Agent), находящимся вне транспортного шлюза. Сам же транспортный шлюз представляется в виде объекта, состоящего из конечных точек - точек входа/выхода информационных потоков и соединений - двух или более соединенных конечных точек. Модель определяет физические конечные точки (например, окончания соединительных линий) и виртуальные конечные точки (например, аудиоисточники). Сам протокол MGCP использует принцип «ведущий/ведомый», согласно которому агент управления вызовами передает транспортному шлюзу команды для управления конечными точками и соединениями, а также инициации определенных действий.

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

Дальнейшим развитием протокола MGCP является протокол управления вызовами Megaco (Media Gateway Control), известный также как стандарт ITU H.248, который определяет взаимодействие, с одной стороны, шлюза между разными средами передачи данных (Media Gateway, MG) и, с другой, - контроллера шлюзов между средами передачи данных (Media Gateway Controller, MGC) Иными словами, Megaco разработан для внутри-доменного удаленного управления устройствами, отвечающими за установление соединения или проведение сеанса связи, включая шлюзы VoIP, серверы удаленного доступа, мультиплексоры цифровых абонентских линий (Digital Subscriber Line Access Multiplexer, DSLAM), маршрутизаторы с поддержкой многопротокольной коммутации с использованием меток (Multiprotocol Label Switching, MPLS), оптические кросс-коннекторы, модули агрегирования сеансов РРР и другие.

Использование протокола Megaco в сети IP-телефонии

Рис. 13. Использование протокола Megaco в сети IP-телефонии

MGCP и Megaco - эти сравнительно низкоуровневые протоколы управления устройствами, которые сообщают шлюзу, каким образом связать потоки, поступающие в сеть с коммутацией пакетов или ячеек, с потоками пакетов или ячеек, переносимыми, например, транспортным протоколом реального времени (Real-Time Transport Protocol, RTF). По существу, Megaco повторяет MGCP в отношении архитектуры и взаимодействия контроллера со шлюзом, но при этом Megaco поддерживает более широкий диапазон сетевых технологий, в том числе ATM.

Типичным примером работы протокола MGCP является проверка состояния конечной точки на предмет снятия трубки (которую поднимает абонент, чтобы сделать звонок). После фиксации события «снятие трубки» шлюз сообщает об этом контроллеру, после чего последний может послать шлюзу команду подать в линию непрерывный гудок и ждать тональных сигналов DTMF набираемого номера абонента. После получения номера контроллер решает, по какому маршруту следует направить вызов, и, используя протокол сигнализации между контроллерами, в том числе Н.323, SIP или Q.BICC, взаимодействует с оконечным контроллером. Оконечный контроллер дает соответствующему шлюзу указание подать звонок на вызываемую линию. Когда этот шлюз определяет, что вызываемый абонент снял трубку, оба контроллера дают соответствующим шлюзам команды на установление двухсторонней голосовой связи по сети передачи данных. Таким способом данные протоколы распознают состояния конечных точек, уведомляют об этих состояниях контроллер,- генерируют в линии сигналы (например, непрерывный гудок), а также формируют потоки данных между подключенными к шлюзу конечными точками и сетью передачи данных, например потоки RTP.

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

Для установления соединения используются сообщения Setup и Connect, после передачи которых устанавливается канал управления Н.245. Канал для передачи информации управления Н.245 может быть установлен двумя способами: через gatekeeper или непосредственно между оконечными устройствами. В случае, если логический канал сигнализации Q.931 устанавливается через gatekeeper, то канал для передачи информации управления Н.245 также должен устанавливаться через gatekeeper. Способ установления канала для передачи информации управления Н.245 между оконечным оборудованием в настоящее время не специфицирован.

Если канал сигнализации RAS установлен, то он может использоваться для установления нескольких соединений. Идентификация сообщений сигнализации, принадлежащих одному и тому же соединению, осуществляется с помощью идентификатора Call ID.

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 
СКАЧАТЬ ОРИГИНАЛ
IP-телефония в основе сети будущего поколения NGN