ФЕДЕРАЛЬНОЕ АГЕНСТВО СВЯЗИ

Государственное образовательное учреждение высшего профессионального образования

«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ

им. проф. М.А. БОНЧ-БРУЕВИЧА»

Б.С. Гольдштейн В.Ю. Гойхман Д.Н. Онучина

ПРОТОКОЛ SIP

Учебное пособие

Рекомендовано УМО по образованию в области телекоммуникаций в качестве учебного пособия для подготовки бакалавров

и магистров техники и технологии и дипломированных специалистов по направлению 210400 "Телекоммуникации" специальности:

210406 "Сети связи и системы коммутации», 210404 "Многоканальные телекоммуникационные системы",

210402 "Средства связи с подвижными объектами», 210407 "Эксплуатация средств связи»

и по направлению подготовки дипломированных специалистов, по направлению 230100 "Информатика и вычислительная техника» специальности:

230101 "Вычислительные машины, комплексы, системы и сети", 230102 "Автоматизированные системы обработки информации и управления",

230105 "Программное обеспечение вычислительной техники и автоматизированных систем"

Санкт-Петербург 2011

2

УДК 621.395:658.512.22 ББК 32.882 Г63

Рецензенты: доктор технических наук, профессор В.В. Лебедянцев (СибГУТИ) кандидат технических наук, доцент О.Г. Шерстенева (СибГУТИ)

Утверждено

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

Г63 Протокол SIP: учебное пособие / Б.С. Гольдштейн, В.Ю. Гойхман, Д.Н. Онучина; ГОУВПО СпбГУТ. – СПб, 2011.

Содержится учебный материал о протоколе сигнализации SIP для се-

тей связи следующего поколения NGN. Процесс обучения строится на ос-нове программируемого интерактивного обучающего комплекса СОТСБИ-У с привлечением учебной лабораторной установки типа Протей-iМАК и тестовой платформы SNTlite. Приводятся планы проведения адаптируемо-го к слушателю интерактивного обучения, практических и лабораторных занятий, заключительного коллоквиума.

УДК 621.395:658.512.22 ББК 32.882

© В.Ю. Гойхман, Б.С. Гольдштейн, Д.Н. Онучина, 2011 © Государственное образовательное учреждение высшего профессионального образования «Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича», 2011

3

ПРИНЯТЫЕ СОКРАЩЕНИЯ ЕСЭ РФ Единая сеть электросвязи Российской Федерации; КПВ контроль посылки вызова; ЛВС локальная вычислительная сеть (LAN); МАК мультисервисный абонентский концентратор; МК мультисервисный коммутатор доступа; ОКС7 общеканальная сигнализация №7; ПК персональный компьютер (PC); ССОП сеть связи общего пользования; ТфОП телефонная сеть общего пользования; ЦОВ центр обслуживания вызовов; DSS1 Digital Subscriber Signaling #1 – цифровая абонентская сигнали-

зация №1; HTTP HyperText Transport Protocol – гипертекстовой транспортный

протокол; IETF Internet Engineering Task Force – группа стандартизации TCP/IP

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

ISDN Integrate Service Digital Network – цифровая сеть интегрального обслуживания;

NGN Next Generation Network – инфокоммуникационная сеть нового поколения;

P2PE Peer-to-Peer Education – обучение по принципу «диалога»; RFC Request For Comment - выпускаемые IETF документы, опреде-

ляющие Интернетстандарты, инструкции, отчеты рабочих групп и т.д.;

SDP Session Description Protocol - протокол описания сеансов связи (SIP);

SIP Session Initiation Protocol – протокол инициирования сеансов связи;

SIPT SIP for Telephony (IETF Draft) - протокол SIP для телефонной связи;

SNTlite Signaling Network Tester – протокол-тестер систем сигнализа-ции ЕСЭ РФ;

UA User Agent - агент пользователя; UAC User Agent Client - клиент агента пользователя; UAS User Agent Server - сервер агента пользователя; URI Universal Resource Identificator - универсальный идентификатор

ресурса.

4

1. ПРОТОКОЛ СИГНАЛИЗАЦИИ SIP 1.1. Общие сведения о протоколе

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

Протокол SIP поддерживает следующие сетевые возможности: ○ персональная мобильность пользователей – пользователи могут не-

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

○ масштабируемость сети – в первую очередь, характеризуется воз-можностью увеличения количества элементов сети при её расшире-нии, что в полной мере обеспечивает серверная структура сети, по-строенной на базе протокола SIP;

○ расширяемость протокола – характеризуется возможностью допол-нения протокола с целью введения новых услуг, а также для адап-тации протокола к работе с непредусмотренными прежде приложе-ниями;

○ интеграция в стек TCP/IP существующих протоколов Интернет, разработанных комитетом Internet Engineering Task Force (IETF);

○ взаимодействие с другими протоколами сигнализации, включая протокол Н.323 и системы общеканальной сигнализации DSS1 и ОКС7, причем для упрощения процедуры взаимодействия сигналь-ные сообщения протокола SIP могут переносить не только специ-фический SIP-адрес, но и телефонный номер формата Е.164 или любого другого формата.

1.2. Архитектура сети

Основными элементами сети SIP-телефонии являются терминалы и серверы. Функционально SIP-серверы подразделяются на прокси-серверы, серверы переадресации, серверы регистрации и серверы определения ме-стонахождения объекта (рис. 1.1.).

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

5

Рис. 1.1. Архитектура сети SIP

Терминалы могут быть двух типов: ПК, оснащённый необходимыми

аппаратными средствами и программным модулем SIP (UA) или SIP- теле-фон, подключающийся непосредственно к ЛВС. Управление обслуживани-ем вызова распределено между разными элементами сети SIP. Основным функциональным элементом, реализующим функции управления соедине-нием, является терминал. Остальные элементы сети отвечают за маршрути-зацию вызовов, а в некоторых случаях предоставляют дополнительные ус-луги. Терминал

В случае, когда клиент и сервер реализованы в оконечном оборудова-нии пользователя, они называются, соответственно, клиентом агента поль-зователя – User Agent Client (UAC) и сервером агента пользователя – User Agent Server (UAS). Если в устройстве присутствуют и сервер UAS, и кли-ент UAC, то оно называется агентом пользователя – User Agent (UA), а по своей сути представляет собой терминальное оборудование SIP.

6

Прокси-сервер Прокси-сервер представляет интересы пользователя в сети. Он прини-

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

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

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

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

7

1.3. Структура протокола В некотором смысле прародителем протокола SIP является протокол

HTTP. Протокол SIP унаследовал от него синтаксис и принцип «клиент-сервер» (рис. 1.2).

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

Рис. 1.2. Принцип «клиент-сервер»

Транзакции SIP – протокол, ориентированный на транзакции: взаимодействие ме-

жду элементами сети происходит путем периодического обмена сообще-ниями. Транзакция состоит из запроса и любого количества ответов на не-го. Обязательно должен присутствовать один (и только один) окончатель-ный ответ и, опционально, один или несколько предварительных ответов. Транзакция имеет клиентскую сторону и серверную сторону, соответст-венно, они носят название клиентской транзакции и серверной транзакции. Клиентская транзакция занимается отправкой запросов, а серверная тран-закция – отправкой ответов. Они создаются агентами пользователя и про-кси-серверами с сохранением состояний (stateful). Адресация

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

SIP-адреса бывают четырех типов: � имя@домен � имя@хост � имя@IР-адрес � номер_телефона@шлюз Таким образом, адрес состоит из двух частей. Первая часть – это имя

пользователя, зарегистрированного в домене или на рабочей станции. Во второй части адреса указывается имя домена, рабочей станции или шлюза. Если вторая часть адреса идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента. В начале SIP-адреса ставится слово «sip:», указывающее, что используется схема адресации SIP, так как бывают и другие схемы адресации (например, «mailto:»).

Примеры адресации протокола SIP:

Клиент Сервер Запрос Ответ

8

sip:userA@loniis.ru sip:userB@192.168.0.14 sip:387-76-58@gateway.ru

Протокол SIP предоставляет также возможность использования URI, гарантирующего защиту передаваемой информации, который называется SIPS URI. Например, sips:userB@domainB.ru. В случае, если вызов осуще-ствляется с терминала с идентификатором SIPS URI, то он будет проходить при использовании транспортного протокола TLS, обеспечивающего защи-ту и шифрование всех SIP-сообщений, переданных от вызывающего поль-зователя в домен вызываемого пользователя. В пределах домена вызывае-мого пользователя механизмы обеспечения безопасности зависят от внут-ренней политики домена.

1.4. Сообщения Структура

Протокол SIP – это текстовый протокол, использующий набор симво-лов ISO 10646 в кодировке UTF-8. Сообщения SIP представляют собой ли-бо запрос от клиента серверу, либо ответ сервера клиенту.

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

Стартовая строка Заголовки Пустая

строка Тело сообщения

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

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

Характеристики сеанса связи, такие как тип медиа-информации, ис-пользуемый кодек или частота дискретизации, не описываются средствами SIP. Тело SIP сообщения содержит описание сессии, выполненное в форма-те другого протокола. Один из таких протоколов – Session Description Protocol (SDP). SDP-сообщение переносится SIP-сообщением так же, как документ, прикреплённый к сообщению электронной почты, или web-страница, переносимая в сообщении протокола HTTP.

9

Формат заголовков Каждое поле заголовка состоит из имени поля, символа «двоеточие» и

значения поля. Имя заголовка: значение заголовка. Порядок следования заголовков не имеет значения. Однако рекомен-

дуется размещать поля заголовков, которые требуются для обработки про-кси-серверу (Via, Route, Record-Route, Proxy-Require, Max-Forwards, Proxy-Authorization и другие), в начале сообщения для ускорения анализа и обра-ботки.

