Интеграция телефонных служб в мультисервисную сеть предприятия, реализованную на оборудовании компании Cisco Systems

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

В данный момент уже сотни и даже тысячи предприятий выбрали в качестве таких решений решения, построенные на оборудовании компании Cisco Systems. Это связано в первую очередь с широким распространением оборудования этой компании как в распределенных, так и в локальных сетях передачи данных. Еще одним немаловажным фактором, обуславливающим использование данного оборудования, является операционная система IOS, под управлением которой функционирует оборудование Cisco Systems. Гибкая архитектура оборудования Cisco позволяет при появлении новых протоколов, стандартов, функций, модулей, обнаруженных ошибках не заменять полностью все старое оборудование, а просто менять в нем версию IOS на более новую. Именно так обстоит дело с интеграцией голосового трафика в уже существующую сеть передачи данных.

С чего все начиналось...

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

АТС подключены к городской телефонной сети посредством выделенных каналов fractional E1. В качестве сигнального протокола используется ISDN PRI (его европейский вариант EDSS1). Так как коммутация звонков между офисами происходит на городских АТС, то организовать единый план нумерации внутри предприятия практически невозможно, не говоря уже о передаче фирменных сигнализаций взаимодействия офисных АТС! Следовательно, чтобы позвонить из одного офиса в другой, необходимо набрать городской номер, закрепленный за другим офисом, дождавшись соединения, ввести тональным набором внутренний номер абонента другого офиса (если на той АТС реализована такая возможность) или попросить секретаря о необходимом переключении. Последовательность, мягко говоря, явно не радующая. Кстати, для успешного ведения бизнеса неплохо бы иметь централизованный центр обработки вызовов, который вобщем может быть и распределенным между офисами. Но как его организовать, если перевод входящего звонка клиента из одного отдела в другой, находящийся в удаленном офисе, будет осуществляться по вышеописанной схеме? Добавим к этому еще и то, что возможность определения номера переводящего вызов будет отсутствовать - протоколы сигнализации городских АТС пока не предоставляют возможность передачи служебной информации, формируемой на офисных АТС, как-то: внутренний номер звонящего, его имя, состояние аппарата, и т.д.

Теперь о сети передачи данных. Для связи офисных ЛВС в единую корпоративную сеть передачи данных используются маршрутизаторы Cisco Systems серии 3600, оснащенные интерфейсом Ethernet 10/100 для подключения ЛВС и двумя интерфейсами E1 для связи с другими офисами. Оставим за рамками данного документа обсуждение вопроса о том, чем обусловлена необходимость применения маршрутизатора такой мощности как 3600, отметив лишь то, что данная схема не является чисто теоретической разработкой, а представляет собой эскиз проекта существующей корпоративной сети. В качестве межсетевого протокола используется протокол IP, поддержка которого и обеспечивается маршрутизаторами Cisco. Вся маршрутизация выполняется статически, так как количество сетей невелико.

Комплектация маршрутизаторов следующая:

Поясним эту конфигурацию. Как известно, любое модульное устройство состоит из корпуса, или шасси, и модулей расширения, которые в него устанавливаются. CISCO3640 и является шасси. Оно включает в себя материнскую плату с процессором, оперативную память, в которой выполняется код IOS и флэш-память, в которой IOS располагается. Если не указано иное, то с завода шасси приходит с уже предустановленной версией IOS IP only, т.е. с поддержкой маршрутизации только протокола IP. При необходимости можно заказать другую версию IOS с другими функциональными возможностями или потом самим установить новую версию IOS. Также в шасси имеется блок питания маршрутизатора. Модули устанавливаются в соответствующие разъемы расширения, или слоты. В модели 3640 имеется 4 слота под сетевые модули расширения. Сетевым модулем расширения в нашем проекте является NM-1FE2W. Этот модуль имеет 1 интерфейс 10/100 Мбит/c Ethernet, которым мы подключаемся к локальной сети офиса, и два слота расширения для так называемых модулей интерфейсов распределенной сети (WAN Interface Cards - WICs). В данном случае мы устанавливаем в один из этих слотов модуль VWIC-2MFT-E1, представляющий собой 2 интерфейса E1 для подключения по арендованным 2Мбит/c каналам к другим филиалам. О букве V в названии модуля поговорим позднее.

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

IP там правит бал

