Принципы организации IP-телефонии на базе решений Cisco Systems
Сетевые решения Сетевые решения

Конечно, такое решение явно не подходит для организации телефонии в серьезной фирме, однако идея передачи голоса через сеть передачи данных очень заманчива, особенно если фирма имеет множество офисов в разных городах

Главная>Сетевые решения>Принципы организации IP-телефонии на базе решений Cisco Systems
Сетевые решения Обзор

Принципы организации IP-телефонии на базе решений Cisco Systems

Дата публикации:
11.03.2008
Посетителей:
7404
Просмотров:
7278
Время просмотра:
2.3

 

 

Введение

 

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

 

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

 

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

Передача голоса через IP-сеть

 

Инкапсуляция голосовых данных и расчет пропускной способности канала

 

Голос для передачи по сети сначала попадает на вход цифрового сигнального процессора DSP (Digital Signal Processor), где он порциями кодируется определенным кодеком. Выход с DSP инкапсулируется в PDU (единица данных протокола — фреймы, пакеты) и передается по сети.

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

 

Технология VoFR (Voice over Frame Relay — передача голоса по каналам Frame Relay) использует специальный заголовок FRF.11 (Рис. 1). Этот заголовок занимает, как минимум, три байта и служит для определения типа данных, которые содержатся во фрейме. Устройства VoATM (Voice over ATM — передача голоса по каналам ATM) используют такой же заголовок.

 

Рисунок 1. Поля, отвечающие за пометку приоритета

 

Пропускная способность канала, занимаемого одним голосовым звонком, зависит от следующих компонентов:

 

  • используемый кодек;
  • размер полезной нагрузки в пакете;
  • размер служебной информации в пакете.

Различные кодеки (сокращение от "кодер-декодер" — компонент системы, обеспечивающий сжатие и распаковку определенных данных) требуют разную полосу пропускания:

 

КодекТехнология сжатияБитрейт кодека (Кб/с)

G.711

PCM

64

G.726

ADPCM

16, 24, 32

G.728

LDCELP

16

G.729

CS-ACELP

8

G.729A

CS-ACELP

8

 

Занимаемую полосу пропускания можно вычислить, основываясь на битрейте (число битов потока, передаваемых за секунду; основная характеристика видео- или аудиопотока при сжатии) кодека, издержке пакетизации и размере полезной нагрузки в пакете.

 

Размер полезной нагрузки зависит от размера голосового сэмпла (звукового файла), который является величиной конфигурируемой и непосредственно влияет на требуемую полосу пропускания. Голосовой сэмпл — это выход с процессора DSP, инкапсулирующийся в PDU. Cisco использует DSP, обрабатывающие по 10 мс голоса. Оборудование Cisco по умолчанию инкапсулирует в PDU 20 мс голоса вне зависимости от используемого кодека. Это значение можно изменить, но при его увеличении требуемая полоса пропускания уменьшается, что может привести к увеличению переменных задержек (так называемых джиттеров — jitter) и появлению ощутимых разрывов в звучании, если пакет не дойдет до пункта назначения.

 

Размер сэмпла в байтах рассчитывается по формуле:

 

Рисунок 2.

где

Bytes_per_sample — размер сэмпла в байтах,

Sample_size — размер сэмпла в секундах,

Codec_bandwidth — битрейт используемого кодека.

 

Для вычисления полосы пропускания канала, занимаемой одним звонком, используется следующая формула:

Total_bandwidth=(Layer2_overhead+IP_UDP_overhead+Sample_size)/Sample_size*Codec_speed,

 

где

Layer2_overhead — объем служебной информации протокола канального уровня в байтах,

IP_UDP_RTP_overhead — размер заголовков протоколов IP, UDP и RTP в байтах,

Sample_size — размер сэмпла в байтах,

Codec_speed — битрейт используемого кодека.

 

Приведем примеры полосы пропускания, занимаемой одним звонком, при использовании кодеков G.711 и G.729 и различных размерах сэмплов. В качестве протоколов канального уровня возьмем Frame Relay и Ethernet II.

 

Размер служебной информации при использовании Ethernet II составляет 18 байт (6 байт — адрес назначения, 6 байт — адрес источника, 2 байта — тип, 4 — контрольная сумма); при использовании Frame Relay — 6 байт (2 байта — DLCI, 2 — FRF.12, 2 — контрольная сумма). Заголовки IP, UDP и RTP без компрессии занимают 40 байт (20 IP, 8 UDP, 12 RTP). Таким образом получаем распределение, представленное в Таб. 1.

 

Таблица 1.

КодекИсп. каналБитрейт, бит/сСэмпл, мсСэмпл, байтL2 OverheadIP/UDP/RTP OverheadЗаним. полоса пропуск-я, бит/с

G.711

Frame Relay

64000

10

80

6

40

100800

G.711

Ethernet II

64000

10

80

18

40

110400

G.711

Frame Relay

64000

20

160

6

40

82400

G.711

Ethernet II

64000

20

160

18

40

87200

G.711

Frame Relay

64000

30

240

6

40

76267

G.711

Ethernet II

64000

30

240

18

40

79467

G.729

Frame Relay

8000

10

10

6

40

44800

G.729

Ethernet II

8000

10

10

18

40

54400

G.729

Frame Relay

8000

20

20

6

40

26400

G.729

Ethernet II

8000

20

20

18

40

31200

G.729

Frame Relay

8000

30

30

6

40

20267

G.729

Ethernet II

8000

30

30

18

40

23467

 

Проблемы использования сети передачи данных для передачи голоса

 

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

Проблемы качества передачи голоса включают:

 

  1. Потери пакетов. Голосовые кодеки способны восполнять небольшие потери, но если они выше некоторого предела, то возможно прерывание голоса.
  2. Задержка. Сквозная задержка — это время, которое требуется для передачи пакета от передающего на принимающее устройство. Задержка складывается из постоянной и переменной составляющих. Постоянная составляющая может быть оценена при проектировании сети. Примеры постоянных задержек — время прохождения сигнала по сети, задержка кодирования, время пакетизации. Перегруженные очереди на интерфейсах и время выкладывания данных на физическую среду передачи данных (Serialization delay) рождают переменные задержки. Время выкладывания данных на физическую среду является функцией от скорости канала и размера пакета — чем больше пакет и меньше скорость канала, тем больше это время. Несмотря на то что это отношение известно, время выкладывания данных на физическую среду отнесено к переменным задержкам, потому что больший пакет может войти в очередь на интерфейсе в любой момент перед голосовым пакетом. В этом случае голосовой пакет будет ждать в очереди на интерфейсе, пока не будет обработан пакет перед ним.
  3. Различие времени задержек передачи от пакета к пакету (джиттер) — разница между ожидаемым и фактическим временем прихода очередного пакета. VoIP-устройства используют специальный буфер для установления постоянного темпа обработки пакетов, таким образом достигается плавность звучания голоса.

 