Формат значения заголовка зависит от имени заголовка. Большинство существующих полей заголовков придерживается общего формата для зна-чений, основанного на последовательности пар имя параметра – значение параметра, разделённых знаком точка с запятой.

Имя заголовка: значение заголовка; имя параметра=значение пара-метра; имя параметра=значение параметра…

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

Стартовая строка Request-Line Подробное описание всех запросов протокола приведено в [1]. SIP-

запросы характеризуются наличием стартовой строки Request-Line (рис. 1.4). Request-Line состоит из названия типа запроса, Request-URI и версии протокола, разделённых пробелом. Она заканчивается символами возврата каретки и перевода строки (CRLF).

Тип запроса Пробел Request-URI Пробел Версия

протокола СRLF

Рис. 1.4. Стартовая строка Request-Line

В базовой рекомендации IETF RFC 3261 определены запросы 6 типов: REGISTER, INVITE, ACK СANCEL, BYE и OPTIONS. Сервер определяет тип принятого запроса по названию, указанному в стартовой строке. Request-URI

Request-URI указывает пользователя или услугу – адресата запроса. Элементы сети SIP могут поддерживать поля Request-URI со схемами, от-личными от «sip» и «sips», например «tel».

Версия протокола И запросы, и ответы содержат идентификатор версии SIP-протокола.

Приложения, посылающие SIP-сообщения, указывают в поле SIP-Version значение «SIP/2.0».

10

Запрос INVITE Запрос INVITE – приглашает пользователя принять участие в сеансе

связи (рис. 1.5). INVITE sip:userB@domainB.ru SIP/2.0 Via: SIP/2.0/UDP domainA.ru;branch=z9hG4bK776asdhds Max-Forwards: 70 To: User B <sip:userB@domainB.ru> From: User A <sip:userA@domainA.ru>;tag=1928301774 Call-ID: a84b4c76e66710@domainA.ru CSeq: 314159 INVITE Contact: <sip:userA@domainA.ru> Content-Type: application/sdp Content-Length: 142

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

Запрос ACK Запрос ACK подтверждает прием ответа на команду INVITE. Этим со-

общением UA вызывающего пользователя показывает, что он получил окончательный ответ на свой запрос INVITE. В запросе ACK может содер-жаться окончательное описание сессии (подробнее о назначении запроса ACK см. в разделе «Основные процедуры»).

Запрос CANCEL

Запрос CANCEL отменяет обработку ранее переданных запросов с та-кими же, как и в запросе CANCEL значениями полей Call-ID, To, From и CSeq (подробнее о назначении запроса CANCEL см. в разделе «Основные процедуры»).

Запрос BYE Сообщением BYE агент пользователя завершает соединение. Сторона,

получившая запрос BYE, должна прекратить передачу медиа-информации и передать ответ с кодом 200 (OK) (подробнее об этом см. в разделе «Ос-новные процедуры»).

Запрос REGISTER C помощью запроса REGISTER UA выполняет процедуры, связанные

с регистрацией (подробнее об этом см. в разделе «Основные процедуры»). Запрос OPTIONS

Сообщением OPTIONS вызываемый пользователь запрашивает ин-формацию о возможностях терминального оборудования вызываемого

11

пользователя. В ответ на запрос оборудование вызываемого пользователя передает требуемую информацию.

Запрос INFO После испытания протокола SIP на реальных сетях оказалось, что для

решения ряда задач вышеуказанных шести запросов недостаточно. Поэто-му организацией IETF вводятся новые сообщения протокола. Ими являют-ся: INFO, PRACK, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE.

Запрос INFO предназначен для обмена сигнальной информацией по сигнальному тракту SIP при установлении и поддержании соединения. За-прос INFO не изменяет состояния SIP-вызовов, так же как не изменяет со-стояния сессий, инициированных при помощи протокола SIP. Однако он обеспечивает передачу дополнительной информации прикладного уровня, которая в дальнейшем может способствовать более производительному функционированию приложений, использующих протокол SIP для достав-ки этой информации. В ходе сессии информация может быть передана или в заголовке сообщения INFO, или в части тела сообщения. В случае успеха UAS должен послать ответ на сообщение INFO с кодом 200

Запрос PRACK Предварительные ответы в SIP обеспечивают передачу информации о

текущей стадии обработки запроса, но пересылаются не надёжно. Однако в некоторых случаях, включая взаимодействие с ТфОП, необходим механизм обеспечения надёжности передачи предварительных ответов. Механизм надёжности работает по схеме, сходной с существующими механизмами надёжности для окончательных ответов 2хх на запрос INVITE. Надёжные предварительные ответы повторно передаются пользователю транзакций с интервалом, возрастающим по экспоненте. Повторные передачи прекра-щаются, когда принимается сообщение PRACK. Запрос PRACK играет ту же роль, что и ACK, но для предварительных ответов.

Запрос UPDATE Часто возникают случаи, когда необходимо изменить некоторые пара-

метры сессии до приема окончательного ответа на INVITE. После установ-ления диалога, уже подтверждённого или находящегося на ранней стадии, вызывающая сторона может создать запрос UPDATE, который содержит информацию offer (предложение с описанием сеанса связи в формате SDP), предназначенную для обновления параметров сессии. Ответ на этот запрос переносит информацию answer (ответ на предложение с указанием приня-тых параметров – тоже в формате SDP). Подобным образом, после уста-новления диалога вызываемая сторона может послать запрос UPDATE с информацией offer, а вызывающая сторона поместит answer в ответ 2хх на UPDATE.

12

Запросы SUBSCRIBE и NOTIFY Запрос SUBSCRIBE используется для запроса информации о текущем

состоянии и информации об обновлениях состояния удалённого узла. За-прос должен быть подтверждён окончательным ответом. Если уведомитель способен незамедлительно установить, что он поддерживает функцию из-вещения о событиях определённого типа (event package), то он создаёт подписку (в случае необходимости диалога) и передает ответ 2хх. После того как подписка была успешно создана или обновлена, уведомитель дол-жен незамедлительно послать сообщение NOTIFY, чтобы сообщить под-писчику текущее состояние ресурса. Когда происходит изменение в со-стоянии, на контроль которого была открыта подписка, подписчику также направляется запрос NOTIFY. После того как подписчик примет уведомле-ние, он должен передать ответ с кодом 200 (OK), как это показано на рис. 1.6.

SUBSCRIBE (1)

200 OK (2)

200 OK (4)

200 (OK) (6)

NOTIFY(5)

UA подписчика UA уведомителя

NOTIFY (3)

Рис. 1.6. Процедура подписки на предоставление информации

Запрос REFER Запрос REFER предписывает получателю связаться с третьей сторо-

ной, используя контактную информацию, которая содержится в сообще-нии. Такой механизм может быть использован для многих целей, включая переадресацию вызова (Call Transfer). В запрос REFER включается заголо-вок Refer-To, содержащий адрес третьей стороны. Если запрос принят, сер-вер UA должен передать ответ с кодом 202 (Accepted). Вслед за этим UA получателя создаёт подписку (рис. 1.7).

13

REFER (1)

202 Accepted (2)

200 OK (4)

200 (OK) (6)

NOTIFY(5)

Agent A Agent B

Agent C

NOTIFY (3)

Рис. 1.7. Процедура переадресации вызова

Подписка, создаваемая запросом REFER, по своей сути является такой же, как подписка, создаваемая запросом SUBSCRIBE. REFER – это только механизм, который создаёт подписку на контроль события переадресации вызова – «refer». Создание подписки влечёт за собой отправку запроса NOTIFY. Механизм отправки сообщений NOTIFY используется для изве-щения UA, передавшего REFER, о статусе переадресованного вызова. NOTIFY содержит тело сообщения типа message/sipfrag, содержащее ис-черпывающую информацию о состоянии переадресуемого вызова. Запрос NOTIFY может быть создан всякий раз, когда появляется новая информа-ция о последовательности событий переадресации вызова.

Запрос MESSAGE Интерактивный обмен текстовыми сообщениями (Instant Messaging)

происходит между общающимися пользователями в режиме, близком к ре-альному времени. В SIP запрос типа MESSAGE предназначен для передачи мгновенных текстовых сообщений. Тело сообщения включает в себя тек-стовое сообщение, которое необходимо доставить. Получив запрос, UA по-лучателя перейдёт к его обработке и в случае успеха отправит окончатель-ный ответ с кодом 200 (OK). Это означает, что текстовое сообщение дос-тавлено пользователю, но не указывает на то, что пользователь с ним озна-комился. Назначение и формат ответов на запросы

Ответы содержат те же значения заголовков To, From, Call-ID, Cseq и параметра «branch» в заголовке Via, что и в запросе, на который они были отправлены, что позволяет коррелировать ответ с посланным запросом.

Стартовая строка Status-Line Характерное отличие SIP-ответов от запросов – это наличие строки

состояния Status-Line в стартовой строке (рис. 1.8). Status-Line составляют: идентификатор версии протокола и код ответа (Status-Code) со связанной с

14

ним текстовой расшифровкой (Reason-Phrase), разделённые пробелом. Символы возврата каретки (СR) и перевода строки (LF) могут использо-ваться только совместно в завершающей строку последовательности CRLF.

Версия протокола Пробел Status-

Сode Пробел Reason-Phrase СRLF

Рис. 1.8. Строка ответа Status-Line

Код ответа – это целое трёхзначное число, отражающее результат об-работки запроса сервером. Reason-Phrase даёт краткое описание статус-кода и предназначена для визуального восприятия пользователем в отличие от Status-Code, который служит для оповещения технических устройств. К формулировке Reason-Phrase не предъявляется жестких требований: фир-мы-производители вправе выбрать любой текст на произвольном нацио-нальном языке, указанном в поле заголовка Accept-Language запроса.

