пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Asterisk
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Почитать лекцию №16 про модель сети Министерства обороны США (DoD) можно тут.
В 1960-х годах, вплоть до 1980-х годов, основной формой связи была коммутируемая схема; отправитель просил сетевой элемент (коммутатор) подключить его к определенному приемнику, коммутатор завершал соединение (если приемник не был занят), и трафик передавался по результирующей схеме. Если это звучит как традиционная телефонная система, то это потому, что на самом деле она основана на традиционной сетевой системе (теперь называемой обычной старой телефонной службой [POTS]). Крупные телефонные и компьютерные компании были глубоко инвестированы в эту модель и получали большой доход от систем, разработанных вокруг методов коммутации цепей. По мере того, как модель DoD (и ее набор сопутствующих протоколов и концепций) начали завоевывать популярность у исследователей, эти сотрудники решили создать новую организацию по стандартизации, которая, в свою очередь, построит альтернативную систему, обеспечивающую "лучшее из обоих миров". Они будут включать в себя лучшие элементы коммутации пакетов, сохраняя при этом лучшие элементы коммутации каналов, создавая новый стандарт, который удовлетворит всех. В 1977 году эта новая организация по стандартизации была предложена и принята в качестве International Organization for Standardizatio (ISO).
Основная цель состояла в том, чтобы обеспечить взаимодействие между крупными системами баз данных, доминировавшими в конце 1970-х гг. Комитет был разделен между инженерами связи и контингентом баз данных, что усложнило стандарты. Разработанные протоколы должны были обеспечить как ориентированное на соединение, так и бесконтактное управление сеансами, а также изобрести весь набор приложений для создания электронной почты, передачи файлов и многих других приложений (помните, что приложения являются частью стека). Например, необходимо было кодифицировать различные виды транспорта для транспортировки широкого спектра услуг. В 1989 году-целых десять лет спустя-спецификации еще не были полностью выполнены. Протокол не получил широкого распространения, хотя многие правительства, крупные производители компьютеров и телекоммуникационные компании поддерживали его через стек и модель протокола DoD.
Но в течение десяти лет стек DoD продолжал развиваться; была сформирована Инженерная рабочая группа по разработке Интернету (Engineering Task Force -IETF) для поддержки стека протоколов TCP/IP, главным образом для исследователей и университетов (Интернет, как тогда было известно, не допускал коммерческого трафика и не будет до 1992 года). С отказом протоколов OSI материализоваться многие коммерческие сети и сетевое оборудование обратились к пакету протоколов TCP/IP для решения реальных проблем "прямо сейчас".
Кроме того, поскольку разработка стека протоколов TCP/IP оплачивалась по грантам правительства США, спецификации были бесплатными. На самом деле существовали реализации TCP/IP, написанные для широкого спектра систем, доступных благодаря работе университетов и аспирантов, которые нуждались в реализации для своих исследовательских усилий. Однако спецификации OSI могли быть приобретены только в бумажном виде у самой ISO и только членами ISO. ISO был разработан, чтобы быть клубом "только для членов", предназначенным для того, чтобы держать должностных лиц под контролем развития технологии коммутации пакетов. Однако принцип "только члены" организации работал против должностных лиц, что в конечном счете сыграло свою роль в их упадке.
Однако модель OSI внесла большой вклад в развитие сетей; например, пристальное внимание, уделяемое качеству обслуживания (QoS) и вопросам маршрутизации, принесло дивиденды в последующие годы. Одним из важных вкладов стала концепция четкой модульности; сложность соединения многих различных систем с множеством различных требований побудила сообщество OSI призвать к четким линиям ответственности и четко определенным интерфейсам между слоями.
Второй - это концепция межмашинного взаимодействия. Средние блоки, называемые затем шлюзами, теперь называемые маршрутизаторами и коммутаторами, явно рассматривались как часть сетевой модели, как показано на рисунке 3.
Гениальность моделирования сети таким образом заключается в том, что она делает взаимодействие между различными частями намного легче для понимания. Каждая пара слоев, перемещаясь вертикально по модели, взаимодействует через сокет или приложение.
Programming Interface (API). Таким образом, чтобы подключиться к определенному физическому порту, часть кода на канальном уровне будет подключаться к сокету для этого порта. Это позволяет абстрагировать и стандартизировать взаимодействие между различными уровнями. Компонент программного обеспечения на сетевом уровне не должен знать, как обращаться с различными видами физических интерфейсов, только как получить данные для программного обеспечения канального уровня в той же системе.
Каждый уровень имеет определенный набор функций для выполнения.
Физический уровень, также называемый уровнем 1, отвечает за модулирование или сериализацию 0 и 1 на физическом канале. Каждый тип связи будет иметь различный формат для передачи сигналов 0 или 1; физический уровень отвечает за преобразование "0" и "1" в эти физические сигналы.
Канальный уровень, также называемый уровнем 2, отвечает за то, чтобы некоторая передаваемая информация фактически отправлялась на нужный компьютер, подключенный к той же линии. Каждое устройство имеет свой адрес канала передачи данных (уровень 2), который можно использовать для отправки трафика на конкретное устройство. Уровень канала передачи данных предполагает, что каждый кадр в потоке информации отделен от всех других кадров в том же потоке, и обеспечивает связь только для устройств, подключенных через один физический канал.
Сетевой уровень, также называемый уровнем 3, отвечает за передачу данных между системами, не связанными через единую физическую линию связи. Сетевой уровень, таким образом, предоставляет сетевые адреса (или Уровень 3), а не локальные адреса линий связи, а также предоставляет некоторые средства для обнаружения набора устройств и линий связи, которые должны быть пересечены, чтобы достичь этих пунктов назначения.
Транспортный уровень, также называемый уровнем 4, отвечает за прозрачную передачу данных между различными устройствами. Протоколы транспортного уровня могут быть либо "надежными", что означает, что транспортный уровень будет повторно передавать данные, потерянные на каком-либо нижнем уровне, либо "ненадежными", что означает, что данные, потерянные на нижних уровнях, должны быть повторно переданы некоторым приложением более высокого уровня.
Сеансовый уровень, также называемый уровнем 5, на самом деле не переносит данные, а скорее управляет соединениями между приложениями, работающими на двух разных компьютерах. Сеансовый уровень гарантирует, что тип данных, форма данных и надежность потока данных все представлены и учтены.
Уровень представления, также называемый уровнем 6, фактически форматирует данные таким образом, чтобы приложение, работающее на двух устройствах, могло понимать и обрабатывать данные. Здесь происходит шифрование, управление потоком и любые другие манипуляции с данными, необходимые для обеспечения интерфейса между приложением и сетью. Приложения взаимодействуют с уровнем представления через сокеты.
Уровень приложений, также называемый уровнем 7, обеспечивает интерфейс между пользователем и приложением, которое, в свою очередь, взаимодействует с сетью через уровень представления.
Не только взаимодействие между слоями может быть точно описано в рамках семислойной модели, но и взаимодействие между параллельными слоями на нескольких компьютерах может быть точно описано. Можно сказать, что физический уровень на первом устройстве взаимодействует с физическим уровнем на втором устройстве, уровень канала передачи данных на первом устройстве с уровнем канала передачи данных на втором устройстве и так далее. Точно так же, как взаимодействие между двумя слоями на устройстве обрабатывается через сокеты, взаимодействие между параллельными слоями на разных устройствах обрабатывается через сетевые протоколы.
Ethernet описывает передачу сигналов "0" и "1" на физический провод, формат для запуска и остановки кадра данных и средство адресации одного устройства среди всех устройств, подключенных к одному проводу. Таким образом, Ethernet попадает как в физический, так и в канальный уровни передачи данных (1 и 2) в модели OSI.
IP описывает форматирование данных в пакеты, а также адресацию и другие средства, необходимые для отправки пакетов по нескольким каналам канального уровня, чтобы достичь устройства за несколько прыжков. Таким образом, IP попадает в сетевой уровень (3) модели OSI.
TCP описывает настройку и обслуживание сеанса, повторную передачу данных и взаимодействие с приложениями. TCP затем попадает в транспортный и сеансовый уровни (4 и 5) модели OSI.
Одним из наиболее запутанных моментов для администраторов, которые когда-либо сталкиваются только со стеком протоколов TCP/IP, является другой способ взаимодействия протоколов, разработанных в/для стека OSI, с устройствами. В TCP/IP адреса относятся к интерфейсам (а в мире сетей с большой степенью виртуализации несколько адресов могут относиться к одному интерфейсу, или к услуге anycast, или к multicast и т. д.). Однако в модели OSI каждое устройство имеет один адрес. Это означает, что протоколы в модели OSI часто называются типами устройств, для которых они предназначены. Например, протокол, несущий информацию о достижимости и топологии (или маршрутизации) через сеть, называется протоколом промежуточной системы (IS-IS), поскольку он работает между промежуточными системами. Существует также протокол, разработанный для того, чтобы промежуточные системы могли обнаруживать конечные системы; это называется протоколом End System to Intermediate System (ES-IS).
Когда мы, разговаривая по IP телефону, слышим голос собеседника в трубке, или, используя систему видеоконференцсвязи, общаемся со своими коллегами и родственниками, то обмениваемся непрерывным потоком данных. При передаче потоковых данных, таких как голос и видео через пакетную сеть, очень важно использовать такие механизмы, которые решали бы следующие задачи:
Устранение эффекта потери пакетов
Восстановление порядка и контроль поступления пакетов
Сглаживание эффекта задержки (джиттера)
Именно для этих целей был разработан RTP (Real-time Transport Protocol) - протокол передачи в реальном времени, о котором пойдет речь в сегодняшней статье. Протокол разрабатывался в IETF группой Audio-Video Transport Working Group и описывается в рекомендации RFC 3550.
Как правило, RTP работает поверх протокола UDP (User Datagram Protocol), так как при передаче мультимедийных данных очень важно обеспечить их своевременную доставку.
RTP включает возможность определения типа полезной нагрузки и назначения последовательного номера пакета в потоке, а также применение временных меток.
На передающей стороне каждый пакет помечается временной меткой, принимающая сторона получает ее и определяет суммарную задержку, после чего вычисляется разница в суммарных задержках и определяется джиттер. Таким образом, появляется возможность установить постоянную задержку выдачи пакетов и тем самым снизить влияние джиттера.
Ещё одна функция RTP связана с возможными потерями пакетов при прохождении по IP сети, что выражается в появлении кратковременных пауз в разговоре. Внезапная тишина в телефонной трубке, как правило, очень негативно действует на слушателя, поэтому возможностями протокола RTP такие периоды тишины заполняются, так называемым,“комфортным шумом”
RTP работает в связке с еще одним протоколом IETF, а именно RTCP (Real - time Transport Control Protocol), который описывается в RFC 3550. RTCP предназначен для сбора статистической информации, определения качества обслуживания QoS (Quality of Service), а также для синхронизации между медиа потоками RTP-сессии.
Основная функция RTCP – установление обратной связи с приложением для отчета о качестве получаемой информации. Участники RTCP сессии обмениваются сведениями о числе полученных и утраченных пакетов, значении джиттера, задержке и т.д. На основе анализа этой информации принимается решение об изменении параметров передачи, например, для уменьшения коэффициента сжатия информации с целью улучшения качества ее передачи.
Для выполнения этих функций RTCP передает специальные сообщения определенных типов:
SR - Sender Report - отчёт источника со статистической информацией о RTP сессии
RR - Receiver Report - отчёт получателя со статистической информацией о RTP сессии
SDES - содержит описание параметров источника, включая cname (имя пользователя)
BYE – Инициирует завершение участия в группе
APP - Описание функций приложения
RTP является протоколом однонаправленного действия, поэтому для организации двусторонней связи необходимо две RTP сессии, по одной с каждой стороны.
RTP-сессия определяется IP адресами участников, а также парой незарезервированных UDP портов из диапазона 16384 - 32767. Кроме того, для организации обратной связи с приложением необходимо также установить двустороннюю RTCP сессию. Для RTCP сессии занимаются порты с номером на единицу большим чем RTP. Так например, если для RTP выбран 19554 порт, то RTCP сессия займет 19555 порт. Наглядно формирование RTP/RTCP сессии представлено на рисунке ниже.
Стоит также отметить, что сам протокол RTP не имеет механизмов для самостоятельного установления сессии, эта задачу выполняют протоколы сигнализации, такие как SIP,H.323,SCCP , которые мы подробно рассматривали в предыдущих статьях.
Порой, например, при подключении аналогового телефона через FXS шлюз, на котором отсутствует регулировка громкости, необходимо отрегулировать громкость при разговоре. Предположим, что на FXS шлюзе отсутствует регулировка на порту, к которому подключен телефон. Давайте разберемся:
Данная регулировка реализуется на базе VOLUME(TX|RX). Информацию по ней можно посмотреть через консоль Asterisk:
asterisk*CLI> core show function VOLUME
-= Info about function 'VOLUME' =-
[Synopsis]
Set the TX or RX volume of a channel. \ можно настроить громкость для канала
[Description]
The VOLUME function can be used to increase or decrease the 'tx' or 'rx' gain
of any channel.
For example:
Set(VOLUME(TX)=3)
Set(VOLUME(RX)=2)
Set(VOLUME(TX,p)=3)
Set(VOLUME(RX,p)=3)
[Syntax]
VOLUME(direction[,options])
[Arguments]
direction
Must be 'TX' or 'RX'.
options
p: Enable DTMF volume control
[See Also]
Not available
Данная функция имеет 2 параметра:
Направление, т.е TX – отправка, RX – прием.
Дополнительная опция p, которая активирует контроль над звуком по DTMF
На данном этапе мы разобрались с функцией VOLUME. Теперь открываем файл extensions_customs.conf и производим следующие настройки нового контекста:
[root@asterisk ~]# vim /etc/asterisk/extensions_custom.conf
[volume-set]
exten => _X.,1,NoOp(Volume settings)
same => n,Set(VOLUME(TX)=5)
same => n,Set(VOLUME(RX)=5)
same => n,Goto(from-internal,${EXTEN},1)
Теперь открываем необходимый нам Extension, и в поле Context, вносим название созданного нами выше контекста - volume-set.
Теперь можно регулировать громкость в настройках контекста, изменяя значение с 5 на другое, параллельно проверяя громкость в трубке