Сетевой инженер
0,0
рейтинг
13 июня 2013 в 11:07

Разработка → Основы IP-телефонии, базовые принципы, термины и протоколы recovery mode


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

Под IP-телефонией подразумевается голосовая связь, которая осуществляется по сетям передачи данных, в частности по IP-сетям (IP — Internet Protocol). На сегодняшний день IP-телефония все больше вытесняет традиционные телефонные сети за счет легкости развертывания, низкой стоимости звонка, простоты конфигурирования, высокого качества связи и сравнительной безопасности соединения. В данном изложении будем придерживаться принципов эталонной модели OSI (Open Systems Interconnection basic reference model) и рассказывать о предмете “снизу-вверх”, начиная с физического и канального уровней и заканчивая уровнями данных.

"
Модель OSI и инкапсуляция данных

Принципы IP-телефонии


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

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

Отличие от традиционной телефонии


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

При этом IP-телефония оказывается более дешевым решением как для оператора, так и для абонента. Происходит это благодаря тому, что:

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

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

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

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

Физический уровень (Physical Layer)


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

PoE


Интересно рассмотреть технологию PoE (Power Over Ethernet) — стандарты IEEE 802.3 af-2003 и IEEE 802.3at-2009. Ее суть заключается в возможности обеспечения питанием устройств посредством стандартной витой пары. Большинство современных IP-телефонов, в частности, модельный ряд Cisco Unified IP Phones 7900 Series, поставляются с поддержкой PoE. Согласно стандарту 2009 года, устройства могут получать ток мощностью до 25,5 Ватт.

При подаче питания используются лишь две витых пары кабеля 100BASE-TX, однако некоторые производители задействуют все четыре, достигая мощности до 51 Ватт. Необходимо заметить, что технология не требует модификации уже существующих кабельных систем, в том числе и кабелей Cat 5.

Для определения того, является ли подключаемое устройство питаемым (PD — powered device) на кабель подается напряжение 2,8 — 10 В. Тем самым вычисляется сопротивление подключаемого устройства. Если данное сопротивление находится в диапазоне 19 — 26,5 кОм, то процесс переходит на следующий этап. Если же нет — проверка повторяется с интервалом ≥2 мс.

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

Канальный уровень (Data Link Layer)


Согласно спецификации IEEE 802 канальный уровень разделяется на два подуровня:

  1. MAC (Media Access Control) — обеспечивает взаимодействие с физическим уровнем;
  2. LLC (Logical Link Control) — обслуживает сетевой уровень.

На канальном уровне работают коммутаторы — устройства, обеспечивающие соединение нескольких узлов компьютерной сети и распределение фреймов между хостами на основе физической (MAC) адресации.

Необходимо упомянуть механизм виртуальных локальных сетей (Virtual Local Area Network). Данная технология позволяет создавать логическую топологию сети без оглядки на ее физические свойства. Достигается это тегированием трафика, что подробно описано в стандарте IEEE 802.1Q.


Формат фрейма

В контексте IP-телефонии отметим Voice VLAN, широко применяющуюся для изоляции голосового трафика, генерируемого IP-телефонами, от других данных. Ее использование целесообразно по двум причинам:

  1. Безопасность. Создание отдельной голосовой VLAN уменьшает вероятность перехвата и анализа голосовых пакетов.
  2. Повышение качества передачи. Механизм VLAN позволяет задать повышенный приоритет голосовым пакетам, и, как следствие, улучшить качество связи.

Сетевой уровень (Network Layer)


На сетевом уровне происходит маршрутизация, соответственно основными устройствами сетевого уровня являются маршрутизаторы (Router). Именно здесь определяется, каким путем данные достигнут получателя с определенным IP-адресом.

Основной маршрутизируемый протокол — IP (Internet Protocol), на основе которого и построена IP-телефония, а также всемирная сеть Интернет. Также существует множество динамических протоколов маршрутизации, самый популярный среди которых OSPF (Open Shortest Path First) — внутренний протокол, основанный на текущем состоянии каналов связи;

На сегодняшний момент существуют специальные VoIP-шлюзы (Voice Over IP Gateway), обеспечивающие подключение обычных аналоговых телефонов к IP-сети. Как правило, они имеют и встроенный маршрутизатор, позволяющий вести учет трафика, авторизовать пользователей, автоматически раздавать IP-адреса, управлять полосой пропускания.

Среди стандартных функций VoIP-шлюзов:

  • Функции безопасности (создание списков доступа, авторизация);
  • Поддержка факсимильной связи;
  • Поддержка голосовой почты;
  • Поддержка протоколов H.323, SIP (Session Initiation Protocol).