Первая цифра статус-кода определяет класс ответа. Оставшиеся две цифры носят дополнительный характер и служат для упорядочения кодов в пределах категории. Определено шесть классов ответов, которые несут различную функциональную нагрузку. Все ответы делятся на два типа: ин-формационные и окончательные. Информационные ответы показывают, что запрос находится в стадии обработки. Окончательные ответы означают завершение обработки запроса, а каждый из них в отдельности – результат обработки запроса. Значение каждого ответа подробно описано в [1].

Информационные или предварительные ответы (1xx) Информационные или предварительные ответы (табл. 1.1) содержат

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

Таблица 1.1 Некоторые информационные ответы

Код Значение 100 Trying. Запрос обрабатывается. Например, сервер обращается к базе

данных, но местонахождение вызываемого пользователя в настоящий момент не определено

180 Ringing. Местонахождение вызываемого пользователя определено. Вы-зываемый пользователь получает сигнал о входящем вызове от своего UA

183 Session Progress. Этот ответ используется для того, чтобы заранее полу-чить от шлюзов, стоящих на пути к вызываемому пользователю, описа-ние сессии (SDP-описание) для проключения разговорного тракта в предответном состоянии (например, речевые подсказки при связи с Call-центром)

15

Ответы об успешной обработке запроса (2xx) Ответы 2хх (табл. 1.2) означают, что запрос был успешно обработан.

Таблица 1.2 Ответы об успешной обработке запроса

Код Значение 200 OK. Запрос успешно выполнен 202 Accepted. Запрос принят для обработки, но она еще не завершена. Неиз-

вестно, будет ли выполнен запрос, поскольку после завершения обра-ботки он может быть отклонён

Ответы переадресации вызова (3xx) Ответы 3хх (табл. 1.3) информируют оборудование вызывающего

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

Таблица 1.3 Некоторые ответы переадресации вызова

Код Значение 300 Multiple Choices. Вызываемый пользователь доступен по нескольким

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

302 Moved Temporarily. Вызываемый пользователь временно изменил свое местонахождение и может быть найден по адресу, указанному в заго-ловке Contact ответа

Ответы при ошибке в запросе (4xx) Ответы 4хх (табл. 1.4) информируют пользователя о том, что в запросе

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

Таблица 1.4 Некоторые ответы «Ошибка в запросе»

Код Значение 400 Bad Request. В запросе обнаружена синтаксическая ошибка 401 Unauthorized. Запрос требует проведения процедуры ауторизации поль-

зователя 404 Not Found. Вызываемый пользователь не обнаружен. Сервер не обна-

ружил вызываемого пользователя в домене, указанном в поле Request-URI

407 Proxy Authentication Required. Перед вызовом вам требуется пройти процедуру аутентификации

480 Temporarily Unavailable. Соединение с оконечным терминалом установ-лено успешно, но пользователь в данное время не доступен (например, находится вне системы или находится в системе, но в состоянии, пре-пятствующем связи с ним, или активизировал опцию «Не беспокоить»)

481 Call/Transaction Does Not Exist. Сервер получил запрос, не относящийся к текущему диалогу или транзакции. Запрос отбрасывается

16

Код Значение 486 Busy Here. Вызываемый пользователь в данный момент либо не желает,

либо не имеет возможности принять еще один вызов в дополнение к уже принятым

487 Request Terminated. Запрос был сброшен сообщением BYE или CANCEL

Ответы об отказе сервера (5xx) Ответы 5хх (табл. 1.5) информируют, что запрос не может быть обра-

ботан из-за отказа сервера. Таблица 1.5

Некоторые ответы «Отказ сервера» Код Значение

500 Server Internal Error. Внутренняя ошибка сервера 501 Not Implemented. Сервер не может обслужить запрос, потому что в сер-

вере не реализованы соответствующие функции 503 Service Unavailable. Обслуживание временно невозможно вследствие

перегрузки или из-за проведения технического обслуживания

Ответы о полной невозможности установить соединение (6xx) Ответы 6хх (табл. 1.6) информируют, что передаваемый пользовате-

лем запрос не может быть обслужен ни одним сервером. Соединение с вы-зываемым пользователем установить невозможно.

Таблица 1.6 Ответы о полной невозможности установить соединение

КОД Значение 600 Busy Everywhere. Вызываемый пользователь занят и в данный момент

не желает принимать вызов 603 Decline. Вызываемый пользователь не может или не желает принять

входящий вызов, не указывая причину отказа 604 Does Not Exist Anywhere. Вызываемый пользователь не существует 606 Not Acceptable. Соединение с сервером было установлено, но отдельные

элементы описания сеанса связи, такие как тип запрашиваемой инфор-мации, полоса пропускания, вид адресации не допустимы

Заголовки сообщений В заголовках содержится информация, необходимая для корректной

обработки сообщений. Заголовок Via

Содержит адрес, на который пользователь, отправивший запрос, ожи-дает получить ответы. Он содержит также параметр «branch», идентифици-рующий транзакцию. Прокси-сервер при передаче запроса добавляет в него заголовок Via, содержащий свой собственный адрес. При передаче ответов на запрос прокси-сервер использует значение в заголовке Via для того, что-бы определить, куда посылать ответ, и удаляет свой собственный адрес, находящийся на первом месте.

17

Заголовок To Указывает желаемого логического получателя запроса, или общеизве-

стный адрес получателя, или адрес ресурса. Запросы вне диалога не долж-ны содержать параметра «tag» в поле To.

Заголовок From Содержит логический идентификатор инициатора сообщения, воз-

можно, общеизвестный адрес вызывающего пользователя. Поле From должно содержать новый параметр «tag», выбранный клиентом UA.

Заголовок Call-ID Cодержит уникальный идентификатор вызова, представляющий собой

сочетание строки со случайным значением и имя или IP-адрес узла, на ко-тором установлено SIP-приложение. Комбинация «tag» заголовка To, «tag» заголовка From и Call-ID полностью описывает отношения между равно-правными SIP-элементами пользователей A и B и определяет диалог.

Заголовок CSeq Cодержит порядковый номер и указание типа запроса. Порядковый

номер увеличивается на единицу для каждого нового запроса в диалоге. Заголовок Contact

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

Заголовок Max-Forwards Cлужит для ограничения числа пересылок, которые может пройти за-

прос на пути к месту назначения. Заголовок Content-Type

Заголовок Content-Type содержит сведения о типе тела сообщения. Заголовок Content-Length

Заголовок Content-Length указывает длину тела сообщения в байтах.

1.5. Основные процедуры Регистрация

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

Впоследствии информацией, сохранённой на сервере определения ме-стонахождения, пользуется прокси-сервер, ответственный за доставку за-

18

просов в этот домен. Запросы REGISTER добавляют, удаляют и изменяют связки в базе данных сервера определения местонахождения. Регистрация может также быть произведена независимой третьей авторизованной сто-роной. Ответ класса 2хх на REGISTER содержит заголовок Contact со спи-ском всех текущих контактных адресов, поставленных в соответствие об-щеизвестному адресу.

Формат запроса Register:

Поле Request-URI сообщает имя домена определения местонахождения, для которого предназначена регистрация. Пользовательская часть и «@» SIP-адреса не должны присутствовать в поле Request-URI. Заголовок To указывает тот общеизвестный адрес, в отношении которого проводится процедура регистрации. Заголовок From содержит общеизвестный адрес отправителя запроса; совпадает с заголовком To, кроме случая, когда реги-страция производится третьей стороной. Запрос REGISTER может вклю-чать в себя заголовок Contact, содержащий ноль и более контактных адре-сов. Параметр «expires» заголовка определяет время действия связки URI пользователя-адрес его местонахождения, непонятные значения параметра должны заменяться величиной 3600.

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

Инициирование сессии

Когда клиент агента пользователя желает установить сеанс связи (ау-дио или видео), он формирует запрос INVITE. INVITE – запрос сервера для установления сеанса связи. Он пересылается прокси-серверами и, в конеч-ном счёте, приходит на один или несколько UAS, которые могут принять предложение клиента. По истечении некоторого времени UAS может при-нять предложение путём передачи ответа 2xx (OK), после чего сеанс связи считается установленным. Если предложение не принято, посылаются от-веты с кодами 3xx, 4xx, 5xx или 6xx в зависимости от причины отказа. Пе-ред отправкой окончательного ответа UAS может также передать предва-рительные ответы (1хх) для того, чтобы уведомлять UAC о состоянии об-работки вызова вызываемой стороной.

Формирование начального запроса INVITE происходит вне диалога с использованием стандартных процедур. UAC может добавить в запрос INVITE тело сообщения. Существуют отдельные правила для тел, содер-жащих описание сеанса связи, – их заголовок Content-Disposition имеет значение session. Протокол SIP использует модель типа «запрос/ответ» (offer/answer), где один UA посылает предложение – запрос с описанием сеанса. Запрос предлагает желаемые средства общения (аудио, видео), их параметры (такие как типы кодека) и адреса для получения медиа-

19

информации от отвечающей стороны. Другой UA отвечает своим описани-ем сеанса, указывающим, какие средства общения приняты, параметры, применяемые к ним, и адреса для получения медиа-информации от ини-циатора запроса. Обмен offer/answer происходит в контексте диалога, по-этому когда посылка запроса INVITE приводит к созданию нескольких диалогов, обмен происходит отдельно для каждого.

Как правило, определяют два вида обмена для агентов пользователя: Offer в запросе INVITE, answer в ответе 2хх (и, возможно, в ответе 1хх с тем же значением). Offer в ответе 2хх, answer в подтверждении ACK.