Технологии магистрали

 

Для обеспечения передачи различных типов трафика в магистральных каналах связи используются различные технологии:

 

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

 

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

 

Механизмы обеспечения качества передачи голосовых данных

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

 

VoIP гарантирует передачу голоса высокого качества только в том случае, если аудио- и сигнальные пакеты имеют приоритет перед любыми другими пакетами в сети. Для выполнения этого требования используется механизм QoS (Quality of Service). QoS — это методика обеспечения качества передачи определенных данных, основанная на разделении трафика по приоритетам для соответствующей его обработки. QoS обеспечивает лучший, более предсказуемый, сервис сети, выполняя следующие функции:

 

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

 

Программное обеспечение Cisco IOS (операционная система активного сетевого оборудования фирмы Cisco Systems) включает в себя полный набор средств обеспечения QoS в сети. Перечислим некоторые из них.

 

  • На выходных очередях маршрутизаторов применяются следующие методы ускорения обработки критичного трафика:

     

    • WFQ (Weighted Fair Queuing) и DWFQ (Distributed WFQ). Разделяет трафик на потоки, после чего распределяет его на вывод особым образом, обеспечивая поддержку заданной полосы пропускания и заданный диапазон задержек.
    • CBWFQ (Class-Based Weighted Fair Queuing). Расширяет функциональность WFQ, предоставляя поддержку пользовательских классов трафика. Можно самостоятельно задать специальный класс трафика для голоса, используя CBWFQ.
    • LLQ (Low Latency Queuing). Предоставляет строго приоритетную постановку в очередь на виртуальных соединениях ATM (VCs) и последовательных интерфейсах.
    • WRED и DWRED (Weighted Random Early Detection и Distributed WRED). Обеспечивает разные параметры производительности для различных классов трафика. Такая классификация гарантирует привилегированную обработку голосового трафика в условиях затора без усугубления ситуации.
  • В глобальной вычислительной сети и протоколах ГВС для улучшения качества обслуживания различных видов трафика применяются:

     

    • CAR (Committed access rate). Обеспечивает ограничение занимаемой полосы пропускания.

      FRTS (Frame Relay traffic shaping). Задерживает "чрезмерный" трафик, используя специальный буфер или механизм очереди для удержания пакетов и нормализации потока данных в случае, когда его объем выше ожидаемого.

      FRF.12. Обеспечивает лучшую пропускную способность на низкоскоростных линиях Frame Relay.

      IP to ATM class of service (CoS). Включает в себя обеспечение соответствия характеристик CoS между IP и ATM.

      MLP (Multilink PPP) с LFI (link fragmentation and interleaving). Фрагментирует большие пакеты. LFI также обеспечивает специальную очередь для передачи небольших, чувствительных к задержкам пакетов, позволяя им быть отосланными раньше других.

      CRTP (Compressed Real-Time Transport Protocol). Сжимает заголовки RTP, уменьшая расход полосы пропускания для голосового трафика.

      RSVP (Resource Reservation Protocol). Поддерживает резервирование ресурсов в IP-сети.

      Распространение политик QoS по протоколу BGP (Border Gateway Protocol). Обеспечивает распространение политик QoS на удаленные маршрутизаторы в сети по протоколу BGP.

 

Классификация и маркировка трафика

 

Классификация позволяет выделить из трафика определенный поток и затем применить к нему политики и действия различного характера. Классификация используется для маркировки, приоритизации, буферизации и т.д.

 

Для определения принадлежности трафика к тому или иному классу, что необходимо для принятия решения о способе его обработки, могут проверяться различные характеристики:

 

  • физический интерфейс, порт;
  • поля из заголовка фрейма 2-го уровня — MAC-адрес, биты поля CoS 802.1Q/P, VLAN id;
  • поля из IP-заголовка — IP Precedence, код DSCP, IP-адреса источника и/или назначения;
  • порты протоколов TCP и UDP;
  • сигнатуры из уровня приложений.

 

Классификация применяется для входящего и/или исходящего из маршрутизатора трафика.

Для маркирования пакета может быть использован заголовок второго уровня (802.1Q/p, FR DE bits) и/или поле TOS IP-заголовка (IP Precedence или DSCP).

 

Маркированный трафик упрощает применение единых правил приоритизации/обработки трафика для всех устройств в сети передачи данных, в том числе и для устройств провайдера услуг.

 

Маркировка трафика и перемаркировка рекомендована на входящем интерфейсе, как можно ближе к источнику трафика.

 

Механизмы очередей или устранения перегрузок на интерфейсах

 

Для регулирования возможных перегрузок на исходящем интерфейсе в ПО маршрутизатора (IOS) существует уровневая система буферизации пакетов. Подсистема L3 оперирует IP-пакетами, L2-буфер сильно зависит от канального протокола и L1-буфер (Tx Ring) работает на драйвере устройства.

 

Существует несколько алгоритмов регулировки очередей для подсистемы L3.

При наличии в сети VoIP-трафика компанией Cisco рекомендовано использовать LLQ (Low-Latency Queuing). Алгоритм основан на классификации потоков:

 

  • поддерживает очередь с безусловным приоритетом strict priority для голосового трафика и CBWFQ для трафика других приложений. Маршрутизатор обрабатывает только очередь strict priority, пока она не будет полностью обработана. Если очередь strict priority пуста, то весь остальной трафик обрабатывается по методике CBWFQ;
  • уменьшает возможные задержки голосовых пакетов и оптимизирует использование полосы пропускания канала.

 

Механизм сжатия заголовков RTP пакетов (cRTP)

 

На маршрутизаторах можно задействовать механизм сжатия заголовков RTP пакетов. В этом случае, вместо того чтобы передавать друг другу RTP-пакеты с заголовком в 40 байт (IP+UDP+RTP), они передают пакеты с заголовком в 2-5 байт. Передающий маршрутизатор заменяет исходный заголовок, а принимающий при приеме его восстанавливает.

 

Механизм не влияет на задержку VoIP-трафика. Уменьшает полосу канала, занимаемую голосовым трафиком.

Механизм cRTP имеет следующие характеристики:

 

  • используется только на соединениях point-to-point и не применяется при передаче пакетов через Ethernet и MPLS.
  • Механизм относится к процессам, работающим на канальном уровне (L2), то есть принимает пакеты после их обработки процессами третьего уровня.
  • Изменяет заголовок исходящего пакета. При приеме пакета заголовок должен быть декомпрессирован для его дальнейшей маршрутизации.
  • Уменьшает полосу, занимаемую голосовым трафиком, что необходимо учитывать при планировании политик очередей LLQ.
  • Механизм создает дополнительную нагрузку на CPU маршрутизатора. Не рекомендуется использовать при загрузке CPU более 70%.
  • Механизм зависим от протокола канального уровня. Работает только на каналах с инкапсуляцией типа HDLC, Frame Relay или PPP.
  • Возможно использование классификатора трафика (class based RTP) для применения механизма сжатия только к VoIP-пакетам, что уменьшает нагрузку на CPU маршрутизатора, так как применение механизма cRTP на интерфейсе автоматически включает сжатие TCP-заголовков для всех исходящих пакетов.
  • Механизм идентифицирует RTP-поток по UDP-портам.

 

