Занятие 1. ПОСТРОЕНИЕ СЕТИ НА БАЗЕ H.323

Назад

Содержание

Вперед

Занятие 1. Построение сети на базе Н.323

Для построения сетей IP-телефонии первой стала рекомендация H.323 МСЭ-Т, которая является первой зонтичной спецификацией систем мультимедийной связи для работы в сетях с коммутацией пакетов, не обеспечивающих гарантированное качество обслуживания.

ITU-T исторически занимался проблемами телефонных сетей, поэтому и предложенная рекомендация была в большей степени ориентирована на передачу телефонного трафика по сети с коммутацией пакетов. Сети, построенные на базе протоколов H.323, ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ISDN, наложенные на сети передачи данных. В частности, процедура установления соединения в таких сетях IP-телефонии базируется на рекомендации ITU-Т Q.931 и практически идентична той же процедуре в сетях ISDN.

При этом рекомендация H.323 предусматривает применение разнообразных алгоритмов сжатия речевой информации, что позволяет использовать полосу пропускания ресурсов передачи гораздо более эффективно, чем в сетях с коммутацией каналов.

Этот вариант построения сетей IP-телефонии ориентирован на операторов местной телефонной связи (или на компании, владеющие транспортными сетями), которые хотят использовать сети с маршрутизацией пакетов IP для предоставления услуг междугородной и международной связи (рис. 1.1).

Основными устройствами сети являются: терминал, шлюз, привратник и устройство управления конференциями. Необходимо отметить, что в отличие от устройств ТфОП, устройства Н.323 не имеют жестко закрепленного места в сети. Устройства подключаются к любой точке IP-сети. Однако при этом сеть Н.323 разбивается на зоны, а каждой зоной управляет привратник.

1.1. Терминал Н.323

Терминал H.323 - это оконечное устройство сети IP-телефо-нии, обеспечивающее 2-стороннюю речевую или мультимедийную связь с другим терминалом, шлюзом или устройством управления конференциями (рис.1.2). При этом терминалом для сети Н.323 может оказаться обычный телефонный аппарат, с которого абонент позвонил на шлюз с помощью оплаченных карт, или пк с установленным мультимедийным приложением (например, NetMeeting).

Пользовательский интерфейс управления системой дает пользователю возможность создавать и принимать

вызовы, а также конфигурировать систему и контролировать ее работу.

Модуль управления поддерживает три вида сигнализации (H.225, Н.245 и RAS), обеспечивает регистрацию терминала у привратника, установление и завершение соединения, обмен информацией, необходимой для открытия разговорных каналов, предоставление дополнительных услуг и техобслуживание.

Телематические приложения обеспечивают передачу пользовательских данных, неподвижных изображений и файлов, доступ к базам данных и т.п. Стандартным протоколом для поддержки таких приложений является протокол Т.120.

Модуль H.225.0 отвечает за преобразование видеоинформации, речи, данных и сигнальной информации в вид, необходимый для передачи по сетям с маршрутизацией пакетов IP, и наоборот. Кроме того, функциями модуля являются разбиение информации на логические кадры, нумерация последовательно передаваемых кадров, выявление и коррекция ошибок.

Сетевой интерфейс обеспечивает гарантированную передачу управляющих сообщений Н.245, сигнальных сообщений Н.225.0 (Q.931) и пользовательских данных при помощи протокола TCP и негарантированную передачу речевой и видеоинформации, а также сообщений RAS при помощи протокола UDP.

Блок синхронизации вносит задержку на приемной стороне для обеспечения синхронизации источника информации с ее приемником, согласования речевых и видеоканалов или сглаживания вариации задержки информации.

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

Аудиокодеки кодируют аудиоинформацию, поступающую от микрофона (или других источников), для ее передачи по сети с маршрутизацией пакетов IP и декодируют сигналы, поступающие от сети, для последующего воспроизведения.

Естественно здесь приведена наиболее полная конфигурация терминального устройства. Понятно, что домашний телефонный аппарат не имеет видеокодеков.

1.2. Шлюз

Шлюз является соединяющим мостом между ТфОП и IP. Основной функцией шлюза является преобразование речевой (мультимедийной) информации, поступающей со стороны ТФОП с постоянной скоростью, в вид, пригодный для передачи по IP-сетям, т. е. кодирование информации, подавление пауз в разговоре, упаковку информации в пакеты RTP/UDP/IP, а также обратное преобразование. Кроме того, шлюз должен уметь поддерживать обмен сигнальными сообщениями как с коммутационным или терминальным оборудованием ТфОП, так и с привратником или оконечным устройством сети Н.323.

Таким образом, шлюз должен преобразовывать аналоговую абонентскую сигнализацию, сигнализацию по 2ВСК и сообщения систем сигнализации DSS1 и OKC7 в сигнальные сообщения Н.323.

При отсутствии в сети привратника должна быть реализована еще одна функция шлюза: преобразование номера ТфОП в транспортный адрес IP-сети.

Со стороны сетей с маршрутизацией пакетов IP так же, как и со стороны ТфОП, шлюз может участвовать в соединениях в качестве терминала или устройства управления конференциями (рис.1.3).

Шлюз может сначала участвовать в соединении в качестве терминала, а затем при помощи сигнализации Н.245 продолжить работу в качестве устройства управления конференциями. Очевидно, что в случае, когда терминалы Н.323, расположенные в одной и той же IP-сети, связываются друг с другом, шлюз в этой связи не участвует.

1.3. Привратник

В привратнике сосредоточен весь интеллект сетей IP-телефонии, базирующихся на рекомендации ITU H.323. Как уже отмечалось, сеть Н.323 имеет зонную архитектуру (рис.1.4). Привратник выполняет функции управления зоной сети IP-телефонии, в которую входят терминалы, шлюзы и блоки конференций, зарегистрированные у данного привра-

тника. Разные участки зоны сети H.323 могут быть территориально разнесены, но соединяться друг с другом через маршрутизаторы.