После создания запроса INVITE UAC отправляет его, следуя процеду-рам, определённым для отправки запросов вне диалога. Это приводит к формированию клиентской транзакции, которая, в конечном счёте, отправ-ляет запрос и доставляет ответы для клиента.

До получения окончательного ответа может прийти любое число предварительных ответов класса 1хх.

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

На запрос INVITE могут быть получены окончательные ответы класса, отличного от 2хх. Ответы класса 4xx, 5xx и 6xx могут содержать в поле за-головка Contact значение, указывающее местонахождение дополнительной информации об ошибке. При получении окончательного ответа класса, от-личного от 2хх, все диалоги, находящиеся на «ранней стадии», разрушают-ся.

Получение любого окончательного ответа на запрос INVITE необхо-димо подтвердить отправкой запроса ACK.

Модификации сессии

Успешный запрос INVITE устанавливает диалог между двумя агента-ми пользователя и сессию, используя модель offer/answer. Модификация сессии может затрагивать изменение адресов или портов, добавление или удаление медиапотока и т.д. Это выполняется путём отправки запроса INVITE в том же диалоге, который установил сеанс связи. Запрос INVITE, отправленный в существующем диалоге, называется re-INVITE. Одно со-общение re-INVITE может одновременно модифицировать и диалог, и па-раметры сессии. Модифицировать сессию способен как вызывающий, так и вызываемый пользователь. Одним из вариантов применения этого запроса является постановка абонента на удержание. Для этого используется запрос re-INVITE, содержащий в SDP-описании сессии параметр sendonly, для снятия с удержания также отправляется запрос re-INVITE, содержащий в теле сообщения параметр sendrecv.

20

Разрушение сессии Когда сессия инициируется сообщением INVITE, каждый ответ 1хх

или 2хх отдельного UAS создаёт диалог, и если ответ завершает обмен offer/answer, создаёт сессию. В итоге, каждая сессия связывается с одним диалогом. Если на начальный запрос INVITE придёт окончательный ответ не 2хх, он разрушит все сессии и диалоги (если они существовали), создан-ные посредством ответов на запрос. Завершая транзакцию, окончательный ответ не 2хх предотвращает также создание сессий как результата отправки запроса INVITE.

Для намеренного завершения сессий используется запрос BYE. Когда участнику диалога приходит сообщение BYE, все сессии, связанные с дан-ным диалогом, должны быть разрушены. UA вызывавшего пользователя может послать BYE как в установленном диалоге, так и в диалогах, нахо-дящихся на «ранней стадии», а UA вызванного пользователя может отпра-вить BYE только в установленном диалоге. UA вызванного пользователя не должен отправлять BYE до тех пор, пока не получит подтверждения ACK получения своего ответа класса 2хх. Отмена запроса

Запрос CANCEL, согласно его названию, служит для отмены пред-шествующего запроса, отправленного клиентом. Точнее, он запрашивает UAS прекратить обработку запроса и создать ответ на него с определённым кодом. Запрос CANCEL не оказывает воздействия на запрос, на который UAS уже дал окончательный ответ. Поэтому отмена запросов представляет наибольшую важность для запросов, формирование ответов на которые требует больших затрат серверного времени. По этой причине CANCEL лучше всего подходит для отмены запросов INVITE, которые требуют большого времени для генерации ответа.

1.6. Базовый вызов

Диаграмма (рис. 1.9) представляет типичный пример обмена SIP-сообщениями между двумя пользователями User A и User B. В этом приме-ре User A использует SIP-приложение на своём ПК (называемое англоя-зычным термином «softphone») для вызова User B через сеть Интернет; при этом User B принимает вызов на свой SIP-телефон. Два прокси-сервера SIP, изображённых на рисунке, действуют от имени пользователей, выполняя функции посредника при установлении сессии.

21

Рис. 1.9. Взаимодействие элементов сети по протоколу SIP

Поскольку softphone пользователя A не располагает сведениями о ме-

стонахождении пользователя B, он посылает запрос INVITE SIP-серверу, обслуживающему домен пользователя A, domainA.ru. Адрес SIP-сервера domainA.ru, может быть занесён в конфигурацию SIP-приложения пользо-вателя A. Прокси-сервер получает запрос INVITE и посылает обратно SIP-приложению пользователя A ответ с кодом 100 (Trying). Этот ответ инфор-мирует пользователя A о том, что запрос INVITE был получен и прокси-сервер выполняет маршрутизацию запроса к месту назначения.

Такой ответ содержит те же значения заголовков To, From, Call-ID, Cseq и параметра «branch» в заголовке Via, что и запрос INVITE, и это по-зволяет коррелировать ответ с отправленным запросом. Прокси-сервер domainA.ru определяет местонахождение прокси-сервера в домене domainB.ru и пересылает ему запрос INVITE. Перед пересылкой прокси-сервер добавляет дополнительное значение заголовка Via, которое содер-жит его собственный адрес (INVITE уже содержит адрес пользователя A в первом значении заголовка Via). Прокси-сервер domainB.ru получает INVITE и передаёт обратно ответ с кодом 100 (Trying), указывающий про-

22

кси-серверу domainA.ru, что он получил запрос INVITE и занимается его обработкой. Прокси-сервер обращается к базе данных, обычно называемой сервером определения местонахождения (location server), которая содержит текущий IP-адрес пользователя B. Прокси-сервер добавляет значение заго-ловка Via со своим адресом в запрос INVITE и пересылает его к SIP-телефону пользователя B.

SIP-телефон пользователя B получает INVITE и отправляет ответ 100 (Trying). При оповещении пользователя о входящем вызове SIP-телефон В информирует об этом SIP-телефон А с помощью ответа с кодом 180 (Ringing), который маршрутизируется обратно через два прокси-сервера.

В приведённом примере User B решает ответить на вызов. Когда он поднимает трубку, его SIP-телефон посылает ответ с кодом 200 (OK), ука-зывающий, что вызов принят. Ответ с кодом 200 (OK) содержит тело со-общения с вариантом SDP-описания сессии, которую желает установить User B с User A. В заголовок To добавляется параметр «tag» – он будет ис-пользоваться во всех следующих запросах и ответах данного сеанса связи. Заголовок Contact содержит URI, который характеризует текущее местона-хождение User B. Заголовки Content-Type и Content-Length указывают тип и длину тела сообщения (SDP-описание сессии пользователя B).

При получении ответа с кодом 200 SIP-телефон пользователя A пре-кращает подачу сигнала КПВ и сообщает о том, что вызываемый пользова-тель принял вызов. В итоге, SIP-приложение User A посылает сообщение подтверждения ACK для того, чтобы подтвердить принятие окончательно го ответа 200 (OK).Это подтверждение завершает трехэтапное согласова-ние INVITE/200/ACK, используемое для установления SIP-сессии. Медиа-сессия между User A и User B теперь считается установленной, и они пере-дают пакеты с речевой информацией, используя формат, принятый при об-мене SDP. В общем случае, передающиеся по сквозному принципу речевые пакеты транспортируются по маршруту, отличному от пути следования сигнальных сообщений SIP.

В конце сеанса связи User B первым кладет трубку – при этом создаёт-ся сообщение BYE. User A подтверждает получение BYE посылкой ответа с кодом 200 (OK), который завершает BYE-транзакцию и сессию. Под-тверждение ACK не посылается – оно используется только для подтвер-ждения ответов на запрос INVITE.

В данном примере прокси-серверы, через которые проходит сигналь-ный тракт SIP, «видят» сообщения, передающиеся между оконечными точ-ками на протяжении всей сессии. Для этого прокси-сервер добавил в запрос INVITE требуемый маршрутизирующий заголовок, называемый Record-Route и содержащий URI (имя узла или IP-адрес) прокси-сервера. Эта ин-формация была получена и SIP-телефоном User B, и (из-за того, что заголо-вок Record-Route передаётся обратно в ответе с кодом 200OK) SIP-телефоном A и была сохранена на время диалога. Каждый прокси-сервер

23

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

1.7. Тестирование протокола сигнализации SIP

Основные принципы Полномасштабное тестирование протокола SIP включает в себя тести-

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

Основными задачами поддержки всего набора протоколов сигнализа-ции Единой сети электросвязи страны (ЕСЭ РФ) является создание точных, формальных и верифицируемых спецификаций протоколов, а также стро-гое соответствие этим спецификациям как самого телекоммуникационного оборудования, так и проверяющих его тестеров протоколов сигнализации. Тестовые сценарии

Для проведения проверки алгоритма работы сигнализации осуществ-ляют ряд необходимых сценариев, подобных тем, что были представлены выше. Тестовые сценарии разделяют на: нормальные («корректного» пове-дения) и ошибочные («некорректного» поведения).

Тестирование реализации протокола SIP рассматривается в следую-щих элементах сети SIP, определенных в стандарте RFC 3261:

◦ агент пользователя – Клиент ◦ агент пользователя –Сервер ◦ прокси-сервер ◦ сервер регистрации (Registrar) Приведем пример тестовых сценариев сигнализации SIP для клиента

агента пользователя. А. Тесты нормального режима: � комплексный тест. Запрос установления соединения; обязательные

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

� получение извещения о начале обработки запроса установления соединения;

� получение ответа об успешном проключении соединения. Кон-троль корректности запроса ACK;

24

� получение ответа о временном отсутствии пользователя по указан-ному адресу;

� начало обработки запроса изменения параметров сессии; � разрушение соединения. Контроль верного указания имени запроса

разрушения соединения; � получение подтверждения разрушения соединения. Б. Тесты ошибочного режима

○ получение запроса разрушения соединения для несуществующей сес-сии. Протокол-тестер SNT

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

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

тирования взаимодействия и наблюдения одновременной работы несколь-ких протоколов сигнализации.

