В этой лекции рассмотрим нагрузку (трафик) в реальном масштабе времени и ее обработку в Интернете. Большинство людей используют термины "нагрузка в реальном масштабе времени" и "мультимедиа-нагрузка" как взаимно заменяемые. Однако не всякий мультимедиа-трафик нуждается в обработке в реальном масштабе времени.
Чтобы отличить связь в реальном масштабе времени от других типов связи, необходимо определить трафик в реальном масштабе времени. Неформально, игнорируя короткие задержки при передаче, — это почти одновременное производство и использование данных. Другими словами, передатчик вырабатывает данные, посылает их в Интернет, а приемник использует их. Обычно, когда приемник использует полученные данные, следующая часть еще в производстве.
Пример трафика мультимедиа, не использующего работу в реальном масштабе времени, – загрузка видео из Интернета. Видео — уже созданный и окончательный продукт. Клиент HTTP использует загрузку видео от HTTP-сервера, и пользователь смотрит видео в последующее время. Производство и использование происходит в различные моменты времени.
Теперь давайте рассмотрим пример трафика, работающего в реальном масштабе времени. Рассмотрим видеоконференцию, в которой камера подключена к серверу, передающему видеоинформацию, как только она произведена. Все, что происходит на стороне сервера, может быть отображено на компьютере клиентской стороны. Это и мультимедиа (видео), и трафик реального времени (продукция и использование в одно и тоже время.).
Данные в реальном масштабе времени имеют характеристики, обычные для всех типов данных (аудио, видео и текста).
Данные в реальном масштабе времени на сети пакетной коммутации требуют сохранения временных соотношений между пакетами сеансов. Например, предположим, что видео-сервер, работающий в реальном масштабе времени, создает живые изображения и посылает их по линии. Видео переводится в цифровую форму и пакетизируется. Имеется только три типа пакетов, и каждый пакет содержит 10 секунд видеоинформации. Первый пакет стартует в 00:00:00, второй — в 00:00:10, а третий пакет в 00:00:20. Также изображение требует одной секунды (преувеличено для простоты) для каждого пакета, чтобы достичь пункта назначения (задержка одинаковая). Приемник может воспроизводить первый пакет в 00:00:01, второй пакет в 00:00:11 и третий пакет в 00:00:21. Хотя имеется односекундная разница между тем, что видит оператор камеры и приемная сторона и что удаленный зритель видит на экране компьютера, действие происходит в реальном масштабе времени. Соотношение между пакетами сохраняется. Односекундная задержка не имеет значения. Рисунок 17.1. иллюстрирует эту идею.
(рис 17.1) Временные соотношенияНо что произойдет, если пакеты прибывают с различной задержкой? Например ( рис. 17.2.а) первый пакет прибывает в 00:00:01 (односекундная задержка), второй в 00:00:15 (пятисекундная задержка) и третий в 00:00:27 (семисекундная задержка). Если приемник начинает воспроизведение первого пакета в 00:00:01, он закончит в 00:00:11, однако следующий пакет еще не прибудет; он прибудет на 4 секунды позднее. Имеется промежуток между первым и вторым пакетом и между вторым и третьим, — это приведет к помехам на дальней стороне.
Один из методов решения проблемы джиттера– использование меток времени. Если каждый пакет имеет метку времени, которая указывает время его создания относительно первого (или предыдущего) пакета, то приемник может дополнить это время ко времени начала воспроизведения. Другими словами, приемник знает, когда каждый пакет должен быть воспроизведен. Допустим, первый пакет в предыдущем примере имеет временную метку 0, второй имеет временную метку 10 и третий временную метку 20. Если приемник начинает воспроизводить первый пакет в 00:00:08, второй в 00:00:18, а третий в 00:00:28, то зазора между пакетами не возникнет. Рис. 17.2б. показывает такую ситуацию.
(рис 17.2) Принцип передачи информации с учетом задержкиЧтобы отделить время прибытия от времени воспроизведения, нам нужен буфер для накопления данных, пока они воспроизводятся. Этот буфер называется буфером воспроизведения. Когда начинается сеанс (прибывает первый бит первого пакета), приемник задерживает воспроизведение данных, пока не будет достигнут порог. В предыдущих примерах первый бит первого пакета прибывал в 00:00:01; порог 7 с., время воспроизведения 00:00:08. Порог измеряется в единицах времени блока данных. Ответ не должен начинаться, пока время единицы данных не равно
Данные накапливаются в буфере, возможно, с переменной скоростью. Заметим, что количество данных в буфере будет сокращаться и расширяться, но пока задержка меньше, чем время воспроизведения, количество данных не имеет джиттера. Рис. 17.3. показывает буфер с различными временами для нашего примера.
(рис 17.3) Буфер воспроизведения
В дополнение к временным соотношениям информации и меткам времени для трафика, работающего в реальном масштабе времени, необходимо еще одно свойство. Нам нужен порядковый номер для каждого пакета. Метка времени не может информировать приемник, если пакет потерян. Например, предположим, что метки времени — 0, 10, 20. Если второй пакет потерян, приемник получает только два пакета с метками времени 0 и 20. Приемник предполагает, что пакет с меткой 20 — это второй по порядку пакет,который послан через 20 секунд после первого. Приемник не имеет средств для того, чтобы узнать, что второй в этой последовательности пакет на самом деле потерян. Чтобы разобраться в этой ситуации, пакетам необходимо присвоить последовательный номер.
Мультимедиа играют первичную роль в аудио- и видеоконференциях. Трафик может быть интенсивным, и данные могут распределяться с использованием метода циркулярной рассылки. Конференц-связь может потребовать использования двух методов коммутации в разных направлениях между приемником и передатчиком.
Иногда трафик, работающий в реальном масштабе времени, нуждается в трансляции. Транслятор – это компьютер, который может изменить формат широкополосного видео в низкокачественный сигнал с узкой полосой. Это нужно, например, для источника, который порождает сигнал 5 Мбит/с и посылает его к получателю, имеющему полосу, меньшую чем 1 Мбит. Для получения сигнала транслятору нужно декодировать сигнал и закодировать опять в сигнал более низкого качества, который нуждается в меньшей полосе.
Если имеется более чем один источник, который может посылать данные в одно и то же время (как в видео- и аудиоконференциях), тогда трафик состоит из многих потоков. Чтобы уменьшить трафик к одному источнику, данные от различных источников могут быть смешаны в один источник. Смешивание – это математическое сложение сигналов, поступающих от различных источников, для того чтобы создать единственный сигнал.
Процедуры, упомянутые в предыдущих разделах, могут выполняться на прикладных уровнях. Однако они настолько обычны для приложений, работающих в реальном масштабе времени, что предпочтительней их выполнение на уровне транспортного протокола. Рассмотрим, какой из существующих транспортных уровней подходит для этого типа трафика.
TCP не годится для трафика, работающего в реальном масштабе времени. Он не обеспечивает метки времени и не поддерживает циркулярную передачу. Однако он обеспечивает механизм управления упорядочения (последовательную нумерацию) При трафике, работающем в реальном масштабе времени, мы не можем позволить повторную передачу потерянных или искаженных пакетов. Если пакет потерян или искажен в трафике реального времени, он может быть только проигнорирован. Повторная передача полностью срывает идею меток времени и воспроизведения. Сегодня есть большая избыточность в аудио- и видеосигналах (даже со сжатием), при которой мы можем просто игнорировать потерю пакета. Слушатель и зритель на дальнем конце может даже не заметить этого.
UDP более пригоден для мультимедиа — трафика реального времени. UDP поддерживает циркулярную передачу, но не имеет стратегии повторной передачи. Однако UDP не обеспечивает метки времени, последовательной нумерации или смешивания.
Транспортный протокол реального масштаба времени (Real-time
Рис. 17.4. показывает формат заголовка
(рис 17.4) RTP формат заголовка пакетаФормат очень прост и в общем случае достаточен, чтобы покрыть все приложения реального времени. Приложение, которое нуждается в большей информации, дополняет его к началу полезной загрузки. Описание каждого поля приведено ниже.
| Тип | Приложение | Тип | Приложение | Тип | Приложение |
|---|---|---|---|---|---|
| 0 | 7 | 15 | G728 audio | ||
| 1 | 1016 | 8 | PCMA audio | 26 | Motion JPEG |
| 2 | G721 audio | 9 | G722 audio | 31 | H.261 |
| 3 | 10-11 | L16 audio | 32 | MPEG2 video | |
| 5-6 | DV14 audio | 14 | MPEG audio | 33 | MPEG2 video |
Хотя
(рис 17.5) RTCPОтчет передатчика посылается периодически активным передатчиком по конференц-связи, чтобы передать отчет о статистике передачи и приема для всех
Отчет приемника – для пассивных участников, тех, которые не посылают
Источник периодически посылает сообщение описания источника, чтобы дать дополнительную информацию о самом себе. Эта информация может быть именем, электронным адресом, телефонным номером и адресом собственника или контроллера источника.
Источник посылает сообщение отбоя, чтобы закрыть поток. Оно позволяет источнику объявить, что он покидает конференцию. Хотя другой источник способен определить отсутствие источника, это сообщение есть прямое объявление. Оно очень полезно для смесителя.
Специальное прикладное сообщение – это пакет для приложения, которое намерено использовать новые приложения (не определенные в системе). Он позволяет определение новых типов сообщений.
Рассмотрим одно из интерактивных приложений протоколов реального времени — IP-телефонию. Задача этого приложения – использовать Интернет как телефонную сеть с некоторыми дополнительными возможностями. При этом вместо коммутации через коммутаторы это приложение позволяет применять коммутацию пакетов через Интернет. Для этого типа коммутации разработано два протокола:
Протокол инициализации сеанса связи (SIP) был разработан IETF. Это протокол прикладного уровня, который устанавливает, управляет и заканчивает мультимедийный сеанс (вызов). Он может использоваться, чтобы создать соединения с двумя участниками, многими участниками или сеансы групповой рассылки.
SIP — протокол, похожий на HTTP.
(рис 17.6) SIP-сообщенияКаждое сообщение имеет заголовок и текстовый блок ("тело"). Заголовок состоит из нескольких строк, которые описывают структуру сообщения, возможности вызывающего абонента, типа среды передачи, и так далее. Рассмотрим кратко описание каждого сообщения. Затем покажем их приложения на примере простого сеанса связи.
Вызывающий абонент вначале инициализирует сеанс сообщением INVITE (приглашение). После того, как вызываемый абонент ответит на вызов, вызывающий абонент передает сообщение
Сообщение BYE заканчивает сеанс. Сообщение OPTION делает запрос компьютера о его возможностях. Сообщение CANCEL отменяет уже начатый процесс инициализации. Сообщение REGISTER обрабатывает вызов, когда вызываемый абонент не доступен.
В обычной телефонной связи применяются два номера: телефонный номер исходящего абонента и телефонный номер входящего абонента.
(рис 17.7) Форматы SIP
Простой сеанс
(рис 17.8) SIP – простой сеансУстановления соединения. Сеанс установления соединения требует трех этапов. Вызывающий абонент для начала установления соединения посылает сообщение INVITE, используя UDP, TCP или SCTP. Если вызываемый абонент желает начать сеанс, он высылает ответное сообщение. Вызывающий абонент для завершения этого этапа посылает сообщение подтверждения
Обмен информацией. После того как сеанс установлен, вызывающий и вызываемый абонент могут обмениваться информацией по двум временным портам.
Завершение сеанса. Сеанс может быть завершен сообщением BYE, которое может быть передано любой стороной.
Что произойдет, если вызываемого абонента нет около терминала? Он может отойти или перейти на другой терминал. Он может не иметь фиксированного IP-адреса, если использует протокол динамической реконфигурации хостов, который автоматически назначает адреса терминальным станциям и хостам.
Когда вызывающий абонент должен связаться с вызываемым абонентом, он может использовать электронную почту вместо адреса IP в сообщении INVITE. Сообщение переходит на вспомогательный сервер (INVITE вызывающего абонента и находит IP-адрес вызываемого абонента. Это сообщение затем посылают вызывающему абоненту. Процесс показан на рис. 17.9.
(рис 17.9) Отслеживание входящего абонента
H.323 — стандарт, разработанный ITU, обеспечивающий разговоры по телефонам на телефонной сети общего пользования с пользователями компьютерами (называемыми в H.323 терминалами), подключенными к Интернету. На рис. 17.10. показана общая архитектура H.323.
(рис 17.10) Архитектура H.323Шлюз (gateway) соединяет Интернет с телефонной сетью. Вообще, шлюз — устройство с пятью уровнями, которое может транслировать сообщение от одного стека протокола к другому. В данном случае шлюз здесь делает точно то же самое, что и везде. Он преобразует телефонное сетевое сообщение в сообщение Интернета. Сервер контроллера зоны (
Контроллер зоны (gatekeeper) выполняет функции: преобразования адресов телефонной сети общего пользования в IP-адреса, управления доступом к сети и обеспечения необходимых мер безопасности.
H.323 использует множество протоколов, чтобы установить и поддерживать передачу речи или видео. Рис. 17.11 показывает эти протоколы.
(рис 17.11) Протоколы H.323H.323 использует для сжатия данных протоколы G.71 и G.723.1. Протокол Q.931 применяется для установления и завершения соединения. H.323 нужен для проверки прав доступа и регистрации пользователей. H.245 — протокол регистрации допуска и статуса
Покажем на простом примере работу по установлению телефонного соединения с помощью протокола H.323. На рис. 17.12. приведены шаги для установления связи терминала с телефоном.
(рис 17.12) Пример установления и завершения соединения по протоколу H.323Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.
В этой лекции рассмотрим нагрузку (трафик) в реальном масштабе времени и ее обработку в Интернете. Большинство людей используют термины "нагрузка в реальном масштабе времени" и "мультимедиа-нагрузка" как взаимно заменяемые. Однако не всякий мультимедиа-трафик нуждается в обработке в реальном масштабе времени.
Чтобы отличить связь в реальном масштабе времени от других типов связи, необходимо определить трафик в реальном масштабе времени. Неформально, игнорируя короткие задержки при передаче, — это почти одновременное производство и использование данных. Другими словами, передатчик вырабатывает данные, посылает их в Интернет, а приемник использует их. Обычно, когда приемник использует полученные данные, следующая часть еще в производстве.
Пример трафика мультимедиа, не использующего работу в реальном масштабе времени, – загрузка видео из Интернета. Видео — уже созданный и окончательный продукт. Клиент HTTP использует загрузку видео от HTTP-сервера, и пользователь смотрит видео в последующее время. Производство и использование происходит в различные моменты времени.
Теперь давайте рассмотрим пример трафика, работающего в реальном масштабе времени. Рассмотрим видеоконференцию, в которой камера подключена к серверу, передающему видеоинформацию, как только она произведена. Все, что происходит на стороне сервера, может быть отображено на компьютере клиентской стороны. Это и мультимедиа (видео), и трафик реального времени (продукция и использование в одно и тоже время.).
Данные в реальном масштабе времени имеют характеристики, обычные для всех типов данных (аудио, видео и текста).
Данные в реальном масштабе времени на сети пакетной коммутации требуют сохранения временных соотношений между пакетами сеансов. Например, предположим, что видео-сервер, работающий в реальном масштабе времени, создает живые изображения и посылает их по линии. Видео переводится в цифровую форму и пакетизируется. Имеется только три типа пакетов, и каждый пакет содержит 10 секунд видеоинформации. Первый пакет стартует в 00:00:00, второй — в 00:00:10, а третий пакет в 00:00:20. Также изображение требует одной секунды (преувеличено для простоты) для каждого пакета, чтобы достичь пункта назначения (задержка одинаковая). Приемник может воспроизводить первый пакет в 00:00:01, второй пакет в 00:00:11 и третий пакет в 00:00:21. Хотя имеется односекундная разница между тем, что видит оператор камеры и приемная сторона и что удаленный зритель видит на экране компьютера, действие происходит в реальном масштабе времени. Соотношение между пакетами сохраняется. Односекундная задержка не имеет значения. Рисунок 17.1. иллюстрирует эту идею.
(рис 17.1) Временные соотношенияНо что произойдет, если пакеты прибывают с различной задержкой? Например ( рис. 17.2.а) первый пакет прибывает в 00:00:01 (односекундная задержка), второй в 00:00:15 (пятисекундная задержка) и третий в 00:00:27 (семисекундная задержка). Если приемник начинает воспроизведение первого пакета в 00:00:01, он закончит в 00:00:11, однако следующий пакет еще не прибудет; он прибудет на 4 секунды позднее. Имеется промежуток между первым и вторым пакетом и между вторым и третьим, — это приведет к помехам на дальней стороне.
Один из методов решения проблемы джиттера– использование меток времени. Если каждый пакет имеет метку времени, которая указывает время его создания относительно первого (или предыдущего) пакета, то приемник может дополнить это время ко времени начала воспроизведения. Другими словами, приемник знает, когда каждый пакет должен быть воспроизведен. Допустим, первый пакет в предыдущем примере имеет временную метку 0, второй имеет временную метку 10 и третий временную метку 20. Если приемник начинает воспроизводить первый пакет в 00:00:08, второй в 00:00:18, а третий в 00:00:28, то зазора между пакетами не возникнет. Рис. 17.2б. показывает такую ситуацию.
(рис 17.2) Принцип передачи информации с учетом задержкиЧтобы отделить время прибытия от времени воспроизведения, нам нужен буфер для накопления данных, пока они воспроизводятся. Этот буфер называется буфером воспроизведения. Когда начинается сеанс (прибывает первый бит первого пакета), приемник задерживает воспроизведение данных, пока не будет достигнут порог. В предыдущих примерах первый бит первого пакета прибывал в 00:00:01; порог 7 с., время воспроизведения 00:00:08. Порог измеряется в единицах времени блока данных. Ответ не должен начинаться, пока время единицы данных не равно
Данные накапливаются в буфере, возможно, с переменной скоростью. Заметим, что количество данных в буфере будет сокращаться и расширяться, но пока задержка меньше, чем время воспроизведения, количество данных не имеет джиттера. Рис. 17.3. показывает буфер с различными временами для нашего примера.
(рис 17.3) Буфер воспроизведения
В дополнение к временным соотношениям информации и меткам времени для трафика, работающего в реальном масштабе времени, необходимо еще одно свойство. Нам нужен порядковый номер для каждого пакета. Метка времени не может информировать приемник, если пакет потерян. Например, предположим, что метки времени — 0, 10, 20. Если второй пакет потерян, приемник получает только два пакета с метками времени 0 и 20. Приемник предполагает, что пакет с меткой 20 — это второй по порядку пакет,который послан через 20 секунд после первого. Приемник не имеет средств для того, чтобы узнать, что второй в этой последовательности пакет на самом деле потерян. Чтобы разобраться в этой ситуации, пакетам необходимо присвоить последовательный номер.
Мультимедиа играют первичную роль в аудио- и видеоконференциях. Трафик может быть интенсивным, и данные могут распределяться с использованием метода циркулярной рассылки. Конференц-связь может потребовать использования двух методов коммутации в разных направлениях между приемником и передатчиком.
Иногда трафик, работающий в реальном масштабе времени, нуждается в трансляции. Транслятор – это компьютер, который может изменить формат широкополосного видео в низкокачественный сигнал с узкой полосой. Это нужно, например, для источника, который порождает сигнал 5 Мбит/с и посылает его к получателю, имеющему полосу, меньшую чем 1 Мбит. Для получения сигнала транслятору нужно декодировать сигнал и закодировать опять в сигнал более низкого качества, который нуждается в меньшей полосе.
Если имеется более чем один источник, который может посылать данные в одно и то же время (как в видео- и аудиоконференциях), тогда трафик состоит из многих потоков. Чтобы уменьшить трафик к одному источнику, данные от различных источников могут быть смешаны в один источник. Смешивание – это математическое сложение сигналов, поступающих от различных источников, для того чтобы создать единственный сигнал.
Процедуры, упомянутые в предыдущих разделах, могут выполняться на прикладных уровнях. Однако они настолько обычны для приложений, работающих в реальном масштабе времени, что предпочтительней их выполнение на уровне транспортного протокола. Рассмотрим, какой из существующих транспортных уровней подходит для этого типа трафика.
TCP не годится для трафика, работающего в реальном масштабе времени. Он не обеспечивает метки времени и не поддерживает циркулярную передачу. Однако он обеспечивает механизм управления упорядочения (последовательную нумерацию) При трафике, работающем в реальном масштабе времени, мы не можем позволить повторную передачу потерянных или искаженных пакетов. Если пакет потерян или искажен в трафике реального времени, он может быть только проигнорирован. Повторная передача полностью срывает идею меток времени и воспроизведения. Сегодня есть большая избыточность в аудио- и видеосигналах (даже со сжатием), при которой мы можем просто игнорировать потерю пакета. Слушатель и зритель на дальнем конце может даже не заметить этого.
UDP более пригоден для мультимедиа — трафика реального времени. UDP поддерживает циркулярную передачу, но не имеет стратегии повторной передачи. Однако UDP не обеспечивает метки времени, последовательной нумерации или смешивания.
Транспортный протокол реального масштаба времени (Real-time
Рис. 17.4. показывает формат заголовка
(рис 17.4) RTP формат заголовка пакетаФормат очень прост и в общем случае достаточен, чтобы покрыть все приложения реального времени. Приложение, которое нуждается в большей информации, дополняет его к началу полезной загрузки. Описание каждого поля приведено ниже.
| Тип | Приложение | Тип | Приложение | Тип | Приложение |
|---|---|---|---|---|---|
| 0 | 7 | 15 | G728 audio | ||
| 1 | 1016 | 8 | PCMA audio | 26 | Motion JPEG |
| 2 | G721 audio | 9 | G722 audio | 31 | H.261 |
| 3 | 10-11 | L16 audio | 32 | MPEG2 video | |
| 5-6 | DV14 audio | 14 | MPEG audio | 33 | MPEG2 video |
Хотя
(рис 17.5) RTCPОтчет передатчика посылается периодически активным передатчиком по конференц-связи, чтобы передать отчет о статистике передачи и приема для всех
Отчет приемника – для пассивных участников, тех, которые не посылают
Источник периодически посылает сообщение описания источника, чтобы дать дополнительную информацию о самом себе. Эта информация может быть именем, электронным адресом, телефонным номером и адресом собственника или контроллера источника.
Источник посылает сообщение отбоя, чтобы закрыть поток. Оно позволяет источнику объявить, что он покидает конференцию. Хотя другой источник способен определить отсутствие источника, это сообщение есть прямое объявление. Оно очень полезно для смесителя.
Специальное прикладное сообщение – это пакет для приложения, которое намерено использовать новые приложения (не определенные в системе). Он позволяет определение новых типов сообщений.
Рассмотрим одно из интерактивных приложений протоколов реального времени — IP-телефонию. Задача этого приложения – использовать Интернет как телефонную сеть с некоторыми дополнительными возможностями. При этом вместо коммутации через коммутаторы это приложение позволяет применять коммутацию пакетов через Интернет. Для этого типа коммутации разработано два протокола:
Протокол инициализации сеанса связи (SIP) был разработан IETF. Это протокол прикладного уровня, который устанавливает, управляет и заканчивает мультимедийный сеанс (вызов). Он может использоваться, чтобы создать соединения с двумя участниками, многими участниками или сеансы групповой рассылки.
SIP — протокол, похожий на HTTP.
(рис 17.6) SIP-сообщенияКаждое сообщение имеет заголовок и текстовый блок ("тело"). Заголовок состоит из нескольких строк, которые описывают структуру сообщения, возможности вызывающего абонента, типа среды передачи, и так далее. Рассмотрим кратко описание каждого сообщения. Затем покажем их приложения на примере простого сеанса связи.
Вызывающий абонент вначале инициализирует сеанс сообщением INVITE (приглашение). После того, как вызываемый абонент ответит на вызов, вызывающий абонент передает сообщение
Сообщение BYE заканчивает сеанс. Сообщение OPTION делает запрос компьютера о его возможностях. Сообщение CANCEL отменяет уже начатый процесс инициализации. Сообщение REGISTER обрабатывает вызов, когда вызываемый абонент не доступен.
В обычной телефонной связи применяются два номера: телефонный номер исходящего абонента и телефонный номер входящего абонента.
(рис 17.7) Форматы SIP
Простой сеанс
(рис 17.8) SIP – простой сеансУстановления соединения. Сеанс установления соединения требует трех этапов. Вызывающий абонент для начала установления соединения посылает сообщение INVITE, используя UDP, TCP или SCTP. Если вызываемый абонент желает начать сеанс, он высылает ответное сообщение. Вызывающий абонент для завершения этого этапа посылает сообщение подтверждения
Обмен информацией. После того как сеанс установлен, вызывающий и вызываемый абонент могут обмениваться информацией по двум временным портам.
Завершение сеанса. Сеанс может быть завершен сообщением BYE, которое может быть передано любой стороной.
Что произойдет, если вызываемого абонента нет около терминала? Он может отойти или перейти на другой терминал. Он может не иметь фиксированного IP-адреса, если использует протокол динамической реконфигурации хостов, который автоматически назначает адреса терминальным станциям и хостам.
Когда вызывающий абонент должен связаться с вызываемым абонентом, он может использовать электронную почту вместо адреса IP в сообщении INVITE. Сообщение переходит на вспомогательный сервер (INVITE вызывающего абонента и находит IP-адрес вызываемого абонента. Это сообщение затем посылают вызывающему абоненту. Процесс показан на рис. 17.9.
(рис 17.9) Отслеживание входящего абонента
H.323 — стандарт, разработанный ITU, обеспечивающий разговоры по телефонам на телефонной сети общего пользования с пользователями компьютерами (называемыми в H.323 терминалами), подключенными к Интернету. На рис. 17.10. показана общая архитектура H.323.
(рис 17.10) Архитектура H.323Шлюз (gateway) соединяет Интернет с телефонной сетью. Вообще, шлюз — устройство с пятью уровнями, которое может транслировать сообщение от одного стека протокола к другому. В данном случае шлюз здесь делает точно то же самое, что и везде. Он преобразует телефонное сетевое сообщение в сообщение Интернета. Сервер контроллера зоны (
Контроллер зоны (gatekeeper) выполняет функции: преобразования адресов телефонной сети общего пользования в IP-адреса, управления доступом к сети и обеспечения необходимых мер безопасности.
H.323 использует множество протоколов, чтобы установить и поддерживать передачу речи или видео. Рис. 17.11 показывает эти протоколы.
(рис 17.11) Протоколы H.323H.323 использует для сжатия данных протоколы G.71 и G.723.1. Протокол Q.931 применяется для установления и завершения соединения. H.323 нужен для проверки прав доступа и регистрации пользователей. H.245 — протокол регистрации допуска и статуса
Покажем на простом примере работу по установлению телефонного соединения с помощью протокола H.323. На рис. 17.12. приведены шаги для установления связи терминала с телефоном.
(рис 17.12) Пример установления и завершения соединения по протоколу H.323Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.