Фрагментация пакетов (LFI)

 

Механизм поддерживает выполнение рекомендации ITU G.114 — устройство не должно обрабатывать голосовой пакет больше 20 мс. Механизм не изменяет занимаемую полосу канала. Уменьшает возможную задержку пакета и вариацию задержки (jitter) потока.

Механизм LFI имеет следующие характеристики:

 

  • пакеты, исходящие из высокоприоритетных очередей, не фрагментируются;
  • механизм относится к процессам, работающим на канальном уровне (L2);
  • рекомендованный интервал фрагментации (serialization) — 10 мс, для канала в 512 Kbps соответствует пакету размером 640 байт;
  • существуют два варианта механизма — Multilink PPP LFI и Frame Relay LFI (FRF.12).

 

Неэффективно использовать данный механизм на каналах более 1 Mbps.

 

Ошибки проектирования IP-телефонии

Отличительные черты неправильного проектирования:

 

  • игнорирование требований QoS на втором уровне модели OSI: QoS на втором уровне включает в себя FRF.11, LFI и планирование трафика;
  • игнорирование других требований QoS: такие сервисы как LLQ и сRTP должны быть включены;
  • игнорирование анализа пропускной способности: планирование количества звонков и их влияние на пропускную способность является критичным для всех пользователей сети;
  • простое добавление VoIP в существующую IP-сеть: при внедрении VoIP может потребоваться перепроектирование сети.

 

Краткий обзор протоколов VoIP

 

В технологии VoIP используются следующие протоколы:

 

  • H.323. Протокол ITU для интерактивной конференции. Был изначально предназначен для мультимедийного взаимодействия в сетях без установления соединения, таких как ЛВС.
  • MGCP (Media Gateway Control Protocol). Предназначен для управления VoIP шлюзов, подключенных к внешним устройствам управления вызовами. MGCP предоставляет сервис сигналлинга для недорогих конечных устройств, таких как шлюзы, которые не поддерживают в полном объеме стек сигналлинга, например H.323.
  • SIP (Session Initiation Protocol). Протокол, определяющий команды и ответы для установления и завершения телефонных вызовов. Также детализирует такие моменты как безопасность, прокси и транспортные сервисы.
  • RTP (Real-Time Transport Protocol). RTP доставляет голос через сеть. Обеспечивает очередность и маркировку времени для правильной последовательной обработки пакетов.
  • RTCP (RTP Control Protocol). Используется для передачи управляющей информации для протокола RTP. Любое RTP-соединение имеет соответствующее RTCP-соединение. RTCP используется для предоставления информации о качестве сервиса.

 

Соответствие протоколов VoIP уровням модели OSI:

 

Application

Софтфоны и приложения Call Manager

Presentation

Кодеки

Session

H.323/SIP/MGCP

Transport

RTP/UDP (голос), TCP/UDP (управление)

Network

IP

Data-Link

Frame Relay, ATM, Ethernet, MLPPP, PPP, HDLC ...

Physical

Физическая среда передачи

 

Принципы установления соединения

 

Абонентские устройства (Dial Peers)

Абонентское устройство (Dial Peer) — это адресуемая точка дозвона. Такие точки устанавливают логические соединения, называемые этапами дозвона (Call Legs), для завершения установления звонка. Маршрутизаторы Cisco, поддерживающие голосовые функции, поддерживают два типа абонентских устройств: POTS Dial Peer и VoIP Dial Peer.

 

POTS (Plane old telephone service) Dial Peer подключаются к традиционным телефонным сетям или традиционным телефонным аппаратам. Такие устройства выполняют функции по предоставлению адреса (телефонного номера или диапазона телефонных номеров) для конечного устройства (сети) и также указывают на конкретный голосовой порт, к которому конечное устройство (сеть) подключено.

 

VoIP Dial Peer подключаются через сеть передачи данных и предоставляют адрес назначения (телефонный номер или диапазон номеров) для конечного устройства в сети и ассоциируют адрес назначения со следующим маршрутизатором, на который звонок должен передаться.

 

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

 

Адрес абонентского устройства, называемый шаблоном назначения (destination pattern), сконфигурирован на каждом абонентском устройстве. Шаблон назначения может соответствовать как одному телефонному номеру, так и диапазону телефонных номеров. Маршрутизатор использует абонентские устройства для установления логических соединений (Call Legs) как в исходящем, так и во входящем направлениях.

 

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

 

В случае VoIP Dial Peer конфигурация маршрутизатора включает телефонный номер назначения (диапазон номеров) и сетевой адрес следующего маршрутизатора.

 

Этапы соединения

Этапы установления соединения (Call Legs) — это логические соединения между любыми двумя телефонными устройствами, такими как шлюзы, маршрутизаторы, приложения Cisco CallManager или оконечные телефонные устройства.

 

Когда поступает входящий вызов, он обрабатывается отдельно, пока не будет определен пункт назначения. После этого устанавливается исходящее соединение, и входящий вызов коммутируется с исходящим портом.

 

Сквозной звонок состоит из четырех этапов соединения: два с точки зрения маршрутизатора, на котором звонок возникает, и два с точки зрения маршрутизатора, на котором телефонное соединение завершается.

 

Входящий этап соединения возникает, когда вызов входит в маршрутизатор или шлюз, исходящий — когда вызов совершается маршрутизатором или шлюзом.

 

Процесс установления телефонного соединения можно описать следующими шагами (Рис. 3):

 

Рисунок 3. Этапы соединения

Рисунок 4. Этапы соединения с точки зрения маршрутизаторов.

  1. Звонок с традиционного телефона приходит на R1 и абонентское устройство, инициировавшее вызов, идентифицировано.
  2. После ассоциирования входящего вызова с абонентским устройством R1 создает входящий этап соединения и назначает ему идентификатор Call ID (Call Leg 1).
  3. R1 использует строку набора с целью определения абонентского устройства для совершения исходящего шага соединения.
  4. После определения абонентского устройства, с которым будет устанавливаться соединение, R1 создает исходящий шаг соединения и назначает ему идентификатор (Call Leg 2).
  5. Сетевой запрос поступает на маршрутизатор 2 (R2), на котором происходит идентификация вызывающего сетевого абонентского устройства.
  6. После определения сетевого абонентского устройства, с которого поступил запрос, R2 создает входящее соединение и назначает ему идентификатор (Call Leg 3). Здесь R1 и R2 согласовывают параметры при необходимости.
  7. R2 использует строку набора с целью определения абонентского устройства для совершения исходящего шага соединения.
  8. После определения абонентского устройства R2 создает исходящий вызов с назначением ему идентификатора и завершает процесс соединения (Call Leg 4).

 

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

 

