ПОЗНАВАТЕЛЬНОЕ

Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.

Отёска стен и прирубка косяков - Когда на доме не достаёт окон и дверей, красивое высокое крыльцо ещё только в воображении, приходится подниматься с улицы в дом по трапу.

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

Системы VoIP на базе протокола SIP 3.3.1. Архитектура сети SIP

Предыдущая 123 4 5 6 7 Следующая

Протокол инициирования сеансов протокола – Session Initiation Pro-tocol (SIP), является протоколом пятого (прикладного) уровня модели про-цессов IETF. Как и Рекомендация Н.323, протокол SIP решает те же задачи организации, поддержания и завершения сеансов связи в мультимедийных сетях, включая телефонную связь, передачу данных и распределение муль-тимедийной информации. Протокол SIP может быть использован совмест-но с протоколом Н.323 и с системами сигнализации сети ТфОП.

Сеть SIP содержит следующие основные элементы:

 агент пользователя (User Agent или SIP client),

 прокси-сервер (proxy server),

 сервер переадресации (redirect server),

 сервер определения местоположения (location server).

Агент пользователяреализуется в терминальном оборудовании и состоит из двух подсистем: клиента агента пользователя (User Agent Client – UAC) и сервера агента пользователя (User Agent Server – UAS), часто на-зываемых клиентом и сервером. Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запро-сы и отвечает на них, т.е. выступает в качестве вызываемой стороны. За-просы могут передаваться не прямо адресату, а на некоторый промежуточ-ный узел. Этот узел может быть реализован в виде двух основных типов: прокси-сервер и сервер переадресации. Прокси-серверпринимает запросы, обрабатывает их и отправляет дальше на следующий сервер, который может быть как другим прокси-сервером, так и терминалом UAS. Приняв запрос от UAC, прокси-сервер самостоятельно действует от имени этого UAC. Прокси-сервер может реа-лизовать два режима: с сохранением состояний (stateful) и без сохранения состояний (stateless). Сервер первого типа хранит в памяти входящие за-просы, которые находятся в памяти сервера только до окончания транзак-ций (сеансов). Сервер без сохранения состояний просто ретранслирует за-просы и ответы, которые получает. Он работает быстрее, чем сервер перво-го типа, так как ресурс процессора не тратится на запоминание состояний, вследствие чего сервер этого типа может обслужить большее количество пользователей. Сервер переадресации (redirect server)передает клиенту в ответе на запрос адрес следующего сервера или клиента, с которым первый клиент связывается затем непосредственно. Сервер переадресации не может ини-циировать собственные запросы и только выполняет функции поиска те-кущего адреса пользователя. Сервер определения местоположенияиспользуется для фиксации местоположения пользователя при перемещении последнего от одной око-нечной системы к другой. Сервер является базой адресов, к которой имеют доступ SIP-серверы, описанные выше. Приняв запрос, SIP-сервер обраща-ется к серверу определения местоположения, чтобы узнать адрес, по кото-рому можно найти пользователя. В ответ тот сообщает либо список воз-можных адресов, либо информирует о невозможности найти их. На рис. 3.3 представлена архитектура сети на базе протокола SIP. 13 3.3.2. Сообщения SIPСогласно архитектуре «клиент-сервер» все сообщения делятся на за- просы, передаваемые от клиента к серверу, и на ответы сервера клиенту. Чтобы инициировать установление соединения, вызывающий пользователь должен сообщить серверу адрес вызываемого пользователя, параметры ин- формационного канала и др. Эти данные передаются в специальном запро- се. От вызываемого пользователя к вызывающему передается ответ на за- прос. Вся информация, необходимая для установления соединения, поме- щается в заголовке. Заголовок содержит адреса вызываемого и вызываю- щего пользователей, пройденный сообщением путь, размер сообщения и т.д.

/ Сервер определения местоположения

Клиент SIP

Передача речи

Рисунок 3. Архитектура сети SIP

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

 ACK – подтверждение приема от вызываемой стороны на команду INVITE и завершение транзакцию;

