 |
Процесс установления соединения
|
|
|
|
Практическое занятие №5
Построение сети на базе протокола SIP. Процесс установления соединения
Цель работы
Изучить элементы SIP-сети, их функции; сообщения протокола SIP и их структура; назначение запросов и ответов протокола SIP. Показать пример SIP-сети, описать в нем процесс установления соединения между терминалами.
Теоретическая часть
Протокол инициирования сеансов – Session Initiation Protocol (SIP) – является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и распределения мультимедийной информации, в основу которого заложены следующие принципы.
Масштабируемость — возможность увеличения количества клиентов при расширении сети.
Мобильность — возможность получения сервиса вне зависимости от местоположения (как например электронная почта), а каждому пользователю выдается персональный идентификатор, по которому он может быть найден.
Расширяемость протокола характеризуется возможностью дополнения протокола новыми функциями при введении новых услуг и его адаптации к работе с различными приложениями.
Интеграция в стек существующих протоколов Интернет. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF).
Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323. Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП - DSS1 и ОКС7.
Протокол SIP разрабатывался с расчетом на возможность использования любых транспортов (Х.25, Frame Relay, AAL5, IPX и др. Структура сообщений SIP не зависит от выбранной транспортной технологии, но, тем не менее, наиболее предпочтительным является использование UDP-пакетов (это позволяет повысить производительность по сравнению с использованием протокола TCP, но требует использования дополнительных механизмов проверки доставки сигнальных сообщений).
|
|
|
Так как телефония с использованием протокола SIP позволяет использовать большое количество разнообразных сервисов (помимо передачи голоса, возможна передача видео, текстовых сообщений, факсов и др.), необходим механизм обмена информацией о том, какие сервисы может использовать вызываемаявызывающая стороны. Для этой цели используется протокол SDP (Session Description Protocol) — протокол описания сессии. Данный протокол позволяет определить, какие звуковые (видео и другие) кодеки и иные возможности может использовать удаленная сторона.
Собственно сама передача голоса осуществляется благодаря использованию протокола RTP (Real-time Transport Protocol, протокол транспортировки в реальном времени). Сам протокол SIP непосредственного участия в передаче голосовых, видео и других данных не принимает, он отвечает только за установление связи (по протоколам SDP, RTP и др.), поэтому под SIP-телефонией понимается не передача голоса по протоколу SIP, а передача голоса с использованием протокола SIP. Использование протокола SIP предоставляет новые возможности установления соединений, а не непосредственной передачи голосового и других видов трафика.
Адресация. Для того чтобы вызвать кого-то, необходимо знать его адрес или хотя бы имя. В сети Интернет для нахождения хоста используется URL (определитель местонахождения), для SIP он обозначается как SIP URL. В качестве адреса в SIP выбран самый распространенный тип – адрес электронной почты. Он уже сейчас является основным адресом, не зависящим от местоположения пользователя. Существуют четыре основные формы адреса: имя@домен, имя@хост, имя@IP-адрес, №телефона-@шлюз.
|
|
|
Первая часть – это имя пользователя, зарегистрированного в домене или на рабочей станции. Если вторая часть адреса идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента.
Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP-адреса устройства необходимо обратиться к службе доменных имен - Domain Name Service (DNS). Если же во второй части SIP-адреса размещается IP-адрес, то с рабочей станцией можно связаться напрямую.
В начале SIP-адреса ставится слово, указывающее, что это именно SIP-адрес, т.к. бывают и другие. Примеры SIP-адресов: sip: [email protected]; sip: [email protected]; sip: [email protected].
Рассмотрим стандартные элементы в SIP-сети, согласно рисунку 30.
Рисунок 30 - Архитектура SIP-сети
Агент пользователя (User Agent или SIP client) является приложением терминального оборудования и включает в себя две составляющие: клиент агента пользователя (User Agent Client - UAC) и сервер агента пользователя (User Agent Server - UAS), иначе называемые клиент и сервер. Клиент UAC инициирует SIP-запросы, т. е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и отвечает на них, т. е. выступает в качестве вызываемой стороны.
Запросы могут передаваться не прямо адресату, а на некоторый промежуточный узел. Такие узлы бывают двух основных типов: прокси-сервер и сервер переадресации.
Прокси-сервер: прокси-сервер принимает запросы и производит с ним некоторые действия (например определяет местоположение клиента, производит переадресацию или перенаправление вызова и др.), и отправляет дальше на следующий сервер, который может быть как другим прокси-сервером, так и последним UAS. Таким образом, прокси-сервер принимает и отправляет запросы и клиента, и сервера. Приняв запрос от UAC, прокси-сервер действует от имени этого UAC. Существует два вида прокси-серверов: с сохранением состояний (stateful) и без сохранения состояний (stateless). Сервер первого типа хранит в памяти входящий запрос, который явился причиной генерации одного или нескольких исходящих запросов. Эти исходящие запросы сервер также запоминает. Все запросы хранятся в памяти сервера только до окончания транзакции, т. е. до получения ответов на запросы. Сервер без сохранения состояний просто ретранслирует запросы и ответы, которые получает. Он работает быстрее, чем сервер 1-го типа, так как ресурс процессора не тратится на запоминание состояний, вследствие чего сервер этого типа может обслужить большее количество пользователей. Прокси-сервер может модифицировать запросы, которые он переправляет дальше. Проще говоря, пользователь отсылает требование установить соединение на прокси-сервер, а тот сам “заботится” о том, чтобы оно было установлено. Прокси-сервер может размножать запрос и передавать его по разным направлениям, чтобы запрос достиг нескольких мест, в надежде на то, что нужный пользователь окажется в одном из них.
|
|
|
Зачастую прокси-сервер совмещают с сервером определения местоположения (Register-сервер), в таком случае его называют Registrar-сервером.
Сервер определения местоположения, или сервер регистрации (Location server, или Register): данный вид сервера служит для регистрации пользователей. Регистрация пользователя производится для определения его текущего IP-адреса, для того чтобы можно было произвести вызов user@IP-адрес. В случае если пользователь переместится в другое место и/или не имеет определенного IP-адреса, его текущий адрес можно будет определить после того, как он зарегистрируется на сервере регистрации. Таким образом, клиент останется доступен по одному и тому же SIP-адресу вне зависимости от того, где на самом деле находится.
Сервер переадресации: обращается к серверу регистрации для определения текущего IP-адреса пользователя, но в отличие от прокси-сервера только "переадресует" клиента, а не устанавливает собственные соединения.
Прокси-серверы в SIP-сети также могут вносить изменения в передаваемые сообщения — это позволяет беспрепятственно преодолевать NAT(модуль преобразования сетевых адресов) в случае если прокси-сервер стоит на NAT-маршрутизаторе (также возможна настройка прокси-сервера, находящегося за NAT в случае, если на последнем невозможно установить прокси-сервер — для этого потребуется задать параметры переадресации так, чтобы полученный прокси-сервер стал "виртуальным сервером"). Помимо этого прокси-серверы можно объединять в "цепочки", которые позволяют использовать телефонию, даже если конечная точка (UA) находится сразу за несколькими NAT-шлюзами.
|
|
|
Сообщения SIP. Структура сообщений. Согласно архитектуре “клиент-сервер” все сообщения делятся на запросы, передаваемые от клиента к серверу, и на ответы сервера клиенту.
Например, чтобы инициировать установление соединения, вызывающий пользователь должен сообщить серверу ряд параметров, в частности, адрес вызываемого пользователя, параметры информационных каналов и др. Эти параметры передаются в специальном SIP-запросе. От вызываемого пользователя к вызывающему передается ответ на запрос, также содержащий ряд параметров.
Все сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP соответствуют используемым в протоколе НТТР. Сообщения SIP-протокола имеют следующую структуру:
Стартовая строка (start-line)
Заголовки сообщения (*message-header)
Пустая строка (CRLF)
Тело сообщения.
Стартовая строка — начальная строка любого SIP-сообщения. Если сообщение является запросом, в ней указывается тип запроса, адресат и номер версии протокола: INVITE sip: [email protected] SIP/2.0
Если сообщение является ответом на запрос, в ней указывается номер версии протокола, тип ответа и его короткая расшифровка.
Заголовки сообщений содержат сведения об отправителе, адресате, пути следования и др., в общем, переносят информацию, необходимую для обслуживания данного сообщения. О типе заголовка можно узнать по его имени. Оно не зависит от регистра (т.е. буквы могут быть прописные и строчные), но обычно имя пишут с большой буквы, за которой идут строчные.
Сообщения протокола SIP могут содержать так называемое тело сообщения. Тело сообщения содержит описание сеансов связи. Не все запросы содержат тело сообщения (например, запрос BYE). Все ответы могут содержать тело сообщения, но содержимое тела в них бывает разным. В сообщениях ACK, INVITE и OPTIONS тело сообщения содержит описание сеансов связи, например, в формате протокола SDP. С ответами дело обстоит иначе: любой ответ может содержать тело сообщения, но содержимое тела в ответах разных типов бывает разным. Вся информация, необходимая для установления соединения, помещается в заголовке. Это может быть, например, адрес вызываемого и вызывающего пользователей, пройденный сообщением путь или размер тела сообщения.О заголовке и содержащейся в нем информации можно узнать по имени, которое всегда начинается с прописной буквы, далее следуют строчные. Некоторые заголовки используются во всех сообщениях, а некоторые – только в определенных случаях.
|
|
|
Существуют заголовки четырех видов:
- общие (и в запросах, и ответах);
- содержания (начинаются со слова Content и несут информацию о размере тела сообщения или об источнике, передавшем сообщение);
- запросов (дополнительная информация о запросе);
- ответов (дополнительная информация об ответе).
Заголовок содержит имя, за которым после двоеточия (:) следует поле, содержащее данные заголовка, т. е. имя:содержимое.
Примеры наиболее часто встречающихся заголовков.
Call-ID – уникальный идентификатор отдельного сеанса связи или регистрации отдельного клиента. Назначается стороной, которая инициирует вызов. Содержит буквенно-числовое значение и имя хоста, разделенное символом @: [email protected]
To – определяет получателя запроса; кроме SIP-адреса, здесь может присутствовать параметр tag для идентификации пользователя или услуги, находящихся в одном SIP URL. Если необходим визуальный вывод имени пользователя, например, на дисплей, его также можно поместить в поле То:
the director <[email protected]> tag=12345.
From – определяет отправителя запроса (по организации аналогичен полю То).
CSeq – уникальный идентификатор запроса внутри одного Call-ID; необходим, чтобы отличить, на какой запрос прошел ответ, так как иногда он может оказаться ответом на другой запрос; состоит из двух частей: натурального числа (от 1 до 232) и типа запроса.
Заголовок Via служит, для того чтобы избежать ситуации, в которых запрос пойдет по замкнутому пути, а также для тех случаев, когда необходимо, чтобы запросы и ответы обязательно проходили по одному и тому же пути. Запрос может проходить через несколько прокси-серверов, каждый из которых принимает, обрабатывает и переправляет его к следующему прокси-серверу и так до тех пор, пока запрос не попадет к адресату. Таким образом, в заголовке Via указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет в запрос поле со своим адресом. Например, запрос на своем пути обрабатывался двумя прокси-серверами: сначала сервером loniis.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля:
Via: SIP/2.0/UDP sip.telecom.com:5060
Via: SIP/2.0/UDP loniis.ru:5060
Content-Type – определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP, включается в тело сообщения.
Content-Length – показывает размер тела сообщения.
Запросы. В протоколе SIP версии 2.0 существует 6 типов запросов (тип запроса задается в стартовой строке). Каждый из них предназначен для выполнения довольно широкого круга задач, что является явным достоинством протокола SIP, так как благодаря этому число сообщений, которыми обмениваются терминалы и серверы, сведено к минимуму. С помощью запросов клиент сообщает о текущем местоположении, приглашает пользователей принять участие в сеансах связи, модифицирует уже установленные сеансы, завершает их и т.д. Сервер определяет тип принятого запроса по названию, указанному в стартовой строке. В той же строке (в поле Request-URI) указан SIP-адрес вызываемого пользователя. Описание запросов приведено ниже.
INVITE – приглашает пользователя принять участие в сеансе связи. Он обычно содержит описание сеанса связи, где указывается вид принимаемой информации и параметры (список возможных вариантов параметров), необходимые для приема информации, и может указываться вид информации, который вызываемый пользователь желает передавать. Пример SIP-запросов, рисунок 1.
В ответе на запрос INVITE указывается вид информации, которая будет приниматься или передаваться.
ACK – подтверждает прием от вызываемой стороны ответа на команду INVITE и завершает транзакцию.
OPTIONS – позволяет получить информацию о функциональных возможностях пользовательских агентов и сетевых серверов, но этот запрос не используется для организации сеансов связи.
BYE – используется вызывавшей и вызванной сторонами для разрушения соединения. Перед тем как разрушить соединение, пользовательские агенты отправляют этот запрос к серверу, сообщая о намерении прекратить сеанс связи.
CANCEL – позволяет пользовательским агентам и сетевым серверам отменить любой ранее переданный запрос, если финальный ответ на него (т.е. ответ с номерами 2хх, 3хх, 4хх, 5хх, 6хх) еще не получен.
REGISTER – применяется клиентами для регистрации данных о местоположении с использованием серверов SIP. При помощи запроса типа REGISTER пользователь сообщает свое текущее местоположение. В этом сообщении содержатся следующие поля:
Поле То содержит адресную информацию, которую надо сохранить или модифицировать на сервере;
Поле From содержит адрес инициатора регистрации. Зарегистрировать пользователя может либо он сам, либо другое лицо, например, секретарь может зарегистрировать своего начальника;
Поле Contact содержит новый адрес пользователя, по которому должны передаваться все дальнейшие запросы INVITE. Если в запросе REGISTER поле Contact отсутствует, то регистрация остается прежней. В случае отмены регистрации здесь помещается символ <*>;
В поле Expires указывается время в секундах, в течение которого регистрация действительна. Если данное поле отсутствует, то по умолчанию назначается время - 1 час, после чего регистрация отменяется. Регистрацию можно также отменить, передав сообщение REGISTER с полем Expires, которому присвоено значение О, и с соответствующим полем Contact.
Пример SIP-запросов показан ниже.
INVITE sip: [email protected] SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A.Bell <sip: [email protected]>
To: T.Watson <sip: [email protected]>
Сall-ID: [email protected]
Cseq: 1 INVITE
Content-Type: application/sdp
Content-Length:...
v =0
0 =bell 53655765 2353687637 IN IP4 128.3.4.5
SIP =IN IP4 kton.bell-tel.com
m =audio 3456 RTP/ AVP 0 3 4 5
Этот запрос приглашает [email protected] для участия в сеансе связи с [email protected]. В теле сообщения оборудование вызывающего пользователя указывает в формате протокола SDP, что оно может принимать в порту 3456 речевую информацию, упакованную в пакеты RTP и закодированную по одному из следующих алгоритмов кодирования: 0 - PCMU, 3 - GSM, 4 - G.723 и 5 - DVI4.Запрос направляется на прокси-сервер boston.bell-tel.com. В полях То и From перед скобками с адресом < > помещена надпись, которую пользователь желает вывести на дисплей вызываемого пользователя.
При передаче сообщений протокола SIP, упакованных в сигнальные сообщения протокола UDP, существует вероятность того, что размер запроса или ответа окажется больше максимально допустимого для данной сети, и произойдет фрагментация пакета. Чтобы избежать этого, используется сжатый формат имен основных заголовков, подобно тому, как это делается в протоколе SDP, Ниже приведен список таких заголовков.
Таблица 7 - Сжатый формат имен основных заголовков
| Сжатая форма имени | Полная форма имени |
| c | Content-Type |
| e | Content- Encoding |
| f | From |
| i | Call-ID |
| m | Contact (от "moved") |
| l | Content-Length |
| s | Subject |
| t | To |
| v | Via |
Ответы. После приема и интерпретации запроса, адресат (прокси-сервер) передает ответ на этот запрос. Содержание ответов: подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях и т.д.
Структуры ответов и их типы протокол SIP унаследовал от протокола НТТР. Определено 6 типов ответов, несущих разную функциональную нагрузку. Тип ответа кодируется 3-значным числом. Самой важной является первая цифра, которая определяет класс ответа, остальные две цифры лишь дополняют первую. В некоторых случаях оборудование может не знать все коды ответов, но оно обязательно должно знать, как интерпретировать первую цифру. Все ответы делятся на 2 группы: информационные и финальные.
Информационные ответы показывают, что запрос находится в стадии обработки. Они кодируются трехзначным числом, начинающимся с единицы, - 1хх. Некоторые информационные ответы, например, 100 Trying, предназначены для установки на нуль таймеров, которые запускаются в оборудовании, передавшем запрос. Если к моменту срабатывания таймера ответ на запрос не получен, то считается, что этот запрос потерян и может (по усмотрению производителя) быть передан повторно. Один из распространенных ответов - 180 Ringing; по назначению он идентичен сигналу <Контроль посылки вызова> в ТфОП и означает, что вызываемый пользователь получает сигнал о входящем вызове. 1хх (информационный) - запрос принят, продолжается его обработка;
Финальные ответы кодируются 3х-значными числами, начинающимися с цифр 2, 3, 4, 5 и 6, что означает завершение обработки запроса, и содержат, когда это нужно, результаты обработки запроса. Назначение финальных ответов каждого типа рассматривается ниже.
2хх (успех) - запрос принят, понят и успешно обработан.
В настоящее время из всех ответов типа 2хх определен лишь один -200 ОК. Его значение зависит от того, на какой запрос он отвечает:
-ответ 200 OK на запрос INVITE означает, что вызываемое оборудование согласно на участие в сеансе связи; в теле ответа указываются функциональные возможности этого оборудования;
- ответ 200 OK на запрос BYE означает завершение сеанса связи, в теле ответа никакой информации не содержится;
-ответ 200 OK на запрос CANCEL означает отмену поиска, в теле ответа никакой информации не содержится;
- ответ 200 OK на запрос REGISTER означает, что регистрация прошла успешно;
- ответ 200 OK на запрос OPTION служит для передачи сведений о функциональных возможностях оборудования, эти сведения содержатся в теле ответа.
3хх(переадресация) - для завершения обработки запроса нужны дальнейшие действия; информируют оборудование вызывающего пользователя о новом местоположении вызываемого пользователя или переносят другую информацию, которая может быть использована для нового вызова:
- в ответе 300 Multiple Choices указывается несколько SIP-адресов, по которым можно найти вызываемого пользователя, и вызывающему пользователю предлагается выбрать один из них;
- ответ 301 Moved Permanently означает, что вызываемый пользователь больше не находится по адресу, указанному в запросе, и направлять запросы нужно на адрес, указанный в поле Contact;
- ответ 302 Moved Temporary означает, что пользователь временно (промежуток времени может быть указан в поле Expires) находится по другому адресу, который указывается в поле Contact.
4хх (ошибка клиента) - запрос содержит ошибку и не может быть выполнен. После получения такого ответа пользователь не должен передавать тот же самый запрос без его модификации:
- ответ 400 Bad Request означает, что запрос не понят из-за наличия в нем синтаксических ошибок;
- ответ 401 Unauthorized означает, что запрос требует проведения процедуры аутентификации пользователя. Существуют разные варианты аутентификации, и в ответе может быть указано, какой из них использовать в данном случае;
- ответ 403 Forbidden означает, что сервер понял запрос, но отказался его обслуживать. Повторный запрос посылать не следует. Причины могут быть разными, например, запросы с этого адреса не обслуживаются и т.д.;
- ответ 485 Ambiguous означает, что адрес в запросе не определяет вызываемого пользователя однозначно;
- ответ 486 Busy Here означает, что вызываемый пользователь в настоящий момент не может принять входящий вызов по данному адресу. Ответ не исключает возможности связаться с пользователем по другому адресу или, к примеру, оставить сообщение в речевом почтовом ящике.
5хх (ошибка сервера) - сервер не может выполнить явно правильный запрос:
- ответ 500 Server Internal Error означает, что сервер не имеет возможности обслужить запрос из-за внутренней ошибки. Клиент может попытаться повторно послать запрос через некоторое время;
- ответ 501 Not Implemented означает, что в сервере не реализованы функции, необходимые для обслуживания этого запроса. Ответ передается, например в том случае, когда сервер не может распознать тип запроса;
- ответ 502 Bad Gateway информирует о том, что сервер, функционирующий в качестве шлюза или прокси-сервера, принял некорректный ответ от сервера, к которому он направил запрос;
- ответ 503 Service Unavailable говорит от том, что сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.
6хх (глобальный сбой) - запрос не может быть обработан никаким сервером:
- ответ 600 Busy Everywhere сообщает, что вызываемый пользователь занят и не может принять вызов в данный момент ни по одному из имеющихся у него адресов. Ответ может указывать время, подходящее для вызова пользователя;
- ответ 603 Decline означает, что вызываемый пользователь не может или не желает принять входящий вызов. В ответе может быть указано подходящее для вызова время;
- ответ 604 Does Not Exist Anywhere означает, что вызываемого пользователя не существует.
Ниже дан пример SIP-ответа.
SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:[email protected]>
To: <sip:[email protected]>;
Сall-ID:[email protected]
Сseq: 1 INVITE
Content-Type: application/sdp
Content-Length:...
v =0
0 =watson 4858949 4858949 IN IP4 192.1.2.3
t =3149329600 0
SIP =IN IP4 boston.bell-tel.com
m =audio 5004 RTP/AVP 0 3
a =rtpmap:0 PCMU/8000
a =rtpmap: 3 GSM/8000
В ответе пользователя Watson на запрос Bell сообщается, что он может принимать аудиоинформацию на порт 5004, понимать кодеки PCMU, GSM. Поля From, To, Via, Call-ID взяты из запроса. Поле Cseq показывает, что - это ответ на INVITE с Cseq: 1.
Еще пример (рисунок 31).Рассмотрим пример процесса установления соединения с использованием SIP-протокола (пример взят из RFC 3261).
Рисунок 31 - Пример процесса установления соединения с использованием SIP-протокола (RFC 3261)
Данный пример отражает работу базовых функций телефонии и соответственно не затрагивает такие возможности как видеосвязь, передача текстовых сообщений и др. — общий принцип работы протокола остается неизменным.
Пользователь Alice (sip:[email protected]) вызывает пользователя Bob (sip:[email protected]).
Пользователь Alice посылает сообщение INVITE прокси-серверу по умолчанию (atlanta.com) Если бы пользователю Alice был известен IP-адрес пользователя Bob и он мог к нему обратиться напрямую, то запрос INVITE в этом случае мог быть послан непосредственно вызываемому пользователю.
Прокси-сервер посылает запрос INVITE серверу вызываемого абонента (biloxi.com). Далее прокси-сервер пользователя Bob при необходимости определяет его текущий IP-адрес и посылает ему сообщение INVITE — у пользователя начинает звонить телефон, о чем сообщается в ответе 180 (Ringing).
Если вызываемый пользователь ответил на звонок, то на запрос INVITE высылается ответ 200 (OK).
Вызывающий пользователь отправляет сообщение ACK, сообщающее вызываемому о том, что он получил ответ на свой запрос INVITE, им задаются окончательные параметры соединения. На этом этапе все готово к установлению соединения по протоколу RTP (Real-time Transport Protocol).
Порядок выполнения работы
Для каждого варианта составить запрос и ответ, применительно к сеансу связи, между вызывающим и вызываемым пользователями согласно исходным данным из таблицы 8. Заголовки, которые нельзя составить на основе таблицы 8, а также тело сообщения, оставить такими же, как на примерах SIP ответов и запросов.
Таблица 8 -Исходные данные
| Вари ант | ||||
| Вызывающий пользователь | Имя: Director SIP-адрес: [email protected] | Имя: Andrew SIP-адрес: [email protected] | Имя: Bill Gaits SIP-адрес: [email protected] | Имя: User A SIP-адрес: [email protected] |
| Вызываемый пользователь | Имя: engineer SIP-адрес: [email protected] | Имя: Sasha SIP-адрес: [email protected] | Имя:V. Ivanov SIP-адрес: [email protected] | Имя: User B SIP-адрес: [email protected] |
| Пройденные cервера | loniis.ru sip.loniis.ru | Sipserver.com central.com bell.org | microsoft.com interconnect. com telecom.ru | bonch.edu centralserver.ru |
| Тип запроса и ответа | INVITE, 200 OK | BYE, 302 Moved Temporarily | OPTION 404 Not Found | REGISTER 200 OK |
Процесс установления соединения
Изучить сценарии установления соединения через сервер переадресации и через прокси-север.
Протоколом SIP предусмотрены 3 основных сценария установления соединения: с участием прокси-сервера, с участием сервера переадресации и непосредственно между пользователями. Различие между перечисленными сценариями заключается в том, что по-разному осуществляется поиск и приглашение вызываемого пользователя. В первом случае эти функции возлагает на себя прокси-сервер, а вызывающему пользователю необходимо знать только постоянный SIP-адрес вызываемого пользователя. Во втором случае вызывающая сторона самостоятельно устанавливает соединение, а сервер переадресации лишь реализует преобразование постоянного адреса вызываемого абонента в его текущий адрес. И, наконец, в третьем случае вызывающему пользователю для установления соединения необходимо знать текущий адрес вызываемого пользователя.
Перечисленные сценарии являются простейшими. Ведь прежде чем вызов достигнет адресата, он может пройти через несколько прокси-серверов, или сначала направляется к серверу переадресации, а затем проходит через один или несколько прокси-серверов. Кроме того, прокси-серверы могут размножать запросы и передавать их по разным направлениям и т.д. Но, все же, как уже было уже отмечено в начале параграфа, эти три сценария являются основными. Здесь мы рассмотрим подробно два первых сценария; третий сценарий в данной главе рассматриваться не будет.
Сеть SIP содержит пользователей (правильно сказать UAS), прокси-серверы и серверы переадресации. Перед началом сеанса связи вызывающий пользователь должен знать либо адрес вызываемого пользователя, либо адрес SIP-сервера. Адрес может быть в виде: user@domain, тогда необходимо преобразовать его в IP-адрес с помощью услуг DNS. Адреса серверов пользователю сообщает поставщик услуги. Для доступа к серверу может потребоваться аутентификация, обеспечивающая обслуживание только определенной группы пользователей, например, тех, кто заплатил за услуги. Если прямого адреса пользователя нет, он обращается к серверу переадресации или к прокси-серверу. Далее алгоритм работы сети зависит от того, к какому серверу он обратился.
Установление соединения через сервер переадресации. Вызывающему пользователю требуется вызвать другого пользователя. Он передает запрос INVITE 1 на известный ему адрес сервера переадресации и на порт 5060, используемый по умолчанию (рисунок 32).
Рисунок 32 - Сценарий установления соединениячерез сервер переадресации
В запросе вызывающий пользователь указывает адрес вызываемого пользователя. Сервер переадресации запрашивает текущий адрес нужного пользователя у сервера местоположения 2, теперь вызывающая сторона может связаться с вызываемой стороной. Для этого она передает новый запрос INVITE 6. В теле сообщения INVITE указываются данные о функциональных возможностях вызывающей стороны в формате протокола SDP. Вызываемая сторона принимает запрос INVITE и начинает его обработку, о чем сообщает ответом 100 Trying 7 встречному оборудованию для перезапуска его таймеров.
После завершения обработки поступившего запроса оборудование вызываемой стороны сообщает своему пользователю о входящем вызове, а встречной стороне передает ответ 180 Ringing 8.
После приема вызываемым пользователем входящего вызова встречной стороне передается сообщение 200 ОК 9, в котором содержатся данные о функциональных возможностях вызываемого терминала в формате протокола SDP.
Терминал вызывающего пользователя подтверждает прием ответа запросом АСК 10. На этом фаза установления соединения заканчивается, и начинается разговорная.
По завершении разговорной фазы любая из сторон передает запрос BYE 11, который подтверждается ответом 200 ОК 12.
Установление соединения через прокси-сервер показан на рисунке 33.
Рисунок 33 - Сценарий установления соединениячерез прокси-сервер
В этом случае действия 1, 2, 3 такие же, как и при использовании сервера переадресации. После выяснения адреса (на сервере определения местоположения) прокси-сервер передает по этому адресу запрос INVITE 4. Вызываемый пользователь В оповещается акустическим или визуальным сигналом о том, что его вызывают; вызов обрабатывается 5: он поднимает трубку, и ответ 200 ОК отправляется к прокси-серверу 6. Прокси-сервер переправляет этот ответ вызвавшему пользователю А, последний подтверждает правильность приема, передавая запрос АСК 7, который переправляется к вызванному пользователю В. Соединение установлено, идет разговор. Вызванный пользователь В кладет трубку, передается запрос BYE 8, прием которого подтверждается ответом 200 ОК 9.
Задание
Составить сценарий установления успешного соединения между терминалами пользователей А и В согласно данным, приведенным в таблице
Таблица 9 – Варианты заданий
| Вариант | ||||
| Вид соединения | т.А → PS→ RS →PS →т.В | т.А → RS → PS →RS → т.В | т.А → PS→ PS→RS →т.В | т.А → RS → PS →PS → т.В |
Сокращения: т.А (В) – терминал А (В), PS – прокси-сервер, RS – сервер переадресации.
Контрольные вопросы
1 Основные принципы, положенные в основу протокола SIP, кто его страндартизировал?
2 С помощью какого протокола терминалы обмениваются информацией о своих функциональных возможностях?
3 Перечислить основные элементы сети SIP.
4 Сообщения протокола SIP. Какой формат сообщений и их структура?
5 Пояснить назначение основных заголовков сообщений.
6 Описать процесс установления соединения через сервер переадресации.
7 Описать процесс установления соединения с участием прокси-сервера.
8 В чем разница двух сценариев?
9 В какие моменты времени терминалы пользователей посылают ин- формацию о своих функциональных возможностях? В каких сообщениях эта информация располагается?
10 Какое минимальное число сообщений необходимо для установления соединения?
|
|
|