Для борьбы с возможными задержками передачи IP необходимо дополнять дополнительными средствами, например протоколами установления очередности (чтобы голосовые данные не конкурировали с обычными).
Как правило, в этих целях на маршрутизаторах используется очередность с малой задержкой (LLQ — Low-Latency queuing), либо взвешенная организация очередей на основе классов (CBWFQ — Class-Based Weighted Fair Queuing).
Кроме того, необходимы схемы маркировки с заданием приоритетов для рассмотрения голосовых данных, как наиболее важных для передачи.

Транспортный уровень (Transport Layer)


Для транспортного уровня характерны:

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

Основные протоколы транспортного уровня — TCP (Transmission Control Protocol), UDP (User Datagram Protocol), RTP (Real-time Transport Protocol). Непосредственно в IP-телефонии используются протоколы UDP и RTP, причем основное их отличие от TCP заключается в том, что они не обеспечивают надежность доставки данных. Это является более приемлемым вариантом, нежели осуществление контроля за доставкой (TCP), так как телефонная связь чрезвычайно зависима от задержек передачи, но менее чувствительна к потерям пакетов.

UDP


UDP базируется на сетевом протоколе IP и предоставляет транспортные услуги прикладным процессам. Его главное отличие от TCP — обеспечение негарантированной доставки, то есть при отправке и получении данных никаких подтверждений не запрашивается. Также при отправке информации не обязательно установление логического соединения между модулями UDP (источник и приемник).

RTP


Несмотря на то, что RTP принято считать протоколом транспортного уровня, как правило он работает поверх UDP. С помощью RTP реализуется распознавание типа трафика, работа с метками времени, контроль передачи и нумерация последовательности пакетов.

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

Уровни данных (Data Layers)


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

H.323


Первым делом необходимо описать стек протоколов H.323, разработанный в 1996 году. Данный стандарт содержит описание оборудования, сетевых служб и терминальных устройств, предназначенных для осуществления аудио- и видеосвязи в сетях с коммутацией пакетов (Интернет). Для любого устройства стандарта H.323 обязательна поддержка обмена голосовой информацией.

Рекомендации H.323 предполагают:

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

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

Согласно H.323 четырьмя основными компонентами VoIP-соединения являются:

  • терминал;
  • шлюз;
  • контроллер зоны;
  • контроллер управления многоточечной конференции (MCU — Multipoint Control Unit).


Пример структурной схемы сети в IP-телефонии 

Выдержка из документа, описывающего стек протоколов H.323
1. Управление соединением и сигнализация:
1.а. H.225.0: протоколы сигнализации и пакетирования мультимедийного потока (использует подмножество протокола сигнализации Q.931).
1.б. H.225.0/RAS: процедуры регистрации, допуска и состояния.
1.в. H.245: протокол управления для мультимедиа.
2. Обработка звуковых сигналов:
2.а. G.711: импульсно-кодовая модуляция тональных частот.
2.б. G.722: кодирование звукового сигнала 7 кГц в 64 кбит/с.
2.в. G.723.1: речевые кодеры на две скорости передачи для организации мультимедийной связи со скоростью передачи 5.3 и 6.3 кбит/с.
2.г. G.728: кодирование речевых сигналов 16 кбит/с с помощью линейного предсказания с кодированием сигнала возбуждения с малой задержкой.
2.д. G.729: кодирование речевых сигналов 8 кбит/с с помощью линейного предсказания с алгебраическим кодированием сигнала возбуждения сопряженной структуры.
3. Обработка видеосигналов:
3.а. H.261: видеокодеки для аудиовизуальных услуг со скоростью 64 кбит/с.
3.б. H.263: кодирование видеосигнала для передачи с малой скоростью.
4. Конференц-связь для передачи данных:
4.а. T.120: стек протоколов (включает T.123, T.124, T.125) для передачи данных между оконечными пунктами.
5. Мультимедийная передача:
5.а. RTP: транспортный протокол реального времени.
5.б. RTCP: протокол управления передачей в реальном времени.
6. Обеспечение безопасности:
6.а. H.235: обеспечение безопасности и шифрование для мультимедийных терминалов сети H.323.
7. Дополнительные услуги:
7.а. H.450.1: обобщенные функции для управления дополнительными услугами в H.323.
7.б. H.450.2: перевод соединения на телефонный номер третьего абонента.
7.в. H.450.3: переадресация вызова.
7.г. H.450.4: удержание вызова.
7.д. H.450.5: парковка вызова ( park ) и ответ на вызов ( pick up ).
7.е. H.450.6: уведомление о поступившем вызове в состоянии разговора.
7.ж. H.450.7: индикация ожидающего сообщения.
7.з. H.450.8: служба идентификации имен.
7.и. H.450.9: служба завершения соединения для сетей H.323.



Сценарий установки соединения на основе протокола H.323

SIP (Session Initiation Protocol)


