Перечень лабораторных работ. Лабораторная работа 1 общие сведения об ip
 Скачать 2.35 Mb.
|
|
Лабораторная работа №7. Изучение возможностей сервера IP-телефонии 3CX 7.1. Краткие теоретические сведения Взаимодействие протоколов VoIP При использовании протоколов, которые непосредственно имеют дело с VoIP, важно правильное понимание спецификации, вносимой этими протоколами. На рис 7.1 показан стек протоколов VoIP. Здесь отсутствует верхний уровень, который подразумевает в себе любую разговорную речь. Данный рисунок характеризует исключительно передачу голосовых данных. Рис. 7.1. Стек протоколов VoIP Технология VoIP может работать в любой физической среде, которая может использоваться обычным протоколом IP. Такие среды могут быть представлены в виде кабеля витой пары (используемой в традиционном Ethernet), телефонных проводов, беспроводных соединений (протокол IEEE 802.11) и др. Второй уровень этой модели – канальный уровень – указывает, что протокол IP для создания фреймов может использовать различные форматы. Как показано на рис 7.1, он включает многоканальный PPP (Multilink PPP), Frame Relay (FR) и ATM. При проектировании сети возможны и другие варианты, поскольку передавать голос могут также Ethernet, Wi-Fi и другие технологии локальных сетей. На третьем, сетевом уровне используется протокол IP в качестве способа передачи голоса, однако обычный IP должен быть дополнен специальными средствами. Поскольку существуют проблемы с задержкой, протоколу IP требуется использовать какой-либо способ установления очередности для того, чтобы голосовым данным не пришлось ожидать передачи в условиях конкуренции с обычными данными. На маршрутизаторах должна быть использована очередность с малой задержкой (Low-Latency queuing – LLQ) или какая-либо иная современная схема установки очередности, чтобы 64 голосовые данные отправлялись раньше обычных данных. Кроме того, должны использоваться схемы маркировки (marking) с заданием приоритетов (coloring), называемые IP-приоритетами, для обеспечения того, чтобы голосовые данные рассматривались системой как более важные для первоочередной передачи, чем обычные данные. Следующим уровнем является транспортный. Поскольку для передачи голоса используется протокол UDP, системе не хватает механизма установки очередности пакетов, чтобы пакеты доставлялись в требуемой последовательности. Транспортный протокол реального времени (Real-Time Transport Protocol – RTP) для выполнения этого требования добавляет номер пакета в последовательности передачи и механизм расстановки временных меток. Также может использоваться протокол резервирования (Resource Reservation Protocol – RSVP) для резервирования полосы пропускания вдоль пути следования голоса по IP-сети. Данный протокол исключает использование зарезервированной полосы пропускания пакетами обычных данных. Пятый уровень модели – сеансовый. На сегодняшний день сети VoIP переходят со стандарта ITU-T H.323 на другой протокол инициирования сеанса (Session Initiation Protocol – SIP) и протокол описания сеанса (Session Description Protocol – SDP). Шестым уровнем модели является уровень представлений. Как определено в модели OSI, уровень представлений анализирует и интерпретирует форматы данных. В терминах передачи голоса уровень представлений обеспечивает методы кодирования и сжатия, используемые для передачи голоса. Все уровни стека протоколов совместно применяются для того, чтобы решить проблемы минимизации задержки и обеспечить требуемый порядок следования пакетов. Качество передачи речевой информации по IP-сети IP-телефония является одной из областей передачи данных, где все процессы передачи информации должны происходить в режиме реального времени и где особенно важна динамика передачи сигнала, которая обеспечивается современными методами кодирования и передачи информации; в результате увеличивается пропускная способность каналов по сравнению с традиционными телефонными сетями. Хорошо изучены факторы, влияющие на качество IP-телефонии. Они могут быть разделены на две категории: 1. Качества IP-сети характеризуют: o максимальная пропускная способность – максимальное количество данных, которая она передает; o задержка – промежуток времени, требуемый для передачи пакета через сеть; o джиттер – задержка между двумя последовательными пакетами; 65 o потеря пакета – пакеты или данные, потерянные при передаче через сеть. 2. Качества шлюза характеризуют: o требуемая полоса частот пропускания; o задержка – время, необходимое сигнальному процессору DSP для кодирования и декодирования речевого сигнала; o объем буфера джиттера для сохранения пакетов данных до тех пор, пока все пакеты не будут получены; затем можно будет передать часть речевой информации в требуемой последовательности и таким образом минимизировать джиттер; o возможность потери пакетов – потеря пакетов при сжатии и/или передаче в оборудовании IP-телефонии; o наличие функции подавления эха, возникающего при передаче речи по сети. В сетях IP протокол управления передачей (Transport Control Protocol – TCP) может решить проблему нарушения порядка следования пакетов данных из-за установления последовательности передачи и использования подтверждений, однако для передачи голоса используется протокол дейтаграмм пользователя (User Datagram Protocol – UDP), а не TCP. Применение протокола UDP в технологии VoIP обусловлено тем, что у посылающего устройства нет необходимости перед отправкой последующих пакетов дожидаться подтверждения от принимающего устройства. Данные VoIP отправляются тем же способом, который используется при отправке аудио- или видеоданных в сети Интернет. Потеря небольшого количества голосовых пакетов считается приемлемой и может быть компенсирована с помощью механизма кодирования/декодирования, а также различных методов интерполяции речи, то есть посредством заполнения отсутствующих звуков с помощью DSP-технологии, которая анализирует форму звукового колебания и предсказывает отсутствующий звук. Задержка и меры по уменьшению ее влияния Организация ITU-T серьезно занималась исследованием проблем, связанных с задержками при передаче голоса по сети. В результате был разработан стандарт ITU-T G.114, который рекомендует, чтобы задержка при передаче голоса в одном направлении не превышала 150 миллисекунд. Также стандарт рекомендует рассматривать задержку от 150 до 400 миллисекунд как приемлемую, если говорящий и слушающий понимают наличие задержки и готовы с ней смириться. В том случае, когда задержка достигает 400 миллисекунд и более, она становится заметной. Для сравнения можно привести общение через спутник: задержка при передаче по спутниковой связи в одном направлении составляет примерно 170 миллисекунд; при этом не учитывается задержка, возникающая в устройствах, расположенных на земле. Стандарт также устанавливает, что при передаче голоса задержка более чем 400 миллисекунд является неприемлемой. 66 Возможны случаи, когда при передаче речи по IP-сети возникают намного большие, чем в ТфОП, задержки, которые, к тому же, изменяются случайным образом. Этот факт представляет собой проблему и сам по себе, но кроме того, усложняет проблему эха. Задержка (или время запаздывания) определяется как промежуток времени, затрачиваемый на то, чтобы речевой сигнал прошел расстояние от говорящего до слушающего. Покажем, что и как оказывает влияние на количественные характеристики этого промежутка времени. Можно выделить следующие причины задержки при передаче речи от источника к приемнику. Задержка накопления (иногда называется алгоритмической задержкой): эта задержка обусловлена необходимостью сбора кадра речевых отсчетов, выполняемая в речевом кодере. Величина задержки определяется типом речевого кодера и изменяется от небольших величин (0,125 мкс) до единиц миллисекунд. Задержка обработки: процесс кодирования и сбора закодированных отсчетов в пакеты для передачи через пакетную сеть создает определенные задержки. Задержка кодирования или обработки зависит от скорости работы процессора и используемого типа алгоритма обработки. Сетевая задержка: задержка обусловлена физической средой и протоколами, применяемыми для передачи речевых данных, а также буферами, используемыми для удаления джиттера пакетов на приемном конце (рис. 7.2.). Рис. 7.2. Источники задержки при передаче речи по IP-сети Важно отметить тот факт, что задержки в сетях с коммутацией пакетов влияют не только на качество передачи речевого трафика в реальном времени. Не менее существенно, что данные задержки в определенных ситуациях могут нарушить правильность функционирования телефонной сигнализации в цифровых трактах типа E1/T1 на стыке голосовых шлюзов с оборудованием коммутируемых телефонных сетей. Явление джиттера, меры уменьшения его влияния 67 Когда речь или данные разбиваются на пакеты для передачи через IP- сеть, пакеты часто прибывают в пункт назначения в различное время и в разной последовательности. Это создает разброс времени доставки пакетов - джиттер. Джиттер приводит к специфическим нарушениям передачи речи, они воспринимаются как треск и щелчки. Различают три формы джиттера: 1. Джиттер, зависимый от данных (Data Dependent Jitter – DDJ) – происходит в случае ограниченной полосы пропускания или при нарушениях в сетевых компонентах. 2. Искажение рабочего цикла (Duty Cycle Distortion – DCD) – обусловлено задержкой распространения между передачей снизу вверх и сверху вниз. 3. Случайный джиттер (Random Jitter – RJ) – является результатом теплового шума. Величины возникающих задержек и их вероятности важны для организации процедуры обработки и выбора параметров обработки. Понятно, что временная структура речевого пакетного потока меняется. Возникает необходимость применения буфера для фильтрации превращения пакетной речи, отягощенной нестационарными задержками в канале и возможными перестановками пакетов, в непрерывный естественный речевой сигнал в масштабе реального времени. Параметры буфера определяются компромиссом между величиной запаздывания телефонного сигнала в режиме дуплексной связи и процентом потерянных пакетов. Потеря пакетов является другим серьезным негативным явлением в IP-телефонии. Можно выделить следующие причины появления джиттера: 1. Влияние сети. Во-первых, неустойчиво и плохо предсказуемо время прохождения пакета через сеть. Если нагрузка сети относительно мала, маршрутизаторы и коммутаторы могут обрабатывать пакеты практически мгновенно, а линии связи бывают доступны почти всегда. Если загрузка сети относительно велика, пакеты могут довольно долго ожидать обслуживания в очередях. Чем больше маршрутизаторов, коммутаторов и линий в маршруте, по которому проходит пакет, тем больше время его запаздывания и тем больше вариация этого времени, то есть джиттер. 2. Влияние операционной системы. Большинство приложений IP-телефонии (особенно клиентских) представляет собой обычные программы, выполняемые в среде какой-либо операционной системы, например, Windows или Linux. Эти программы обращаются к периферийным устройствам (платам обработки речевых сигналов, специализированным платам систем сигнализации) через интерфейс прикладных программ для взаимодействия с драйверами этих устройств, а доступ к IP-сети осуществляют через Socket-интерфейс. Большинство операционных систем не могут контролировать распределение времени центрального процессора между разными процессами с точностью, превышающей несколько десятков миллисекунд, и не могут обрабатывать за такое же время более одного прерывания от внешних 68 устройств. Это приводит к тому, что задержка в продвижении данных между сетевым интерфейсом и внешним устройством речевого вывода составляет, независимо от используемого алгоритма кодирования речи, величину такого же порядка или даже больше. Из сказанного следует, что выбор операционной системы является фактором, влияющим на общую величину задержки. Чтобы минимизировать влияние операционной системы, некоторые производители шлюзов и IP- телефонов применяют так называемые ОС реального времени (VxWorks, pSOS, QNX Neutrino и т. д.), которые используют более сложные механизмы разделения времени процессора, действующие таким образом, чтобы обеспечивать более быструю реакцию на прерывания и более эффективный обмен потоками данных между процессами. Другой, более плодотворный подход – переложить все функции, которые необходимо выполнять в жестких временных рамках (обмен данными между речевыми кодеками и сетевым интерфейсом, поддержку RTP и т. д.), на отдельный быстродействующий специализированный процессор. При этом пересылка речевых данных осуществляется через выделенный сетевой интерфейс периферийного устройства, а операционная система рабочей станции поддерживает только алгоритмы управления соединениями и протоколы сигнализации, т. е. задачи, для выполнения которых жестких временных рамок не требуется. Влияние джиттер-буфера. Проблема джиттера весьма существенна в пакетно-ориентированных сетях. Отправитель речевых пакетов передает их через фиксированные промежутки времени (например, через каждые 20 мс), но при прохождении через сеть задержки пакетов оказываются неодинаковыми, так что они прибывают в пункт назначения через разные промежутки времени. Это иллюстрирует рис 7.3. Рис. 7.3. Различие интервалов между моментами прибытия пакетов (джиттер) Задержка прохождения пакетов по сети Т i может быть представлена как сумма постоянной составляющей Т (время распространения плюс средняя 69 длительность задержки в очередях) и переменной величины j, являющейся результатом джиттера: T i = T±j. Для того чтобы компенсировать влияние джиттера, в терминалах используется так называемый джиттер-буфер. Этот буфер хранит в памяти прибывшие пакеты в течение времени, определяемого его объемом. Пакеты, прибывающие слишком поздно, когда буфер заполнен, отбрасываются. Интервалы между пакетами восстанавливаются на основе значений временных меток RTP-пакетов. В функции джиттер-буфера обычно входит и восстановление исходной очередности следования пакетов, если при транспортировке по сети они оказались «перепутаны». Слишком короткий буфер будет приводить к слишком частым потерям «опоздавших» пакетов, а слишком длинный – к неприемлемо большой дополнительной задержке. Обычно предусматривается динамическая подстройка длины буфера в течение всего времени существования соединения. Для выбора наилучшей длины используются эвристические алгоритмы. 3. Влияние кодека и количества передаваемых в пакете кадров. Большинство современных эффективных алгоритмов кодирования/декодирования речи ориентировано на передачу информации кадрами, а не последовательностью кодов отдельных отсчетов. Поэтому в течение времени, определяемого длиной кадра кодека, должна накапливаться определенной длины последовательность цифровых представлений отсчетов. Кроме того, некоторым кодекам необходим предварительный анализ большего количества речевой информации, чем должно содержаться в кадре. Это неизбежное время накопления и предварительного анализа входит в общий бюджет длительности задержки пакета. На первый взгляд кажется, что чем меньше длина кадра, тем меньше должна быть задержка. Однако из-за значительного объема служебной информации, передаваемой в RTP/UDP/IP-пакетах, передача маленьких порций данных очень неэффективна, так что при применении кодеков с малой длиной кадра приходится упаковывать несколько кадров в один пакет. Кроме того, кодеки с большей длиной кадра более эффективны, поскольку могут «наблюдать» сигнал в течение большего времени и, следовательно, могут более эффективно моделировать этот сигнал. ITU-T в рекомендации G.114 определил требования к качеству передачи речи. Оно считается хорошим, если сквозная задержка при передаче сигнала в одну сторону не превышает 150 мс (рис. 7.4). Современное оборудование IP- телефонии при включении «спина к спине» (два устройства-шлюза соединяются напрямую) вносит задержку порядка 60-70 мс. Таким образом, остается еще около 90 мс на сетевую задержку при передаче IP-пакета от отправителя к пункту назначения, что говорит о возможности обеспечить при современном уровне технологии передачу речи с достаточно хорошим качеством. 70 Рис. 7.4. Задержка при передаче Временные задержки – проблема исключительно IP-телефонии. Именно поэтому на рисунке 4 приведены отдельные характеристики спутниковой передачи, при которой требуется примерно 170 мс для того, чтобы сигнал достиг спутника и вернулся обратно к Земле (без учета затрат времени на обработку сигнала). Таким образом, полное время задержки превышает 250- 300 мс. Согласно рекомендации G.114, такая задержка выходит за границы диапазона, приемлемого для передачи речи. Тем не менее, ежедневно значительное количество разговоров ведется по спутниковым линиям связи. Следовательно, приемлемое качество речи определяется также и требованиями пользователей, которые вынуждены согласиться с обстоятельствами. 7.2 Практическая часть 1. Изучите Руководство по настройке IP-АТС 3CX Phone System. 2. Изучите особенности настройки IP-АТС в соответствии с рекомендациями, указанными в Методическом пособим «Приемы и методы работы с аппаратурой и программным обеспечением». 3. Соберите сеть с топологией, представленной на рисунке 7.5. Рис. 7.5. Топология сети 71 4. Запустите сервер IP-телефонии в режиме Windows 7 (IP-SRV 3CX Phone System) и зарегистрируйте необходимое количество абонентов в соответствие с топологией сети. 5. Включите ПЭВМ пользователя. 6. Проверьте наличие устройств ввода-вывода звуковой информации (встроенные динамики, гарнитура) на ПЭВМ пользователя. При необходимости установите их в качестве устройств, подключенных к звуковой карте. 7. Проверьте статус регистрации абонентов на всех подключенных устройствах и сервере IP-телефонии. 8. Включите IP-телефоны и проверьте статус регистрации абонентов на IP-телефонах и сервере IP-телефонии. При необходимости зарегистрируйте абонентов заново. 9. Совершите пробные вызовы абонентов 10. Настройка переадресации вызовов: 10.1. В панели администрирования IP-АТС 3СХ Phone System в разделе «Статус абонентов», выберите номер, настройки которого необходимо изменить. Два раза «кликните» по нему мышкой. Откроются свойства абонента. В них выберите закладку «Правила переадресации». Измените настройки переадресации, установив в качестве номера абонента, на который будет переадресовываться вызов (если абонент не отвечает или занят), номер любого зарегистрированного абонента. 10.2. Сделайте пробный вызов и проследите статус абонента в панели управления, а также реакцию аппаратуры. 10.3 Проделайте те же действия с другими номерами. 10.4 Возвратите изменения в исходное состояние. 11. Настройка голосовой почты 11.1. В панели администрирования IP-АТС 3СХ Phone System в разделе «Статус абонентов», выберите номер, настройки которого необходимо изменить. Два раза «кликните» по нему мышкой. Откроются свойства абонента. В них выберите закладку «Голосовая почта». Измените настройки голосовой почты, наличие пароля доступа, озвучивание номеров и даты и т.д.). 11.2. Сделайте пробный вызов на абонента и запишите голосовую почту. 11.3. С телефона абонента, которому была адресована почта, прослушайте записанное сообщение (по умолчанию номер 9999). 11.4 Возвратите изменения в исходное состояние. 12. Настройка «Черного списка IP» 12.1. В панели администрирования IP-АТС 3СХ Phone System в разделе «Безопасность» перейдите во вкладку «Черный список IP» 12.2. Добавьте в список IP адрес телефона, номер которого, вы хотите заблокировать. Сохраните изменения. 12.3. Посмотрите реакцию телефона, номер которого заблокировали. 72 12.3. Сделайте пробный вызов заблокированного абонента. Проследите статус абонента в панели управления, а также реакцию аппаратуры. 12.4. Возвратите изменения в исходное состояние. 13. Сделайте соответствующие выводы и приведите рабочее место в первоначальное состояние |