Всеми этими функциональными возможностями в полной мере обла-дают протокол-тестеры отечественной платформы SNT, в частности порта-тивный вариант SNTlite, ставший стандартом де факто для ЕСЭ страны (рис. 1.10).

25

Рис. 1.10. Протокол-тестер SNTlite

Для задач настоящего учебного пособия SNTlite используется также в

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

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

1.8. Реализация SIP в лабораторном оборудовании NGN

Конвергенция сетей связи и переход к сетям следующего поколения NGN (Next Generation Network) обуславливают необходимость того, чтобы кафедры ИТ-вузов использовали в учебном процессе лабораторные базы NGN, позволяющие изучить реализацию основного протокола сетей NGN – протокола SIP. Одним из примеров такой лабораторной базы является ор-ганизованная на кафедре систем коммутации и распределения информации СПбГУТ им. проф. М.А. Бонч - Бруевича учебно-исследова-тельская лабо-ратория «Систем коммутации NGN», созданная совместно с научно-техническим центром «Протей» для полноценного теоретического и прак-тического преподавания таких направлений развития инфокоммуникаций, как IP-телефония, мультисервисный абонентский доступ, интеллектуаль-ные сети и инфокоммуникационные услуги, концепция Softswitch и, нако-нец, организация сетей связи следующего поколения NGN в целом.

Представленная на рис. 1.11 лабораторная установка систем коммута-ции NGN на основе протокола сигнализации SIP позволяет проводить практические занятия по темам курсов IP-телефонии, по предоставлению информационных услуг средствами IP-контакт-центров, обеспечение муль-тисервисного доступа к NGN, предоставление интеллектуальных услуг в сетях нового поколения.

26

В состав представленной на рис. 1.11 структуры сети лаборатории входит мультисервисный коммутатор доступа (МКД), представляющий со-бой Softswitch класса 5 и предназначенный для предоставления услуг связи в местных телефонных сетях. На его базе возможно также создание корпо-ративных ведомственных сетей и организация связи в офисах. МКД вы-полняет функции программного коммутатора в мультисервисной сети свя-зи, т.е. маршрутизирует VoIP-вызовы в сетях с коммутацией IP-пакетов.

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

IPПротей-МАК

концентратор абонентского

доступа

ТА 1

ТА 2

ТА 3

ТА n

Протей-IP

шлюзVoIP

Call-центрПротей-РВ

SoftswitchПротей-МКД

РМ 1 РМ 2 РМ n

Схема учебно-исследовательской лабораториисистем коммутации NGN кафедры СКиРИ

ISDN PRI

ISDN PRI Ethernet 100 Мб/c

Ethernet 100 Мб/c

Ethernet 100 Мб/c

Ethernet 100 Мб/cаналоговая

линия

аналоговая линия

ISDN BRINT

IAD-ASHDSL

Рис. 1.11. Структура сети лаборатории систем коммутации NGN

Технологии доступа, на которых основаны концентраторы iМАК, по-

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

Другой комплекс Протей-РВ, входящий в состав лаборатории систем коммутации NGN, представляет собой многофункциональный центр об-служивания вызовов (ЦОВ), реализованный на базе протокола SIP и но-вейших программно-аппаратных средств и IP-технологий. На практике Протей-РВ предназначен для оснащения справочных, заказных и экстрен-ных служб разного вида и назначения. Кроме высокоэффективной обработ-ки традиционных вызовов комплекс позволяет принимать и обслуживать

27

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

Наконец, Протей-IP – это шлюз IP-телефонии, как входящий в состав iМАК и Протей-РВ, так и позволяющий отдельно от остальных систем проводить практические занятия по курсу IP-телефонии. Кроме того, лабо-ратория NGN должна быть оснащена разнообразным терминальным обору-дованием.

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

1) Каковы основные элементы сети SIP? 2) Каковы основные достоинства протокола SIP по отношению к более

ранним протоколам IP-телефонии? 3) В чем заключается принцип транзакции? 4) Для чего используется идентификатор SIP URI? 5) Какова структура сообщения протокола SIP? 6) Какие сообщения используются элементами сети SIP для обслу-

живания базового вызова?

28

2. ИНТЕРАКТИВНЫЙ ЛАБОРАТОРНО-УЧЕБНЫЙ КОМ-ПЛЕКС ТЕЛЕКОММУНИКАЦИОННЫХ ТЕХНОЛОГИЙ И ПРОТО-

КОЛОВ «СОТСБИ-У»

2.1. Принципы построения Бурное развитие самых разнообразных, взаимодействующих между

собой технологий и протоколов в современном мире телекоммуникаций делает весьма актуальной задачу подготовки и переподготовки квалифици-рованных кадров, владеющих всеми этими новыми и существующими ин-фокоммуникационными технологиями. Столь трудновыполнимая задача несколько упрощается благодаря появившимся в самое последнее время новейшим мультимедийным интерактивным методам и средствам обуче-ния, одним из которых является комплекс СОТСБИ-У.

Интерактивный лабораторно-учебный комплекс СОТСБИ-У базирует-ся на принципе Peer-to-Peer Education (P2PE) и позволяет адаптировать процесс обучения к каждому студенту.

Дополнительный синергетический эффект дают интегрируемые в ком-плекс СОТСБИ-У вышеупомянутый протокол-тестер (рис. 1.9) и лабора-торное оборудование, уже имеющееся в распоряжении кафедры, в том чис-ле АТС, УПАТС, ЦОВ и т.п. Это достигается за счет гибкости настройки программной платформы СОТСБИ-У, возможности дополнительного мо-делирования построенных на ее базе теоретических курсов и лабораторных работ, а также за счет заложенной концепции использования протокол-тестера (например, тестер SNTlite), обеспечивающего мониторинг, симуля-цию вызовов и моделирование различных ситуаций. Именно такой ком-плексный подход дает нужный эффект, апробированный как при повыше-нии квалификации уже сформировавшихся специалистов, так и при обуче-нии студентов в университете.

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

2.2. Описание Интерактивный лабораторно-учебный комплекс СОТСБИ-У включает

в себя постоянно расширяющийся набор курсов изучения систем сигнали-зации POTS, протоколов ISDN, стека протоколов NGN, протоколов мо-бильных сетей связи 2G, 2.5G, 3G, протоколов VoIP и др. Программная

29

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

2.3. Этапы проведения занятий Лабораторно-учебный класс СОТСБИ-У предполагает прохождение

учащимися трех основных стадий обучения: □ стадия подготовки (изучение теоретического материала) □ стадия интерактивного обучения и программной оценки знаний

(прохождение допусков и выполнение лабораторных работ) □ эксплуатационная стадия (стадия работы непосредственно с

телекоммуникационным оборудованием). Структурная схема интерактивного лабораторно-учебного класса

СОТСБИ-У (рис. 2.1) содержит следующие элементы: � рабочие места учащихся, оборудованные ПК с установленным про-

граммным комплексом СОТСБИ-У; � рабочее место преподавателя, оборудованные ПК с установленным

программным комплексом СОТСБИ-У (версия преподавателя), а также ус-тановленной системой наблюдения за мониторами пользователей;

� принтер, с возможностью распечатки документов с рабочих мест; � сервер; � телекоммуникационное оборудование, поддерживающее протокол; � тестер телекоммуникационных протоколов с возможностью пере-

дачи трейсов протоколов и результатов тестирования на сервер и принтер.

30

Рис. 2.1. Структурная схема СОТСБИ-У для CCОП/NGN/СПС 2G, 2.5G, 3G

Описание этапов обучения Изучение теоретического материала

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

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

предлагается ответить на вопросы, предусмотренные для получения допус-ка к моделированию.

В случае успешного прохождения процедуры допуска учащийся пере-ходит к третьему этапу – моделированию. В случае, если допуск к модели-рованию не был получен, учащемуся предлагается выборка разделов тео-рии для повторного изучения, создаваемая специальной программой СОТСБИ-У на основе анализа ошибочных ответов. После повторного изу-

31

чения предложенного материала учащийся может снова приступить к тес-тированию.

Цикл заданий моделирования Учащемуся предлагается выполнить ряд заданий моделирования для

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

Анализ уровня знаний учащихся подсистемой статистики При выполнении лабораторных работ на каждом рабочем месте учаще-

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

Отчетность При выполнении лабораторных работ формируются отчеты в элек-

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

Дистанционный контроль процесса обучения В процессе изучения теоретического материала, тестирования и моде-

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

Работа с телекоммуникационным оборудованием Учащийся выполняет блок заданий, работая на реальном оборудова-

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

При успешном прохождении текущего этапа учащийся может перехо-дить к следующему этапу обучения.

32

Работа с теоретическим материалом Все основные аспекты теории изложены в программной части ком-

плекса СОТСБИ-У в виде анимированных слайдов с необходимым пояс-няющим текстом, предназначенных для просмотра на экране монитора. Кроме того, теоретический материал представлен в краткой форме в разд. 1. Детально с работой протоколов можно ознакомиться, обратившись к ос-новной [1] и дополнительной [2] литературе. Для достижения наиболее эф-фективных результатов обучения рекомендуется комплексное использова-ние как материала, содержащегося в СОТСБИ-У, так и указанных в конце пособия книг по телекоммуникационным протоколам.

Аппаратно- программные средства СОТСБИ-У

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

В комплекс СОТСБИ-У входит набор интерактивных электронных курсов обучения с обратной связью, предназначенных для получения базо-вых знаний по протоколам сигнализации и новым инфокоммуникационным технологиям в рамках ряда теоретических и практических программ подго-товки специалистов (инженеров), бакалавров и магистров по разным спе-циальностям направления «Телекоммуникации», по смежным направлени-ям системы высшего образования, а также по программам телекоммуника-ционных университетов для факультетов повышения квалификации.