Протоколы VoIP

 

Стек протоколов H.323 является одним из самых распространенных на сегодня. Это старейший и наиболее стабильный из всех используемых сейчас протоколов, поэтому он требует особого внимания.

 

Протокол инициации сессий (SIP) — это относительно новый протокол, получающий широкое распространение. Он является значительно более молодым относительно H.323 и поэтому пока не получил такого же масштабного распространения.

 

Протокол MGCP — это управляющий VoIP-протокол, который наиболее часто используется для управления шлюзами в VoIP-сети. Относительно новый протокол MGCP получил широкое распространение как часть архитектуры Cisco AVVID. AVVID обычно использует именно MGCP в связке с CCM для управления шлюзами.

 

H.323

 

Как уже говорилось, H.323 является набором протоколов. Взаимодействие протоколов H.323 показано на Рис. 5.

 

Рисунок 5. Взаимодействие протоколов H.323

 

Все устройства, используемые H.323, можно поделить на четыре категории: терминалы, шлюзы, гейткиперы (Gatekeeper — привратник) и точки многопунктового контроля (Multipoint Control Unit — MTU).

 

Терминалы, также называемые конечными точками (endpoints), предоставляют пользовательский интерфейс к протоколу H.323 и обеспечивают двустороннюю мультимедийную связь реального времени. Шлюзы выполняют роль "переводчиков" для обеспечения взаимодействия между H.323 и не-H.323 сущностями. Шлюзы, так же как и терминалы, рассматриваются как конечные точки. Гейткиперы выполняют функции контроля вызовов, такие как трансляция адресов и управление занимаемой полосой пропускания. Гейткиперы можно считать наиболее важным компонентом в стеке H.323. MCU обеспечивают возможность конференций.

 

Стек протоколов H.323

IP, TCP, UDP

 

Протоколы IP, TCP и UDP несомненно являются протоколами стека TCP/IP, но они здесь рассматриваются потому, что предоставляют транспортный сервис для стека протоколов H.323.

 

Каждый терминал, шлюз, гейткипер и MCU должен иметь свой уникальный IP-адрес. Это также относится и к ПК с приложениями, которые используют H.323. IP предоставляет каждой точке H.323-адрес и обеспечивает механизм маршрутизации H.323-пакетов в сети. TCP используется для установления начального соединения между терминалами H.323 и шлюзами/гейткиперами. Протокол UDP используется для передачи непосредственно голоса через сеть.

 

H.225

H.225 обеспечивает установление и контроль вызовов со всей необходимой сигнализацией для осуществления соединения между двумя конечными точками.

 

H.245

Управляющая сигнализация H.245 применяется для согласования использования канала и возможностей. Управляющие сообщения несут информацию, относящуюся к следующим моментам:

 

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

 

После установления вызова все процессы передачи информации проходят по логическим каналам.

 

RAS

 RAS — это протокол, использующийся между конечными точками (терминалами и шлюзами) и гейткиперами. Он применяется для осуществления регистрации, контроля доступа, статуса и изменений доступной полосы пропускания, а также для отключения конечных точек от гейткипера. RAS использует порт UDP 1719.

 

RTP

 RTP предоставляет сквозной сетевой транспорт для приложений, передающих данные реального времени. Он использует для передачи данных протокол UDP. Передача данных сопровождается управляющим протоколом (RTCP) для мониторинга доставки данных.

 

Кодеки

Кодеки используются не только протоколом H.323, а всеми протоколами VoIP для определения алгоритмов компрессии и декомпрессии, применяемых для передачи аудио/видео по сети. H.323 поддерживает большинство стандартов кодирования аудио и видео, включая G.7XX для аудио и H.26X для видео.

 

Рис. 6 иллюстрирует взаимодействие протоколов стека H.323.

Рисунок 6. Стек протоколов H.323

 

Этапы соединения

Процедуры соединения при формировании звонка по протоколу H.323 могут быть сгруппированы в пять этапов:

 

  1. Обнаружение и регистрация.
  2. Установление вызова.
  3. Сигнальный поток.
  4. Медийный поток и поток управления.
  5. Завершение вызова.

 

Обнаружение и регистрация устройств

 

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

 

Регистрация используется конечной точкой для определения зоны, с которой она может быть ассоциирована. Зона — это набор компонентов, управляемых одним гейткипером. После определения зоны привратник информируется об адресе зоны (Рис. 7).

 

Рисунок 7. Процесс регистрации

 

Внутризоновые вызовы

Допустим, шлюзы (терминалы) уже зарегистрированы, и шлюз X хочет сделать вызов на терминал, подключенный к шлюзу Y. Шлюз X посылает ARQ (Admission Request) сообщение гейткиперу, запрашивая разрешение на установление вызова на телефон, обслуживаемый шлюзом Y. Гейткипер разрешает вызов с требованием сигнализации (дозвона) напрямую, посылая сообщение ACF (Admission Confirmation). См. Рис. 8.

 

Рисунок 8. H.323. Установление внутризонового вызова

 

Межзоновые вызовы

Допустим, гейткипер A контролирует зону A, а гейткипер B — зону B, шлюз X зарегистрирован на гейткипере A, а шлюз Y — на гейткипере B, и шлюз A хочет установить соединение с терминалом, подключенным к шлюзу Y.

Процесс установления вызова содержит следующие этапы (Рис. 9):

 

Рисунок 9. H.323. Установление межзонового вызова

  1. Шлюз X запрашивает соединение со шлюзом Y у своего локального гейткипера.
  2. Запрос местоположения (LRQ — Location request). Гейткипер шлюза X не знает IP-адрес шлюза Y и запрашивает адрес у гейткипера шлюза Y.
  3. Местоположение подтверждено (LCF — Location confirm). Гейткипер шлюза Y отвечает IP-адресом шлюза Y.
  4. Гейткипер шлюза X подтверждает его запрос и предоставляет ему IP-адрес шлюза Y.
  5. Установление соединения между шлюзами.

 

Установление соединения

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

Установление соединения основано на протоколе ITU-Q.931 (H.225 является подмножеством Q.931), который определяет метод установления, обработки и завершения сетевого соединения по цифровой сети ISDN. Процесс состоит из шести фаз (Рис. 10):

 