SIP — протокол сигнализации, предназначенный для организации, изменения и завершения сеансов связи. SIP независим от транспортных технологий, однако при установлении соединения предпочтительно использовать UDP. Для передачи самой голосовой и видеоинформации рекомендовано применять RTP, но возможность использования других протоколов не исключена.

В SIP определены два типа сигнальных сообщений — запрос и ответ. Также существует шесть процедур:

  • INVITE (приглашение) — приглашает пользователя принять участие в сеансе связи (служит для установления нового соединения; может содержать параметры для согласования);
  • BYE (разъединение) — завершает соединение между двумя пользователями;
  • OPTIONS (опции) — используется для передачи информации о поддерживаемых характеристиках (эта передача может осуществляться напрямую между двумя агентами пользователей или через сервер SIP);
  • АСК (подтверждение) — используется для подтверждения получения сообщения или для положительного ответа на команду INVITE ;
  • CANCEL (отмена) — прекращает поиск пользователя;
  • REGISTER (регистрация) — передает информацию о местоположении пользователя на сервер SIP, который может транслировать ее на сервер адресов (Location Server).


Сценарий сеанса связи SIP

Кодеки


Аудиокодеком называют программу или алгоритм, который сжимает, либо разжимает цифровые звуковые данные, позволяя снизить требования к пропускной способности канала передачи данных. В IP-телефонии на сегодняшний день наиболее распространено преобразование посредством кодека G.729, а также сжатие G.711 по А-закону (alaw) и μ-закону (ulaw).

G.729

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

Пропускная способность канала, на которую рассчитан данный кодек — 8 кбит/с. Длина кадра обрабатываемого G.729 — 10 мс, частота дискретизации — 8 кГц. Для каждого из таких кадров определяются параметры математической модели, которые в дальнейшем и передаются в канал в виде кодов.

При использовании кодирования G.729 задержка составляет 15 мс, из которых 5 мс тратится на заполнение предварительного буфера. Отметим также, что кодек G.729 предъявляет достаточно высокие требования к ресурсам процессора.

G.711

G.711 — голосовой кодек, который не предполагает никакого сжатия, помимо компандирования — метода уменьшения эффектов каналов с ограниченным динамическим диапазоном. В основе данного метода лежит принцип уменьшения количества уровней квантования сигнала в области высокой громкости, сохраняя при этом качество звука. Две широко использующиеся в телефонии схемы компандирования — alaw и ulaw.

Сигнал в данном кодеке предоставлен потоком величиной 64 кбит/с. Частота дискретизации — 8000 кадров по 8 бит в секунду. Качество голоса субъективно лучше, нежели при применении кодека G.729.

alaw

alaw или А-закон — алгоритм сжатия звуковых данных с потерей информации. В основном используется на территории Европы и России.

Для сигнала x преобразование по алгоритму alaw выглядит следующим образом:

Где А — параметр сжатия (обычно принимается равным 87,7).

ulaw

ulaw или μ-закон — алгоритм сжатия звуковых данных с потерей информации. В основном используется на территории Японии и Северной Америки.

Для сигнала x преобразование по алгоритму ulaw выглядит следующим образом:

где μ принимается равным 255 (8 бит) в стандартах Северной Америки и Японии.

Импульсно кодовая модуляция (PCM — Pulse Code Modulation)


Импульсно кодовая модуляция — передача непрерывной функции в виде серии последовательных импульсов.

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

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


Квантование сигнала

На данном рисунке представлено кодирование с помощью четырех битов (то есть все промежуточные значения аналогового сигнала будут округляться до одного из заранее заданных 16 уровней). Для примера, при времени равном нулю сигнал будет представлен подобным образом: 0111.

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

В современной телефонии число уровней квантования должно быть большим или равным 100, то есть минимальное количество бит, которым может кодироваться сигнал — 7.

Вопросы качества обслуживания в IP-телефонии (Quality of Service — QoS)


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

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

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

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

Для улучшения качества связи используются следующие механизмы:

  1. Перемаршрутизация. При перегрузке одного из каналов связи позволяет осуществить доставку при помощи резервных маршрутов.
  2. Резервирование ресурсов канала связи на время соединения.
  3. Приоретизация трафика. Дает возможность помечать пакеты в соответствии с уровнем их важности и производить обслуживание на основе меток.

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

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


Источники задержки в IP-телефонии

Джиттер


Еще одно явление, характерное для IP-телефонии — джиттер, или, иначе, случайная задержка распространения пакета.

Обуславливается джиттер тремя факторами:

  • Ограниченная полоса пропускания или некорректная работа активных сетевых устройств;
  • Высокая задержка распространения сигнала;
  • Тепловой шум.

Наиболее часто применяющийся метод борьбы с джиттером — джиттер-буфер, хранящий определенное количество пакетов.

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

Джиттер буфер

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


Джиттер буфер

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

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

Размер джиттер буфера

Случайная задержка распространения Ji для i-го пакета может определяться по формуле:

где:
Di – отклонение от ожидаемого времени прибытия i-го пакета.
Отклонение от ожидаемого времени прибытия i-го пакета Di определяется по формуле:

где:
R – время прибытия пакета в метках времени RTP,
S – временная метка RTP, взятая из пакета.

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

Пусть J4=10 мс; R4=10, R3=11, S4=6, S3=5, тогда D5 будет равно (10-11)-(6-5)=-2.

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

Для определения требуемого размера джиттер буфера в мегабайтах, домножим полученное значение на 100 мбит/сек – среднюю пропускную способность сети: 10•10^-3•100 = 128 кб.

Размер джиттер-буфера должен быть больше, чем флуктуация транзитного времени в сети. Например, если для 10 пакетов время транзита колеблется от 5 до 10 мс, то буфер должен быть хотя бы 8 мс, чтобы ни один пакет не был потерян. Лучше, если буфер еще больше, например 12 мс, тогда сможет работать механизм перезапроса потерянных пакетов.

Решения для развертывания телефонной сети


Asterisk




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

Поддерживаемые протоколы: IAX, SIP, H.323, Skinny, UNIStim.
Поддерживаемые кодеки: G.711 (ulaw и alaw), G.722, G.723, G.729, GSM, iLBC, LPC-10, Speex.

Asterisk — динамично развивающееся открытое программное обеспечение, которое может быть установлено без оглядки на лицензирование. Это делает данную программную АТС привлекательной для малого и среднего бизнеса. Количество абонентов в сети может достигать 2000 и ограничено только мощностью сервера.

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

В сравнении с решениями от таких вендоров, как Cisco или Avaya, Asterisk привлекателен еще и стоимостью развертывания. Фактически все затраты сводятся только к покупке телефонных аппаратов и сервера, способного обеспечить требуемую нагрузку на сеть. Сама программа абсолютно бесплатна.

Cisco Unified Communication Manager (CallManager)




CallManager предназначен скорее для крупных сетей, включающих до 30000 абонентов. Данный программно-аппаратный комплекс обеспечивает надежность работы и позволяет конфигурировать множество параметров, таких как переадресация звонков или голосовое меню. Существует и “облегченная” express версия, предназначенная скорее для небольших офисов.

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

Avaya IP Office




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

Конфигурирование может осуществляться через ряд программ, но наиболее популярная и простая в обращении — Avaya IP Office Manager. Также возможно управление через консоль с помощью Avaya Terminal Emulator.

В целом, продукция корпорации Avaya не ограничивается одним IP Office. Avaya, в 2009 году слившаяся с еще одним известным производителем Nortel, является признанным лидером на рынке оборудования для IP-телефонии.

Что можно почитать по теме:

  • Wendell Odom — все его книги хороши.
  • “IP-телефония в компьютерных сетях”. И.В. Баскаков, А.В. Пролетарский, С.А. Мельников, Р.А. Федотов.
  • “IP-телефония”. Б. С. Гольдштейн, А. В. Пинчук, А. Л. Суховицкий.
  • “Asterisk. Будущее телефонии”. Джим Ван Меггелен, Лейф Мадсен, Джаред Смит.
  • “Протокол SIP. Справочник”. Б. С. Гольдштейн, А. А. Зарубин, В. В. Саморезов.