В настоящее время широкое распространение в сетях передачи данных получил протокол IP (Internet Protocol), чему дало толчок широкое распространение сети Интернет с одной стороны, а с другой - относительная простота и логичность реализации. Сейчас практически невозможно отыскать ни одной сетевой вычислительной системы, в которой не был бы реализован данный протокол. Логичным является также и то, что компания Cisco Systems реализовала в своих продуктах возможность передачи трафика реального времени по сетям передачи данных, использующих протокол IP в качестве межсетевого. Разумеется, может возникнуть вопрос: что, кроме Cisco никто больше не делает подобных решений? Да, их производят, конечно, но как правило это совершенно новые продукты, внедрение которых лучше всего производить, как говорится, "с нуля" из-за их плохой интеграции со старым оборудованием этих производителей. Более подробно о голосовых шлюзах компании Cisco Systems рассказывается в другом документе.

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

Традиции нарушать нельзя!

Сделаем некоторое отступление от обсуждения оборудования Cisco Systems в сторону традиционной телефонии, взглянув на проблему интеграции голоса в сеть передачи данных глазами инженеров АТС. Как правило, чтобы все прошло гладко, со стороны мультисервисного сетевого оборудования необходимо предоставить для подключения АТС интерфейсы с сигнализацией, которая используется в существующих станциях. В нашем случае таковыми будут интерфейсы fractional E1 с сигнализацией ISDN PRI. В общем случае в возможности этой сигнализации входит передача вызываемого номера, вызывающего номера и символического имени абонента, чего вполне достаточно для организации единого корпоративного плана нумерации. Из-за того, что в случае коммутации звонков через городские АТС некоторая часть этой информации теряется (у операторов городской связи свой план нумерации), то мультисервисное оборудование корпоративной сети обязано прозрачно передавать всю служебную информацию в неизменном виде для обеспечения прозрачности мультисервисной сети.

Так как сигнализация ISDN PRI является так называемой сигнализацией по общему каналу (Common Channel Signaling, CCS), то есть по определенному логическому каналу передаются служебные сообщения о состоянии голосовых (bearer) каналов в виде структурированных данных, то функцию прозрачности устройств передачи голоса можно реализовать несколькими способами. Во-первых, не разбирая содержимого сигнальных сообщений, посылаемых устанавливающей соединение АТС, транслировать их на другое, заранее определенное, устройство, к которому подключена АТС назначения. В терминологии Cisco это носит название Transparent CCS (T-CCS). Положительным аспектом в данном механизме является то, что таким образом можно прозрачно передавать практически любую фирменную сигнализацию по общему каналу. Естественно, есть и обратная сторона медали: так как маршрутизатор не заглядывает внутрь сигнализации, то конечные точки T-CCS туннеля должны быть заранее статически сконфигурированы, что несколько уменьшает гибкость в маршрутизации звонков. Во-вторых, можно наоборот принимать сигнальные сообщения на ближайшем к АТС сетевом устройстве и разбирать их содержимое с целью выбора оптимального маршрута для данного звонка. Плюсы: самый близкий к источнику анализ звонка позволяет более гибко маршрутизировать звонки исходя из различных условий. Минусы: проблемы с фирменной сигнализацией.

Так что же все-таки выбрать? Неужели нет никакого компромисса? Оказывается, есть. Это протокол QSIG. Основанный на протоколе ISDN, он является открытым стандартом, расширяющим возможности АТС в частных сетях для обеспечения прозрачности некоторых функций. В стандартизации QSIG принимают участие такие организации как ECMA, ETSI, ISO. Протокол QSIG является открытым стандартом, что позволяет обеспечивать функциональную прозрачность в сетях, состоящих из оборудования разных производителей. Также этот протокол является транспортонезависимым, т.е. он может работать, например, как поверх соединения ISDN PRI, так и поверх ISDN BRI. Со стороны производителей телефонного оборудования поддержка QSIG реализована у Avaya, Alcatel, Ericsson, Siemens, Nortel и многих других. Естественно, Cisco Systems также реализовала поддержку QSIG в своих мультисервисных продуктах.

Не вдаваясь в подробности скажем, что сетевой QSIG имеет 3 подуровня, каждый из которых несет набор некоторых функций. Вот эти три подуровня:

• Установка базового соединения. Включает в себя обычные функции установки коммутируемого соединения.
• Базовые дополнительные сервисы. Включают в себя передачу имени и номера звонящего, переадресацию звонка, трансфер звонка, а также функции окончания звонка: завершение по занятости, по неответу.
• Дополнительные сервисы с перемаршрутизацией. Включают в себя переадресацию и трансфер звонков с перемаршрутизацией.

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

...и что из этого вышло