Рисунок 10. Установление соединения

  1. Шлюз X посылает H.225 сообщение установления дозвона для запроса соединения.
  2. Шлюз Y посылает обратно H.225 сообщение, заявляя о возможности продолжения процесса.
  3. Шлюз Y запрашивает у гейткипера правомерность звонка, посылая ему RAS-сообщение (ARQ) по каналу RAS.
  4. Гейткипер подтверждает, что звонок правомерен, посылая шлюзу Y ACF-сообщение.
  5. Шлюз Y посылает H.225-сообщение шлюзу X, оповещая его, что соединение установлено.
  6. Шлюз Y посылает H.225-сообщение шлюзу X, оповещая его, что вызов установлен.

 

Установление логических каналов

После того как соединение установлено, взаимодействие происходит по логическим каналам. H.245 используется для определения процесса управления этими каналами. На один вызов может приходиться несколько каналов для различных типов трафика (видео, аудио, данные). H.245 LCSE (Local Channel Signaling Entity) открывает логический канал для каждого потока. Каналы могут быть как однонаправленными, так и двунаправленными.

Установление логических каналов происходит следующим образом:

 

  1. Шлюз X сообщает шлюзу Y, какие возможности он поддерживает, посылая H.245 Terminal Capability Set сообщение.
  2. Шлюз Y подтверждает запрос, посылая H.245 Terminal Capability Set Acknowledge сообщение.
  3. Аналогичен п.1, но только в обратном направлении.
  4. Аналогичен п.2, но только в обратном направлении.
  5. Шлюз X открывает медиаканал со шлюзом Y, посылая H.245 сообщение Open Logical Channel, включая адрес RTCP канала.
  6. Шлюз Y подтверждает установление логического канала со шлюзом X, посылая H.245-сообщение Open Logical Channel Acknowledge, включая RTP-адрес, выделенный шлюзом Y, и RTCP-адрес, полученный от шлюза X.
  7. Аналогичен п.5, но только в обратном направлении.
  8. Аналогичен п.6, но только в обратном направлении.

 

Медийный поток и поток управления

Медийный поток управляется RTCP. RTCP использует выделенный логический канал для каждого RTP-потока. Конечные точки могут попытаться изменить выделенную полосу пропускания, которую они изначально запросили. Для увеличения выделенной полосы пропускания конечные точки должны запросить на это разрешение у гейткипера.

 

Завершение вызова останавливает медиапоток и закрывает логические каналы. Оно может быть запрошено как конечными точками, так и гейткипером. Завершение вызова также завершает H.245-сессию, освобождает H.225/Q.931 соединение и предоставляет гейткиперу подтверждение о разъединении по RAS.

 

Сигнализация между конечными точками без посредника в H.323

Если шлюзы знают IP-адреса друг друга, то возможно их взаимодействие без гейткипера. Этот процесс можно описать следующими шагами:

  1. Шлюз инициирует H.225.0-сессию со шлюзом назначения.
  2. Процедура установления вызова, базирующаяся на Q.931, создает сигнальный канал между конечными точками.
  3. Конечные точки открывают канал для функций управления H.245. Происходит обмен возможностями и дескрипторами логических каналов.
  4. Открывается RTP-сессия.

 

MGCP

 

Протокол MGCP представляет собой пример модели с централизованным управлением вызовами. Он определяет управление телефонными шлюзами с центрального управляющего компонента, называемого телефонным агентом (Call Agent). Шлюзы взаимодействуют с агентами, которые осуществляют сигнализацию и обработку вызовов.

 

Компоненты MGCP

В MGCP-окружении используются следующие компоненты:

 

  • конечные точки;
  • шлюзы;
  • телефонный агент (назовем для краткости агентом).

 

Конечные точки — это точки соединения пакетной сети и традиционной телефонной сети. Они могут быть физическими и логическими. Шлюзы — это узлы объединения конечных точек.

 

Телефонный агент MGC (Media Gateway Controller) представляет собой центральный управляющий элемент в MGCP-окружении. MGC осуществляет управление деятельностью шлюзов в предположении, что шлюзы фиксируют события и докладывают о них. Агент, основываясь на событиях, инструктирует шлюзы о действиях, которые необходимо предпринимать. Он также инициирует все VoIP-этапы соединения.

 

Понятия MGCP

Базовые понятия MGCP:

 

  • вызовы и соединения. Позволяют устанавливать сквозные соединения двух и более конечных точек.
  • События и сигналы. Позволяют телефонным агентам инструктировать шлюзы.
  • Цифровые карты и пакеты. Позволяют шлюзам определять пункт назначения вызовов.

 

Рисунок 11. Компоненты MGCP

 

Взаимодействие агентов и шлюзов

Процесс взаимодействия телефонного агента со шлюзами для обеспечения телефонного вызова можно описать следующей последовательностью действий (Рис. 11):

 

Рисунок 12. Взаимодействие шлюзов с агентом

 

  1. Агент направляет сообщение RQNT (Request Notification) каждому шлюзу. Этот запрос дает инструкцию шлюзам ждать события off-hook (когда снимается телефонная трубка) и дать гудок, когда такое событие произойдет. Агент также сообщает о необходимости мониторинга других событий. Предоставляя цифровую карту в запросе, агент позволяет шлюзам собрать цифры перед тем как информировать о событии агента (иначе шлюз не будет "знать", когда набор номера завершается, будет вынужден посылать агенту все цифры набора по одной).
  2. Шлюз отвечает на запрос. С этого момента агент и шлюзы ждут событий.
  3. Пользователь на шлюзе А поднял трубку. Следуя инструкции, шлюз дает телефонный гудок. Так как у шлюза есть карта номеров, он начинает собирать набираемые цифры, пока не будет получено соответствие (или пока набранные цифры не покажут, что соответствие невозможно).
  4. Шлюз А посылает оповещение (NTFY) агенту, сообщая ему, что требуемое событие произошло. Оповещение включает в себя конечную точку, событие и набранные цифры.
  5. После подтверждения возможности звонка агент инструктирует шлюз А создать соединение (CRCX) с его конечной точкой.
  6. Шлюз отвечает дескриптором сессии. Дескриптор определяет, как минимум, IP-адрес и UDP-порт для последующей RTP-сессии. Шлюз не имеет дескриптора сессии удаленной стороны, и соединение переходит в режим ожидания.
  7. Агент отправляет запрос на соединение шлюзу В. В запросе агент предоставляет дескриптор сессии, который он получил от шлюза А. Агент также посылает инструкции о том, какие в данный момент события важны и какие сигналы шлюзу генерировать. В данном случае таким событием является off-hook, сигналом — звонок.
  8. Шлюз В отвечает на запрос и сообщает свой дескриптор сессии.
  9. Агент передает дескриптор сессии шлюзу А в запросе MDCX (Modify Connection). Теперь шлюзы могут установить RTP-сессии для передачи голоса.
  10. В конце вызова одна из конечных точек распознает переход в состояние on-hook (трубка повешена). Допустим, это случилось на шлюзе А. Так как агент проинструктировал сообщить о таком событии, шлюз А посылает агенту уведомление.
  11. Агент рассылает сообщение DLCX (Delete Connection) каждому шлюзу.
  12. Шлюзы удаляют соединения и отвечают.