Клиент-серверная платформа СОТСБИ-У, ядро которой разработано на основе технологии Macromedia Flash, содержит материалы о современ-ных протоколах сигнализации, проверяет уровень знаний и закрепляет зна-ния при моделировании. В случае если уровень знаний низкий, программа проанализирует ошибки и подскажет, каким теоретическим вопросам сле-дует уделить дополнительное внимание.

Лабораторные работы состоят из цикла работ по моделированию, на которых изучаются форматы сигнальных сообщений и сценарии обмена. Обучающая программа накапливает статистические данные о каждом поль-зователе, формирует выборку разделов теории, плохо изученных пользова-телем, и обеспечивает доступ к глоссарию, что дает возможность быстро и без пробелов получить необходимые знания. Представляемая информация основана на международных рекомендациях и национальных специфика-циях, изложенных в книгах серии «Телекоммуникационные протоколы»[1].

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

33

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

При разработке курса обучения был проведен анализ существующих на современном рынке электронных образовательных программ. В резуль-тате этого комплекс СОТСБИ-У вобрал в себя все положительные черты существующей на сегодняшний день успешной практики создания учебных программ. Это помогло также избежать при проектировании комплекса не-достатков, характерных для лабораторных практикумов такого рода, среди которых закрытость архитектуры комплекса, узкая специализация, негиб-кость, невозможность создавать собственные сценарии моделирования и т.п. Удалось избежать этого благодаря использованию в СОТСБИ-У мо-дульной структуры, позволяющей расширять возможности обучающей программы, а также механизма создания собственных сценариев и новых теоретических курсов на основе технологии Flash Macromedia.

Для преодоления другого недостатка – преимущественно демонстра-ционного характера большинства образовательных программ – введена уже упоминавшаяся интерактивность комплекса. Благодаря этому СОТСБИ-У не только предоставляет материал для изучения, но и позволяет проверять знания учащихся в области функционирования протоколов систем сигнали-зации путем моделирования ими определенных сценариев. Упомянутая возможность создания множества новых заданий моделирования позволяет адаптировать подготовку для разнообразной дальнейшей работы с обору-дованием в ходе практических занятий. Работа с телекоммуникационным оборудованием

После выполнения программных моделирования на СОТСБИ-У учащимся полезно увидеть работу изученных протоколов сигнализации на коммутационном оборудовании, имеющемся в распоряжении кафедры, и выявить особенности ее реализации для конкретных условий. В дополне-ние к этому полезна работа с протокол-тестером класса SNT (рис. 1.9) для анализа протоколов TDM-сетей и сигнализации VoIP, а также с реализаци-ей мониторинга сетевой сигнализации на основе лабораторного варианта системы СПАЙДЕР [5].

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

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

34

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

2.4. Особенности ИТ-образования на базе СОТСБИ-У Использование лабораторной установки СОТСБИ-У может макси-

мально автоматизировать процесс проведения лабораторных работ и прак-тических занятий, сделать его самодостаточным, независимым от времен-ного расписания, а при необходимости – и дистанционным. Результаты ус-певаемости и дополнительная информация публикуются в специальном разделе кафедрального Web-сайта [7].

35

3. ПРОГРАММИРУЕМЫЕ ЛАБОРАТОРНЫЕ РАБОТЫ

3.1. Выполнение лабораторных работ на СОТСБИ-У Вход в программу

Для запуска программы необходимо выбрать на рабочем столе ярлык интерактивного обучающего курса «Учебный курс», после чего на экране монитора ПК появится окно «Вход в программу» (рис. 3.1).

В программе предусмотрен учет пользователей, который обеспечивает сохранение статистических данных о пользователях (например, данных о полученных допусках к моделированию и выполненных работах по моде-лированию). Поэтому учащемуся, заходящему в программу, необходимо пройти процедуру авторизации. Обычно для этого необходимо указать свои «Фамилию Имя» и последние 4 цифры № зачетной книжки.

Рис. 3.1. Окно авторизации пользователей

Необходимо заполнить поля ввода логина и пароля, под которыми

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

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

36

гина и пароля необходимо нажать кнопку «+» для добавления пользователя в бригаду. Фамилия и имя пользователя отобразятся в поле «Состав брига-ды». Кнопка «-» служит для удаления пользователя из бригады. После до-бавления всех пользователей необходимо нажать кнопку «Войти».

Главное меню

После входа в программу учащийся попадает в главное меню (рис. 3.2), интерфейс которого состоит из нескольких функциональных частей, визуально разнесенных по экрану: раскрывающееся меню (кнопки теория, тестирование, моделирование), статистика (кнопки статистика тестов, от-четов, общая), сервисные кнопки (руководство пользователя, блокнот, глоссарий), системные кнопки (развернуть и выход), кнопка «О програм-ме».

Рис. 3.2. Интерфейс главного меню

37

Раскрывающееся меню В верхней части экрана расположено раскрывающееся многоуровне-

вое меню (рис. 3.3).

Рис. 3.3. Многоуровневое меню и индикаторы кнопок При нажатии соответствующих кнопок меню «Теория», «Тестирова-

ние» или «Моделирование», учащийся может выбрать этап обучения, с ко-торым намерен работать, а при нажатии соответствующих кнопок подменю - необходимый курс обучения (POTS, ISDN, NGN и прочее).

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

На этапах «Теория» и «Тестирование» подменю дает возможность на-чать изучение с необходимой главы теоретического материала выбранного курса или пройти любой допуск к моделированию.

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

Кнопки подменю содержат индикаторы, которые дают информацию о доступности или недоступности того или иного раздела и изменяются в за-висимости от прогресса выполнения заданий (табл. 3.1).

38

Таблица 3.1 Индикаторы

Индикатор недоступности - замок, информирует о невозможности выполнения моделирования Отсутствие замка информирует о доступности со-ответствующего раздела

После получения допуска к моделированию инди-катор недоступности сменяется индикатором дос-тупности. Индикатор счетчика попыток тестирования или выполнения моделирования информирует о коли-честве использованных попыток

Индикатор прохождения допуска и выполнения моделирования информирует о том, что тестирова-ние или моделирование пройдены

При входе в блокнот, статистику, руководство пользователя, глосса-

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

Для перехода в нормальный режим просмотра достаточно нажать на окно просмотра (рис. 3.4).

39

Рис. 3.4. Окно просмотра

Сервисные кнопки

Сервисные кнопки (табл. 3.2) расположены в левой части экрана Глав-ного меню.

Таблица 3.2 Сервисные кнопки

Объект Описание Кнопка “Руководство пользователя”

дает доступ к информации о руково-дстве

Кнопка “Блокнот” позволяет обра-титься к записям пользователя.

Кнопка “Глоссарий” служит для пе-рехода в глоссарий.

РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

БЛОКНОТ

ГЛОССАРИЙ

40

Системные кнопки Справа от раскрывающегося меню находятся системные кнопки про-

граммы (табл. 3.3). Таблица 3.3

Системные кнопки

Кнопка перехода в оконный или в полноэкранный режим из главного меню

Кнопка выхода из программы из главного меню

Кнопка перехода в оконный или в полноэкранный режим из части про-граммы

Кнопка выхода из программы из части программы

Их аналоги находятся в правом верхнем углу каждой части програм-

мы («Теория», «Тестирование», «Статистика» и пр.)

Статистика Кнопки Статистика (табл. 3.4) расположены в левой части экрана

Главного меню. Таблица 3.4

Кнопки статистики Кнопки «Статистика»: тестов, от-

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

СТАТИСТИКА: ОТЧЕТОВ

ТЕСТОВ

ОБЩАЯ

41

О программе Кнопка О программе (табл. 3.5) расположена в левой части экрана

Главного меню. Таблица 3.5

Кнопка «О программе»

Кнопка “О программе” дает доступ к информации о разработчиках обу-чающей программы

Теоретический материал Интерфейс теоретической части

Изучение любого материала традиционно начинается с изучения тео-рии.

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

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

Текстовое поле расположено в нижней части экрана. Сбоку слева - по-лоса прокрутки.

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

42

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

Функциональные кнопки

Панель функциональных кнопок теории (табл. 3.6) служит для удоб-ной и быстрой навигации по теоретическому курсу:

Таблица 3.6 Функциональные кнопки

Объект Описание

Кнопка «Назад» возвращает к предыдущему слайду рас-сматриваемой главы теории

Кнопка «Вперед» служит для перехода к следующему слайду просматриваемого материала. Переход по слай-дам также может производиться с помощью клавиш на-вигации на клавиатуре

Кнопка «Блокнот» служит для перехода в блокнот из любого режима просмотра

Кнопка «Глоссарий» служит для перехода в глоссарий из любого режима просмотра

43

Кнопки «Пауза» и «Анимация» позволяют приостано-вить или продолжить анимацию слайда

При нажатии кнопки «К следующей главе» происходит переход к следующей главе теории

При нажатии кнопки «К предыдущей главе» происходит переход к предыдущей главе теории

При нажатии кнопки «Включить автоматическую смену слайдов» происходит переход к режиму автоматического воспроизведения слайдов (слайд-шоу). При нажатии кнопки «Выключить автоматическую сме-ну слайдов» происходит переход к режиму просмотра слайдов вручную

Кнопка перехода в главное меню

Рекомендации: ◦ До работы с теоретическим материалом рекомендуется изучить раз-

делы по работе с «Блокнотом» и «Глоссарием».

44

Записи пользователя – Блокнот Для ведения записей и пометок, в обучающую программу введен

блокнот (рис. 3.6), позволяющий учащемуся сохранять нужную ему ин-формацию. Пользователь может вводить текст или при помощи Ctrl+C – Ctrl+V, например, чтобы записать параметры и назначение нескольких таймеров, и не отыскивать их вновь в теоретическом материале.

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

