
- •2) Конкурентом DiffServ на роль протокола для обеспечения QoS является другой проект ietf под названием «Многопротокольная коммутация меток» ( Multiprotocol Label Switching , mpls ).
- •3) Кодек g. 711
- •Обеспечение безопасности в ip – телефонии на базе vpn
- •2. Реализация функций сорм в ip – телефонии
- •3. Дифференциальное обслуживание трафика - Diff – Serv
- •2. Трафик реального времени в ip – сетях
- •3. Основные алгоритмы кодирования речи, используемые в ip – телефонии
- •Использование полосы пропускания канала
- •Подавление периодов молчания (vad, cng, dtx)
- •Размер кадра
- •Чувствительность к потерям кадров
- •2. Концепция tdMoIp
- •2. Шлюз MultiVoice Gateway
- •3. Модель организации связи
- •3. Модель организации связи
10
1 1.Особенности оборудования IP-телефонии для России
При внедрении технологии передачи речевой информации по сетям с маршрутизацией IP-пакетов во Взаимоувязанной сети связи Российской Федерации (ВСС РФ), помимо рассмотренных выше, возникают следующие специфические трудности:
- при подключении оборудования IP-телефонии к АТС телефонной сети общего пользования по двухпроводным аналоговым абонентским линиям препятствием часто становится большое затухание сигналов в этих линиях;
- при подключении оборудования IP-телефонии к коммутационному оборудованию ТфОП по межстанционным соединительным линиям затруднения связаны с тем, что декадно-шаговые и координатные АТС имеют специфические системы сигнализации [6], основная из которых определяется неформальным, но весьма точным термином «R полтора»;
- присутствующие в ТфОП декадно-шаговые АТС создают большие помехи и поддерживают только импульсный набор номера.
Специфические требования к оборудованию IP-телефонии, подключаемому к ВСС России, изложены в руководящем документе отрасли РД 45.046-99 «Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования», утвержденном Министерством связи 12.11.99 г., изложение которого выходит за рамки данной книги. Сэкономленное таким образом место отдано краткому описанию отечественной платформы IP-телефонии ПРОТЕЙ-IP, реализующей все требования данного РД и учитывающей упомянутую выше специфику ВСС России.
2) Конкурентом DiffServ на роль протокола для обеспечения QoS является другой проект ietf под названием «Многопротокольная коммутация меток» ( Multiprotocol Label Switching , mpls ).
При IP-коммутации узел анализирует первые несколько пакетов поступающего трафика и, в случае короткой посылки, например запроса DNS или SNMP , обрабатывает их как обычный маршрутизатор. Но если узел идентифицирует длительный поток - от трафика telnet или FTP до загрузки файлов через Web и мультимедийных приложений, то IP-коммутатор переключается на нижележащую структуру ATM и применяет сквозную коммутацию для быстрой доставки данных адресату.
Если DiffServ задействует заголовок DS , уже имеющийся в пакетах IPv4, то MPLS использует 32-разрядную информационную метку, добавляемую к каждому IP-пакету. Эта метка, добавляемая при входе в сеть с поддержкой MPLS, сообщает каждому маршрутизатору вдоль пути следования, как надо обрабатывать пакет. В частности, она содержит информацию о требуемом для данного пакета уровне QoS .
В отличие от поля DS, метка MPLS изначально не является частью пакета IP . Скорее, она добавляется при поступлении пакета в сеть и удаляется при выходе пакета из сети MPLS.
В обычной ситуации маршрутизаторы анализируют заголовок пакета для определения его адресата. Ввиду того, что такой анализ проводится на каждом транзитном узле независимо, предсказать, каким маршрутом будет следовать пакет, практически невозможно, поэтому обеспечение гарантированного уровня QoS оказывается невероятно сложной задачей.
При использовании меток MPLS маршрутизатор или коммутатор может присвоить метки записям из своих таблиц маршрутизации и в виде меток передать информацию о маршрутизации конкретным маршрутизаторам и коммутаторам. Считав метку, каждый коммутатор или маршрутизатор узнает информацию о следующем адресате на пути, не анализируя заголовок пакета. Это экономит время и ресурсы ЦПУ. Пакеты с метками MPLS могут, следовательно, передаваться от отправителя к получателю без задержек на обработку, причем все промежуточные узлы знают, как нужно обрабатывать каждый пакет.
По сути, MPLS привносит коммутацию каналов, какую мы имеем в ATM , в мир пакетных сетей, связанных с IP . На практике MPLS можно использовать для доставки IP-трафика по сетям IP .
Следует отметить, что DiffServ функционирует на третьем уровне, а MPLS - на втором, поэтому с технической точки зрения обе технологии могут мирно существовать друг с другом. Как уже упоминалось, DiffServ классифицирует пакеты при их поступлении на краевой маршрутизатор, поэтому данный стандарт, скорее всего, будет использоваться на границе сети, например, между компанией и ее сервис-провайдером.
Если DiffServ требует некоторой настройки сетевых маршрутизаторов, то MPLS предполагает более серьезную модернизацию, чтобы коммутаторы могли читать метки и направлять пакеты по конкретным маршрутам.
3) Кодек g. 711
Кодек G.711 - «дедушка» всех цифровых кодеков речевых сигналов, был одобрен ITU-T в 1965 году. Применяемый в нем способ преобразования аналогового сигнала в цифровой с использованием полулогарифмической шкалы был достаточно подробно описан выше. Типичная оценка MOS составляет 4.2. В первую очередь отметим, что, как и для ТфОП, минимально необходимым для оборудования VoIP является ИКМ- кодирование G.711. Это означает, что любое устройство VoIP должно поддерживать этот тип кодирования.
11
Проект TIPHON
Упростить процесс внедрения технологии IP-телефонии призван проект TIPHON, реализация которого позволит успешно решить задачи:
установления;
модификации;
разъединения телефонных соединений;
межсетевого взаимодействия;
управления вызовами;
управления запросами о качестве обслуживания;
шифрования;
аутентификации пользователей и др.
Проект TIPHON (Telecommunications and Internet Protocol Harmonization over Networks - название проекта ETSI) был разработан для обеспечения взаимодействия IP-сетей и коммутируемых сетей с коммутацией каналов.
Функциональная модель TIPHON состоит из трех компонентов: контроллера зоны (Gatekeeper), шлюза (Gateway), терминала. Шлюз состоит из трех функциональных объектов:
шлюза сигнализации (Signalling Gateway, SG);
транспортного шлюза (Media Gateway, MG);
контроллера транспортного шлюза (Media Gateway Controller, MGC).
Шлюз сигнализации служит промежуточным звеном сигнализации при взаимодействии сетей IP с сетями, использующими технологию коммутации каналов (Switched Circuit Network, SCN). В задачи транспортного шлюза входят:
преобразование и/или перекодирование передаваемой информации;
обеспечение приема и передачи трафика SCN, пакетного трафика и потоков плезиохронных цифровых систем передачи (ИКМ);
трансляция адресов;.
Контроллер MGC выполняет процедуры сигнализации Н.323, которые определены в рекомендациях Н.323, Н.225 (RAS и Q.931) и Н.245, и преобразует (конвертирует) сообщения сигнализации SCN в сообщения сигнализации Н.323. Основная его задача - управлять работой транспортного шлюза: осуществлять контроль соединений, использования ресурсов, трансляции протокольных блоков данных.
Контроллер зоны в модели TIPHON поддерживает все те функции, которые определены для него в стандарте Н.323. Но, помимо этого, он решает и другие задачи:
тарификации;
взаиморасчетов;
составления отчетов об используемых ресурсах;
управления взаимодействием с другими объектами модели.
Разработанная в рамках проекта TIPHON модель сети, состоящая из функциональных элементов и интерфейсов, показана на рисунке 3.4.
Чтобы соответствовать рекомендациям TIPHON, программно-аппаратные средства поставщика должны поддерживать следующие интерфейсы:
интерфейс D - предназначен для маршрутизации вызовов между контроллерами зоны (gatekeeper);
интерфейс C - для взаимодействия между контроллером транспортного шлюза (MGC) и контроллером зоны;
интерфейс N - предназначен для взаимодействия между объектами MGC и транспортным шлюзом (MG).
Контроллер и шлюз обмениваются информацией при:
создании, модификации и разъединении соединений; определении требуемого формата информации;включении в поток тональных сигналов и различных речевых уведомлений; запросе данных о событиях, связанных с прохождением информационного потока.
Показанные на рисунке 3.4 службы поддержки могут быть использованы для аутентификации, биллинга, преобразования адресов и решения других задач.