Руководство по технологиям объединенных сетей Cisco (953103), страница 61
Текст из файла (страница 61)
Этот простой н компактный протокол обладает богатым набором функций и реализуется вместе с протоколом Сосо 1Р Р)гопеа. Маршрут сигнализации использует порт 2000 протокола ТСР, а маршрут передачи мультимедийных данных использует протокол \ЛЗР. Набор сообщений для управления работой клиентского приложения включает в себя три основных сферы; регистрация и управление, управление вызовом (установка, прекращение и статистика) и контроль мультимедийного потока (аудио). Первоначально этот протокол был спроектирован и реализован в технологии С!асо Сай Мапаяег, однако за прошедшее время привлек внимание многих других производителей. Са!! Мапаяег или Бойкоту!гсЬ управляют конечными точками, установкой прекращением и учетом вызовов, однако потоки мультимедийных данных управляются непосредственно конечными точками.
Сравнение альтернатив передачи сигналов Чо! Р У различных вариантов передачи сигналов есть свои достоинства и недостатки с точки зрения системных разработчиков, Некоторые из ннх описаны ниже. Первое, что следует отметить, сравнивая МОСР н Н.323, — это различия в их возможностях. МОСР— простой протокол управления устройствами, а Н.З23 — полнофункциональный мультимедийный протокол для конференций. У Н.323 уже появилась 3-я версия, а МОСР, возможно, даже не будет окончательно утвержден; это лишь неофициальный стандарт, принятый некоторыми производителями. Поэтому МОСР, хоть и обеспечивает функциональную совместимость, не является промышленным стандартом. С другой стороны, функциональной совместимости Н.323 мешает сто сложность. Протокол МОСР устанавливает соединение всего за два прохода, а Н.З23 для этого обычно требуется семь или восемь проходов.
(Примечание. в Н.323ч2 есть функция ускоренного запуска, позволяющая устанавливать некоторые соединения за два прохода, но такой протокол не очень широко распространен.) Управление вызовом в МОСР ненамного лучше управления устройствами, в то время как в Н.323 оно унаследовано от системы сигнализации О.93! ЬРХ как протокол управления передачей информации.
Для МОСР эта управляющая информация передается по ()ь)Р, а для Н.323 — по ТСР. Протокол Б!Р и Н.323 являются мультимедийными протоколами полнофункциональных одноранговых систем, ЯР представляет собой 1ЕТР цРС, а Н.323чЗ утвержден 1ТО. Как уже отмечалось, данные протоколы функционально совместимы. ЯР эффективнее, чем Н.323, так как устанавливает некоторые вызовы всего за один проход. Кроме того, ЯР использует существующие протоколы )пгегпсг, а для Н.323 продолжают появляться новые элементы для приспособления к модели О.931 !ЯЗВ.
Сравнение протоколов Б!Р с МОСР подобно сравнению протоколов Н.323 с МОСР, потому что 31Р (как и Н.323) является протоколом управления средой передачи, а МОСР— протоколом управления устройствами. Поэтому проявляются те же отличия, что и между клиент-серверными протоколами и одноранговыми протоколами. Основнос отличие состоит в том, что одноранговые протоколы, такнс как Н.З23 и б!Р, обычно лучше масштабируются, а клиент-серверные протоколы наподобие МОСР проще для разработки и обслуживания. Глава 19. Интегрированная передача голосовых и обычных данных 311 Развитие систем интегрированной передачи голоса и данных Первые продукты для интегрированной передачи голоса и данных были предназначены для того, чтобы избежать оплаты междугородных телефонных переговоров путем соединения телефонных сетей через инфраструктуру.
Эти продукты, как правило, встраивались в маршрутизатор или другое компьютерное устройство и обеспечивали прямое соединение "точка-точка", используя обычные аналоговые магистральные порты. По мсрс их совершенствования появилась поддержка разных типов интерфейсов, в том числе цифровых, ЕегМ и других. Затем, с расширением возможностей, появилась поддержка аналоговых телефонных вилара~он. Данное приложение первоначально предназначалось для резервных расширений мини-АТС по частным автоматическим каналам прямого вызова (Рг!чаге ).!пе Ацготаг!с й!пег)овп — Р).АК), но позже в таких шлюзовых устройствах появилось распознавание ОТМЕ и поддержка основных вариантов автоматического набора.
В конце концов это привело к тому, что сетевые устройства %АМ стали обеспечивать не только передачу, но и транзитную коммутацию для подключенных к ним мини-АТС. Со временем логику корпоративных вызовов стали переносить на устройства распределенной компьютерной сети. Мини-АТС, подключенным к тУАХ, оставалось только передавать межузловые вызовы шлюзу тУАХ, не заботясь о дальнейших подробностях вычисления маршрута. Варианты автоматического вызова, предоставляемые такими шлюзами, как маршрутизаторы Свсо Буз!сиз с интегрированной передачей речи, обсспечивали магистральную связь между многими узлами.
Данная модель работала очень хорошо, особенно для небольших сетей, размером до 10 узлов. Однако по мере появления все более крупных систем с гораздо большим количеством узлов, их стало трудно администрировать. Каждый раз, когда добавлялся новый узел или изменялась схема связи, сетевым инженерам приходилось вручную регистрироваться на каждом маршрутизаторе в сети и вносить в схему связи соответствующие изменения. Это был громоздкий процесс, порождавший ошибки.
В конце концов это привело к появлению утилит, облегчающих такую работу. Например, СНМ (С!зсо Уо!се Мапаяег) имеет графический интерфейс для настройки и управления схемой связи, который позволяет сетевым инженерам управлять сотнями голосовых шлюзов. Эти решения вполне соответствовали требованиям многих приложений, но дальнейшее увеличение масштабов сетей вызвало появление систем с сотнями и даже тысячами узлов. Крупные предприятия и провайдеры, оценивая технологию, обнаружили две основные проблемы масштабирования — это управление полномочиями соединения (Соппесйоп Адтпжюп Сои!го! — САС) и централизация схемы связи.
По мере роста объемов передачи голосовых данных повысилось значение управления полномочиями соединения. Стало очевидным, что даже если олин шлюз 'видит" другой шлюз в логически плоской связной сети, то он не всегда в состоянии выполнить вызов. Необходимо было некое центральное управляющее средство, выполняющего функции дорожного регулировщика„регламентирующего количество вызовов между основными узлами. Вызовы, поступившие после того, как было прсвышено их прсдслыюс количество, должны отбрасываться или, если нужно, направляться по другим маршрутам. Схемы связи тоже стали слишком громоздкими для администрирования малыми сетевыми элементами. Плоская связная топология, в сущности, привела к необходимости хра- З1г Часть )Н.
Технологии алультисервисного доступа нить в каждом узле информацию схемы связи со всеми узлами. Ограниченность ресурсов памяти и процессоров скоро стала тормозить дальнейший рост. Решением указанных двух проблем стало введение централизованного управления вызовами. Для передачи голоса по Ргатс Ке!ау и АТМ были внедрены виртуальные коммутирующие системы контроллсрного типа, позволяющие централизировать логику и информацию о вызове. В Ъо!Р для этого появился драйвер шлюза Н.323. В Сасо В)ягела, например, был разработан драйвер шлюза Мцйппегйа Сопгегепс(па Мапааег (МСМ) Н.323 для поддержки как голосовых сетей, так и видеоконференций, для которых он, в сущности, и бьп создан.
Необходимо обратить вниманис на то, что централизованная логика управления вызовами пе означает централизацию голосовых маршрутов. 11ентрализованы только администрирование схем связи и управление вызовами. Собственно коммутация голосовых пакетов происходит, как всегда, в элементах компьютерной сети, поэтому сохраняются экономичность и эффективность, присущая продуктам, связанным с обработкой голосовых пакетов, Будущие приложения для телефонии По мере дальнейшего совершенствования решений интегрированной передачи голоса и данных„различныс производители начали создавать приложения нового типа, Вместо простой передачи и коммугации между мини-АТС системы пакетной передачи голоса теперь начинают заменять мини-АТС решениями "точка-точка". Это означает, что технологии пакетной передачи голоса уже являются нс сетевой службой, а приложением, работающим в сети. Разница между данными терминами существенна, когда речь идет о сбыте и администрировании продуктов.
По архитектуре их можно разделить на следующие типы. ° миии-АТС вЂ” миня-АТС. В этой архитектуре сервер на базе РС имеет как порты магистральных шлюзов, так и аналоговые телефонные порты. Обычно специальныс программы и драйверы, работающис под управлением ХТ, обеспечивают все основные стандартные системные функции для аналоговых телефонов. Дополнительные функции, такис как яо)а и Ггапзгег, подаются путем нажатия на рычаг аппарата или на кнопку Р)аз)ь Системы обычно масштабируются до 48 телефонов.
Обратите внимание, что в системе нет избыточности, но ее полная стоимость может быть намного ниже, чем у большинства старых систем. В состав многих продуктов входит интегрированная голосовая почта, позволяющая сохранять оцифрованные голосовые сообщения на жестком диске.
° ГАгч-АТС. В эту категорию входят продукты, основанные на 1А)Ч-телефонии и распространяющиеся вплоть до настольных ПК. Некоторые из них позволяют использовать службы ЕА)ч-телефонии через компьютерные программы на ПК пользователя; другие фактически представляют собой телефоны, подключаемые к локальной компьютерной сети. Со временем возможно создание таких продуктов на базе МАС-уровня (Еглсгпег), АТМ или 1Р. Продукты 3-уровня (на базе 1Р) обеспечивают большую гибкость и масштабируемость благодаря тому, что!Р является маршрутизируемым протоколом.
Следовательно, их можно применять в различных сегментах 1АХ. Продукты на базе низкоуровневых протоколов имеют привлекательную цену, вследствие меньшей сложности их клиентской части. Как показал опыт, основными проблемами 1А)ч-телефонии являются надежность и масштабируемость. Для того чтобы интегрированная передача голоса и данных од- Глава 19.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