Архитектура AVVID

 

Cisco AVVID

 

Решение Cisco для построения сетей IP-телефонии основано на использовании архитектурной модели Cisco AVVID (Architecture for Voice, Video and Integrated Data) и предназначено для решения следующих основных задач:

 

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

 

Кроме того, данное решение позволяет создать сеть видеотелефонии, которая может быть частью корпоративной IP телефонной системы.

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

 

Архитектура предлагаемого решения позволяет технологически и экономически эффективно создать географически распределенную сеть корпоративной телефонии.

 

Решение Cisco IP-телефонии состоит из следующих основных компонентов:

 

  • интеллектуальная сетевая инфраструктура на базе протокола IP, включающая маршрутизаторы, коммутаторы, шлюзы и другое сетевое оборудование. IP-инфраструктура является основой для дальнейшего внедрения пользовательских приложений и должна обеспечивать поддержку таких жизненно важных для сети сервисов, как безопасность, сетевое управление и механизмы качества обслуживания (QoS). В рамках архитектуры Cisco AVVID интеллектуальная сетевая инфраструктура используется наряду с передачей данных для функционирования корпоративной телефонной и видеотелефонной системы.
  • Интеллектуальные клиентские устройства с поддержкой протокола IP, в том числе цифровые IP-телефоны Cisco, видеоустройства, персональные компьютеры со специализированным программным обеспечением для решения различных бизнес-задач, программные эмуляторы телефонов (например, Cisco IP Communicator) и так далее.
  • Управление корпоративной системой IP-телефонии, а также видеотелефонии Cisco осуществляется специализированным приложением Cisco CallManager либо кластером Cisco CallManager. Кроме того, в системе могут использоваться дополнительные служебные устройства и приложения, такие как корпоративная служба каталогов, которая служит централизованным хранилищем информации об абонентах в телефонной и видеосистеме, а также служебные устройства для обеспечения аудио- и видеоконференций, H.323-гейткиперы и т.д.
  • Современные телефонные приложения, возникшие благодаря развитию интегрированных систем с поддержкой голоса, видео- и данных, например, системa унифицированной обработки сообщений (Unified Messaging), интеллектуальные центры обработки вызовов (Contact Center), мультимедийные системы организации конференций. Внедрение подобных приложений создает дополнительные возможности для пользователей/абонентов корпоративной телекоммуникационной сети, повышает удобство и эффективность использования системы.

 

Управляющий сервер Cisco CallManager обеспечивает управление установлением телефонных соединений и видеосоединений в системе. CallManager также управляет предоставлением дополнительных функций абонентам, использующим как IP-телефоны, так и видеоустройства. Он также обеспечивает администратора сети средствами для настройки и управления взаимодействием различных компонентов системы IP-телефонии.

Специализированные цифровые IP-телефоны Cisco подключаются в коммутируемую локальную сеть Ethernet 10/100 и обеспечивают как традиционную функциональность цифровых телефонов, так и ряд новых возможностей.

 

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

 

Преимущества применения Cisco AVVID:

 

  • скорость внедрения новых сервисов;
  • надежность;
  • возможность взаимодействия различных сетей;
  • снижение материальных расходов.

 

Архитектура AVVID состоит из четырех уровней:

  1. Инфраструктурный уровень — это фундамент сети.
  2. Уровень обработки вызовов, выполняющий функции коммутации вызовов. Его функции схожи с функциями УАТС при использовании традиционных технологий телефонии.
  3. Уровень приложений, обеспечивающих дополнительную функциональность.
  4. Клиентский уровень, на котором располагаются устройства и приложения, с которыми пользователь непосредственно взаимодействует.

 

Рисунок 13. Уровни архитектуры AVVID

 

Модели развертывания

Cisco поддерживает следующие модели развертывания IP-телефонии:

 

  • однообъектная;
  • с централизованной обработкой вызовов;
  • с распределенной однокластерной обработкой вызовов;
  • с распределенной многокластерной обработкой вызовов.

 

Однообъектная модель

В однообъектной модели развертывания (Рис. 14) все приложения CCM и DSP-ресурсы физически расположены в одном месте.

 

Рисунок 14. Однообъектная модель AVVID

 

Отличительные черты модели:

 

  • CCM, DSP и приложения находятся в одном месте;
  • поддержка приблизительно 36 тыс. IP-телефонов на кластер;
  • несколько кластеров могут быть соединены с помощью транков;
  • для внешних звонков используется телефонная сеть общего назначения (PSTN).

 

Модель с централизованной обработкой вызовов

Данная модель (Рис. 15) подразумевает CCM-кластер на центральном узле и соединения к удаленным узлам через сеть передачи данных (IP-сеть с соблюдением QoS). Удаленные узлы обращаются к центральному CCM-кластеру для обработки вызовов. Приложения, такие как голосовая почта и автоответчик, обычно располагаются на центральном узле. Такая организация уменьшает затраты на содержание оборудования и обеспечивает централизованное администрирование и обслуживание.

 

Рисунок 15. Структура модели с централизованной обработкой вызовов.

 

Сеть передачи данных может быть построена на технологиях выделенных линий, Frame Relay, ATM. На маршрутизаторах, стыкующихся с сетью передачи данных, должны быть реализованы механизмы QoS, такие как установка приоритетов на очередях и контроль трафика, для "защиты" голосового трафика от других типов трафика в сети.

 

В данной модели для защиты сети передачи данных от перегрузки может потребоваться контроль доступа (CAC). В версии CCM Release 3.3 используется возможность автоматического выбора маршрута (AAR — Automated Alternate Routing). AAR позволяет CCM динамически перенаправлять вызовы через телефонную сеть общего пользования, когда сеть передачи данных перегружена, для предотвращения ухудшения качества установленных вызовов.

 

Телефонная сеть общего назначения используется как резервная. Можно также применять технологию ISDN в качестве резервного канала передачи данных, но ISDN не годится для передачи голоса, так как не поддерживает требования QoS. Даже если удаленный офис потеряет связь с кластером CCM, обработка вызовов может быть осуществлена при помощи технологии безотказной телефонии удаленного узла (SRST — Survivable Remote Site Telephony), доступной при использовании маршрутизаторов Cisco IOS. На время потери связи с CCM эта технология будет обеспечивать внутреннюю коммутацию вызовов в удаленных точках.

 

Модели с распределенной обработкой вызовов

CCM-кластеры могут присутствовать во всех узлах, в этом случае локальная коммутация вызовов будет производиться без участия центрального узла. Также имеется возможность разнести компоненты одного CCM-кластера по разным точкам (Рис. 16 и Рис. 17).

 

Рисунок 16. Многокластерная модель с распределенной обработкой вызовов.