ния существует кнопка «сохранить», а для вывода на печать — кнопка «распечатать».

Напоминанием для сохранения внесенных изменений служит статус данных: до сохранения изменений в статусе данных написано «Изменено», после сохранения - «Сохранено».

Из блокнота пользователь может вернуться к теории или главному ме-ню путем нажатия соответствующих кнопок.

Рис. 3.6. Интерфейс Блокнота

45

Тестирование Уровень изучения теоретического материала, изложенного в разд. 1, а

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

Интерфейс тестирования

Интерфейс тестирования состоит из следующих функциональных эле-ментов, визуально разнесенных по экрану (рис. 3.7): заголовок; блок зада-ния; блок ответов; блок статистики; кнопка «Проверить»/«Следующий во-прос»; кнопка «Возврат в главное меню».

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

Блок задания представляет собой вопрос, ответ на который необходи-мо выбрать из предложенных вариантов блока ответов.

Рис. 3.7. Тестирование

После выбора какого либо варианта в блоке ответов, учащийся должен нажать на кнопку «Проверить». Именно нажатие кнопки «Проверить» счи-

46

тается моментом начала прохождения тестирования, и засчитывается, как первая попытка получить допуск.

После ответа, выбранный вариант подсвечивается красным или зеле-ным цветом, в зависимости от его правильности (зеленый цвет – верный ответ, красный цвет – неверный ответ), а кнопка «Проверить» исчезает, и появляется кнопка «Следующий вопрос» (рис. 3.8), позволяющая перейти к следующему вопросу теста.

Рис. 3.8. Правильный ответ на вопрос тестирования

В нижней части экрана располагается блок статистики, отображающий общее количество вопросов и количество вопросов, с правильными и не-правильными ответами.

В правом верхнем углу находится кнопка «Переход в главное меню». Если во время прохождения тестирования пользователь захочет вер-

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

47

Рис. 3.9. Предупреждение о выходе из незавершенного задания Если во время прохождения тестирования пользователь захочет выйти

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

Рис. 3.10. Предупреждение о выходе из программы В разделе SIP предусмотрено 2 допуска: 1 — для лабораторных работ

№1 и №2, ориентирован на проверку знания общих принципов работы про-токола SIP, а также правил обмена сообщениями при организации базовых вызовов по протоколу; 2 — для лабораторной работы №3, проверка знания формата сообщений протокола. Первый допуск содержит 19 вопросов , второй – 18 вопросов.

Рекомендации: • при должном владении материалом учащийся с первого раза может

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

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

48

Результат тестирования По умолчанию для получения допуска необходимо ответить правильно

на 75% всех вопросов (данный критерий может изменяться.) После ответа на последний вопрос, в зависимости от количества пра-

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

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

Рис. 3.11. Допуск к моделированию не получен

49

Рис 3.12. Блок «Рекомендуется изучить»

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

Рекомендации: после трех неуспешных попыток получить допуск к моделированию, тестирование будет заблокировано на 10 минут, и на эк-ране высветится соответствующее сообщение.

Моделирование

Переход к моделированию Моделирование позволяет проверить и закрепить полученные уча-

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

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

Все задания моделирования делятся на изучение: • обмена сигналами (стрелочные) (рис. 3.14) • структуры пакета сигнала (блочные) (рис. 3.15)

Рекомендации: если в курсе доступно более одной работы по моделированию,

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

50

«Стрелочные» задания.

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

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

Рис. 3.14. Стрелочное моделирование (Задание выполнено неверно)

51

Блочные задания Идея «блочных» заданий состоит в корректном заполнении различных

полей в соответствии с заданием лабораторной работы. При переходе к выполнению моделирования в рабочей области появ-

ляются определенные поля, которые необходимо заполнить в соответствии с заданием лабораторной работы (рис. 3.15). После того как задание лабо-раторной работы выполнено (т.е. во все поля, которые нужно было запол-нить, помещены определенные студентом значения), пользователь должен нажать кнопку «Проверить».

Рис. 3.15.Блочное моделирование

Интерфейс моделирования

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

52

Таблица 3.7 Элементы интерфейса моделирования

Объект Описание Раскрывающееся меню элементов

В стрелочных заданиях в левой части экрана на па-нели инструментов расположено выпадающее мно-гоуровневое меню. При нажатии соответствующих кнопок меню выбирается необходимое направление передачи сигнала (например, от аб. А к аб. В, или наоборот), а при нажатии соответствующих кнопок подменю выбирается необходимое сообщение про-токола SIP При выполнении блочных заданий при нажатии со-ответствующих кнопок меню и подменю выбирает-ся необходимое значение для заполнения выбран-ного поля (например, выбираются запросы INVITE, BYE)

Рабочая область Центральную часть окна занимает рабочая область, в которой визуально отражается процесс выполне-ния лабораторной работы и результат ее проверки. В разделе SIP рабочая область представляет собой сценарий обмена сообщениями. В рабочей области студенту необходимо моделировать обмен сообще-ниями протокола SIP. При выборе типа сообщения и направления передачи в рабочей области появля-ется стрелка с названием передаваемого сообщения.В блочных заданиях рабочая область содержит оп-ределенные поля, которые студенту необходимо за-полнить в соответствии с заданием лабораторной работы. Поля, которые необходимо заполнить, при нажатии на них окрашиваются в белый цвет. Значе-ния для заполнения полей либо выбираются из мно-гоуровневого меню, либо вводятся с клавиатуры (если значение вводится с клавиатуры, при нажатии на поле, которое необходимо заполнить, в нем по-является курсор). Для того чтобы ввести значение в определенное поле, его необходимо предварительно выделить, а затем уже либо вводить значения с кла-виатуры, либо выбирать их из многоуровневого ме-ню. Если же ни одно поле не выделено, никаких изменений не произойдет.

53

Объект Описание Кнопка «Глоссарий» Кнопка «Глоссарий» служит для перехода в глосса-

рий в режиме выполнения моделирования, не пре-рываая его, но при этом возможность перехода по ссылкам в глоссарии отсутствует

Кнопка «Блокнот»

Кнопка «Блокнот» позволяет раскрыть записи пользователя во время выполнения задания по мо-делированию, не прерывая ее выполнения

Кнопка «Удалить»

Кнопка «Удалить», расположенная на панели инст-рументов, позволяет удалить выбранную в рабочей области стрелку (сигнал или сообщение передавае-мые между элементами сети). Если ни один из эле-ментов не был выбран, то удаляется нижний эле-мент.

Кнопка «Проверить»

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

Счетчик количества попыток

Максимальное число попыток выполнить одно за-дание моделирования ограничено. При каждом на-жатии кнопки «Проверить» изменяется значение счетчика количества попыток. Он расположен пра-вее и отображает общее число попыток и число по-пыток, которые уже использованы. После макси-мально разрешенного числа попыток выполнить за-дание моделирования, кнопка «Проверить» исчеза-ет, а выполнение этой работы учащийся должен бу-дет начать снова, с ее первого задания, независимо от того, в каком по счету задании работы была до-пущена ошибка. И это будет считаться второй попыткой выполнить моделирование.

Текстовое поле с заданием по моделированию

В текстовом поле поставлена задача для выполне-ния и содержатся необходимые пояснения.

ГЛОССАРИЙ

БЛОКНОТ

Проверить

Удалить

54

Объект Описание Поле с номером задания по моделированию

Указывает номер работы по моделированию и но-мер выполняемого задания

Полоса прокрутки

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

Кнопка «Возврат в главное меню»

В правом верхнем углу находится кнопка «Возврат в главное меню», которая служит для перехода в режим главного меню.

Кнопка «К следующему заданию»

После того как задание моделирования выполнено, учащийся должен нажать на кнопку «Проверить». Если задание выполнено правильно, то появляется кнопка «К следующему заданию». А при наличии в теоретическом разделе соответствующего заданию слайда, он запускается в качестве фонового ролика. После нажатия кнопки «К следующему заданию» учащийся переходит к выполнению следующего за-дания моделирования.

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

нажать кнопку «Проверить» (табл. 3.7). В результате, допущенные ошибки (если они существуют) будут отме-

чены красным цветом, и одна попытка выполнения задания будет зачтена (рис. 3.14).

55

В случае, если задание выполнено правильно, то появится кнопка «К следующему заданию». А при наличии в теоретическом разделе соответст-вующего заданию слайда, он запустится в качестве фонового ролика.

В случае, если учащимся допущены ошибки, то он имеет право на по-вторное выполнение задания моделирования.

После того как будет исчерпано максимальное число попыток выпол-нить задание (по умолчанию в программе установлено 5 попыток, однако данное число может изменяться), кнопка «Проверить» исчезнет, и в тек-стовом поле появляется уведомление, что лабораторная работа не выпол-нена.

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

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

Рис. 3.16. Предупреждение о выходе из незавершенного задания Если во время прохождения задания по моделированию пользователь

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

Рис. 3.17. Предупреждение программы о выходе из программы

Наибольшее количество заданий содержится в первой и третьей лабо-раторных работах (9 и 7 соответственно), рассчитанных на изучения прин-ципов обмена сообщениями и формирования сообщений протокола SIP. Наименьшее количество заданий (3 задания) содержит вторая лабораторная работа, рассчитанная на изучение принципов взаимодействия протокола SIP с другими системами сигнализации, однако она требует дополнитель-ных знаний по системам сигнализации ISUP и DSS.

56

Рекомендации: • курс лабораторных работ предназначен, в первую очередь, для

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

• при хорошем знании материала студенты выполняют задания дос-таточно быстро, но даже без хорошего усвоения материала есть возможность разобраться в поставленном вопросе. Часть ответа заключается в самом вопросе, часть в многоуровневом меню, часть в фоновом рисунке (ролике), часть в глоссарии и, главное, в определении места ошибки при проверке;

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

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

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

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