В число наиболее важных функций, выполняемых привратником, входят:

  • преобразование так называемого alias-адреса (имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сетей с маршрутизацией пакетов IP (IP-адрес и номер порта TCP);

  • контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS (используются сообщения ARQ/ACF/ARJ);

  • контроль, управление и резервирование пропускной способности сети;

  • маршрутизация сигнальных сообщений между терминалами, расположенными в одной зоне; привратник может организовывать сигнальный канал непосредственно между терминалами или ретранслировать сигнальные сообщения от одного терминала к другому.

Привратник также обеспечивает мобильность абонентов, т.е. способность пользователя получить доступ к услугам любого терминала в любом месте сети, и способность сети идентифицировать пользователей при их перемещении из одного места в другое.

Если вызывающий абонент знает IP-адрес терминала вызываемого абонента, то соединение между двумя устройствами может быть установлено без помощи привратника. Часть функций привратника берет на себя шлюз, например, преобразование адреса вызываемого абонента, поступающего со стороны ТфОП в формате E164, в транспортный адрес IP-сетей.

1.4. Устройство управления конференциями

Одна из дополнительных услуг IP-телефонии, возможность организации конференций. Рекомендация Н.323 предусматривает три вида конференций (рис.1.5).

Первый вид - централизованная конференция, в которой оконечные устройства соединяются в режиме “точка-точка” с устройством управления конференциями (MCU), контролирующим процесс создания и завершения конференции, а также обрабатывающим потоки пользовательской информации.

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

Третий вид - смешанная конференция, т.е. комбинация двух предыдущих видов.

Преимущество централизованной конференции - сравнительно простые требования к терминальному оборудованию, недостаток - большая стоимость устройства управления конференциями.

Для децентрализованной конференции требуется более сложное терминальное оборудование; кроме того, желательно, чтобы в сети поддерживалась передача пакетов IP в режиме многоадресной рассылки (IP multicasting). Если сеть не поддерживает этот режим, терминал может передавать информацию к каждому из остальных терминалов, участвующих в конференции, в режиме “точка-точка”, но это становится неэффективным при числе участников более четырех.

Устройство управления конференциями MCU содержит один обязательный элемент - контроллер многоточечных соединений (Multipoint controller, MC). При этом MCU может содержать один или более процессоров для обработки

информации пользователей при многоточечных соединениях (Multipoint processor, MP).информации пользователей при многоточечных соединениях (Multipoint processor, MP).

Контрольные вопросы

1. Перечислите основные функции привратника?

2. Каким требованиям должен удовлетворять терминал IP-телефонии?

3. Зачем нужен шлюз?

4. Какие виды конференций Вы знаете?

Контрольное задание

Нарисовать структуру сети на базе рекомендации Н.323, пояснить принципы работы сети, взаимодействие устройств и функции, выполняемые каждым устройством

Вариант | Аналоговые телефонные аппараты | Компьютерные терминалы | Зона | Операторы
1 |  |  |  |
2 |  |  |  |
3 |  |  |  |

Назад

Содержание

Вперед


Занятие 2. Протокол RAS

Семейство протоколов Н.323 включает: протокол взаимодействия оконечного оборудования с привратником RAS, протокол управления соединениями H.225 и протокол управления логическими каналами Н.245.

ITU-T в рекомендации Н.225.0 определил протокол взаимодействия компонентов сети Н.323 - оконечного оборудования (терминалов, шлюзов, устройств управления кон-ференциями) с привратником, который получил название RAS (Registration, Admission and Status).

Основные процедуры, выполняемые оконечным оборудованием и привратником с помощью протокола RAS:

  • обнаружение привратника;

  • регистрация оконечного оборудования у привратника;

  • контроль доступа оконечного оборудования к сетевым ресурсам;

  • определение местоположения оконечного оборудования в сети;

  • изменение полосы пропускания в процессе обслуживания вызова;

  • опрос и индикация текущего состояния оконечного оборудования;

  • оповещение привратника об освобождении полосы пропускания, ранее занимавшейся оборудованием.

Выполнение первых трех процедур, предусмотренных протоколом RAS, является начальной фазой установления соединения с использованием сигнализации H.323. Далее следуют фаза сигнализации H.225.0 (Q.931) и обмен управляющими сообщениями Н.245. Разъединение происходит в обратной последовательности: в первую очередь закрываются управляющий канал Н.245 и сигнальный канал H.225.0, после чего по каналу RAS привратник оповещается об освобождении ранее занятой оконечным оборудованием полосы пропускания.

Для переноса сообщений протокола RAS используется протокол негарантированной доставки информации UDP.

2.1. Обнаружение привратника

Прежде чем устройство станет полноправной частью сети, необходимо сделать так, чтобы все остальные устройства увидели нового участника и смогли взаимодействовать с ним. Для этого, прежде всего, необходимо зарегистрировать оборудование на привратнике зоны, в которой будет работать это устройство, чтобы устройству стал известен сетевой адрес подходящего привратника. Процесс определения этого адреса называется обнаружением привратника. Определены два способа обнаружения: ручной и автоматический.

Ручной способ заключается в том, что привратник, обслуживающий определенное устройство, определяется заранее при его конфигурации. Первая фаза установления соединения начинается сразу с запроса регистрации устройства, который передается на уже известный сетевой адрес привратника и на UDP порт 1719, а в случае взаимодействия с привратником, поддерживающим первую версию протокола H.323, - на порт 1718.

При автоматическом способе обнаружения привратника устройство передает запрос Gatekeeper Request (GRQ) в режиме многоадресной рассылки (multicasting), используя IP-адрес 224.0.1.41 (Gatekeeper UDP Discovery Multicast Address) и UDP порт 1718 (Gatekeeper UDP Discovery Port). Ответить оконечному оборудованию могут один или несколько привратников, передав на адрес, указанный в поле rasAddress запроса GRQ, сообщение Gatekeeper Confirmation (GCF) с предложением своих услуг и с указанием транспортного адреса канала RAS (рис.2.1). Если привратник не имеет возможности зарегистрировать оконечное оборудование, он отвечает на запрос сообщением Gatekeeper Reject (GRJ). Если на GRQ отвечает несколько привратников, оконечное оборудование может выбрать по своему усмотрению любой из них, после чего инициировать процесс регистрации. Если в течение

5 с ни один привратник не ответит на GRQ, оконечное оборудование может повторить запрос.

При возникновении ошибки в процессе регистрации у своего привратника, т.е. при получении отказа в регистрации или при отсутствии ответа на запрос регистрации, оконечное оборудование должно провести процедуру обнаружения привратника повторно.

2.2. Регистрация оконечного оборудования

Следующим шагом оконечного оборудования после обнаружения привратника будет присоединение к зоне сети, обслуживаемой данным привратником.

Для этого оборудование должно пройти процедуру регистрации (рис. 2.2). При этом привратнику сообщается информация: списки alias-адресов и транспортных адресов.

Оконечное оборудование передает запрос регистрации Registration Request (RRQ) на сетевой адрес привратника либо полученный при выполнении процедуры его автоматического обнаружения, либо известный априори. Стоит отметить, что запрос направляется на общеизвестный номер UDP порта 1719, который имеет соответствующее название - Gatekeeper UDP Registration and Status Port. Привратник отвечает на запрос подтверждением Regis-tration Confirmation (RCF) или отказом в регистрации Registration Reject (RRJ). Напомним, что оконечное оборудование может зарегистрироваться только у одного привратника.Если оконечное оборудование не указывает alias-ад-рес в запросе RRQ, привратник может сам назначить адрес и передать его оборудованию в сообщении RCF.Регистрация оконечного оборудования должна быть проведена до установления его первого соединения с любым другим оборудованием. Этот процесс может периодически повторяться, например, при включении питания оборудования, поэтому привратник должен уметь обрабатывать множество запросов регистрации от одного и того же оборудования.

Если привратник получает запрос RRQ, содержащий те же самые alias- и транспортный адреса оконечного оборудования, что и в предыдущем RRQ, он должен ответить подтверждением RCF.

Если привратник получает запрос RRQ с тем же, что и в предыдущем RRQ, alias-адресом, но с другим транспорт

ным адресом, он может либо подтвердить регистрацию, либо отказать в ней, учитывая внутреннюю политику зоны сети. При приеме запроса RRQ, содержащего тот же, что и предыдущий RRQ, транспортный адрес, но другой alias-адрес оборудования, привратник должен закрепить за принятым транспортным адресом тот alias-адрес, который был принят последним, и подтвердить запрос. Заметим, что привратник может проверять наличие права пользователей на проведение вышеуказанных изменений.

Оконечное оборудование может регистрироваться на ограниченный промежуток времени, указывая в параметре timeToLive сообщения RRQ длительность этого промежутка в секундах. Привратник может подтвердить регистрацию сообщением RCF с параметром timeToLive, имеющим то же или меньшее значение.

В течение указанного промежутка времени оконеч-ное оборудование может продлить регистрацию, передав сообщение RRQ с параметром keepAlive. Получив это сообщение, привратник должен перезапустить таймер. По истечении назначенного промежутка времени регистрация считается недействительной. В этом случае привратник может передать сообщение об отмене регистрации, и оконечное оборудование должно пройти повторную регистрацию.

Оконечное оборудование может отменить регистра-цию у привратника, передав сообщение Unregister Request (URQ); привратник должен ответить подтверждением Unregister Confirmation (UCF).

Такая процедура позволяет оборудованию изменить свой alias-адрес или транспорт-ный адрес. Если оборудова-ние не было зарегистрировано у привратника, последний должен ответить на требование URQ отказом Unregister Reject (URJ).

Привратник может отменить регистрацию оборудо-вания, передав сообщение Unregister Request (URQ), при получении которого оконечное оборудование должно ответить подтверждением Unregister Confirmation (UCF). Теперь, чтобы получить возможность участия в любом соединении, оконечное оборудование должно перерегистрироваться у то-го же привратника или зарегистрироваться у нового.

Оборудование, не зарегистрированное у привратника, не может требовать от него допуск к участию в любых соединениях. Привратник не выполняет для этого оборудования такие функции, как управление полосой пропускания, преобразование адресов и другие предусмотренные рекомендацией H.323 функции.

Кроме того, привратник может запретить оконечному оборудованию своей зоны принимать вызовы от оборудования, которое у него не зарегистрировано.

2.3. Доступ оконечного оборудования

к сетевым ресурсам

Чтобы оборудование могло работать в сети, ему необходим доступ к ее ресурсам, поэтому в начальной фазе установления соединения, а также после получения сообщения Setup, оборудование обращается к привратнику при помощи запроса Admissions Request (ARQ) с просьбой разрешить соединение с другим оборудованием (рис.2.3).

Это является началом процедуры доступа к сетевым ресурсам, причем процедура доступа выполняется всеми участниками соединения.

В сообщении ARQ содержится идентификатор оборудования, передавшего сообщение ARQ, и контактная информация того оборудования, с которым оно желает связаться. Контактная информация оборудования включает в себя alias-адрес и/или транспортный адрес сигнального канала, но, как правило, в запрос ARQ помещается только alias-адрес вызываемого оборудования.

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

Привратник может выделить требуемую полосу пропускания или снизить предел суммарной скорости, передав сообщение Admissions Confirm (ACF) (рис.2.3). В этом же сообщении, кроме суммарной скорости, указывается транспортный адрес сигнального канала встречного оборудования, если сигнальный канал будет связывать оборудование непосредственно, или адрес привратника, если он будет маршрутизировать сигнальные сообщения.

Если процедура доступа инициируется вызывающим оборудованием, то после получения ответа ACF на указанный в этом сообщении адрес передается сообщение Setup и делается попытка установить сигнальное соединение Н.225.0. Следует отметить, что инициирование процедуры доступа вызываемым оборудованием к сетевым ресурсам начинается после организации сигнального канала и получения по нему сообщения Setup. Если требуемая полоса недоступна, привратник передает сообщение Admissions Reject (ARJ).

2.4. Определение местоположения оборудования в сети

Если оконечное оборудование или привратник желают узнать контактную информацию (адреса сигнального канала и канала RAS), то при наличии alias-адрес этого оборудования, посылается запрос Location Request (LRQ). Привратник, у которого зарегистрировано указанное оборудование, должен ответить сообщением Location Confirmation (LCF), содержащим требуемую контактную информацию. Эта процедура называется определением местоположения оконечного оборудования в сети (рис.2.4).

Привратник, получивший на транспортный адрес своего канала RAS запрос LRQ, должен ответить отказом Location Reject (LRJ), если искомое оборудование у него не зарегистрировано. Привратники, у которых искомое оборудование не зарегистрировано, а сообщение LRQ получено в режиме многоадресной рассылки Gatekeeper` s Discovery Multicast, вообще не должны отвечать на запрос.

Вышеописанная процедура используется, в частнос-ти, тогда, когда в сети имеется несколько зон, а вызов вы-ходит за пределы одной зоны. Привратник, у которого за-регистрировано вызывающее оборудование, передает зап-рос адреса сигнального канала вызываемого оборудования.

2. 5. Опрос текущего состояния оборудования

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

Запрос информации о текущем состоянии (статусе) оборудования производится привратником при помощи со-общения Information Request (IRQ). Выбор интервала между посылками IRQ - на усмотрение производителя, но он должен быть не меньше 10 с. Получив запрос IRQ, оконечное оборудование должно передать запрашиваемую информацию в сообщении Information Request Response (IRR).

2. 6. Освобождение полосы пропускания

В конечной фазе разрушения соединения оборудование извещает привратник об освобождении раннее занимавшейся полосы пропускания (рис.2.6). Оконечное оборудование передает своему привратнику сообщение Disengage

Request (DRQ), на что тот должен ответить подтверждением Disengage Confirm (DCF).

Привратник может сам инициировать освобождение сетевых ресурсов, т.е. разрушение существующего соединения, передав сообщение DRQ. Получив сообщение DRQ, оконечное оборудование должно закрыть логические каналы, управляющий и сигнальный каналы, а затем ответить подтверждением DCF. В случае если привратник инициирует завершение конференции, сообщение DRQ должно передаваться каждому ее участнику.

Контрольные вопросы

1. Перечислить основные функции протокола RAS?

2. Для чего нужно сообщение ARQ?

3. В каком случае пользователь получит сообщение ARJ?

Контрольное задание

Нарисовать полный сценарий взаимодействия двух устройств IP-телефонии с использованием команд и сообщений RAS:

  1. шлюз - шлюз,

  2. шлюз - привратник,

  3. терминал - привратник.


Занятие 3. СИГНАЛЬНЫЙ КАНАЛ H.225

Занятие 3. Сигнальный канал Н.225

Процедуры управления соединениями в сетях H.323 специфицированы ITU-Т в рекомендации Н.225, которые предусматривают использование в базовом процессе обслуживания вызова сигнальных сообщений Q.931.

Сообщение Setup передается вызывающим оборудованием с целью установить соединение. Это сообщение передается на общеизвестный TCP порт 1720 вызываемого оборудования.

Сообщение Call Proceeding передается к вызывающему оборудованию и информирует его о том, что вызов принят к обслуживанию.

Сообщение Alerting передается к вызывающему оборудованию и информирует его о том, что вызываемое оборудование свободно и вызываемому пользователю подается сигнал о входящем вызове.

Сообщение Connect передается к вызывающему оборудованию и информирует его о том, что вызываемый пользователь принял входящий вызов. Сообщение Connect может содержать транспортный адрес управляющего канала H.245.

Сообщение Release Complete передается вызывающим или вызываемым оборудованием с целью разрушить соединение. Это сообщение передается только в том случае, если открыт сигнальный канал.

Сообщение Q.932 Facility используется для обращения к дополнительным услугам в соответствии с рекомендациями ITU-T H.450.х.

Транспортировку сигнальных сообщений осуществляет протокол Transport Control Protocol (TCP) с установлением соединения и гарантированной доставкой информации.

В сетях, не имеющих привратника, открывается сигнальный канал Н.225.0, непосредственно соединяющий вызывающее оконечное оборудование с вызываемым.

В этом случае вызывающий пользователь должен знать транспортный адрес сигнального канала (Call Signal-ling Transport Address) оборудования вызываемого пользо-вателя.

В сетях с привратником вызывающее оборудование передает по транспортному адресу канала RAS привратника сообщение ARQ с указанием alias-адреса вызываемого пользователя.

Если сигнальные сообщения будет маршрутизировать привратник (Gatekeeper Routed Call Signalling), то в ответном сообщении он передает транспортный адрес своего сигнального канала.

Если же сигнальный канал будет организован непосредственно между вызывающим и вызываемым оборудованием (Direct Endpoint Call Signalling), то в ответном сообщении передается транспортный адрес сигнального канала вызываемого оборудования. Выбор варианта передачи сигнальных сообщений оставлен за привратником, хотя оконечное оборудование может указывать, какой вариант для него предпочтителен. И в первом, и во втором случаях сигнальный канал Н.225 выполняет одни и те же функции, переносит одни и те же сообщения.

При маршрутизации сигнальных сообщений привратником сигнальный канал может закрываться сразу после установления соединения или оставаться открытым в течение всего соединения для предоставления дополнительных услуг.

Закрыть сигнальный канал может только привратник, но если в соединении участвует шлюз, то сигнальный канал должен оставаться открытым до окончания соединения. При закрытии сигнального канала оконечным оборудованием должно сохраняться текущее состояние соединения. Привратник может в любой момент соединения снова открыть сигнальный канал.

После обмена с привратником сообщениями ARQ и ACF по каналу RAS вызывающее оборудование передает запрос соединения Setup либо по транспортному адресу сигнального канала привратника (если сигнальные сообщения будет маршрутизировать привратник), либо по транспортному адресу сигнального канала вызываемого оборудования (если сигнальный канал будет связывать вызывающее и вызываемое оборудование непосредственно). В ответ на сообщение Setup вызываемое оборудование может передать сообщение Call Proceeding, означающее, что вся информация, необходимая для установления соединения, получена, и вызов принят к обслуживанию.

Далее от вызываемого оборудования может поступить сообщение Alerting, означающее, что вызываемому пользователю подается вызывной сигнал. После того как пользователь принимает вызов, вызываемому оборудованию передается сообщение Connect с транспортным адресом управляющего канала H.245 вызываемого оборудования, если управляющий канал устанавливается напрямую между вызывающим и вызываемым оборудованием, или транспортный адрес канала H.245 привратника, если управляющие сообщения маршрутизирует привратник. В некоторых случаях, например, для проключения разговорных каналов в предответном состоянии, транспортный адрес управляющего канала H.245 вводится в сообщения Call Proceeding или Alerting.

Контрольные вопросы

1. Перечислите основные сообщения Н.225?

2. Когда посылается сообщение Setup?

3. Что означает Alerting с точки зрения абонента?

Контрольное задание

Нарисовать полный сценарий установления соединения с использованием команд и сообщений Н.225.0:

  1. с привратником,

  2. без привратника.


Занятие 4. Управляющий канал H.245

В рекомендации ITU-T H.245 определен ряд независимых процедур, которые должны выполняться для управления информационными каналами:

  • определение ведущего и ведомого устройств (Mas-er/slave determination);
  • обмен данными о функциональных возможностях (Capability Exchange);

  • открытие и закрытие однонаправленных логических каналов (Open/Close Logical Channel Signalling);

  • открытие и закрытие двунаправленных логических каналов (Open/Close Bidirectional Logical Channel Signalling);
  • определение задержки, возникающей при передаче информации от источника к приемнику и в обратном направлении (Round Trip Delay Determination);
  • выбор режима обработки информации (Mode Re-quest);

  • сигнализация по петле, создаваемой для целей технического обслуживания оборудования (Maintenance Loop Signalling).

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

Примечательно, что терминалы, устройства управления конференциями, шлюзы и привратники могут участвовать одновременно в нескольких соединениях и, следовательно, открывать несколько управляющих каналов.

Перенос управляющей информации Н.245 осуществляется протоколом TCP по нулевому логическому каналу, который должен быть постоянно открытым с момента организации канала Н.245 и вплоть до его ликвидации.

По управляющему каналу Н.245 передаются сообщения четырех категорий: запросы, ответы, команды и индикации. Получив сообщение-запрос, оборудование должно выполнить определенное действие и немедленно передать обратно сообщение-ответ. Получив сообщение-команду, оборудование также должно выполнить определенное действие, но отвечать на команду не должно. Сообщение-индикация служит, для того чтобы информировать о чем-либо получателя, но не требует от него ни ответа, ни каких бы то ни было действий.

4.1. Определение ведущего и ведомого оборудования

Процедура определения ведущего и ведомого оборудования используется для разрешения конфликтов, возникающих между двумя устройствами при организации конференции, когда ведущим в ней может быть любое из этих устройств, или между двумя устройствами, которые одновременно пытаются открыть двунаправленный логический канал. Устройства обмениваются сообщениями master-SlaveDetermination (рис. 4.1), в поле terminalType которых помещается значение, соответствующее типу данного оборудования, а в поле statusDetermination-Number - случайное число из интервала 0, … , (224 - 1). Ведущим становится оборудование, поместившее большее число в поле terminalType, а при совпадении типов обору-дования - большее число в поле statusDetermination-Number. В ответ на полученные сообщения masterSlave-Determination оба устройства передают сообщения MasterSlave-DeterminationAck, в которых указывается, какое оборудование является для данного соединения ведущим, а какое - ведомым. При этом любое оборудование стандарта Н.323 должно работать и в качестве ведущего, и в качестве ведомого.

4. 2. Обмен данными

о функциональных возможностях оборудования

Оборудование стандарта H.323 в общем случае способно принимать и передавать речь, видеоинформацию и данные. Это означает, что оборудование обычно содержит приемник и передатчик информации. Как правило, устройства поддерживают несколько алгоритмов кодирования и декодирования информации каждого вида.

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

Терминалы обмениваются сообщениями Terminal-CapabilitySet, в которых каждый из них указывает алгоритмы, используемые им для декодирования принимаемой и кодирования передаваемой информации, т. е. режимы, в которых терминал способен функционировать.

В сообщение TerminalCapabilitySet включается поле capabilityTable - таблица функциональных возможностей, где каждому алгоритму кодирования/декодирования присвоен порядковый номер. Указанные порядковые номера объединяются в список альтернативных режимов alterna-tiveCapabilitySet. Оборудование может использовать любой (но только один) из режимов, указанных в списке. В свою очередь, альтернативные режимы объединяются в наборы одновременно возможных режимов функционирования simultaneous-Capabilities.

Функциональные возможности терминала описываются набором дескрипторов (capabilityDescriptor), каждый из которых состоит из одного набора одновременно возможных режимов функционирования оборудования и номера дескриптора (capabilityDescriptorNumber).

Если при обмене данными о функциональных возможностях оборудование указывает более одного дескриптора, то это означает, что оно поддерживает несколько режимов функционирования. Оборудование может в любое время передать сообщение TerminalCapabilitySet с дескриптором, добавляющим новые функциональные возможности, или с дескриптором, исключающим некоторые из ранее указанных возможностей.

Оборудование, которое получило от другого оборудования сообщение TerminalCapabilitySet, может подтвердить его получение передачей сообщения TerminalCapa-bilitySetAck.

Приняв сообщение с некорректным набором возможностей, оборудование отвечает сообщением Terminal-CapabilitySetReject. При срабатывании таймера, запущенного после отправки сообщения TerminalCapabilitySet, обо-рудование, его пославшее, передает сообщение Terminal-CapabilitySetRelease.

4. 3. Открытие и закрытие логических каналов

Информация, передаваемая источником к одному или более приемникам, в сетях на базе H.323 переносится по логическим каналам, которые идентифицируются уникальным для каждого направления передачи номером канала. Рекомендацией Н.245 предусмотрена возможность создания логических каналов двух видов: однонаправленных (unidirec-tional), т.е. открывающихся в направлении от источника к приемнику информации, и двунаправленных (bidirectional), открывающихся сразу в двух направлениях - от источника к приемнику информации и в обратном направлении. Одно-направленные логические каналы открываются при помощи процедуры Unidirectional Logical Signal-ling (рис. 4.3).

В требовании открыть логический канал open-LogicalChannel оборудование указывает вид информации, которая будет передаваться по этому каналу, и алгоритм кодирования информации. Если оборудование открывает однонаправленный логический канал то, чтобы организо-вать дуплексную связь, встречное оборудование также должно открыть однонаправленный канал в обратном на-правлении, используя для этого вышеописанную процедуру

Unidirectional Logical Signalling. В некоторых случаях оборудование, инициирующее такой обмен, должно откры-вать сразу и прямой, и обратный каналы. Делается это с помощью процедуры Bidirectional Logical Signalling, которая

практически идентична вышеописанной процедуре Unidi-rectional Logical Signalling, и также предусматривает обмен сообщениями openLogicalChannel и openLogicalChannel-Ack. Добавляется еще одно сообщение openLogicalChan-nelConfirm, которое передается в ответ на сообщение open-LogicalChannelAck и подтверждает, что двунаправлен-ный логический канал открыт (рис. 4.4).

Закрытие логических каналов может производиться с помощью процедуры CloseLogicalChannel, но она используется, в основном, для поддержки предоставления дополнительных услуг, в первую очередь, услуги перевода соединения в режим удержания. Для нормального разрушения соединения стороны обмениваются сообщениями endSession-Command. После обмена этими сообщениями закрываются не только логические каналы, но и управляющий канал H.245.

Контрольные вопросы

1. Как определяется ведущее и ведомое оборудование?

2. В чем разница между однонаправленными и двунаправленными логическими каналами?

3. Что содержит сообщение TerminalCapabilitySet?

Контрольное задание

Нарисовать полный сценарий взаимодействия двух устройств IP-телефонии с использованием команд и сообщений Н.245.


Занятие 5. ПОСТРОЕНИЕ СЕТЕЙ IP-ТЕЛЕФОНИИ НА БАЗЕ ПРОТОКОЛА SIP

Занятие 5. ПОСТРОЕНИЕ СЕТЕЙ IP-ТЕЛЕФОНИИ

НА БАЗЕ ПРОТОКОЛА SIP

5.1. Функциональные возможности протокола

Вторым вариантом построения сетей стал протокол SIP, разработанный группой MMUSIC (Multiparty Multime-dia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543

Протокол инициирования сеансов - Session Initiation Protocol (SIP)- является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и распределения мультимедийной информации, в основу которого заложены следующие принципы.

Персональная мобильность пользователей. Пользователи могут перемещаться без ограничений в пределах сети, поэтому услуги связи должны предоставляться им в любом месте этой сети. Пользователю присваивается уникальный идентификатор, а сеть предоставляет ему услуги связи вне зависимости от того, где он находится.

Для этого пользователь с помощью специального сообщения - REGISTER - информирует о своих перемещениях сервер определения местоположения.

Масштабируемость сети характеризуется, в первую очередь, возможностью увеличения количества элементов сети при ее расширении. Серверная структура сети, построенной на базе протокола SIP, в полной мере отвечает этому требованию.

Расширяемость протокола характеризуется возможностью дополнения протокола новыми функциями при введении новых услуг и его адаптации к работе с различными приложениями.

Интеграция в стек существующих протоколов Интернет. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF).

Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323. Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП - DSS1 и ОКС7.

Одной из важнейших особенностей протокола SIP является его независимость от транспортных технологий. В качестве транспорта могут использоваться протоколы Х.25, Frame Relay, AAL5, IPX и др. Структура сообщений SIP не зависит от выбранной транспортной технологии. Но в то же время предпочтение отдается технологии маршрутизации пакетов IP и протоколу UDP.

Здесь же следует отметить, что сигнальные сообщения могут переноситься не только протоколом транспортного уровня UDP, но и протоколом ТСР (рис. 5.1) По сети с маршрутизацией пакетов IP может передаваться пользовательская информация практически любого вида: речь, видео и данные, а также любая их комбинация, называемая мультимедийной информацией. При организации связи между терминалами пользователей необходимо известить встречную сторону, какого рода информация может приниматься (передаваться), алгоритм ее кодирования и адрес, на который ее следует передавать. Таким образом, одним из обязательных условий организации связи при помощи протокола SIP является обмен между предполагаемыми участниками этой связи данными об их функциональных возможностях. Для этой цели чаще всего используется протокол описания сеансов связи SDP (Session Description Protocol). В течение сеанса связи может производиться его модификация, поэтому предусмотрена передача средствами SDP сообщений SIP с новыми описаниями сеанса.

Для передачи речевой информации комитет IETF предлагает использовать протокол RTP, но сам протокол SIP не исключает возможность применения для этих целей других протоколов.

5.2. Адресация

Для того чтобы вызвать кого-то, необходимо знать его адрес или хотя бы имя. В сети Интернет для нахождения хоста используется URL (для SIP он обозначается как SIP URL). В качестве адреса в SIP выбран самый распространенный тип - адрес электронной почты. Он уже сейчас является основным адресом, не зависящим от местоположения пользователя. Существуют четыре основные формы адреса: имя@домен, имя@хост, имя@IP-адрес, №телефона-@шлюз.

Адрес состоит из двух частей. Первая - это та часть, в которой указывается адрес домена, хоста или шлюза. Она может быть представлена и alias-адресом; тогда, чтобы найти IP-адрес, необходимо обратиться к сервису системы DNS. Если же здесь помещен IP-адрес, то никакого преобразования не надо, так как в этом случае достаточно напрямую связаться с адресатом.

Вторая часть адреса - это имя пользователя в домене или хосте. Если в первой части указан адрес шлюза, то вторая часть представлена телефонным номером абонента в глобальной или частной системе нумерации.

В начале адреса ставятся слово sip, указывающее, что это именно SIP-адрес, так как бывают другие (например, mailto).

SIP-адрес может соответствовать разным физическим адресам в зависимости от времени суток, алгоритма работы и т.п. Он может направлять вызов к одному определенному пользователю, первому свободному из группы пользователей или ко всей группе. Благодаря этому можно организовать такие услуги, как ночной вызов, переадресация, конференция и др.

Возможно использование адреса электронной почты в качестве публикуемого SIP-адреса. Применение URL позволяет, например, размещать свой адрес на Web-страницах:

sip: user1@rts.loniis.ru

sip: user1@ 195.201.37.104

sip: 273-44-55@gateway.ru

5.3. Элементы SIP-сети

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

Агент пользователя (User Agent или SIP client) является приложением терминального оборудования и включает в себя две составляющие: клиент агента пользователя (User Agent Client - UAC) и сервер агента пользователя (User Agent Server - UAS), иначе называемые клиент и сервер. Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и отвечает на них, т.е. выступает в качестве вызываемой стороны.

Запросы могут передаваться не прямо адресату, а на некоторый промежуточный узел. Такие узлы бывают двух основных типов: прокси-сервер и сервер переадресации

Прокси-сервер (proxy server) принимает запросы, обрабатывает их и отправляет дальше на следующий сервер, который может быть как другим прокси-сервером, так и последним UAS. Таким образом, прокси-сервер принимает и отправляет запросы и клиента, и сервера. Приняв запрос

от UAC, прокси-сервер действует от имени этого UAC.

Существует два вида прокси-серверов: с сохранением состояний (stateful) и без сохранения состояний (stateless). Сервер первого типа хранит в памяти входящий запрос, который явился причиной генерации одного или нескольких исходящих запросов. Эти исходящие запросы сервер также запоминает. Все запросы хранятся в памяти сервера только до окончания транзакции, т.е. до получения ответов на за просы. Сервер без сохранения состояний просто ретранслирует запросы и ответы, которые получает. Он работает быстрее, чем сервер 1-го типа, так как ресурс процессора не тратится на запоминание состояний, вследствие чего сервер этого типа может обслужить большее количество пользователей.

Протокол инициирования сеансов связи ( SIP ) | Прикладной уровень
Протоколы TCP и UDP | Транспортный уровень
Протоколы IPv4 и IPv6 | Сетевой уровень
PPP, AAL5. ATM, Ethernet, V.34. | Уровень звена данных
UTP5, ВОЛС и др. | Физический уровень

Рис. 5.1. Место протокола SIP в стеке протоколов TCP/IP

Прокси-сервер может модифицировать запросы, которые он переправляет дальше. Проще говоря, пользователь отсылает требование установить соединение на прокси-сер-вер, а тот сам “заботится” о том, чтобы оно было установлено. Прокси-сервер может размножать запрос и передавать его по разным направлениям, чтобы запрос достиг нескольких мест, в надежде на то, что нужный пользователь окажется в одном из них.

Сервер переадресации (redirect server) передает клиенту в ответе на запрос адрес следующего сервера или клиента, с которым первый клиент связывается затем непосредственно. Он не может инициировать собственные запросы. Адрес сообщается первому клиенту в поле Contact сообщений SIP. Таким образом, этот сервер просто выполняет функции поиска текущего адреса пользователя.

Пользователь может перемещаться от одной оконечной системы к другой, так что нужен какой-то метод определения его местоположения (рис. 5.2). Для этого в SIP используется сервер местоположения (location server) - это база адресов, доступ к которой имеют SIP-серверы, пользующиеся ее услугами для получения информации о возможном местоположении вызываемого пользователя. Принципы работы сервера местоположения не регламентированы документом RFC 2543, но там имеются примеры протоколов, которые могут использоваться для этого LDAP (RFC 1777), rwnois (RFC 2167) и др. Упрощенно базу данных можно представить как совокупность адресных записей, в которых напротив “публикуемого” адреса пользователя его стоит текущий адрес. Приняв запрос, сервер SIP обращается к серверу местоположения, чтобы узнать адрес, по которому можно найти пользователя. В ответ тот сообщает либо список возможных адресов, либо информирует о невозможности найти их. С другой стороны, пользователь информирует SIP-сервер о своем местоположении сообщением REGISTER. Сервер местоположения может располагаться как совместно с SIP-сервером (рис. 5.2), где могут присутствовать некоторые элементы базы адресов, так и отдельно от него.

Контрольные вопросы

1. Зачем нужен протокол SIP?

2. Основные принципы, положенные в основу протокола SIP, кто его стандартизировал?

3. Какое место занимает протокол SIP в стеке протоколов TCP/IP.

4. С помощью какого протокола терминалы обмениваются информацией о своих функциональных возможностях?

5. Перечислить основные элементы SIP-сети.

6. Какой тип адресации используется в протоколе SIP.

7. Перечислить типы SIP-адресов, что значат их элементы?

Контрольное задание

1. Элементы SIP-сети, их функции.

2. Агент пользователя и его элементы.

3. Прокси-сервер: типы и функции.

4. Сервер переадресации, его функции.

5. Сервер определения местоположения, его функции.

6. Описать процесс установления соединения между терминалами на примере SIP-сети


Занятие 6. СООБЩЕНИЕ SIP

Занятие 6. Сообщения SIP

6.1. Структура сообщений

Согласно архитектуре “клиент-сервер” все сообщения делятся на запросы, передаваемые от клиента к серверу, и на ответы сервера клиенту.

Например, чтобы инициировать установление соединения, вызывающий пользователь должен сообщить серверу ряд параметров, в частности, адрес вызываемого пользователя, параметры информационных каналов и др. Эти параметры передаются в специальном SIP-запросе. От вызываемого пользователя к вызывающему передается ответ на запрос, также содержащий ряд параметров.

Все сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP (рис. 6.1) соответствуют используемым в протоколе НТТР.

Стартовая строка представляет собой начальную строку любого SIP-сообщения. Если сообщение является запросом, в этой строке указываются тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в стартовой строке указываются номер версии протокола, тип ответа и его короткая расшифровка, предназначенная только для обслуживающего персонала и необрабатываемая клиентом.

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

Сообщения протокола SIP могут содержать так называемое тело сообщения. В сообщениях ACK, INVITE и OPTIONS тело сообщения содержит описание сеансов связи, например, в формате протокола SDP. Сообщение BYE тела сообщения не содержит, а ситуация с сообщением REGISTER подлежит дальнейшему изучению. С ответами дело обстоит иначе: любой ответ может содержать тело сообщения, но содержимое тела в ответах разных типов бывает разным. Вся информация, необходимая для установления соединения, помещается в заголовке. Это может быть, например, адрес вызываемого и вызывающего пользователей, пройденный сообщением путь или размер тела сообщения. О заголовке и содержащейся в нем информации можно узнать по имени, которое всегда начинается с прописной буквы, далее следуют строчные. Некоторые заголовки используются во всех сообщениях, а некоторые - только в определенных случаях.

Существуют заголовки четырех видов:

  • общие (и в запросах, и ответах);

  • содержания (начинаются со слова Content и несут информацию о размере тела сообщения или об источнике, передавшем сообщение);

  • запросов (дополнительная информация о запросе);

  • ответов (дополнительная информация об ответе).

Заголовок содержит имя, за которым после двоеточия (:) следует поле, содержащее данные заголовка,

т.е. имя:со-держимое.

Примеры наиболее часто встречающихся заголовков.

Call-ID - уникальный идентификатор отдельного сеанса связи или регистрации отдельного клиента; он подобен метке соединения (call reference) в DSS-1. Назначается стороной, которая инициирует вызов. Содержит буквенно-числовое значение и имя хоста, разделенное символом @:

2345call@rts.loniis.ru

To - определяет получателя запроса; кроме SIP-адреса, здесь может присутствовать параметр tag для идентификации пользователя или услуги, находящихся в одном SIP URL. Если необходим визуальный вывод имени пользователя, например, на дисплей, его также можно поместить в поле То:

the director <userA@loniis.ru> tag=12345.

From - определяет отправителя запроса (по организации аналогичен полю То).

CSeq - уникальный идентификатор запроса внутри одного Call-ID; необходим, чтобы отличить, на какой запрос прошел ответ, так как иногда он может оказаться ответом на другой запрос; состоит из двух частей: натурального числа (от 1 до 232) и типа запроса.

Заголовок Via служит, для того чтобы избежать ситуации, в которых запрос пойдет по замкнутому пути, а также для тех случаев, когда необходимо, чтобы запросы и ответы обязательно проходили по одному и тому же пути (например, в случае использования межсетевого экрана - firewall). Запрос может проходить через несколько прокси-серверов, каждый из которых принимает, обрабатывает и переправляет его к следующему прокси-серверу и так до тех пор, пока запрос не попадет к адресату. Таким образом, в заголовке Via указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет в запрос поле со своим адресом. Например, запрос на своем пути обрабатывался двумя прокси-серверами: сначала сервером loniis.ru, потом sip.tele-com.com. Тогда в запросе появятся следующие поля:

Via: SIP/2.0/UDP sip.telecom.com:5060

Via: SIP/2.0/UDP loniis.ru:5060

Content-Type - определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP, включается в тело сообщения.

Content-Length - показывает размер тела сообщения.

6.2. Запросы

В настоящей версии протокола SIP определено 6 типов запросов. Каждый из них предназначен для выполнения довольно широкого круга задач, что является явным достоинством протокола SIP, так как благодаря этому число сообщений, которыми обмениваются терминалы и серверы, сведено к минимуму. С помощью запросов клиент сообщает

о текущем местоположении, приглашает пользователей

Стартовая строка

Заголовки

Пустая строка

Тело сообщения

Рис. 6.1. Структура сообщений протокола SIP

INVITE sip: watson@boston.bell-tel.com SIP/2.0

    Via: SIP/2.0/UDP kton.bell-tel.com

    From: A.Bell <sip: a.g.bell@bell-tel.com>

    To: T.Watson <sip: watson@bell-tel.com>

    Сall-ID: 3298420296@kton.bell-tel.com

    Cseq: 1 INVITE

    Content-Type: application/sdp

    Content-Length: ...

    v =0

    0 =bell 53655765 2353687637 IN IP4 128.3.4.5

    SIP =IN IP4 kton.bell-tel.com

    m =audio 3456 RTP/ AVP 0 3 4 5

Рис. 6.2. Пример SIP-запросов

принять участие всеансах связи, модифицирует уже установленные сеансы, завершает их и т.д. Сервер определяет тип принятого запроса по названию, указанному в стартовой строке. В той же строке в поле Request-URI указан SIP-адрес вызываемого пользователя. Описание запросов приведено ниже.

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

В ответе на запрос INVITE указывается вид информации, которая будет приниматься или передаваться

(рис. 6.2). Этот запрос приглашает watson@bell-tel.com для участия в сеансе связи с a.g.bell@bell-tel.com. В теле сообщения отправитель указывает, что он может принимать на порт 3456 аудиоинформацию, кодированную 0 (PCMU), 3 (GSM), 4 (G.723) и 5 (DV14). Запрос направляется на прокси-сервер boston.bell-tel.com. В полях То и From перед ско-бками с адресом < > помещена надпись, которую пользователь желает вывести на дисплей вызываемого пользователя.

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

OPTIONS - позволяет получить информацию о функциональных возможностях пользовательских агентов и сетевых серверов, но этот запрос не используется для организации сеансов связи.

BYE - используется вызывавшей и вызванной сторонами для разрушения соединения. Перед тем как разрушить соединение, пользовательские агенты отправляют этот запрос к серверу, сообщая о намерении прекратить сеанс связи.

CANCEL - позволяет пользовательским агентам и сетевым серверам отменить любой ранее переданный запрос, если финальный ответ на него (т.е. ответ с номерами 2хх, 3хх, 4хх, 5хх, 6хх) еще не получен.

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

6.3. Ответы

После приема и интерпретации запроса, адресат (прокси-сервер) передает ответ на этот запрос. Содержание ответов: подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях и т.д.

Структуры ответов и их типы протокол SIP унаследовал от протокола НТТР. Определено 6 типов ответов, несущих разную функциональную нагрузку. Тип ответа кодируется 3-значным числом. Самой важной является первая цифра, которая определяет класс ответа, остальные две цифры лишь дополняют первую. В некоторых случаях оборудование может не знать все коды ответов, но оно обязательно должно знать, как интерпретировать первую цифру. Все ответы делятся на 2 группы: информационные и финальные.

Информационные ответы показывают, что запрос находится в стадии обработки.

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

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

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

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

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:a.g.bell@bell-tel.com>

To: <sip:wstson@bell-tel.com>;

Сall-ID:3298420296@kton.bell-tel.com

Сseq: 1 INVITE

Content-Type: application/sdp

Content-Length: ...

v =0

0 =watson 4858949 4858949 IN IP4 192.1.2.3

t =3149329600 0

SIP =IN IP4 boston.bell-tel.com

m =audio 5004 RTP/AVP 0 3

a =rtpmap:0 PCMU/8000

a =rtpmap: 3 GSM/8000

Рис. 6.3. Пример SIP-ответов

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

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

В ответе пользователя Watson на запрос Bell сообщается, что он может принимать аудиоинформацию на порт 5004, понимать кодеки PCMU, GSM. Поля From, To, Via, Call-ID взяты из запроса. Поле Cseq показывает, что - это ответ на INVITE с Cseq: 1.

Контрольные вопросы

  1. Описать принцип “клиент-сервер”.

  2. Сообщения протокола SIP, их формат и структура.

  3. Существующие виды сообщений.

  4. Назначение запросов и ответов протокола SIP.

  5. Пояснить назначение основных заголовков сообщений.

Контрольное задание

Для каждого варианта составить запрос и ответ применительно к сеансу связи между вызывающим и вызываемым пользователями (табл. 6.1). Заголовки, которые нельзя составить по табл. 6.1, и тело сообщения взять из рис. 6.2 и 6.3


Занятие 7. ПРОЦЕСС УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ

Сеть SIP содержит пользователей (правильно сказать UAS), прокси-серверы и серверы переадресации. Перед началом сеанса связи вызывающий пользователь должен знать либо адрес вызываемого пользователя, либо адрес SIP-сервера. Адрес может быть в виде: user@domain, тогда необходимо преобразовать его в IP-адрес с помощью услуг DNS. Адреса серверов пользователю сообщает поставщик услуги. Для доступа к серверу может потребоваться аутентификация, обеспечивающая обслуживание только определенной группы пользователей, например, тех, кто заплатил за услуги. Если прямого адреса пользователя нет, он обращается к прокси-серверу или к серверу переадресации. Далее алгоритм работы сети зависит от того, к какому серверу он обратился.

7.1. Установления соединения

через сервер переадресации

Вызывающему пользователю требуется вызвать другого пользователя. Он передает запрос INVITE 1 на известный ему адрес сервера переадресации и на порт 5060, используемый по умолчанию (рис. 7.1). В запросе вызывающий пользователь указывает адрес вызываемого пользователя. Сервер переадресации запрашивает текущий адрес нужного пользователя у сервера местоположения 2, теперь вызывающая сторона может связаться с вызываемой стороной. Для этого она передает новый запрос INVITE 6. В теле сообщения INVITE указываются данные о функциональных возможностях вызывающей стороны в формате протокола SDP. Вызываемая сторона принимает запрос INVITE и начинает его обработку, о чем сообщает ответом 100 Trying 7 встречному оборудованию для перезапуска его таймеров.

После завершения обработки поступившего запроса оборудование вызываемой стороны сообщает своему пользователю о входящем вызове, а встречной стороне передает ответ 180 Ringing 8.

После приема вызываемым пользователем входящего вызова встречной стороне передается сообщение 200 ОК 9, в котором содержатся данные о функциональных возможностях вызываемого терминала в формате протокола SDP.

Терминал вызывающего пользователя подтверждает прием ответа запросом АСК 10. На этом фаза установления соединения заканчивается, и начинается разговорная.

По завершении разговорной фазы любая из сторон передает запрос BYE 11, который подтверждается ответом 200 ОК 12.

7.2. Установления соединения

через прокси-сервер (рис.7.2)

В этом случае действия 1, 2, 3 такие же, как и при использовании сервера переадресации. После выяснения адреса (на сервере определения местоположения) прокси-сервер передает по этому адресу запрос INVITE 4. Вызываемый пользователь В оповещается акустическим или визуальным сигналом о том, что его вызывают 5; он поднимает трубку, и ответ 200 ОК отправляется к прокси-серверу 6. Прокси-сервер переправляет этот ответ вызвавшему пользователю А 7, последний подтверждает правильность приема, передавая запрос АСК 8, который переправляется к вызванному пользователю В 9. Соединение установлено, идет разговор. Вызванный пользователь В кладет трубку, передается запрос BYE 10, прием которого подтверждается ответом 200 ОК 11.

Контрольные вопросы

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

Контрольное задание

Составить сценарий установления успешного соединения между терминалами пользователей А и В по данным табл. 7.1.

Таблица 7.1

Вариант

1

2

3

4

Вид

соединения

Терминал А®

прокси-сервер®

сервер переадресации®

®прокси-сервер

®терминал В

Терминал.А® сервер

переадресации®

прокси-сервер®

сервер переадресации

®терминал В

Терминал А®

прокси-сервер®

прокси-сервер®

сервер переадресации

®терминал В

Терминал.А®

сервер

переадресации

®прокси-сервер

®прокси-сервер

®терминал В


Занятие 8. ПРИНЦИПЫ ПОСТРОЕНИЯ ШЛЮЗА IP-ТЕЛЕФОНИИ

Занятие 8. Принципы

построения шлюза IР-телефонии

Для проведения этих лабораторных работ рекомендуется использовать учебную лабораторную установку шлюза Протей. Последующие лабораторные работы включают изучение процедур установления соединений, операционной системы Linux, на которой построено программное обеспечение шлюза, и техобслуживания.

Каждая лабораторная работа содержит теоретическую часть и практическое задание. Практические задания выполняются на терминале шлюза Протей-ITG.

8.1. Основы построения шлюза

Шлюз Протей-ITG (рис.8.1) предназначен для организации доступа абонентов существующей телефонной аналого-цифровой сети общего пользования к сети Интернет через цифровую коммутационную станцию в соответствии с требованиями Минсвязи России к аппаратуре, реализующей функции передачи речевой информации по сетям передачи данных с протоколом IP.

Основным функциональным назначением шлюза является преобразование речевой информации, поступающей со стороны ТфОП с постоянной скоростью передачи, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP.

Шлюз может использоваться операторами связи (сервис-провайдерами) для предоставления услуг IP-телефонии посредством доступа к сети Интернет.

Оборудование шлюза реализует передачу речевого трафика и факсимильной информации по сетям с маршрути-

зацией пакетов IP в соответствии с рекомендацией ITU-T H.323 v2, выполняя функции:- кодирования и упаковки речевой информации в пакеты RTP/UDP/IP;

- конвертирования сигнальных сообщений систем сигнализации E-DSS1и ОКС7 (ISUP-R - российская версия) в сигнальные сообщения H.323 и обратного преобразования в соответствии с рекомендацией ITU-T H.246;

- обработки сигналов DTMF; распознавания и обработки тоновых сигналов.

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

Оборудование шлюза обеспечивает совместимость с Н.323 шлюзами (Cisco) и клиентскими программами (Microsoft Netmeeting 3.0).

Состав лабораторной установки

Программное обеспечение лабораторной установки (табл. 8.1):

- системное;

- взаимодействия с пользователем через Web-интерфейс (да-лее - интерфейс пользователя);

- собственно шлюза для обработки вызовов.

В состав оборудования шлюза (рис.8.2) входят:

- материнская плата с процессором (Celeron 500 MГц) и оперативной памятью (64 Мбайт);

- жесткий диск (10 Гбайт);

- плата внутрисистемного интерфейса, обеспечивающая аппаратную обработку речевого пакетизированного сигнала и обработку HDLC по сигнальным каналам;

- плата преобразования речи (количество плат зависит от числа подключенных ИКМ-трактов);

- кабель для подключения ИКМ-трактов;

- сетевая плата (2), обеспечивающая сетевой интерфейс;

- плата ОКС, обеспечивающая обработку сигнализации ОКС7 и согласование с платой внутрисистемного интерфейса.

Компоненты ПО | Характеристика
Системное программное обеспечение: |
- операционная система | Red Hat Linux 6.2
Интерфейс техобслуживания | telnet
ПО управления функциями шлюза: - модуль телефонной сигнализации (DSS1, SS7), - модуль сигнализации H.323, - модуль обработки вызова, - модуль обработки сигнализации ОКС7 | ПО диалогового режима

Плата преобразования речи выполняет функции подготовки речевого сигнала, поступающего из ТфОП/ЦСИО, для дальнейшей передачи по сети с маршрутизацией пакетов IP. Основными функциями платы являются: преобразование речевого сигнала в соответствии с алгоритмом кодирования (G.711, G.723.1, G.726, G.728, G.729), обнаружение активных периодов и пауз в речи, адаптация воспроизведения и эхокомпенсация.

Кроме того, в модуле реализованы функции детектирования и генерации сигналов DTMF, а также обработки факсимильных и модемных сигналов.

Плата ИКМ обеспечивает физический стык по G.703 шлюза с цифровой системой передачи Е1.

Плата интерфейса с телефонной сетью обеспечивает интерфейс с материнской платой, а также взаимодействие платы ИКМ и платы преобразования речи.

Материнская плата содержит процессор (Celeron, 500 МГц), жесткий диск, (10 Гбайт), оперативную память (64 Мбайт) и обеспечивает согласованную работу всех плат шлюза.

Сетевые платы обеспечивают стык шлюза с сетью, использующей технологию пакетной передачи.

Сетевая плата 1 обеспечивает интерфейс с сетью оператора IP-телефонии.

Сетевая плата 2 обеспечивает интерфейс с оператором системы техобслуживания сети.

В упрощенной учебной установке шлюз содержит только одну сетевую плату.

Таблица 8.2

Наименование характеристики | Значение
Емкость системы | До 2 трактов Е1
Интерфейс оборудования для подключения к сети ТфОП. Параметры физического уровня: - скорость цифрового потока, кбит/с - линейный код - амплитуда импульса на нагрузке 120 Ом, В - ширина импульса, нс | Симметричный, 120 Ом (рек. ITU-T G.703) 2048 ± 0,1 HDB3 3 ± 0,3 244 ± 25
Скорость передачи данных, кбит/с | 30´ 64 (PRI)
Интерфейс оборудования для подключения к сети с маршрутизацией пакетов IP | Ethernet 10/100 BaseT
Протоколы | TCP/IP, RTP/RTCP, UDP
Системы сигнализации | H.323 v2, H.225 (RAS, Q.921), H.245; DSS1 (Q.921, Q.931); ОКС-7 (российские национальные спецификации ISUP-R, MTP)
Алгоритмы кодирования речи | G.711, G.723.1, G729
Питание: - напряжение, В - частота, Гц | 60 ± 6 50 ± 2,5
Техническое обслуживание | telnet

Оборудование шлюза реализует передачу речевого тра-фика и факсимильной информации по сетям с маршрутизацией IP-пакетов по H.323 v2, выполняя функции:

- кодирования и упаковки речевой информации в пакеты RTP/UDP/IP;

- конвертирования сигнальных сообщений систем сигнализации E-DSS1 и ОКС7 (ISUP-R - российская версия) в сигнальные сообщения H.323 и обратного преобразования в соответствии с рекомендацией ITU-T H.246;

- обработки сигналов DTMF; распознавания и обработки тоновых сигналов.

Для работы шлюза в сети IP-телефонии без привратника реализована функция преобразования номера ТфОП в IP-адрес. Оборудование шлюза (табл. 8.2 - 8.4) обеспечивает совместимость с Н.323 шлюзами (Cisco) и клиентскими программами (Microsoft Netmeeting 3.0).

Шлюз Протей-ITG подключается к опорной АТС по линиям первичного доступа PRI (уровень 1 по рекомендации ITU-T-Т I.431 и стандартом ETSI ETS 300 011) с использованием системы сигнализации DSS1 (уровень 2 по рекомендации ITU-T-Т Q.921, уровень 3 по рекомендации ITU-T-Т Q.931) и системы сигнализации ОКС7 (ISUP). К сетям с маршрутизацией пакетов IP-шлюз подключается с помощью интерфейса Ethernet 10/100 BaseT.

Таблица 8.3

Устройство

Характеристика

Процессор

Celeron, 500 MHz

Жесткий диск, Гбайт

10

Оперативная память, Мбайт

64

Таблица 8.4

Характеристики платы | Значение
Интерфейс Скорость передачи Линейный код Электрические характеристики интерфейса | Цифровой интерфейс ИКМ-30 2048 кбит/с HDB3 G.703 (симметричный)

Задание на лабораторную работу

Отчет должен содержать структурную схему шлюза, его назначение и описание основных блоков. При защите необходимо ответить на контрольные вопросы.

Контрольные вопросы

  1. Пояснить назначение шлюза Протей-ITG.
  2. Перечислить основные компоненты шлюза, пояснить их назначение.
  3. Подключение шлюза к сети (телефонной и коммутации IP-пакетов).
  4. Какие системы сигнализации поддерживает шлюз (ТфОП и IP-сети)?
  5. Перечислить функциональные характеристики шлюза.
  6. Нарисовать схемы подключения шлюза и их соединение между собой


Занятие 9. установление соединения шлюзом без привратника

9.1. Теоретический материал

АТС 1 (рис 9.1) посылает сообщение Q.931 Setup на шлюз 1, в котором указывается номер вызывающего и вызываемого пользователей. Шлюз 1 принимает сообщение Q.931 Setup, обрабатывает его на основании адресной информации, находящейся в поле Called Party Number. ПО шлюза обращается к файлу callroute.cfg (см. задание 3), по которому определяется IP-адрес встречного шлюза, который может обслужить данный вызов. Шлюз 2 принимает сообщение, если передающий IP-адрес (или его часть), находится в файле permissions.cfg. Из сообщения H.225 Setup берется номер вызываемого пользователя, который (номер) отправляется в сообщении Q.931 Setup на АТС 2. Вызываемое оборудование отвечает на Setup сообщением Call Proceeding.

Вызываемому абоненту выдается сигнал посылки вызова, а на шлюз 2 передается сообщение Q.931 Alerting. Шлюз 2 посылает сообщение H.225 Alerting шлюзу 1.

На АТС 1 передается сообщение Q.931 Alerting, а абоненту А выдается сигнал контроль посылки вызова (КПВ). После ответа АТС 2 генерирует сообщение Q.931 Connect. Шлюз 2 подтверждает прием Q.931 Connect сообщением Q.931 Connect ACK. Шлюз 2 посылает сообщение H.225 Connect шлюзу 1 с указанием транспортного адреса управляющего канала Н.245, после чего он открывается. Шлюз 1 генерирует сообщение Q.931 Connect и посылает его АТС 1. После получения транспортного адреса управляющего канала Н.245, устанавливается TCP-соединение, по которому передаются сообщения протокола Н.245.

После открытия управляющего канала H.245 начинается обмен данными о функциональных возможностях обору-дования. Шлюзы обмениваются сообщениями Terminal-CapabilitySet, в которых указываются возможные алгоритмы декодирования принимаемой информации. Следует отметить, что сообщение TerminalCapabilitySet должно быть первым сообщением, передаваемым по управляющему каналу. Оборудование, принявшее сообщение TerminalCapabilitySet от другого оборудования, подтверждает его получение передачей сообщения TerminalCapabilitySetAck.

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

В ходе процедуры устройства обмениваются сообщениями masterSlaveDetermination.

В ответ на полученные сообщения masterSlave-Determination оба устройства передают сообщения master-SlaveDeterminationAck, в которых указывается, какое из этих устройств является для данного соединения ведущим, а какое - ведомым.

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

В ответ на сообщение openLogicalChannel оборудование должно передать подтверждение openLogicalChan-nelAck, указывающее транспортный адрес, на который передающей стороне следует посылать RTP пакеты, а также транспортный адрес канала RTCP.

Далее открывается разговорная сессия. Оборудование вызывающего пользователя передает речевую информацию, упакованную в пакеты RTP/UDP/IP, на транспортный адрес RTP-канала оборудования вызванного пользователя, а вызванный пользователь передает пакетированную речевую информацию на транспортный адрес RTP-канала оборудования вызывающего пользователя.

При помощи канала RTCP ведется контроль передачи информации по RTP каналам. После окончания разговорной фазы начинается фаза разрушения соединения. Оборудование пользователя, инициирующего разъединение, прекращает передачу речевой информации, закрывает логические каналы и передает по управляющему каналу сообщение H.245 endSessionCommand, означающее, что пользователь хочет завершить соединение. Ожидается сообщение endSession-Command от встречного оборудования, после чего управляющий канал Н.245 закрывается. Следующим шагом, если сигнальный канал открыт, передается сообщение Release-Complete, и сигнальный канал закрывается.

Пользователь, получивший команду endSession-Command от пользователя, инициировавшего разъединение, должен прекратить передачу речевой информации, закрыть логические каналы и передать сообщение endSessionCom-mand. Далее, если сигнальный канал остался открытым, передается сообщение ReleaseComplete, сигнальный канал закрывается, и обслуживание вызова считается завершенным.

Более подробную информацию о процессе установления соединения можно найти в [1].

Задание на лабораторную работу

Отчет должен содержать сценарий установления соединения. При защите необходимо пояснить назначение каждого из представленных сообщений и ответить на контрольные вопросы.

Контрольные вопросы

  1. Стандарт Н.323. Архитектура сети IP-телефонии на основе рекомендации Н.323.
  2. Стандарт Н.323. Элементы сети IP-телефонии на основе рекомендации Н.323.
  3. Сигнализация Н.323. Сигнальный канал Н.225 (функции, основные команды).
  4. Сигнализация Н.323. Управляющий канал H.245 (функции, основные команды).


Занятие 10.УСТАНОВЛЕНИЕ СОЕДИНЕНИЯ ШЛЮЗОМ С ПРИВРВТНИКОМ

Занятие 10. установление соединения шлюзом с привратником

10.1. Теоретический материал

Данный сценарий (рис. 10.1) похож на сценарий рис. 9.1, за исключением начальной и конечной фаз установления соединения. Для взаимодействия с привратником

используется протокол RAS. После приема сообщения Q.931 Setup шлюз 1 с помощью протокола RAS обращается к привратнику (рис. 10.1) за доступом к сетевым ресурсам (сообщение ARQ). Если привратник разрешает использовать сетевые ресурсы шлюзу, он посылает ему сообщение ACF. То же самое происходит на шлюзе 2 при приеме сообщения Н.225 Setup. При завершении сеанса связи шлюзы посылают сообщение DRQ привратнику, который подтверждает их прием сообщением DCF.

Более подробно о работе привратника в [1 - 5].

Задание на лабораторную работу

Отчет должен содержать сценарий установления соединения. При защите необходимо пояснить назначение каждого из представленных сообщений и ответить на контрольные вопросы.

Контрольные вопросы

  1. В чем отличие сценариев с/без участия привратника?

  2. Какие функции выполняет привратник?

  3. Какие функции выполняет протокол RAS?

  4. Зачем необходимы сообщения ARQ и ACF, DRQ и DCF?


Занятие 11.ИЗУЧЕНИЕ ОПЕРАЦИОННОЙ СИСТЕМЫ LINUX

Занятие 11. ИЗУЧЕНИЕ ОПЕРАЦИОННОЙ СИСТЕМЫ

LINUX

11.1. Теоретический материал

Linux - современная Unix-подобная операционная система для персональных компьютеров и рабочих станций. Это многопользовательская сетевая операционная система с сетевой оконной графической системой X Window System. ОС Linux поддерживает стандарты открытых систем и про-

токолы сети Internet, совместимые с системами Unix, DOS, MS Windows. Все компоненты системы, включая исходные тексты, распространяются с лицензией на свободное копирование и установку для неограниченного числа пользователей. ОС Linux распространена на платформах Intel PC 386/486/Pentium/Pentium Pro. Разработка ОС Linux выполнена Линусом Торвалдсом из университета Хельсинки и большой командой из тысяч пользователей сети Internet, сотрудников исследовательских центpов, фондов, унивеpситетов и т.д.

Техобслуживание шлюза осуществляется посредством удаленного доступа к нему через локальную сеть с использованием протокола telnet. Для этого необходимо иметь ПК со специализированным ПО протокола, в качестве которого может служить встроенное в операционные системы семейства MICROSOFTâ WINDOWS приложение, реализующее протокол telnet (вызывается командой telnet).

Для лабораторной работы используется более удобная программа PuTTY (рис. 11.1).

Из списка устройств необходимо выбрать шлюз Протей-ITG (конкретное устройство указывает преподаватель). Для соединения с ним необходимо дважды щелкнуть мышкой на соответствующем имени в поле Stored Sessions. После этого появится окно (рис. 11.2). Компьютер подключился к операционной системе Linux, что видно из первой строки экрана.

Данное окно является окном идентификации пользователей операционной системы Linux, на базе которой работает шлюз Протей-ITG. Необходимо ввести имя пользователя и пароль. Если пароль правильный, на экране появляется командная строка операционной системы Linux (рис. 11.3).

Для более удобной работы необходимо запустить оболочку Midnight Commander, используя команду мс. На экране появится рабочая панель этой оболочки (рис. 11.4).

Работа с ней подобна работе с Norton Commander для операционной системы DOS (ПО шлюза расположено в определенной директории, имя которой указывается преподавателем).

Хождение по меню осуществляется с помощью клавиш Ü , Ý , Þ , ß , PageUp, PageDown, Home, End.

Для того чтобы зайти в директорию, нужно использовать клавишу Enter.

Для просмотра файлов необходимо нажать клавишу F3, а чтобы изменить какие-либо значения - клавишу F4, после чего можно с клавиатуры вводить необходимые значения.

Задание на лабораторную работу

Отчет должен содержать краткое описание операционной системы Linux, а также ответы на контрольные вопросы.

При защите необходимо показать, каким образом можно просматривать и изменять содержание файлов.

Контрольные вопросы

  1. На какой операционной системе работает шлюз?

  2. Каким образом осуществляется подключение к шлюзу?

  3. Что такое протокол telnet?

  4. Что такое Midnight Commander? Как с ним работать?


Занятие 12. ИЗУЧЕНИЕ СИСТЕМЫ ТЕХОБСЛУЖИВАНИЯ ШЛЮЗА

Занятие 12. Изучение

системы техобслуживания шлюза

12.1. Теоретический материал

Конфигурация шлюза задается посредством набора конфигурационных файлов, состоящего из следующих двух групп.

В первую группу входят конфигурационные файлы, разработанные на основе одноименных файлов платформы “Протей”:

  • DSS1.cfg ,

  • physical.cfg ,

  • protei.cfg ,

  • SS7.cfg .

Во вторую группу входят конфигурационные файлы, разработанные специально для шлюза:

  • gateway.cfg (основные параметры шлюза),

  • callroute.cfg (правила маршрутизации вызова),

  • permissions.cfg (правила доступа к шлюзу из сети IP).

  • H323.cfg (настройка процедур протоколов Н.225, Н.245 и процедур, связанных с передачей аудиоинформации по рекомендации H323).

Примечание. Во всех файлах после символа # следует текстовое описание значения данного поля, необходимое для технического персонала.

Настройка основных параметров шлюза

- файл gateway.cfg

Общая (General) - это обязательная секция, которая описывает основные параметры шлюза:

Name - строковое имя шлюза (обязательный параметр), которое присутствует в качестве “alias” в сигнальных сообщениях H.323;

IP - IP-адрес шлюза (обязательный параметр), куда приходят сигнальные сообщения;

Port - номер порта TCP, используемый для установления телефонных вызовов из IP-сети на шлюз (значение по умолчанию 1720);

Prefixes - набор префиксов телефонных номеров в сети ТфОП, на которые шлюз способен направить вызовы (для Санкт-Петербурга - 812) и которые необходимы для регистрации на привратнике (значение по умолчанию - пустой список);

MaxCall - максимальное число вызовов, которые может обслужить шлюз;

Секция (Audio) - настройки, общие для всех кодеков. Это необязательная секция, которая содержит параметры:

SilenceSupression - подавление пауз в разговоре. Значения 0/1, т.е. использовать или не использовать (значение по умолчанию - 1);

Codecs (g729/g723/g711/gsm) - обозначения, используемых кодеков в порядке приоритетов (значение по умолчанию - g729, g711). Пока реализован только g729.

Секция привратник (Gatekeeper) - это необязательная секция, которая описывает параметры использования привратника:

UseGatekeeper 0/1 - использовать или не использовать привратник (значение по умолчанию - 0);

AutomaticGatekeeperDiscovery 0/1 - ручное или

автоматическое задание привратника (значение по умолчанию - 1).

В случае ручного задания привратника:

IP - IP-адрес привратника (значение по умолчанию - 0000),

Port - UDP-порт, используемый для передачи сообщений RAS-сигнализации (значение по умолчанию - 1719).

Правила маршрутизации вызова - файл callroute.cfg

Файл содержит таблицу маршрутизации вызовов из ТфОП в H.323 по префиксам телефонных номеров либо по полным телефонным номерам.

Первый столбец таблицы – префикс или номер, второй - адрес шлюза, на который следует направить данный вызов.

Не допускается запись, при которой одному префиксу соответствуют два разных IP-адреса. Форматы номера - последовательность цифр (0, … , 9), а префикса - последовательность цифр, заканчивающаяся символом *.

Правила доступа к шлюзу из IP-сети

- файл permissions.cfg

Файл содержит список (черный или белый) IP-адре-сов, которым разрешен выход на шлюз для установления соединения:

AccessRule - секция, в которой определены правила доступа для всех IP-адресов, кроме упомянутых в списке исключений. Параметр секции может принимать значение GeneralRule = ALLOWED/DENIED: разрешить или запретить доступ по умолчанию.

ExceptList - секция, в которой определен список исключений для указанных в предыдущей секции правил доступа. Цифра, записанная через косую черту /, означает, сколько бит в IP-адресе, начиная слева, являются обязательными при анализе номера.

Настройка процедур протоколов Н.225, Н.245

и процедур, связанных с передачей аудиоинформации

- файл H323.cfg

Секция H.225 содержит настраиваемые параметры: FastStart - принимает значения 0/1 - используется или не используется процедура Fast Connect (значение по умолчанию - 0);

MediaWaitForConnect - принимает значения 0/1- допускается или не допускается передача речи до приема сообщения Connect (значение по умолчанию - 0).

Секция H.245 содержит настраиваемые параметры:

H245Tunneling - принимает значения 0/1 - используется или не используется туннелирование сообщений сигнализации H.245 в канале сигнализации H.225 (значение по умолчанию - 1);

EarlyH245 - принимает значения 0/1 - допускается или не допускается инициирование процедур H.245 до установления соединения, т.е. Connect (значение по умолчанию - 0).

Секция параметров обработки речи (Audio) содержит настраиваемые параметры джиттер-буфера и аудио-кодеков.

Для настройки джиттер-буфера используются следующие параметры:

AdaptiveJitter - принимает значения 0/1 - используются или не используются алгоритмы адаптивного изменения jitter-буфера (значение по умолчанию - 0);

InitialJitter - начальный размер jitter-буфера, в мс (значение по умолчанию - 60).

Для настройки аудиокодеков используются следующие параметры:

Кодек G.711

PacketizationIntrerval - длительность одного генерируемого речевого пакета, в мс (значение по умолчанию - 30).

Кодек G.723.1

PacketizationIntrerval - длительность одного генерируемого речевого пакета, в мс (длительность фрейма G.723.1 - 30 мс) (значение по умолчанию - 30);

Rate - скорость работы кодека: 0 - 5.3 кбит/с, 1 - 6.3 кбит/с (значение по умолчанию - 0).

Кодек G.729

PacketizationIntrerval - длительность генерируемого речевого пакета, в мс (длительность фрейма G.729 - 10 мс) (значение по умолчанию - 30).

Примеры файлов конфигурации

Gateway.cfg

# general gateway parameters

[General]

Name=Loniis

IP=192.168.100.4

Port=1720

Prefixes=7812

MaxCalls=5

# gatekeeper parameters

[Gatekeeper]

UseGatekeeper=1

# Gatekeeper discovery method

# 0 – manual discovery

# 1 – automatic discovery

AutomaticGatekeeperDiscovery=0

#manually set gatekeeper address

IP=192.168.100.21

Port=1719

#Audio parameters

[Audio]

SilenceSuppression=1

Codecs=g729,g723

Callroute.cfg

[CallRouting]

# prefix gateway

7095* 195.239.254.13 # Moscow /Teleross

Permissions.cfg

[AccessRule]

GeneralRule = DENY

[ExceptList]

194.85.131.3/32 # from Moscow

195.205.33.11/32 # from Arkhangelsk

195.205.35.24/32 # from Severodvinsk

192.168.100.0/24 # from our subnet

H323.cfg

#Protocol options

[H.225]

FastStart=1

MediaWaitForConnect=1

[H.245]

H245Tunneling=1

EarlyH245=0

#Speech processing parameters

[Audio]

AdaptiveJitter=0

InitialJitter=60 #60 ms

[G.711]

PacketizationIntrerval=30 #30 ms

[G.729]

PacketizationIntrerval=30 #3 frames, 10 ms per frame

[G.723.1]

PacketizationIntrerval=30 #1 frame, 30 ms per frame

# Speech rate:

# 0 - low-rate speech (5.3 kb/s)

# 1 - high-rate speech (6.3 kb/s)

Rate=1

Задание на лабораторную работу

Отчет должен содержать название и назначение конфигурационных файлов.

Описать, какие изменения в файлах необходимо сделать в следующих режимах работы шлюза:

1) все вызовы направляются на удаленное устройство с IP-адресом: 192.168.100.104;

2) шлюз принимает вызовы только с IP- адресов: 192.168.100.104 и 192.168.100.22;

3) по номерам, начинающимся с цифр 10 и 11, вызовы отправляются на IP-адрес: 192.168.100.104, а с 20 и 21 - на IP-адрес: 192.168.100.22;

4) шлюз может обрабатывать только кодек G.711;

5) не используется процедура FastStart [1];

6) шлюз использует привратник с IP-адресом: 192.168.100.25.

Контрольные вопросы

1. Каким способом осуществляется подключение к шлюзу Протей-ITG?

2. В каком виде хранится конфигурация шлюза?

3. Перечислить название и назначение конфигурационных файлов.

4. Каким образом можно задать определенную маршрутизацию вызовов?

5. Каким образом можно ограничить доступ к шлюзу?

6. Где задается IP-адрес шлюза?

7. Префиксы и их использование в шлюзе.


IP - телефония

медодические рекомендации

к лабораторным работам

200900

СОДЕРЖАНИЕ:

Предисловие

Занятие 1. Построение сети на базе Н.323

Занятие 2. Протокол RAS

Занятие 3. Сигнальный канал Н.225.0

Занятие 4. Управляющий канал Н.245

Занятие 5. Построение сетей на базе протокола SIP

Занятие 6. Сообщения SIP

Занятие 7. Процесс установления соединения

Занятие 8. Принципы построения шлюза Протей-ITG

Занятие 9. Установление соединения шлюзом без привратника

Занятие 10. Установление соединения шлюзом с привратником

Занятие 11. Изучение операционной системы Linux

Занятие 12. Изучение системы техобслуживания шлюза

Литература

перейти на DVO Pages

E-mail: teach@sut.ru

перейти к Списку литературы


ЛИТЕРАТУРА

1. Гольдштейн Б.С., Пинчук А.В., Суховицкий А.Л. IP-теле-фония. М.: Радио и Связь, 2001.

2. Кузнецов А.Е., Пинчук А. В., Суховицкий А.Л. Постро-ение сетей IP-телефонии // Компьютерная телефония. 2000. № 6.

3. Кульгин М. Технологии корпоративных сетей. СПб: Пи-тер, 1999.

5. Мюнх Б., Скворцова С. Сигнализация в сетях IP-теле-фонии // Сети и системы связи. 1999. № 13 (47), 14 (48).

5. ITU-T Recommendation H.225.0. Call signaling protocols and media stream packetization for packet-based multimedia communication systems. Geneva, 1998.

6. ITU-T Recommendation H.245. Control protocol for multimedia communication. Geneva, 1998.

7. ITU-T Recommendation H.323. Packet based multimedia communication systems. Geneva, 1998.

    RFC 2543. SIP: Session Initiation Protocol. M.: Handley, 1999.


Предисловие

Технология передачи речевой информации по сетям с маршрутизацией пакетов IP - Voice over IP (VoIP) или IP-телефонии представляет собой компрессию голосового сигнала с последующей передачей по цифровым каналам передачи данных с использованием протокола IP.Частным случаем IP-телефонии является Интернет-телефония, когда в качестве передающей сети используется сеть Интернет.

IP-телефония - сравнительно новая технология, она уже успела зарекомендовать себя вполне перспективной и жизнеспособной. Согласно прогнозам аналитиков, в мире ожидается значительный (в ближайшие годы в десятки раз) рост речевого трафика, переносимого по сетям с маршрутизацией пакетов. Несмотря на разброс оценок величины рынка, большинство аналитиков сходятся на том, что IP-телефония является магистральным путем развития телекоммуникационной индустрии. Дополнительно IP-телефония вносит новые услуги в сферу телекоммуникаций: речевые и видеоконференции, одновременный доступ к приложениям, быстрый поиск абонента и другие.

IP - всего лишь протокол, который наравне с некоторыми другими (ATM, FR) используется для передачи по сети Интернет оцифрованной и сжатой в “пакеты” определенного объема электронной информации. В принципе, после соответствующей обработки таким способом на любые досягаемые для паутины Интернет расстояния может передаваться любой тип информации (голосовая, видео, компьютерные данные), так что собственно телефония является лишь одной составляющей общего процесса, однако данные методические рекомендации ограничиваются только ею.

Преимущества IP-телефонии неоспоримы. В первую очередь - это низкая стоимость передачи информации, а также универсальность обработки информации независимо от ее исходного вида, следовательно, использование одних и тех же каналов для передачи информации разного типа. Это доступность сети Интернет, относительно низкая стоимость (звонки из России в Соединенные Штаты, например, при использовании канала IP-телефонии удешевляются в несколько раз), совместимость стандартов большинства производителей оборудования для IP-телефонии.

Без сомнения, популярность технологий пакетной передачи речи растет, причем как среди операторов, так и среди корпоративных пользователей. В последние годы немало компаний успешно внедрили эти технологии для организации каналов дальней телефонной связи.

До 1995 г. IP-телефония не была широко распространена. Существовали отдельные свободно распространяемые программы, созданные программистами-исследовате-лями без перспективы их широкого распространения, так как считалось невозможным получить качественное голосовое соединение через Интернет. Компания VocalTec, выпустившая программу Internet Phone в феврале 1995 г., доказала, что это не так. Установив на персональный компьютер (486/33-MHz и выше) со средствами мультимедиа (звуковая карта, микрофон, колонки) и подключением к Интернет программу Internet Phone, можно разговаривать с другим пользователем персонального компьютера в любой точке мира, где есть доступ в Интернет. В конце 1995 г. общее количество активных пользователей IP-телефонии оценивалось уже в 500 тысяч. Львиную долю этого рынка (94%) занимала продукция VocalTec. Активные пользователи определяются как люди, которые пользуются IP-телефонией на постоянной основе. Первоначальными пользователями IP-телефонии в 1995 г. были люди, осуществляющие небольшие эксперименты в деловых Intranet приложениях. В 1996 г. IP-телефония за один год выросла на 97% от оцененного в $1,8 млн рынка (Frost&Sullivan, 1997).

К 1997 г. общее число минут, переданных по IP-сетям, составило 0,1 млрд (US Bancorp Piper Jaffray), а в 1998 г. голосовой трафик IP-телефонии в компаниях, входящих в список Fortune-1000, составляет менее 1% от всех междугородных и международных звонков. В 1999 г. использование IP-протокола в телефонии достигло в общей сложности 310 млн мин.

Россия не была исключением среди стран, проявивших интерес к IP-телефонии, так как интерес к новой технологии имеет особый практический смысл. Дело в том, что в нашей стране услуги международной телефонной связи традиционно дороже, чем на Западе. Кроме того, географические размеры страны делают актуальным вопрос о стоимости междугородной связи.

Использование IP-технологии подразумевает возможность ведения телефонных разговоров по более дешевому тарифу, что позволяет сэкономить значительные средства удаленным на большие расстояния абонентам.

В 1996 г. российско-американская компания CompTek приобрела пробный комплект оборудования для IP-связи, состоящий из двух шлюзов производства израильской фирмы VocalTec. Это были первые в мире устройства для телефонных разговоров через IP-сеть. Шлюзы поддерживали неплохое качество передачи речи. И в скором времени CompTek заключила с VocalTec соглашение о дистрибьюции шлюзов на территории России и СНГ. Хотя этот проект ожидал большой коммерческий успех, возникли некоторые проблемы. С кем будет связываться имеющийся шлюз, если развитых IP-сетей в России еще не существует? Поэтому изначально покупателями шлюзов становились в основном территориально распределенные компании, использовавшие IP-телефонию для связи между своими офисами. Очевидный выход из сложившейся ситуации заключался в налаживании партнерских отношений с фирмами-операторами.

На этом этапе ведущую роль в продвижении IP-техно-логии в России сыграла компания “Тарио”, которая к тому времени она уже сотрудничала с VocalTec, и появление IP-шлюзов открыло новые перспективы и возможности для совместного бизнеса. Установкой шлюзов после заключения соответствующих соглашений занялись компании “Тарио” и RGC. При этом “Тарио” строила сети шлюзов в городах России, RGC налаживала связи для предоставления услуг международной связи.

Начиная с 1997 г., в России стали реально строиться сети IP-телефонии, но из-за неопределенности с лицензированием эта услуга предоставлялась с пометкой “в тестовом режиме”. Тем не менее, технология широко рекламировалась в прессе и демонстрировалась на выставках. Там постоянно предоставлялась бесплатная возможность сделать городские, междугородные и международные звонки через систему IP-телефонии.

Представители компании VocalTec, в то время единственной фирмы, поставлявшей оборудование для IP-сетей, участвуя в различных семинарах и конференциях, неоднократно заявляли, что Россия обогнала многие страны на пути предоставления коммерческих услуг по междугородной и международной IP-связи.

В то же время крупные Internet-провайдеры и телефонные операторы не спешили осваивать новую технологию. Свои услуги на рынке активно предлагали только небольшие и средние компании. Такое положение объяснялось двумя аспектами: правовым и техническим.

Порядок лицензирования для IP-телефонии еще не существовал, и эта технология распространялась в стране практически нелегально, следовательно, крупные фирмы не могли выйти на рынок с рекламной компанией услуг IP-телефонии. Технический аспект состоял в несовершенстве оборудования. Первые шлюзы поддерживали не более одного потока Е1 (до 30 одновременных звонков), а качество связи было низким, что приводило к значительному искажению голосовых сообщений. Со временем эти проблемы начали решать, и, хотя до окончательного решения проблемы качества еще далеко, уже 1998 г. ознаменовался радикальным скачком в развитии технологии.

По решению Минсвязи России в Ассоциации документальной электросвязи (АДЭ) была создана рабочая группа IР-телефонии, в которую вошли фирмы-разработчики и фирмы-поставщики оборудования, а также традиционные операторы связи (всего 41 компания). Группе было поручено разработать пакет документов для легализации Интернет-телефонии в России. IP-телефония (1.06.99) была официально признана “телематической службой передачи речевой информации”. На сегодняшний день уже многие российские компании, получив лицензии, приступили к внедрению IP-телефонии либо рассматривают такую возможность, решая, на каком оборудовании остановить свой выбор.

В Санкт-Петербурге на базе платформы ПРОТЕЙ (в 2000 г.) была начата разработка узла услуг IP-телефонии, а в 2001 г. на выставке Связь-Экспокомм в Москве был представлен первый российский коммерческий продукт - шлюз Протей-IP. Именно учебная установка на базе Протей-IP может быть использована для выполнения лабораторных работ. Несмотря на рост популярности технологии VoIP, необходимо отметить, что трафик в реальном времени больше страдает от перегрузок, чем традиционный трафик данных. Сегодня Интернет в целом не гарантирует качество соединений, т. е. необходимость каким-то образом сохранить в периоды перегрузки трафик реального времени или, по крайней мере, гарантировать ему получит более высокий приоритет. В частности, для переноса трафика реального времени в сети Интернет используется не протокол гарантированной доставки TCP, который применялся для передачи данных, а протокол UDP, поверх которого работает протокол доставки информации в реальном времени RTP. Однако и это не решает в достаточной степени проблему качества обслуживания (QoS), что является отдельной темой и не рассматривается в данных рекомендациях.