Рассмотрим схему сети, которая получилась после модернизации существующей с внесением в нее изменений, касающихся интеграции голоса. На первый взгляд ничего принципиально не изменилось: те же АТС, те же маршрутизаторы, те же выделенные каналы E1. Вот только АТС теперь подключены как к городской сети, так и к маршрутизаторам. Остановим выбор на протоколе QSIG в качестве сигнального между АТС и мультисервисным оборудованием корпоративной сети, а соединения с городскими АТС по протоколу ISDN PRI оставим без изменения в качестве резервных. Что же необходимо добавить и изменить в сетевом оборудовании для его готовности к функционированию в мультисервисной сети? Во-первых, это обеспечение качества обслуживания потоков данных реального времени, которое включает в себя набор соответствующих механизмов. Эти механизмы включены во все последние версии IOS и как правило не требуют изменения какого-либо аппаратного обеспечения узлов сети. Во-вторых, необходимо установить соответствующие интерфейсные модули для подключения традиционного телефонного облорудования. Также, вероятно, нужно будет заменить программное обеспечение IOS на маршрутизаторах для поддержки этих модулей. Итак, получается следующая конфигурация маршрутизаторов:

Здесь жирным шрифтом выделены дополнения к уже существовавшей конфигурации маршрутизаторов. Это S364CP-12205, ПО IOS IP Plus, включающее в себя поддержку голосовых интерфейсов. MEM3600-8U16FS и MEM3640-32U48D - дополнительные модули оперативной памяти и флэш-памяти, необходимой для функционирования обновленного ПО IOS. Также часть этой памяти будет использована модулем NM-HDV-1E1-30, являющимся интерфейсом в телефонную сеть и выполняющим функции компрессии-декомпрессии голосовых потоков для сохранения полосы пропускания распределенной сети. Этот модуль представляет собой плату с набором цифровых сигнальных процессоров (Digital Signaling Processors, DSPs), и имеющую слот расширения для установки в него собственно интерфейсного модуля к АТС. Этот интерфейсный модуль не надо заказывать дополнительно, он входит в поставку NM-HDV-1E1-30, и является обычным VWIC-1MFT-E1. Вот тут как раз и стоит вспомнить о букве V в названии модуля. Все дело в том, что этот модуль, как мы уже успели заметить, универсальный: он может быть использован как интерфейс доступа к распределенной сети (WIC), и как интерфейс к традиционному голосовому оборудованию. Отсюда и буква V - Voice. По сути своей, ничего принципиально голосового этот модуль сам не делает, поэтому его возможности по интеграции голосовых каналов реализуются только при поставке с NM-HDV-1E1-30. Эта связка модулей поддерживает довольно большой список телефонных сигнализаций, но как уже говорилось, в нашем случае им будет QSIG, сообщения которого будут анализироваться на граничных маршрутизаторах.

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

Сразу возникает вопрос: а чем пердача голоса по пакетным сетям лучше традиционных коммутируемых каналов? Аргументов несколько. Это уплотнение полосы пропускании, используемой в обычных АТС, с 64 Кбит/c до 8 или даже 5-6 Кбит/c (нюансы, связанные с накладными расходами на инкапуляцию голосовых пакетов в сетевые пока не рассматриваем - при любом раскладе полоса пропускания, потребующаяся компрессированным пакетам, не будет превосходить 64 Кбит/с); это возможность гибкой перемаршрутизации голосовых потоков в случае отказа основных каналов на резервные без обрыва соединения (что, кстати, в традиционной телефонии возможно делать на АТС не ниже городского уровня); и, наконец, реализация многих телефонных сервисов на компьютерных платформах, используя технологии компьютерно-телефонной интеграции (CTI).

Так как же все должно работать?

Разобравшись с протоколом сигнализации, зададимся вопросом: каким образом будет проходить установка соединения, шаг за шагом, начиная от набора номера абонентом на своем телефонном аппарате, заканчивая тем моментом, когда и вызываемый, и вызывающий абоненты услышат друг друга? Ясно, что этот процесс многоступенчатый и для традиционной телефонии, а уж для телефонии нового поколения - и подавно!

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

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

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

В случае, если вызываемый абонент в данный момент разговаривает по телефону, то вызывающему абоненту будет сгенерирован тон "занято". А если у вызывающего абонента на аппарате имеется некоторое количество свободных виртуальных линий, то на клавише, соответствующей следующей свободной линии, загорится индикатор вызова, на дисплее появится информация о новом поступившем звонке, и вызываемый абонент услышит КПВ. После принятия звонка вызываемым абонентом все произойдет точно также, как и в рассмотренном ранее случае.

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

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

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

	© TerraNet webmaster@terranet.ru