- •2 .3.5.1 Основные понятия ………………………………………………….….23
- •3.10. Комплексная оценка качества ip-телефонии……………………...42
- •8.1. Типы угроз в сетях ip-телефонии…………………..…79
- •Перспективы
- •1. Общие вопросы технологии ip-телефонии
- •1.1.Терминология
- •1.2ОсобенностиIp-телефонии
- •1.4 Виды соединений, взаимодействие с компьютерной сетью.
- •2 Использование протоколов Интернет в ip-телефонии.
- •2.1 Адресация в ip-сетях
- •2.2 Модель osi.
- •2.3. Основные протоколы ip-телефонии
- •2.3.1 Протокол ip версии 4
- •2.3.2 Протокол ip версии 6
- •2.3.3 Протокол tcp
- •2.3.4 Протокол udp
- •2.3.5 Протоколы rtp и rtcp
- •2.3.5.1 Основные понятия
- •2.3.5.2 Групповая аудиоконференцсвязь
- •2.3.5.3 Видеоконференцсвязь
- •2.3.5.4 Понятие о микшерах и трансляторах
- •2.5.5.5. Порядок байтов, выравнивание и формат меток времени
- •2.3.5.6 . Протокол управления rtcp
- •2.3.5.7 Интенсивность передачи пакетов rtcp
- •2.3.5.8 Общее описание транслятора и микшера
- •2.3.5.9 Взаимодействие rtp с протоколами сетевого и транспортного уровней
- •3. Передача речи по ip-сети
- •3.1 Протоколы VoIp
- •3.2 Особенности передачи речевой информации по ip-сети.
- •3.3 Задержка и меры уменьшения ее влияния.
- •3.4. Явление джиттера, меры уменьшения его влияния.
- •3.5. Эхо, устройства ограничения его влияния.
- •3.6 Принципы кодирования речи
- •3.7 Кодирование формы сигнала
- •3.8 Основные требованияк алгоритмам кодирования ip-телефонии.
- •3.9 Кодеки ip-телефонии.
- •3.10. Комплексная оценка качества ip-телефонии
- •4. Протокол н.323
- •Рекомендации h.323 предусматривают:
- •Управление полосой пропускания
- •Межсетевые конференции
- •Совместимость
- •Гибкость
- •4.1. Архитектура стандарта h.323
- •4.2. Стек протоколов h.323
- •4.3. Установка соединения по h.323
- •4.4. Характеристики шлюзов ip-телефонии
- •Классификация шлюзов ip-телефонии
- •1. Автономные ip-шлюзы
- •2. Маршрутизаторы-шлюзы
- •4. Шлюзы-модули для упатс
- •5. Шлюзы с интеграцией бизнес-приложений
- •6.Учрежденческие атс на базе шлюзов
- •7. Сетевые платы с функциями телефонии
- •8. Автономные ip-телефоны
- •4.5. Достоинства и недостатки h.323
- •5. Протокол инициирования сеансов связи (sip)
- •5.1 Принципы построения протокола sip
- •5.2 Интеграция протокола sip с ip-сетями
- •5.3 Адресация
- •5.4 Архитектура сети sip
- •5.4.1 Терминал
- •5.4.2 Прокси-сервер
- •5.4.3 Сервер переадресации
- •5.4.4 Сервер определения местоположения пользователей
- •5.4.5 Пример sip-сети
- •5.5 Соединение по sip
- •6.1 Принцип декомпозиции шлюза
- •6.2 Классификация шлюзов
- •6.3 Модель организации связи
- •6.4 Команды протокола mgcp
- •7. Качество обслуживания в сетях ip-телефонии
- •7.2 Трафик реального времени в ip-сетях
- •7.3 Дифференцированное обслуживание разнотипного трафика - Diff-Serv
- •7.4. Интегрированное обслуживание IntServ
- •7.6 Протокол резервирования ресурсов - rsvp
- •7.7 Технология mpls
- •7.8 Сравнение технологий IntServ, DiffServ, mpls
- •7.9 Обслуживание очередей
- •7.9.1 Алгоритмы организации очереди
- •7.9.2 Алгоритмы обработки очередей
- •Справедливые очереди базирующиеся на классах (cbwfq)
- •Очереди с малой задержкой (llq)
- •8. Информационная безопасность в ip-сетях
- •8.1. Типы угроз в сетях ip-телефонии
- •8.2. Методы криптографической защиты информации
- •8.3. Технологии аутентификации
- •8.3.1. Протокол ppp
- •8.3.2. Протокол tacacs
- •8.3.3. Протокол radius
- •8.4. Особенности системы безопасности в ip-телефонии
- •1. Телефонный аппарат.
- •2. Установление соединения.
- •3.Телефонный разговор.
- •4. Невидимый функционал.
- •5. Общение с внешним миром.
- •8.5. Обеспечение безопасности на базе протокола osp
- •8.6. Обеспечение безопасности ip-телефонии на базе vpn
- •9. Мобильность ip-телефонии
- •9.1. Разновидности мобильности
- •9.2. Идентификация терминала и пользователя
- •9.3. Сценарии мобильности в сетях ip-телефонии
- •9.4. Мобильность в сети ip-телефонии на базе протокола sip и h.323
- •10 Системы биллинга и менеджмента пользователейIp-телефонией.
- •10. 1 Особенности учета и биллинга ip - услуг
- •10.2. Требования к системе биллинга и менеджмента пользователей ip-телефонии
- •10.3. Обзор систем биллинга и менеджмента пользователей ip-телефонии
- •11. Внедрение ip-телефонии на базе продуктовой линейки d-Link. В качестве примера, рассмотрим реализацию ip-телефоной связи на базе наиболее экономически доступного оборудования.
- •11.1. Варианты построения ip-телефонных систем
- •11.2. Применение телефонных usb-адаптеров
- •11.3. Применение VоIp-шлюзов
- •11.4. Соединение офисов с помощью сети Интернет
- •Информационное представление речевого сигнала
- •Речевые кодеки для ip-телефонии
- •Архитектура шлюза
- •Для ознакомления с работой шлюза воспользуемся следующей схемой:
- •Сетевые протоколы
- •Реализация шлюзов для ip-телефонии
- •11.5. Видеотелефония
- •Построение транков в ip-телефонии
- •Варианты связи
- •Оборудование
- •Требования к каналу
- •23 Расширения протокола управления резервированием (rsvp-te) при обобщенной многопротокольной коммутации по меткам (gmpls)
2.3.5.2 Групповая аудиоконференцсвязь
Для организации групповой аудиоконференцсвязи требуется многопользовательский групповой адрес и два порта. При этом один порт необходим для обмена звуковыми данными, а другой используется для пакетов управления протокола RTCP. Информация о групповом адресе и портах передается предполагаемым участникам телеконференции. Если требуется секретность, то информационные и управляющие пакеты могут быть зашифрованы, в этом случае также должен быть сгенерирован и распределен ключ шифрования.
Приложение аудиоконференцсвязи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC) использовался при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.
В сети Internet, как и в других сетях передачи данных с коммутацией пакетов, пакеты иногда теряются и переупорядочиваются, а также задерживаются на различное время. Для противодействия этим событиям заголовок RTP содержит временную метку и порядковый номер, которые позволяют получателям восстановить синхронизацию в исходном виде так, чтобы, например, участки звукового сигнала воспроизводились динамиком непрерывно каждые 20 мс. Эта реконструкция синхронизации выполняется отдельно и независимо для каждого источника пакетов RTP в телеконференции. Порядковый номер может также использоваться получателем для оценки количества потерянных пакетов.
Так как участники телеконференции могут вступать и выходить из нее во время ее проведения, то полезно знать, кто участвует в ней в данный момент, и как хорошо участники конференции получают звуковые данные. Для этой цели каждый экземпляр звукового приложения во время конференции периодически выдает на порт управления (порт RTCP) для приложений всех остальных участников сообщения о приеме пакетов с указанием имени своего пользователя. Сообщение о приеме указывает, как хорошо слышим текущий оратор, и может использоваться для управления адаптивными кодерами. В дополнение к имени пользователя, может быть включена также другая информация идентификации для контроля полосы пропускания. При выходе из конференции сайт посылает пакет BYE протокола RTCP.
2.3.5.3 Видеоконференцсвязь
Если в телеконференции используются и звуковые, и видеосигналы, то они передаются отдельно. Для передачи каждого типа трафика независимо от другого спецификацией протокола вводится понятие сеанса связи RTP (см. список используемых сокращений и терминов). Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пакеты для каждого типа трафика передаются с использованием двух различных пар портов UDP и/или групповых адресов. Никакого непосредственного соединения на уровне RTP между аудио- и видеосеансами связи не имеется, за исключением того, что пользователь, участвующий в обоих сеансах, должен использовать одно и то же каноническое имя в RTCP-пакетах для обоих сеансов так, чтобы сеансы могли быть связаны.
Одна из причин такого разделения состоит в том, что некоторым участникам конференции необходимо позволить получать только один тип трафика, если они этого желают. Несмотря на разделение, синхронное воспроизведение мультимедийных данных источника (звука и видео) может быть достигнуто при использовании информации таймирования, которая переносится в пакетах RTCP для обоих сеансов.