Рисунок 17. Однокластерная модель с распределенной обработкой вызовов.

 

Процесс регистрации IP-телефонов

 

Каждый раз, когда IP-телефон загружается, происходит следующий процесс:

  1. Если используется коммутатор Cisco с поддержкой питания, коммутатор посылает специальный FLP (Fast Link Pulse) сигнал. Коммутатор использует этот сигнал, чтобы определить, подключен ли к нему IP-телефон, требующий питания. В обесточенном состоянии IP-телефон Cisco возвращает сигнал, запрашивая тем самым коммутатор подать напряжение 48 вольт постоянного тока.
  2. После того как IP-телефон получил питание и загрузился, коммутатор посылает ему CDP (Cisco Discovery Protocol) пакет с информацией виртуальной голосовой локальной сети (если сконфигурировано).
  3. IP-телефон посылает широковещательный запрос DHCP-серверу. DHCP-сервер возвращает телефону, как минимум, IP-адрес, маску подсети и IP-адрес Cisco TFTP-сервера.
  4. Телефон соединяется с TFTP-сервером и получает с него свою конфигурационную информацию, содержащую перечень CCM (до трех CCM).
  5. Телефон пытается зарегистрироваться с первым CCM из перечня, полученного с TFTP-сервера.

 

Коммутация на Cisco CallManager

 

CCM маршрутизирует два типа вызовов:

  1. Внутренние (on-cluster).
  2. Внешние (off-cluster).

 

Коммутация внутренних вызовов

Когда поступает вызов с IP-телефона, CCM анализирует набранный номер. Если он соответствует DN (Directory Number), зарегистрированному на том же CCM-кластере, CCM направляет вызов на IP-телефон назначения, ассоциированный с соответствующим DN. Это внутренний (on-cluster) вызов. CCM позволяет обрабатывать такие вызовы без направления его на внешний шлюз.

 

Не только IP-телефоны могут выступать в роли устройств, способных инициировать и принимать внутренние вызовы, это может быть любое устройство с зарегистрированным на CCM DN. Например, такими устройствами могут быть Cisco софтфоны и аналоговые телефоны, подключенные к MGCP-шлюзам или шлюзам, работающим по протоколу Skinny.

 

Коммутация внешних вызовов

Если на IP-телефоне набирается номер, для которого не нашлось соответствующего DN, значит, имеет место внешний (off-cluster) вызов. CCM в этом случае просматривает свою таблицу внешних маршрутов, чтобы определить, куда направить вызов. CCM использует концепцию таблиц маршрутов и шаблонов трансляций для определения, куда и как направлять внешний вызов.

 

Можно создавать планы маршрутизации для внешних вызовов, используя трехъярусную архитектуру, которая предоставляет несколько уровней маршрутизации и манипуляций с цифрами. Шаблон маршрута (Route Pattern) определяет по номеру дозвона список маршрутов (Route List), который выберет доступный путь для исходящего звонка на основе приоритетов. Эти пути Cisco определяет как "группы маршрутов" (Route Group).

Уровни выбора маршрута показаны на Рис. 18.

 

Рисунок 18. Элементы маршрутизации внешних вызовов в CCM.

 

Процесс конфигурирования маршрутов для внешних вызовов содержит следующие этапы:

 

  • добавление шлюзов;
  • создание групп маршрутов из доступных устройств;
  • создание списков маршрутов из доступных групп маршрутов;
  • создание шаблона маршрута и ассоциирование его с доступным списком маршрутов или шлюзом.

 

Шаблон маршрута является ключевым элементом в плане маршрутизации. Он определяет набранный номер и направляет вызов на подходящий шлюз.

 

Когда набранный номер соответствует шаблону маршрута, CCM направляет вызов на соответствующий список маршрутов или шлюз.

Шлюзы

 

Шлюзы — это устройства, позволяющие CCM взаимодействовать с не-IP-сетями, такими как телефонная сеть общего пользования (PSTN). Cisco разделяет свои шлюзы на две главные категории — аналоговые и цифровые. Аналоговые шлюзы могут быть шлюзами станций или транковыми шлюзами.

 

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

 

Цифровые шлюзы обеспечивают то же подключение к телефонной сети общего пользования или УАТС, однако они используют цифровые технологии подключения, такие как PRI CCS и транки T1 CAS.

CCM поддерживает три типа шлюзов:

 

  • MGCP-шлюзы. Использует модель клиент-сервер, в которой CCM управляет шлюзом. MGCP-шлюзы поддерживают все дополнительные сервисы CCM, избыточность CCM и бесперебойность вызовов. Дополнительным преимуществом таких шлюзов является их несложное конфигурирование.
  • Non-IOS MGCP-шлюзы. Аналогичны MGCP-шлюзам, но не поддерживают бесперебойность вызовов.
  • H.323-шлюзы. Используют одноранговую модель. Большая часть конфигурации производится непосредственно на шлюзе. При одноранговой модели CCM не имеет контроля над шлюзом, что приводит к уменьшению количества доступных сервисов CCM при использовании таких шлюзов. Зато H.323-шлюзы поддерживают дополнительную функциональность Cisco IOS — CAC и SRST.

 

Помимо перечисленных здесь, существует еще один тип шлюзов — межкластерный транк. Это логический шлюз, который используется для коммуникации между кластерами CCM.

 

Примеры конфигураций

 

Конфигурация абонентских устройств

 

Для того чтобы сконфигурировать POTS Dial Peer (традиционное телефонное устройство), нужно:

  1. Сконфигурировать абонентское устройство типа POTS.
  2. Сконфигурировать телефонный номер.
  3. Указать, к какому порту устройство подключено.

 

Рисунок 19. Примеры конфигурации.

 

Если к голосовому порту подключена УАТС, то вместо телефонного номера может быть сконфигурирован диапазон номеров.

Для конфигурирования VoIP Dial Peer администратор должен знать, как идентифицировать устройство на другом конце линии — это может быть IP-адрес устройства, а может быть Cisco CallManager или гейткипер (gatekeeper), используюемые для разрешения адресов и управления доступа вызовов (CAC — call admission control) для завершения установления вызова.

 

Для конфигурирования VoIP Dial Peer необходимо выполнить следующие шаги:

 

  1. Сконфигурировать путь через сеть для голосовых данных.
  2. Определить абонентское устройство как VoIP Dial Peer.
  3. Сконфигурировать телефонные номера, доступные через удаленный маршрутизатор (шлюз).
  4. Сконфигурировать IP-адрес маршрутизатора (шлюза), на котором установление телефонного соединения заканчивается.
  5. В качестве IP-адреса использовать адрес самого устройства, а не адрес его порта.

 

Методы конфигурирования диапазонов телефонных номеров

 