Работа с глоссарием В программе предусмотрен глоссарий, в котором содержатся опреде-

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

1. Из окна Главного меню; 2. Из окна просмотра теоретического материала; 3. Из окна выполнения лабораторных работ.

57

Рис. 3.18. Задание разделов глоссария

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

После этого на экране появится информация о терминах, содержащая три столбца (рис. 3.19):

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

деление этого термина . Существует возможность автоматического выбора всех разделов обу-

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

Далее можно осуществлять поиск определенных терминов обучающе-го курса по ключевому слову. Для этого необходимо ввести ключевое сло-во в поле ввода поиска (рис. 3.19) и нажать кнопку «Показать термины вы-бранных разделов» (справа от поля ввода) или сразу задать критерии поис-ка и нажать кнопку начала поиска, после чего на экран выведутся все тер-мины, содержащие ключевое слово.

58

В правой части окна глоссария расположена полоса прокрутки. Ис-пользуя кнопки и полосу прокрутки, пользователь может просматривать весь материал информационной части.

Кнопка задания разделов возвращает пользователя к окну для задания разделов глоссария (рис. 3.18).

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

Из глоссария возможен возврат к просмотру теории, заданию модели-рования или к главному меню путем нажатия соответствующих кнопок (рис. 3.19).

Рис. 3.19. Интерфейс глоссария

59

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

программы по всему курсу. При входе в программу нескольких человек, объединенных в бригаду,

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

В главном меню программы выделены три раздела статистики, обозна-ченные соответствующими кнопками: статистика тестов, статистика отче-тов, общая статистика.

Статистика тестов Для получения статистических данных необходимо: � выбрать раздел обучающего курса � выбрать номер теста Статистика тестов содержит данные о прохождении студентом

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

шие затруднение (рис. 3.20). Рис. 3.20. Статистика тестов

Для просмотра большого количества неотвеченых вопросов существу-ет полоса прокрутки, а для возможности вывода на печать – кнопка «Пе-чать».

60

Чтобы покинуть статистику необходимо воспользоваться кнопкой вы-хода в главное меню.

Статистика отчетов Статистика отчетов представляет собой отчет о работе по моделирова-

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

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

Информацию, хранящуюся в отчете, можно разделить на три блока данных: заголовок, тестирование и моделирование (рис. 3.21):

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

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

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

Чтобы покинуть статистику необходимо воспользоваться кнопкой вы-хода в главное меню.

Рис. 3.21. Статистика отчетов

61

Для просмотра функциональной схемы существует полоса прокрутки, а для возможности вывода на печать – кнопка «Печать».

Общая статистика

Общая статистика содержит данные о прохождении тестирования и мо-делирования по всем разделам обучающих курсов.

Рис. 3.22. Выбор раздела общей статистики

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

один или несколько разделов обучающего курса и нажать кнопку «Задать раздел» (рис. 3.22). После этого появится статистическая таблица (рис. 3.23), в заголовке ко-

торой выводится дата составления, группа, фамилия студента(ов).

62

Рис. 3.23. Общая статистика

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

Кнопка «Печать» и полоса прокрутки аналогичны указанным в общей статистике и отчете.

3.2. Перечень лабораторных работ Общее содержание

Курс содержит три лабораторные работы («Обмен сообщениями», «Взаимодействие с другими протоколами», «Формат сообщений») и преду-сматривает два допуска к ним. Первый допуск получается для выполнения первых двух лабораторных работ, второй – для выполнения третьей лабо-раторной работы.

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

63

Лабораторная работа 1. «Обмен сообщениями протокола SIP при обслуживании вызовов и предоставлении дополнительных услуг» Задание 1.1. Процедура регистрации Необходимо сформировать обмен сообщениями при регистрации SIP-

пользователя. Задание 1.2. Базовый вызов без участия Прокси-сервера Необходимо сформировать обмен сообщениями при обслуживании ба-

зового вызова одним SIP-терминалом другого SIP-терминала без участия прокси-сервера (Рис. 3.24).

Задание 1.3. Вызов в случае «занято» Необходимо сформировать обмен сообщениями при обслуживании ба-

зового вызова в случае, если на вызываемом терминале активизирована функция «Не беспокоить».

Задание 1.4. Отмена обработки запроса установления соединения вы-зывающей стороной

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

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

са элементом сети SIP данных о состоянии удаленного ресурса Задание 1.6. Базовый вызов c участием прокси-сервера Необходимо сформировать обмен сообщениями при обслуживании ба-

зового вызова одним SIP-терминалом другого c участием прокси-сервера.

64

Рис. 3.24. Пример выполнения второго задания ЛР1 Задание 1.7. Постановка на удержание Необходимо сформировать обмен сообщениями для процедуры поста-

новки на удержание и снятия с удержания удаленного абонента. Задание 1.8. Неуспешное установление соединения (отсутствие дан-

ных о вызываемом абоненте) Необходимо сформировать обмен сообщениями при обслуживании ба-

зового вызова в случае, если на прокси-сервере отсутствуют данные о вы-зываемом абоненте.

Задание 1.9. Переадресация вызова Необходимо сформировать обмен сообщениями для процедуры пере-

адресации вызова с одного абонента на другого. Лабораторная работа 2 «Взаимодействие протокола SIP с протоко-

лами сигнализации ССОП (ISUP, DSS)» Задание 2.1. Вызов абонентом сети SIP абонента УПАТС (протокол

EDSS-1) Необходимо сформировать обмен сообщениями при обслуживании

вызова от абонента сети SIP к абоненту сети УПАТС. Задание 2.2. Вызов абонентом ССОП (ISUP) абонента сети SIP Необходимо сформировать обмен сообщениями при обслуживании

вызова от абонента ССОП к абоненту сети SIP. Задание 2.3. Вызов абонентом сети SIP абонента ССОП (ISUP) Необходимо сформировать обмен сообщениями при обслуживании

вызова от абонента сети SIP к абоненту ССОП.

65

Лабораторная работа 3 «Формат сообщений протокола SIP. Запросы и ответы».

Задание 3.1. Общий формат сообщения протокола SIP Необходимо заполнить в правильном порядке части сообщения. Задание 3.2. Формат строки Request-line запроса Необходимо заполнить в правильном порядке части строки Request-

line запроса. Задание 3.3. Формат строки Status-line ответа Необходимо заполнить в правильном порядке части строки Status-line

ответа. Задание 3.4. Формат запроса INVITE Необходимо ответить на вопросы на основе приведенного трейса со-

общения INVITE. Задание 3.5. Формат ответа 200 OK на запрос INVITE Необходимо заполнить поля заголовков для ответа 200 OK на запрос

INVITE. Задание 3.6. Формат запроса INVITE после прохождения прокси-

сервера Необходимо заполнить поля заголовков для запроса INVITE после его

прохождения через прокси-сервер. Задание 3.7. Формат запроса REGISTER и ответа 200OK Необходимо заполнить поля заголовков для запроса REGISTER и для

ответа 200OK на этот запрос.

66

Рис. 3.25. Пример выполнения второго задания ЛР3

67

ЛИТЕРАТУРА

Основная

1. Гольдштейн Б.С., Справочник по телекоммуникационным протоколам. Протокол SIP / Гольдштейн Б.С., Зарубин А.А., Саморе-зов В.В. СПб.: «БХВ - Санкт-Петербург», 2007.

Дополнительная

1. Атцик А.А., IP-коммуникации. Методические рекомендации к ла-бораторным работам / Атцик А.А., Гольдштейн А.Б., Саморезов В.В.;СПБГУТ, СПб, 2007. 2. Гольдштейн А.Б., Softswitch / Гольдштейн А.Б., Гольдштейн Б.С. - СПб.: «БХВ - Санкт-Петербург», 2006. 3. Гольдштейн Б.С., Методические указания к лабораторным рабо-там по теме: Мониторинг сети ОКС7 / Гольдштейн Б.С., Розенцвайг И.З. - СПБГУТ, СПб, 2003.

Сайты

4. http://www.skri.sut.ru 5. http://www.niits.ru 6. http://www.sotsbi.spb.ru 7. http://www.seventest.ru

68

СОДЕРЖАНИЕ Принятые сокращения .......................................................................................3 1. Протокол сигнализации SIP..........................................................................4

1.1. Общие сведения о протоколе .................................................................4 1.2. Архитектура сети.....................................................................................4 1.3. Структура протокола...............................................................................7 1.4. Сообщения................................................................................................8 1.5. Основные процедуры ............................................................................17 1.6. Базовый вызов........................................................................................20 1.7. Тестирование протокола сигнализации SIP .......................................23 1.8. Реализация SIP в лабораторном оборудовании NGN........................25 1.9. Контрольные вопросы...........................................................................27

2. Интерактивный лабораторно-учебный комплекс телекоммуникацион-ных технологий и протоколов «СОТСБИ-У»..........................................28

2.1. Принципы построения ..........................................................................28 2.2. Описание ................................................................................................38 2.3. Этапы проведения занятий ...................................................................29 2.4. Особенности ИT-образования на базе СОТСБИ-У ...........................34

3. Лабораторные работы ..................................................................................35 3.1. Описание лабораторной установки СОТСБИ-У ................................35 3.2. Перечень лабораторных работ .............................................................62

Литература .........................................................................................................66

69

Борис Соломонович Гольдштейн Вадим Юрьевич Гойхман Дарья Николаевна Онучина

Протокол SIP

Учебное пособие

Редактор Л.А. Медведева Набор М.Ю. Кусовой

Подписано к печати … .2011 Обьем 3 уч. изд. л. Тир. .. экз. Зак. …

РИО СПбГУТ. 191186 СПб, наб. р. Мойки, 61 Отпечатано в СПбГУТ