Никита Вельгин @Avtandilko
карма
28,0
рейтинг 0,0
Сетевой инженер
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (58)

  • –1
    Большое спасибо за пост. Сейчас он мне очень пригодится так как пишу дипломку по теме IP-телефонии и буду испытывать и сравнивать разные решения для построения малой VoIP сети.
    • +1
      Недавно пробовал клиента надоумит на IP-телефонию внутри офиса на 15 чел. Наткнулся на полное непонимаение со стороны руководства. В итоге купили аналоговую мини АТС. Может такое замечание будет полезно для Вашего диплома.
      • 0
        Аналоговая миниатс тоже замечательно подключается к SIP, так что одно другому не мешает.
        • 0
          Не очень замечательно.
  • +1
    Расскажите, пжлста, про IP АТС от Panasonic (напр NCP1000). Есть ли у панаса преимущества перед астериском. Как астриск и панас дружат с SIP провайдерами (типа дом.ру и бит-телеком). Может быть в следующей статье. Было б полезно.
    • +6
      Панас – дорого и геморройно. Ибо деревянно. Астериск куда лучше.
    • 0
      Я, честно говоря, никогда не работал с панасониками, так что сказать ничего не могу. Насчет астериска — он по-моему дружит с чем угодно, хотя были определенные проблемы при попытке подружить его с циской.
    • 0
      У панаса политика «негарантирования» совместимости со сторонним железом) Т.е. теоретически должно, но «мы не гарантируем». Три года столкнулся с такой проблемой, в итоге вместо платы для панаса за 80 т.р. купил VoIP шлюз за 30. В плане аналога Панасоник — классные станции, надежные. Надежные они и под цифровую связь, но совместимость и гибкость настройки, конечно, слабовата.
  • –1
    На мой взгляд статья бесполезная чуть более, чем полностью. Понять из нее как и что работает все равно невозможно. Лучше бы уж плюсы/минусы расписали.
  • +4
    Еще одно явление, характерное для IP-телефонии — джиттер. Суть его состоит в том, что отправленные пакеты по ряду причин могут прибыть к получателю в неверном порядке.

    Ну нет… Джиттер — вариация задержки. В идеальных условиях пакеты, отправленные с интервалом в 20мс, будут приняты получателем с тем же интервалом в 20мс вне зависимости от RTT, и их можно сразу декодировать и озвучивать. На практике, первый пакет дойдет за 50мс, следующий за 40мс, следующий за 150мс, и так далее. В таких условиях нельзя сразу воспроизводить звук, иначе беда, дошедший за 150мс пакет будет отброшен. Нужен буфер, в который пакеты набираются, что в свою очередь увеличивает задержку в разговоре.

    А переупорядочивание пакетов — исключительно редкое явление. Сейчас никто не делает попакетной балансировки.
    • 0
      да, спасибо, действительно некорректно написал
    • 0
      > А переупорядочивание пакетов — исключительно редкое явление. Сейчас никто не делает попакетной балансировки.

      Может и не делает, но мы регулярно сталкиваемся с переупорядочиванием пакетов. И как это у провайдера получается
      • 0
        Регулярно — в смысле действительно постоянно, то есть из десятка пакетов хотя бы пара перепутается местами? Такое и TCP очень плохо переносит — обычно он приравнивает такое к потерянному пакету.
        А если изредка, в момент перемаршрутизации, когда N-ный пакет шел по одному линку, а N+1-й и последующие по другому — это нормально.

        «Как получается»? Да запросто. На старом железе можно сказать «ip cef load-sharing per-packet». Новое уже так не умеет — и хорошо.
        • 0
          Да, регулярно — это постоянно. Из десятка не знаю, вот результат тестирования ttcp
          Datagrams (max data segment is 1460 bytes):
          Rcvd: 611 (out of order: 145), with data: 600, total data bytes: 819200

          Да, подтверждаю tcp от Windows (с дефолтными настройками) такое переносит плохо, а TCP от linux нормально это обрабатывает.

          Это магистральный провайдер, который нам дает MPLS VPN.
          • 0
            То, что вы описали — это ошибка конфигурации, без вариантов. Собираете дамп пакетов, заводите заявку, раз в час пинаете их.
            • 0
              Пинали год. Пока «само» не починилось. А может и не починилось но уже просто все к этом привыкли.
              В процессе пинание вышли на верхушку компании — это тоже не помогло. Инженеры компании клянутся, что нигде нет никаких параллельных путей.
              • 0
                Инженеры компании клянутся, что нигде нет никаких параллельных путей.

                Тут надо не клясться, а тестировать. Пусть высунут в ваш VRF несколько интерфейсов на разных участках пути, ну и IP SLA до нескольких сразу. Мы такое не раз делали, к примеру, в случае дропов где-то не пойми где на канале. После такого проблема редко решается более чем за день.
                • 0
                  Дима, поверь, это делалось. Когда они высовывали другие участки — проблем нет, а на составном — есть :)
                  • 0
                    Ну значит плохо тестировали. Мы в таких случаях призываем в офис сервис-менеджера и начальника управления, проводим с ними беседу на тему «вокруг так много замечательных провайдеров», и после этого проблема волшебным образом самоустраняется.
                    • +1
                      :) Если было бы все так просто. Мы далеко ушли от первого сообщения. Я говорил лишь об одном — нарушение порядка пакетов — это не бесконечно малая величина в современном Интернете. Это случается.
                      • 0
                        Но согласись, случается редко. Наравне с несовпадающим дуплексом где-то на сети оператора (долдоны несколько дней искали причины дропов при небольшой нагрузке).
                        • 0
                          Соглашусь. Случается редко или мы редко замечаем что такое происходит. Все ж работает, только тормозит иногда.
  • +1
    Если не трудно. Объясните как вписываются в ip телефонию аналоговые модемы и факсы. Например есть офисная сеть, есть ip АТС (например Asterisk), есть шлюзы FXS и FXO (для подключения аналоговых абонентов внутри сети и подключения нашей ip АТС к аналоговым линиям провайдера). Будут ли в такой конфигурации работать аналоговые факсы и модемы? Какие протоколы для этого должны поддерживать шлюзы (T.30, T.38)? Какая максимальная скорость доступна? Заранее благодарю.
    • +1
      Зависит от возможностей шлюза. Сейчас большинство моделей поддерживают Т.38, однако это не означает, что все будет работать на 100%. Бывают, что разные реализации Т.38, его инициации и возврата на 711-й делают передачу факсов просто невозможной. Ну и кроме того, если по дороге есть NAT, то с вероятностью 95% факс по Т.38 передаваться не будет.
    • +1
      Из практики по asterix факсы бегают нормально по кодеку g711, факс модем максимум выжимает 4800 бит в секунду, pos терминалы (для работы с картами) работают нормально (там скорости смешные по v24 или v32). По g729, который сильно жмет работал только голос.
    • +1
      g711 сам по себе поддерживает факсы без необходимости переключаться на Т.38, поэтому если в офисной сети используется g711, и шлюзы его поддерживают, то факсы должны, в теории (и как пока показывала практика), работать. Если же в сети в приоритете g729, то шлюзы должны уметь T.38, но при переключении возникают разные странные проблемы, так что 100% гарантии работоспособности не дать.
  • 0
    Тоже диплом будет по подобной теме, только нужно много математики, помимо практической части хочу рассмотреть несколько протоколов. Не подскажете качественных источников подобного? Желательно книги на русском/английском.
    • +1
      как минимум, “Протокол SIP. Справочник”. Б. С. Гольдштейн, А. А. Зарубин, В. В. Саморезов.
      Очень полное описание протокола.
    • +1
      А какие протоколы собираетесь рассматривать? Сигнализации? Или передачи голоса? Или передачи видео? Или контроля?
      SIP — все в RFC. Смотрите в RFC — книг нормальных по SIP я не нашел.
      H.323 — смотрите на сайте itu — ссылки тут en.wikipedia.org/wiki/H.323#ITU-T_Recommendations_of_the_H.323_System
      MGCP — RFC
      RTP — RFC
      RTCP — RFC
      и т.д.
      • 0
        Вообще изначально планировал SIP и Speex, как минимум. Спасибо, погляжу. [irony]Через год ждите статью[/irony]
  • 0
    > Из преимуществ Cisco CallManager следует отметить в первую очередь знаменитую техническую поддержку корпорации Cisco. При соответствующем уровне контракта на обслуживание, любая проблема, начиная с вопросов по настройке и заканчивая вышедшим из строя оборудованием, будет решена практически мгновенно. Поэтому Cisco CallManager подойдет компаниям, готовым платить немалые деньги, но и получать при этом высочайшее качество обслуживания.

    Это просто ложь.
    Не мгновенно и не высочайшее. Готовьтесь открыть тикет и ждать час минимум, пока с вам свяжется инженер (даже если открыли с высоким приоритетом). А потом готовтесь, что ваш тикет, в зависимости от сложности будет вичеть от дня до нескольких месяцев. При этом если тикет не на тему «как включить галочку» — то его еще, скорее всего, решить не смогут.
    • 0
      Да ладно вам… За йеменцев не скажу, они традиционно деревянные, но в нашем TACе сидят очень грамотные ребята.

      Правда, у CUCM есть и другие преимущества. Он офигительно прост и удобен в работе, чертовски стабилен (я на нем вроде ни одного бага не видел) и при этом отлично масштабируется.

      Только:
      «до 30000 абонентов» — это на кластер, а не на сервер.
      «программно-аппаратный комплекс» — нет в нем ничего аппаратного. Последние версии вообще рекомендовано виртуализировать.
      • 0
        Русский TAC, польский TAC — выше всяких похвал. Но все равно не мгновенно. :) Ребята в русском таке перегружены.
        Про простоту CUCM-а я бы сильно поспорил. Прост для чего? Например как на нем просто для 5-ти сотен телефонов изменить какой-то параметр, причем значение этого параметра для всех 5-ти телефонов не одинаковое?

        Про стабильность — лично две недели назад запилил два бага с помощью TAC-а. Сейчас еще один баг между TAC-ом и программистами cucm-а завис. На этих выходных обновлял его (накатывал SU). Так это «создание» при перезагрузке впало в кому на полчаса, потом сказала «дискам капец. Timeout» и не запустила сервисы. Перезагрузка — и все как по маслу. И так на каждом сервере :) Или еще бага как AXL вытаскивает удаленных пользователей и выдает их за живых :)

        И еще претензия к CUCM-у — уж больно через версии он скачет. 7-8-9 — покупать не успеваешь, а разработчики фиксить баги.

        • 0
          До сих пор сидим на 6ке. Только сейчас купили 9.
          • 0
            Угу. В августе 2012 купили 8.6. И сейчас имеем только security updates. Ничего нового больше в 8-й версии не увидим.
        • 0
          Но все равно не мгновенно.

          По severity 3 — да, час-два может потребоваться подождать (обычно оно и не горит). По более высоким — оператор сразу переводит на инженера.
          Например как на нем просто для 5-ти сотен телефонов изменить какой-то параметр, причем значение этого параметра для всех 5-ти телефонов не одинаковое?

          Подготовить CSV в екселе, затем BAT. А еще лучше продумать архитектуру так, чтобы делать такое не потребовалось, благо он позволяет. Мне не требовалось.
          Про стабильность — лично две недели назад запилил два бага с помощью TAC-а.

          Если не секрет — что за линейка? Или вы уже на 9? Любой цисковод знает, что НЕ НАДО сразу переводить прод на новую мажорную версию. 9-й еще и года не исполнилось :)
          И еще претензия к CUCM-у — уж больно через версии он скачет.

          Циска же. И баги в большинстве своем чинятся без мажорных апдейтов. Вон под 7 до сих пор SU выходят.
          • 0
            1. Это зависит от продукта. Или от расположения звезд на небе. У меня было что я висел на телефоне 1.5 часа при отказе сети и ждал пока найдут инженера.
            2. Ну да. То есть получается, чтобы обновить один параметр — то надо — экспортировать телефоны, удалить их, импортировать телефоны (и молится, что импортер не сломается). А в это время пользователи без телефонов сидят. Я так не делаю, я предпочитаю через axl телефоны настраивать. Но это каждый раз программу писать. Не тянет это на легкость конфигурирования. Не требовалось — значит не было достаточного опыта эксплуатации.
            3. 8.6.x. И посмотри в багтуле сколько тикетов открытых на эту mature версию.
            4. ну да, Зато под 6.1 su больше не выходят.:)
            • 0
              2. Опыт эксплуатации есть. Есть инфраструктура на тысячи телефонов и сотни шлюзов. Но я вот думаю — и не могу придумать, зачем такое. Разве что смена плана нумерации, или ext phone number mask хитрый прописать…
              3. Ну не глючит седьмая версия :) Пару раз пытался поймать ее на косяках, уже радовался, запускал трейсы (единственное отвратительное в CUCM), чтобы сразу всё к кейсу приложить — и находил собственный косяк.
              • 0
                2. Например, прописывание другой CSS для группы телефонов. Причем для одной группы — один CSS, для второй группы — другой CSS. Причем это просто так не отфильтровать, чтобы BAT-ом запустить изменение двух групп.
                3. Не глючит — значит вы счастливчик. Кто-то ведь заводит все эти баги из багтула, которые потом фиксятся? Ну вот баг навскидку — Я не видел 7-ку, но я почти уверен, что на сайте «Cisco Unified Communications Manager CDR Analysis and Reporting» прикладывается (или не прикладывается совсем) правильный css на главной странице. Дизайна попросту нет. Это было так и в 6-й версии и в 8-й.
                Я понимаю что баг косметический, но меня он крайне удивляет — уж настолько явный и настолько легко чинящийся. Ан нет.
                • 0
                  2. А цель-то какая?
                  Да и в BATе можно тупо перечислить DNы, а дальше уже одним кликом применить к группе нужный CSS. И я плохо представляю себе что-либо радикально более удобное. Все равно потребуется перечислять список номеров.
                  3. Выглядит странно. Работает полноценно.
                  • 0
                    2. Можно перечислить 10 телефонов за раз по их SEPid. Долго и муторно. Радикально более удобное — это как в BAT-е сделано обновление пользователей — дал CSV файл в котором userid и то поле что меняешь — и все поменялось. Быстро и удобно. Для телефонов такую штуку не запилили.
                    3. Так про все что угодно можно сказать. :)
  • +3
    Не раскрыта тема электричества, закон Ома, и еще куча очевидных и столь же относящихся к IP-телефонии вещей .Все-таки про модель OSI и рекламные предложения, а также PCM, не пойми каким боком конкретно к IP-телефонии относящейся, нужно читать отдельно. Статья обо всем — в итоге ни о чем. Вообще интересующимся рекомендую поднять Asterisk в минимальной конфигурации, поставить software SIP-телефон, Wireshark и банально посмотреть, как устанавливается соединение, и что происходит в процессе — весьма познавательно. Человеку, не знающему модель OSI и стек TCP/IP, вообще к сетевым технологиям и протоколам подходить не рекомендую.
  • 0
    У Cisco есть call manager express который работает на рутерах. Для небольших офисов самое оно.
  • +1
    Важно не забывать, что сеть SDH (на ней строится традиционная сеть телефонии) до сих пор является самой оптимальной по скорости передачи голосовой информации. IP-сеть хорошо, но там каждый узел вносит заметные задержки в распространение сигнала. Фактически IP сети стали пригодны для передачи голосового трафика без дискомфорта дла абонентов лишь во времена внедрения гигабитных каналов. До сих пор реальные операторы связи придерживаются правила: на близких дистанциях (район с деревнями) допустимо IP, всё что дальше (междугородняя/международная связь) до сих пор SDH сеть с E1. Впрочем, чего там разбираться. Есть жёсткие требования к качеству связи, которую традиционные операторы обязаны выполнять. Сеть IP там не всегда справиться сможет, особенно если учесть, что кроме голосового трафика по IP сети течёт ещё и менее предсказуемый по объёмам интернет.
    • 0
      Не скажите. Интересующихся отсылаю к понятиям NGN и IMS — например, в РБ это уже внедряется на общегосударственном масштабе, традиционная сеть практически не развивается.
    • 0
      сеть SDH (на ней строится традиционная сеть телефонии) до сих пор является самой оптимальной по скорости передачи голосовой информации.

      Сейчас и междугородку все активно переводят на IP. Это дешевле и удобнее. Я уж не говорю о том, что даже в моей конторе ЦО в Москве может общаться с дальним заМКАДьем вроде Владивостока поверх GRE/IPSec туннелей поверх обычных IP VPN каналов связи, и характеристики связи будут на высоком уровне.

      Ну и «SDH сеть с E1» очень не вяжется с «самой оптимальной по скорости передачи голосовой информации». Когда говорят о скорости, я представляю себе гигабиты, а не миллисекунды, с которыми особых проблем нет. Да, некоторые операторы любили мультиплексировать десятки Е1 потоков, но все пытаются избавиться от этого безумия.
      кроме голосового трафика по IP сети течёт ещё и менее предсказуемый по объёмам интернет.

      А QoS на что? Если настроить правильно, то при 100% утилизации канала ни один голосовой пакет не дропнется и не задержится в очереди. Для крупных операторов вроде РТТ, ТТК на своей сети это не такая уж и проблема.
  • 0
    Вы не правы. Эффективность SDH при передаче голосового трафика значительно выше. И скорости достаточно не маленькие. Просто соотношение голосового трафика и трафика данных складывается не в пользу первого, и поэтому, чтобы не строить разные транспортные сети, переходят на IP. И надежность, и резервирование маршрутов у SDH тоже гораздо выше и быстрее.
    • –1
      Эффективность SDH при передаче голосового трафика значительно выше.

      Учитывая, что многие ограничиваются тем самым E1, не поднимаясь выше — не факт :) Потребность в отдельной инфраструктуре еще больше мешает.
      И надежность, и резервирование маршрутов у SDH тоже гораздо выше и быстрее.

      Правильно настроенная пакетная сеть приближается к этим значениям. FRR сходится за примерно 50мс. Это уже тот уровень, когда можно сказать «этого достаточно».
  • 0
    Почему через IP-телефонию SMS не устраивают?
    • 0
      Зачем передавать SMS через IP-телефонию? Ничего, что это немного разные штуки (одна — текст, другая — голос в реальном времени)?
      • 0
        Возможно потому, что стоимость СМС оператора слишком высока, особенное если рассылать их например всем для активации по 10000 в день? :)
        • 0
          И все-таки, какое отношение имеет передача сообщений к IP-телефонии?
          Вам мало решений либо на XMPP, либо на email=>XMPP и тому подобных?
          • 0
            Иногда удобно скинуть короткий текст на IP телефон
            Например человек на переговорах и у него с собой дектовская айпи трубка
            xmpp и подобные тоже не поддерживаются «железными телефонами», а только софтфоном (спарк и тд)
            В 11 версии астериска есть текстовые сообщения, но опять же нет поддержек у «железа»
            • 0
              у железа обычно есть поддержка текстовых сообщений, но, похоже, у каждого своя проприетарная
          • 0
            возможно я просто что-то не то знаю про XMPP но отправить рассылку на 1000 телефонов задешево оно не помогает. Или я не знаю как — подскажите.
            • 0
              Причем тут XMPP? На его месте может быть что угодно вплоть до HTTP и SMTP. Это просто протокол, наиболее похожий на используемые операторами при транспорте SMS и требующий наименьшего числа прослоек (но он в любом случае ужасен).
    • 0
      Еще как устраивают — rfc3428
  • 0
    > случайная задержка распространения пакета

    Имхо лучше говорить «вариация задержки» — так по крайней мере во многих документах. «Случайная задержка» же подразумевает разделение на случайные и стабильные задержки, что не так очевидно и в добавок не совсем верно.

    Размер джиттер буфера надо выставлять с учетом реакции сети на аварии, например если время схождения 50мс, то и и размер буфера стоит ставить больше. Также надо смотреть как работает оборудование и какие тайминги для перезапроса потерянных пакетов, которые например на радио по дефолту достаточно большие — до 0.5 с, что для Voip уже слишком много.
    Краем уха слышал что до 100мс задержки вполне комфортны, но они учитывают всю задержку, а размер джиттер-буфера прибавляется к средней задержке на сети. На практике не чувствовал проблем при увеличении джиттер буфера до 40-50мс.

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.