· BYE – разъединение соединения;

 REGISTER – применяется клиентами для регистрации данных о местоположении с использованием серверов SIP.

Ответы. После приема запроса, адресат (сервер) передает ответ на этот запрос. Ответы могут включать в себя подтверждение установления соединения, передачу запрошенной информации, сведения о неисправно-стях и т.д. Определено шесть типов ответов; каждый тип ответа кодируется трехзначным числом. Первая цифра определяет вид ответа, остальные две цифры лишь дополняют первую. Все ответы делятся на две группы: информационные и финальные. Информационные ответы начинаются с единицы и показывают, что запрос находится в стадии обработки. Финальные ответы начинаются с цифр 2, 3, 4, 5 и 6: они означают завершение обработки запроса и содержат результат обработки запроса. Примеры различных ответов:

 1хх (информационный) – запрос принят, продолжается его обра-ботка;

 2хх (успех) – запрос принят, понят и успешно обработан;

 3хх (переадресация) – для завершения обработки запроса нужны дальнейшие действия;

 4хх (ошибка клиента) – запрос содержит ошибку и не может быть выполнен;

 5хх (ошибка сервера) – сервер не может выполнить явно правиль-ный запрос;

 6хх (глобальный сбой) – запрос не может быть обработан никаким сервером.

Протокол RTP

Транспортный протокол реального времени RTP (Real-time Transport Protocol), описанный в RFC 1889 и RFC 1890, поддерживает услугу сквоз-ной доставки данных, передаваемых в реальном времени, таких как инте-рактивный трафик аудио и видео. Протокол RTP обеспечивает идентифи-кацию типа полезной нагрузки, нумерацию последовательности пакетов, присвоение меток времени и контроль доставки. В протоколе предусмотрены следующие функции:

 обнаружение ошибок;

 защита информации;

 контроль времени нахождения пакета в сети;

 идентификация схемы кодирования;

 контроль доставки.

Шлюзы VoIP используют протокол RTP для доставки речевого тра-фика. В системах VoIP протокол RTP используется поверх протокола UDP 134

и относится к протоколам, не ориентированным на соединения. Несмотря на это свойство, протокол поддерживает систему упорядочения пакетов, что позволяет обнаруживать потерянные пакеты. Протокол RTP может ис- пользоваться поверх любого другого транспортного протокола, в том числе протоколов, ориентированных на установление соединений (например, протокола TCP). Протокол RTP используется вместе с протоколом управления RTCP (RTP Control Protocol), обеспечивающим управляющую информацию для протокола RTP. Протокол RTCP используется периодически для передачи пакетов управления к участникам сеанса VoIP. Основная функция протоко- ла состоит в том, чтобы информировать участников об уровне качества об- служивания, поддерживаемом протоколом RTP. Протокол RTCP собирает информацию о числе переданных и потерянных пакетов, о значениях за- держки и джиттера. Например, получив информацию о снижении показа- телей качества обслуживания, механизмы контроля QoS могут ограничить поток сообщений VoIP. После восстановления требуемых значений показа- телей QoS интенсивность потока может восстановиться. На рис. 3.4 показана общая схема организации сеанса VoIP. Пользо- ватель вызывающего ТА набирает номер вызываемого ТА, и шлюз на пере- дающей стороне с помощью сигнальных сообщений информирует сервер обработки вызовов (ОВ) о входящем вызове. Сервер ОВ анализирует при- нятый номер и, используя сигнальные сообщения, информирует шлюз на приемной стороне о поступлении вызова. Затем сервер ОВ дает команду шлюзам установить прямое соединение RTP через сеть IP. Шлюзы откры- вают сеанс RTP, когда пользователь ТА пункта назначения поднимает трубку. В зависимости от выбранной системы сигнализации в качестве сер- вера ОВ могут использоваться привратник (H.323, МСЭ-Т), контроллер шлюза (MEGACO/H.248, IETF, МСЭ-Т) или прокси-сервер (SIP, IETF RFC3261).

Сервер обработки вызовов

Рис. 4. Общая схема организации сеанса VoIP

Архитектура Н.323

Предыдущая 123 4 5 6 7 Следующая