Для конфигурирования телефонных номеров используются так называемые шаблоны назначения (Destination Pattern).

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

 

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

 

  • Плюс (+): опционный символ, указывающий на номер стандарта E.164. E.164 — это рекомендации ITU-T (International Telecommunication Union Telecommunication Standardization Sector) для интернационального плана нумерации. Знак плюс ставится впереди строки, определяющей шаблон назначения, и означает, что строка должна соответствовать рекомендациям E.164.

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

     

    • звездочка (*) и решетка (#). Эти символы всегда есть на стандартных клавиатурах кнопочных телефонов. Они могут использоваться в автоматических телефонных системах, таких как автоответчик.
    • Запятая (,) вставляет односекундную паузу между набираемыми цифрами. Запятая может быть использована, например, когда набирается 9 для выхода в телефонную сеть общего назначения через УАТС — пауза дает УАТС время для коммутации с телефонной сетью общего назначения.
    • Точка (.) — соответствует любой цифре. Используется для задания диапазона телефонных номеров.
    • Квадратные скобки ([]) — обозначают диапазон. Например "20[0-4]." соответствует диапазону номеров от 2000 до 20049.
  • T. Опционный контрольный символ, обозначающий, что значение шаблона является строкой переменной длины. Маршрутизатор накапливает набираемые цифры до тех пор, пока интервал между ними не превысит сконфигурированного значения (которое по умолчанию составляет 10 секунд). После окончания набора, чтобы не ждать, пока истечет таймаут, можно набрать решетку и тогда маршрутизатор начнет обрабатывать запрос немедленно.

 

Список используемых сокращений

 

ПК — персональный компьютер.

ПО — программное обеспечение.

УАТС — учрежденческая автоматическая телефонная станция.

AAR — автоматический выбор маршрута (Automated Alternate Routing).

AVVID — архитектурная модель фирмы Cisco Systems (Architecture for Voice, Video and Integrated Data).

CCM — ПО фирмы Cisco Systems, выполняющее функции коммутации телефонных вызовов (Cisco CallManager).

CPU — центральный процессор (Central Processor Unit).

cRTP — механизм сжатия заголовков RTP (Compressed RTP).

DHCP — протокол динамической конфигурации хоста (Dynamic Host Configuration Protocol).

DSP — цифровой сигнальный процессор (Digital Signal Processor).

FLP — служебный сигнал коммутатора фирмы Cisco (Fast Link Pulse).

FRF.11 — стандарт, применяющийся при передаче голоса по протоколу Frame Relay (Frame Relay Forum standard 11).

FXO — тип порта (Foreign Exchange Office).

FXS — тип порта (Foreign Exchange Station).

H.323 — стек протоколов для передачи аудио- и видеоинформации по сети.

IP — маршрутизируемый сетевой протокол (Internet Protocol).

ISDN — цифровая сеть с интеграцией служб (Integrated Services Digital Network).

ITU — Международный Телекоммуникационный Союз (International Telecommunications Union).

MGC — управляющий элемент MGCP (Media Gateway Controller).

MGCP — протокол управления шлюзами (Media Gateway Control Protocol).

PDU — единица данных протокола (Protocol Data Unit).

POTS — аналоговые телефонные сети связи (Plane Old Telephone Service).

PSTN — телефонная сеть общего пользования. (Public Switched Telephone Network).

QoS — качество сервиса (Quality of Service).

RAS — регистрация, управление, статус (Registration, Administration, and Status).

RTCP — протокол, использующийся совместно с RTP (RTP Control Protocol).

RTP — протокол для передачи данных реального времени (Real-Time Transport Protocol).

SIP — протокол инициирования сессий (Session Initiation Protocol).

TFTP — простой протокол передачи файлов (Trivial File Transfer Protocol).

UDP — протокол пользовательских датаграмм (User Datagram Protocol).

VoATM — технология передачи голоса по протоколу ATM.

VoFR — технология передачи голосовых данных по протоколу Frame Relay (Voice over Frame Relay).

 

Литература

 

[1] Cisco Voice Over IP. Student Guide -- Cisco Systems Inc, 2003

[2] Cisco IP Telephony. Student Guide. Version 3.3. -- Cisco Systems Inc, 2002

[3] Robert Padjen -- Cisco AVVID and IP Telephony. Design & Implementation -- Syngress Publishing Inc, 2001

[4] Paul J. Fong -- Configuring Cisco Voice Over IP. Second Edition -- Syngress Publishing Inc, 2001

[5] http://www.cisco.com/global/RU/products/netsolutions/networking_solutions_package.shtml

Уведомления об обновлении тем – в вашей почте

Аналитическая информация без человеческого фактора

Рассматриваются варианты подготовки аналитической информации для руководства компании до и после внедрения BI-решения

SDDC - основа новой облачной инфраструктуры

Термин «программно-определяемый ЦОД» (Software Defined Datacenter, SDDC) в последнее время встречается все чаще. Что за ним скрывается?

The Standoff: топ-10 самых ярких ИБ-фактов

С 12 по 17 ноября компания Positive Technologies провела киберполигон The Standoff — мероприятие, где на виртуальной платформе проводили киберучения и стримы с ИБ-экспертами со всего мира.

О каналах скрытых, потайных, побочных и не только

Пик исследований в области скрытых каналов приходится на середину 1980-х годов, когда была опубликована "Оранжевая книга" Министерства обороны США, в которой, начиная с класса безопасности B2, было введено требование анализа скрытых каналов.

Облако как шаг к трансформации ИТ

Облака, cloud-сервисы, облачные технологии - в последние несколько лет не проходит и дня, чтобы мы не слышали эти слова

Уход от «трубы»

Текущее состояние дел на телеком-рынке имеет негативный оттенок. Это перманентная конфронтация: идет борьба телеком-операторов со сторонними поставщиками специализированных сервисов за долю в структуре потребления абонентов

Тестирование маршрутов терминации трафика для ОАО «КОМСТАР-ОТС»

Услуга транзита и приземления трафика на местные телефонные сети – один из основных «генераторов» дохода любого оператора связи. Тем более, такой компании как «КОМСТАР-ОТС», которая не только предоставляет местную связь в Москве (как «Комстар-ОТС», так и МГТС), но также является и оператором международной связи. При этом услуги пропуска трафика являются излюбленной мишенью для мошенников, встречающихся как среди абонентов оператора, так и среди недобросовестных интерконнект-партнеров.

Анализ современных методов маршрутизации

Маршрутизаторы становятся узким местом современных компьютерных сетей, как корпоративных, так и глобальных. Причин тому несколько (см. ):   Увеличение числа пользователей. Увеличение скорости передачи до гигабит в секунду. Появление новых ...

Мониторинг бизнес-приложений: экономим 50 млн рублей в час

Сколько стоит час простоя бизнес-приложений? Что умеют и чего не умеют АРМ-решения? Как пилот может сократить стоимость внедрения?

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня