4.7. Ввды систем сигнализации в сетях ip-телефонии и сеть ip-телефонии с протоколами н.323

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

В настоящее время в IP-сетях применяются две основные систе­мы сигнализации Н.323 и SIP.

Система сигнализации Н.323 представлена в одноименной реко­мендации МСЭ-Т, получившей название: «Мультимедийные систе­мы связи на основе передачи пакетов (Packet-based multimedia communications systems)». Рекомендация предназначена для созда­ния систем связи на базе сетей с пакетной коммутацией для переда­чи речевой и видеоинформации, организации конференций, пере­дачи данных. В настоящее время приняты вторая, третья и четвертая версии этого стандарта — Н.323 v.2, Н.323 v.3 и Н.323 v.4. На правах времи того документа существуют документы Н.323 v.5 и Н.323 v.6.

Протокол SIP (Session Initiation Protocol — протокол инициали­зации сессии) разработан комитетом IETF (Internet Engineering Task Force) и первоначально его описание было приведено в документе RFC 2543. В настоящее время действует усовершенствованный до­кумент RFC 3261. Протокол предназначен для организации и управ­ления сессиями, в течение которых между участниками происходит обмен мультимедийными данными: речью, видео и текстом.

К системам сигнализации следует отнести протоколы управления шлюзами MGCP (Media Gateway Control Protocol—протокол управ­ления медиашлюзом) и MEGACO/H.248. Первоначально появив­шийся протокол MGCP был предложен комитетом IETF. Работая над усовершенствованием протокола MGCP, комитет IETF создал про­токол MEGACO. Одновременно над подобным протоколом работал союз МСЭ-Т, которому было дано название Н.248.

Сеть IP-телефонии, построенная по стандарту Н.323, включает в себя четыре основных компонента: терминал Н.323, гейткипер (gatekeeper, или привратник), шлюз и устройства управления кон­ференциями (MCU) (рис. 4.18). Они все включаются в сеть комму­тации пакетов, которая может не гарантировать требуемое качество услуг — QoS (Quality of Service). В качестве такой сети могут исполь­зоваться сети: LAN, MAN (Metropolitan Area Networks — вычисли­тельная сеть в пределах города), Интернет и Интранет. В рекоменда­ции Н.323 не определены конкретные типы сетей, их протоколы и интерфейсы. В качестве примеров приведены сети Ethernet, Fast Ethernet, FDDI, Token Ring, ATM.

К сети Н.323 могут подключаться другие сета: телефонные сети, сети ISDN и В-ISDN (широкополосная сеть ISDN), а через сеть ISDN — сеть LAN, гарантирующая качество услуг. Взаимодействие с этими се­тями происходит через шлюзы, причем один шлюз может обеспечить подключение к нескольким сетям разного назначения (на рис. 4.18 по­казано по одному шлюзу к каждой сети). В указанные сети могут вклю­чаться терминалы, служащие только для передачи речи — речевые

терминалы, так и терминалы, позволяющие одновременно передавать речь и ввдео — вадеофоны. Такие терминалы способны также переда­вать данные. Терминалы типа ввдеофон в зависимости от сети должны соответствовать одной из рекомендаций: Н.320, Н.321, Н.322 и Н.324. Терминалы Н.323 способны обмениваться с другими терминалами речевой, видеоинформацией и данными. Терминал может быть рас­считан либо на предоставление только одной услуги: речевой, ви­део, данных, либо любой комбинации из двух или трех таких услуг. В телефонной сети и сети ISDN к речевым терминалам относятся аналоговые телефонные аппараты, а в сети ISDN — также и цифро­вые телефонные аппараты. Роль терминалов Н.323 могут выполнять IP-телефоны и софгфоны.

В сети Н.323 возможны соединения между любой парой терми­налов Н.323, между терминалом Н.323 и любым терминалом другой сети, подключенной через шлюз. Допустимы соединения между дву­мя терминалами двух разных TDM-сетей, подключенных через шлю­зы. Также возможно соединение между двумя терминалами Н.323 с применением TDM-сети (сетей), в котором участвуют два шлюза, один для исходящего соединения к TDM-сети, другой — для входя­щего соединения от TDM-сети.

В сети Н.323 шлюз выполняет две основные функции. Во-первых, преобразовывает сигнализацию сети Н.323 в систему сигнализации, соответствующей TDM-сети, и наоборот. Во-вторых, в направлении от TDM-сети к пакетной сети производит преобразование речевых или видеосигналов TDM-сети в сигналы пакетной сети, вставляет их в пакеты и посылает пакеты в сеть коммутации пакетов, а в направле­нии от пакетной сети к TDM-сети производит такие же операции в обратной последовательности. Со стороны как пакетной, так и TDM-сети, шлюз выполняет функции терминала соответствующей сети. На пакетной сети — это терминал Н.323, а на TDM-сети — терми­налы Н.320, Н.321, Н.322, Н.324, V.70 и речевые терминалы. Терминал TDM-сети рассматривает шлюз как терминал такого же типа.

При соединениях между речевыми терминалами шлюз может под­держивать обмен DTMF-сигналами. Для этого шлюз со стороны TDM-сети детектирует и формирует DTMF-сигналы, а со стороны пакетной сети — передает и принимает сигналы по протоколу Н.245 или использует специальные RTP-пакеты, служащие для передачи DTMF-сигналов и иных тональных сигналов (RFC 2833). Гейткипер обеспечивает управление вызовами в сети Н.323. Он взаимодействует с терминалами Н.323, шлюзами и MCU. В сети Н.323 может быть множество гейткиперов и каждый обслуживает свою зону сети. При установлении соединений между терминала­ми разных зон, гейткиперы обмениваются между собой сигналь­ной информацией. Гейткипер выполняет следующие обязательные функции.

Преобразование адреса — происходат преобразование так назы­ваемого алиас-адреса (alias address) в транспортный адрес вызывае­мого абонента. Алиас-адрес передается от вызывающего абонента и может иметь разную форму записи: телефонный номер, символьное имя, адрес электронной почты.

Управление доступом — при каждом вызове гейткипер определя­ет право пользователя на доступ к сети Н.323. Для этого использует­ся протокол RAS (Registration, Admission and Status — регистрация, доступ и статус).

Управление полосой пропускания — осуществляется контроль над допустимым числом терминалов, получившим одновременно доступ к сети Н.323. При недостаточной полосе пропускания гейткипер может отказать в обслуживании очередного вызова. Эта функция также действует, когда соединение уже установлено, а терминалу тре­буется дополнительная полоса пропускания. Управление полосой пропускания происходит по протоколу RAS.

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

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

Гейткипер необходим, когда в сети есть хотя бы один шлюз, что объясняется требованием преобразования поступающих от TDM-сети цифр номера в транспортный адрес. В сети, в которую включены толь­ко терминалы Н.323, гейткилера может не быть. Однако в этом случае терминалам Н.323, должны быть известны транспортные адреса дру­гих абонентов сети. В сети также не будут выполняться основные фун­кции гейткипера.Устройство управления конференциями MCU (Multipoint Control Unit) служит для образования конференций, в которых могут уча­ствовать терминалы сети Н.323 и других сетей. Конференция может быть аудио или видео, а также одновременно аудио и видео. Во вре­мя конференции между участниками могут передаваться данные. Функционально MCU состоит из контроллера конференций (МС — Multipoint Controler) и процессора конференций (MP — Multipoint Processor). Контроллер управляет организацией конференций. Он обменивается информацией с терминалами, входящими в конферен­цию, и согласовывает параметры передачи медиапотоков. Процес­сор обрабатывает поступающие от терминалов потоки речевой, ви­деоинформации и потоки данных и полученные в результате обра­ботки потоки возвращает терминалам.Конференции могут быть централизованными, децентрализован­ными и комбинированными.

В централизованной koi гференции терминал каждою участника со­единяется с MCU в режиме «точка—точка». При передаче речи это означает, что между каждым терминалом и MCU образуется двусторон­ний логический канал, по которому от терминала к MCU передается поток RTP-пакетов с речью одного абонента. В MCU происходит циф­ровое суммирование речевых сигналов, принимаемых в RTP-пакетах оттерминалов участников конференции. С выходов сумматора or MCU к каждому терминалу передается поток RTP-пакетов с суммарным ре­чевым сигналом. В суммарном рече­вом сигнале, посылаемом термина­лу, не должно содержаться речевого сигнала, поступившего от этого тер­минала (абонент i ie дсшже1 г слышать самого себя). На рис. 4.19 показан пример централизованной аудио- конференции с тремя терминалами Т1...ТЗ (S — цифровой сумматор).

В децентрализованной конфе­ренции каждый терминал участни­ка конференции передает каждомуфугому терминалу поток аудио- i/или видеоинформации без учас­тия MCU. Со стороны MCU с по­мощью МС осуществляется управ- юние конференцией по протоколу -1.245 (рис. 4.20). Каждый терминал финимаег одинаковое число ме- шапотоков, равное N— 1, где N— шсло участников конференции. 3 случае передачи речи, терминал 1роизводиг цифровое суммирование речевых сигналов, поступаю- цих от всех других терминалов.

Комбинированная конференция представляет собой сочетание хентрализованной и децентрализованной конференций. На рис. 4.21 токазан пример комбинированной аудиоконференции, в которой терминалы Т1...ТЗ входят в централизованную конференцию, а Г4...Т6 — в децентрализованную. Все терминалы связаны с MCU, фичем при передаче речевых пакетов в децентрализованной кон­ференции MCU рассматривается как терминал этой конференции. То этой причине на выходах сумматора, направленных к термина- тм децентрализованной конференции (Т4...Т6), должны присут­ствовать только речевые сигналы от терминалов централизованной конференции (Т1...ТЗ). На выходе, направленном к терминалу цент­рализованной конференции, должны быть речевые сигналы всех участников комбиниро­ванной конференции, кроме сигналов данного терминала.

При цифровом суммирова­нии, осуществляемом процес­сором MP, сигналы на каждом входе преобразовываются в сигналы с линейной характе­ристикой (производится де­компрессия сигналов). Затем раздельно для каждого выхо­да происходит собственно суммирование сигналов, по­ступающих с входов. В суммарном сигнале одного выхода не долж­но быть речевого сигнала, принятого по этому же входу. Суммарный сигнал кодируется по одному из стандартов (например, G.703) и пе­редается на соответствующий выход. Чтобы снизить шумы и добить­ся одинакового уровня речевых сигналов, MP может ограничить по­ступление или ввести затухание сигналов на отдельных входах.

Рассмотрим процессы установления соединений на сети Н.323.

В процессе установления соединения и разъединения использу­ются три протокола: RAS, Н.225.0 и Н.245.

Протокол RAS позволяет обмениваться сообщениями между тер­миналом и гейткипером при регистрации и отказе от регистрации пользователей, при управлении полосой пропускания и управле­нии доступом. Для переноса сообщений этого протокола исполь­зуется протокол ненадежной передачи пакетов UDP. Описание про­токола RAS приведено в рекомендации Н.225.0 МСЭ-Т.

Протокол Н.225.0 аналогичен протоколу Q.931, используемому на сети ISDN для сигнализации по каналу D. Служит для управления вызовом на этапах установления соединения, разъед инения и в дру­гих случаях. По этому протоколу пункты сети обмениваются сигналь­ными сообщениями таких же типов, как в стандарте Q.931. На сети Н.323 для передачи сообщений по протоколу Н.225.0 используется протокол надежной доставки TCP. В начальных версиях стандарта Н.323 для каждого соединения открывался отдельный сигнальный канал. Начиная с третьей версии, образуется общий для всех соеди­нений сигнальный канал, а соединения различаются метками (call reference).

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

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

Процедура передачи сигнальных сообщений начинается с фазы установления соединения, когда вначале происходит обмен сообще­ниями по протоколу RAS, затем по протоколу Q.931, а затем по про­токолу Н.245.

Далее по образованному логическому каналу терми­налы обмениваются речевыми пакетами. На фазе разъединения сиг­нальные сообщения передаются в обратной последовательности: Н.245, Q.931, RAS.

Рассмотрим подробнее процесс установления соединения и разъе­динения для варианта с применением гейткипера и передачей сиг­нальных сообщений напрямую между речевыми терминалами. На рис. 4.22 показана диаграмма установления соединения и разъеди­нения между двумя терминалами одной зоны сети Н.323. Предпола­гается, что используя протокол RAS, оба терминала уже зарегистри­ровались в гейткипере. В рассматриваемом примере в качестве тер­минала выступает IP-телефон или шлюз, в который непосредствен­но включен аналоговый телефонный аппарат.

При поступлении вызова от абонента, гейткипер с помощью про­токола RAS проверяет право пользователя на доступ к сети. Для это­го от терминала 1 к гейткиперу передается сообщение ARQ (Admis­sion Request), являющееся требованием на установление соединения. В этом сообщении содержится алиас-адрес вызываемого абонента. Гейткипер отвечает терминалу 1 сообщением ACF (Admission Con­firm), извещающим о согласии на установление соединения. В нем гейткипер посылает транспортный адрес сигнального канала терми­нала 2. Если у пользователя нет права доступа к сети, гейткипер от­ветит сообщением отказа доступа ARJ (Admission Reject).

Теперь терминалы 1 и 2 обмениваются сигнальными сообще­ниями по протоколу Q.931. От вызывающей стороны по получен­ному от гейткипера транспортному адресу сигнального канала тер­минала 2 передается сообщение Setup, несущее в себе требование

на установление соединения. В обратном направлении от термина­ла 2 к терминалу 1 по образованному сигнальному каналу передает­ся сообщение Call Proceeding, извещающее о том, что принято дос­таточно информации для продолжения соединения. Если терминал 2 готов принять вызов, он передает запрос допуска к ресурсам сети ARQ, на который привратник отвечает подтверждением ACF. При свободности вызываемого абонента, ему передается сигнал вызова, а по сигнальному каналу посылается сообщение Alerting. При ответе абонента на вызов от терминала 2 к терминалу 1 передается сообще­ние Connect. В этом сообщении содержится транспортный адрес ло­гического канала Н.245. Теперь по протоколу TCP открывается логический канал Н.245 и происходит обмен сообщениями Н.245. Первым от каждого из терминалов передается сообщение Terminal- CapabilittySet, в ответ на которой другой терминал отправляет сооб­щение подтверждения TerminalCapabilittySetAck. В сообщении TerminalCapabilittySet содержится информация для согласования параметров обмена потоками речевой информации. Сюда обязатель­но вход ят данные о типах кодеков с которыми может работать каж­дый из терминалов, информация об обмене пакетами в обоих или в одном направлении соединения.

Далее определяется какой из терминалов будет ведущим (master), а какой — ведомым (slave). С этой целью терминалы обмениваются сообщениями MasterSlaveDetermination и MasterSlaveDetermination- Ack. Ведущий терминал определяется по максимальному из двух слу­чайных чисел, посланных от каждого из терминалов. Процедура вве­дения ведущего терминала необходима для разрешения конфликтов, которые могут возникнуть между терминалами. Например, это не­обходимо для исключения одновременного открытия каждым тер­миналом логического канала для передачи пользовательской инфор­мации.

Теперь для пересылки речевых пакетов надо открыть однонаправ­ленные логические каналы в направлениях передачи от терминала 1 к терминалу 2 и наоборот. Для этого используется сообщение Open- Logical Channel, передаваемое от каждого из терминалов. В ответ на него поступает подтверждающее сообщение OpenLogicalChannelAck. В сообщении OpenLogicalChannel содержатся: уникальный номер ло­гического канала для передачи речи в соответствующем направле­нии; транспортные адреса портов RTP и RTCP, на которые должны приниматься речевые пакеты; вид передаваемой информации — речь; тип выбранного кодека.

Процесс установления соединения закончился, и пользователи могут передавать речевую информацию, используя два односторон­них логических канала между терминалами. Во время разговора ис­пользуется схема передачи RTP/UDP/IP. Протокол RTCP служит для контроля над передачей потоков речевых пакетор.

По окончании разговора начинается фаза разъединения. При при­еме от абонента сигнала отбоя, терминал прекращает передачу речевых пакетов и посылает по каналу Н.245 сообщение EndSessionCommand, извещающее другой терминал об окончании сессии. Этот терминал должен прекратить посылку речевых пакетов и также передать сообще­ние EndSessionCommand. Абоненту передается сигнал «занято».

По образованному при установлении соединения сигнальному каналу передается по протоколу Q.931 сообщение Release Complete. Теперь сигнальный канал закрывается.

Разъединение завершается обменом сообщений между терми­налами и гейткипером по протоколу RAS. От каждого из терминалов в сторону гейткипера передается сообщение DRQ (Disengage Request — требование на освобождение), в ответ на которое гейткипер посы­лает подтверждение в виде сообщения DCF (Disengage Confirm — согласие освобождения). Гейткипер освобожд ает зарезервированную полосу пропускания для закончившегося соединения.

4.8. Сеть IP-телефонии с протоколом SIP

На сетях с пакетной коммутацией все большее значение находит протокол инициализации сеансов связи — SIP, разработанный в ка­честве стандарта для пакетных сетей рабочей группой по инженер­ным проблемам Интернет (IETF). Этот станд арт имеет назначение, аналогичное стандарту Н.323, однако имеет множество отличий. Не вдаваясь в подробности, можно заметить, что в рекомендациях Н.323 рассматривается прикладная сеть, наложенная на сеть передачи дан­ных с пакетной коммутацией, в то время как протокол SIP ориенти­рован на интеграцию со службами сети Интернет. По протоколу SIP происход ит установление, модификации и завершение мультимедий­ных (в том числе речевых) соединений. SIP многое позаимствовал у таких популярных и уже доказавших свою состоятельность прото­колов сети Интернет, как HTTP и SMTP.

Описание протокола SIP приведено в документе RFC3261 (вер­сия 2). С этим протоколом связаны другие документы: RFC3265 — SIP Specific Event Notification (характерные уведомления о событиях по протоколу SIP), RFC3665 — SIP Basic Call Flow Examples (приме­ры обслуживания основных потоков вызовов по протоколу SIP), RFC3372 — SIP-T Context and Architectures (протокол SIP для теле­фонии: контекст и архитектура), RFC3515 — SIP Refer Method (на­ведение справки по протоколу SIP), RFC3725 — SIP Best Current Practices for Зрсс (применение протокола SIP для организации трех­сторонней конференции), RFC4028 — SIP Session Timers (таймеры в течение сессий для протокола SIP) и другие. В протоколе SIP пре­дусмотрен обмен информацией по протоколу SDP (Session Descrip­tion Protocol — протокол описания сессии) в соответствии с доку­ментом RFC2327.

При создании протокола SIP были заложены следующие основ­ные принципы.

Мобильность пользователей, состоящая в том, что пользователь может получать услуги сети независимо от своего местоположения в ней. С этой целью в сети должен быть сервер регистрации, а пользо­ватель информирует о своем местоположении с помощью специаль­ного сообщения — REGISTER.

Масштабируемость сети означает, что можно построить сеть раз­ных размеров и любая сеть может быть расширена

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

Возможность взаимодействия с другими протоколами сигнализации необходима для работы с другими сетями, где используются иные системы сигнализации. Сети с протоколом SIP могут взаимодейство­вать с пакетными сетями, в которых применяются протоколы Н.323, MGCP и другие. В телефонных сетях общего пользования и техно­логических сетях протокол SIP взаимодействует с системами сигна­лизации DSS1 и ОКС № 7.

Важной особенностью протокола SIP является его полная совме­стимость с протоколами сети Интернет, разработанных комитетом IETF и отраженных в документах серий RFC. С точки зрения пере­дачи мультимедийной информации в сети SIP находят применение протоколы: RTP, RTCP, RSVP (Resource Reservation Protocol — про­токол резервирования ресурсов сети, RFC2205), RTSP (Real-Time Streaming Protocol — протокол передачи потоковой информации в реальном времени, RFC 2326).

Протокол SIP может быть использован на разных сетях с пакет­ной коммутацией: Х.25, ATM, Frame Relay и другие. Однако пред­почтение отдается IP-сетям со стеком протоколов TCP/IP. Сигналь­ная информация может передаваться по протоколу TCP или UDP, но в первую очередь рекомендован протокол UDP. Чтобы достиг­нуть надежной передачи сигнальных сообщений при использовании протокола UDP предусматривается подтверждение приема и повтор­ная передача сигнальных сообщений.

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

По сети SIP может передаваться любая мультимедийная пользо­вательская информация: речь, видео и данные и любые их комби­нации. При установлении соединения вызывающая и вызываемая стороны обмениваются информацией о своих функциональных воз­можностях: тип мультимедийной информации, алгоритм кодиро­вания, режим передачи пакетов: одноадресный (unicasting) или мно­гоадресный (multicasting), транспортный адрес пункта приема пользовательской информации (для режима unicast) и другие. Для этой цели используется протокол SDP, данные которого вставля­ются в сообщения протокола SIP. Во время сеанса предусмотрена возможность его модификации (например, при переадресации вы­зова на другого абонента, при добавлении или прекращении пере­дачи одной мультимедийной информации), для чего также приме­няется протокол SDP. В сети с протоколом SIP можно организовывать централизован­ные, децентрализованные и комбинированные конференции, на подобие тех, что рассмотрены для стандарта Н.323. В описании про­токола SIP не приведены способы организации и управления кон­ференциями, а только лишь процедуры, связанные с обменом сиг­нальной и мультимедийной информацией. Протокол SIP позволяет образовывать конференции с одноадресной (режим unicasting) и мно­гоадресной (режим multicasting) рассылкой пакетов. Режим unicasting означает, что к каждому терминалу участника конференции переда­ется индивидуальный мультимедийный (например, речевой) поток пакетов с транспортным адресом этого терминала. В режиме multicasting все мультимедийные пакеты одной сессии передаются с одним multicast-адресом, в соответствии с которым они доставля­ются сетью терминалам участников конференции. В этом случае па­кетная сеть должна обеспечить режим многоадресной рассылки. Протокол SIP позволяет во время конференции добавлять или вы­водить из нее какого-либо участника.

Сеть с протоколом SIP строится с применением следующих уст­ройств (рис. 4.23): прокси-сервера (proxy-server) SIP, сервера регист­рации (registrar) и терминалов. К терминалам относятся софтфоны, IP-телефоны и шлюзы. В сети SIP прокси-сервер SIP и сервер реги­страции обычно бывают совмещены в одном оборудовании.

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

Прокси-серверы могут быть двух типов: с сохранением (statefull) и без сохранения (stateless) состояний. Сервер с сохранением состо­яний хранит в своей памяти все входящие и исходящие запросы в течение транзакции, т.е. до получения ответов на них. Сервер без сохранения состояний только ретранслирует поступающие к нему Запросы и ответы. От сервера первого типа требуется большая про­изводительность, но этот тип имеет больше функциональных воз­можностей. Возможен вариант комбинированного прокси-сервера, когда для одних пользователей он работает с сохранением состоя» * ний, а для других — без сохранения состояний.

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

В сети SIP может быть сервер перенаправления (Redirect server), который служит для определения текущего IP-адреса вызываемого пользователя. На этот сервер поступают запросы об определении местоположения пользователя. Он через сервер регистрации или напрямую обращается к базе данных с местоположением пользова­телей сети. Сервер перенаправления применяется, когда в сети нет прокси-сервера (соединения между терминалами устанавливаются напрямую) или для снижения загрузки прокси-сервера.

При установлении соединений в сети SIP используется адресация, подобная адресации электронной почты. Адрес состоит из двух частей: имени пользователя, зарегистрированного в домене или на узле сети (хосте); имени домена, узла или шлюза. Две части разделены знаком @. Используются четыре типа адресов:

• имя пользователя@домен;

• имя пользователя@хост;

• номер телефона@шлюз;

• имя пользователя@1Р-адрес.

При использовании трех первых типов адресов необходимо об­ратиться к службе доменных имен DNS (Domain Name Service) для того, чтобы определить IP-адрес, соответствующий данному имени домена, узла или шлюза. При наличии во второй части IP-адреса, связаться с сервером или терминалом сети SIP можно напрямую.

Адрес записывается в строчку и перед ним ставится признак принадлежности к протоколу SIP. Ниже показаны примеры запи­си SIP-адресов:

sip: [e-mail];

sip: [e-mail];

sip: kvant@192.168.58.136

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

Важным понятием в протоколе SIP является агент пользователя UA (User Agent) — это терминал SIP, который формирует запросы, отвечает на них при взаимодействии с другими агентами пользова­телей в течение сеанса связи. Взаимодействие между агентами пользователей может быть непосредственным или через промежу­точный сервер, например, прокси- сервер. Программное обеспечение агента пользователя делится на две части: клиентскую UAC (User Agent Client) и серверную UAS (User Agent Server).

Сообщения SIP имеют одина­ковую структуру, показанную на рис. 4.24.

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

Далее следуют заголовки, необходимые для передачи информации о вызывающем и вызываемом пользователях, пути следования сооб- п гений и других данных. Используются заголовки разных типов, при­чем каждому типу присвоено имя. После заголовков следует пустая стро­ка, а за ней — тело сообщения. В теле сообщений может содержаться описание сеансов связи, например по протоколу SDP (сообщения ти­пов INVITE, АСК и OPTION). В некоторых сообщениях тела сообще­ния может не быть, например в сообщении BYE. В стартовой строке, заголовках и в теле сообщения информация записывается в виде текста с использованием набора символов ISO 10646 в кодировке UTF-8.

Заголовки протокола SIP делятся на четыре вида: общие заголов­ки, присутствующие в запросах и ответах; заголовки содержания, включающие в себя информацию о размере тела сообщения или об источнике запроса; заголовки запросов, передающие дополнительную информацию о запросе; заголовки ответов, передающие дополнитель­ную информацию об ответе. Формат заголовка начинается с его на­звания, далее следует двоеточие, а за ним содержание заголовка.

При обработке сообщений протокол SIP игнорирует заголовки с не­известны ми названиями. Наиболее часто используются следующие общие заголовки: From (источник запроса), То (получатель запроса), Call-ID (идентификатор сеанса связи), Contact (контакт), Cseq (после­довательность), Via (через). К заголовкам содержания относятся: Content-Type (тип содержимого), Content-Length (размер тела сообще­ния), Content-Encoding (кодирование тела сообщения). Во все запросы вставляется заголовок Max-Forwards (максимальное количество пере­адресаций). Подробное назначение и содержание заголовков рассмат­ривается ниже при описании процессов соединения и разъединения.

В протоколе SIP первоначально были заложены запросы следую­щих типов:

INVITE — приглашение пользователя к сеансу связи; содержит описание сеанса по протоколу SDP;

АСК — подтверждение приема последнего ответа на запрос INVITE;

BYE — окончание сеанса; передается от любого из пользовате­лей, участвующих в сеансе;

CANCEL — прекращение обработки запросов;

REGISTER — требование на регистрацию пользователя на сер­вере определения местоположения;

OPTION — запрос информации о функциональных возможнос­тях терминала.

В дальнейшем были добавлены следующие запросы:

INFO — служащий для передачи дополнительной информации прикладного уровня после установления соединения в течение се­анса связи; примеры применения: обмен сигналами между шлюза­ми телефонной сети общего пользования или сети ОбТС во время сеанса связи; посылка сигналов DTMF в течение SIP-сеанса;

PRACK — участвует в механизме надежной доставки отдельных типов ответов;

UPDATE — служит для изменения некоторых параметров сеан­сов (например, кодеков) до поступления окончательного ответа на запрос INVITE;

NOTIFY — служит для переноса информации о текущем состоя­нии соответствующего объекта сети; может передаваться каждый раз, когда состояние объекта меняется;

SUBSCRIBE — используется для получения информации о теку­щем состоянии удаленного ресурса сети; служит для создания диа­лога между двумя агентами пользователей: подписчиком на предо­ставление информации и держателем этой информации; информа­ция о текущем состоянии переносится в сообщении NOTIFY;

REFER — предназначен для реализации дополнительных услуг, таких, как переадресация вызова и наведение справки;

MESSAGE — позволяет передавать текстовые сообщения между пользователями без установления соединения между ними; исполь­зуется модель, подобная передаче SMS (Shot Message Service — услу­га коротких сообщений) в сети мобильной связи.

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

• 1хх — предварительные ответы, означающие, что запрос при­нят и продолжается его обработка;

• 2хх — ответы успешной обработки запроса; означают, что за­прос был получен, понят и принят к исполнению;

• Зхх — ответы перенаправления, указывающие на необходимость принять меры по завершению обработки запроса;

• 4хх — ответы об ошибках клиента, сообщающие о наличии син­таксических ошибок в запросе или о том, что запрос не может быть выполнен сервером;

• 5хх — ответы об ошибках, обнаруженных сервером и указываю­щие на то, что сервер не может выполнить данный запрос;

• бхх — ответы с отказом обслужить вызов на сервере.

Ниже приведены наиболее часто используемые ответы и их на­значение:

100 Trying — запрос был принят и обрабатывается на сервере про­межуточного узла сети;

180 Ringing — запрос INVITE принят вызываемой стороной и пользователю посылается сигнал вызова;

200 ОК — подтверждение о выполнении запроса;

301. Moved Permanently — вызываемый пользователь изменил свое местоположение, его новый адрес указан в заголовке Contact;

302. Moved Temporarily — вызываемый пользователь временно из­менил свое местоположение, его новый адрес указан в заголовке Contact;

     400. Bad Request — в запросе обнаружена синтаксическая ошибка;

     401. Unauthorised — должна быть проведена авторизация вызыва­ющего пользователя;

404 Not Found — сервер не нашел вызываемого пользователя, ад­рес которого указан в заголовке То;

480 Temporarily not available — вызываемый пользователь времен­но недоступен;

500 Server Internal Error — сервер обнаружил ошибку, которая не позволяет выполнить запрос; клиент может повторить запрос через 1несколько секунд;

600 Busy Everywhere — вызываемый пользователь найден, но он занят и не хочет в данное время принять вызов; в ответе может быть указано время для приема вызова;

604 Does Not Exist Anywhere — вызываемого пользователя не су­ществует;

606 Not Acceptable — соединение с вызываемым пользователем невозможно из-за того, что содержащиеся в описании сеанса пара­метры (протокол SDP) недопустимы.

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

Рассмотрим процессы установления соединения и разъединения на сети SIP.

Начнем с варианта с использованием одного прокси-сервера на сети с фиксированным местоположением пользователей. Предпо­лагается, что соединение устанавливается от пользователя А к пользо­вателю Б и что у каждого пользователя находится IP-телефон с но­меронабирателем (рис. 4.25).

Запросы показаны непрерывными линиями, а ответы — пунктир­ными. В IP-телефоне пользователя А должен быть прописан IP-адрес прокси-сервера, на который передается запрос INVHE.

После того как пользователь А набрал номер абонента Б (36074), от его IP-телефона прокси-серверу посылается сообщение INVITE. Содержимое этого сообщения показано на рис. 4.26.

Первая строчка представляет собой стартовую строку, содержа­щую наименование типа сообщения, адрес вызываемого абонента: [e-mail] и версию протокола SIP.

Далее следует заголовок Via, служащий для исключения прохож­дения запроса по замкнутому пути (образование петли) и для того, чтобы в необходимых случаях задавать для запросов и ответов один и тот же путь в сети SIP. Заголовок Via учитывает прохождение запроса через каждый узел сети. При этом в каждом прокси-сервере прини­маемый запрос обрабатывается и, если требуется, направляется к дру­гому прокси-серверу. Каждый прокси-сервер добавляет поле со сво­им адресом. Таким образом, по заголовку Via можно определить пол­ный путь прохождения запроса. Заголовок Via содержит версию про­токола SIP, тип протокола транспортного уровня IP-сети, адрес узла сети, отправившего запрос (в рассматриваемом случае адрес терми­нала Iocat3.otdelenl.com) и параметр branch, необходимый для иден­тификации данной транзакции. В ответе на данный запрос передает­ся такое же значение параметра branch. Содержимое заголовка Via

INVITE sip:36074@otdelen1 .com SIP/2.0

Via:SIP/2.0/UDP locat3.otdelen1 ,com;branch=z9hG4bK776asdhds Max-Forwards:70

To:36074<sip:[e-mail]>;tag=287447

From:33051 <sip:33051 @otdelen 1 ,com>;tag=1928301774

Call-ID: a84b4c76e66710@otdelen1 .com

CSeq:314159 INVITE

Contact:<sip:33051 @otdelen1 .com>

Content-Type:application/sdp

Content-Length: 162

Рис. 4.25. Соединение на сети SIP: Терминал—Прокси—Терминал

v=0

o=- 2890844526 2890844526 IN IP4 locat3.otdelen1.com s=-

t=2873397496 0 C=INIP4 192.2.17.12 m=audio 49170 RTP/AVP 8 0 4

Рис. 4.26. Содержание первого запроса INVITE

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

Следующий заголовок — Max-Forwards присутствует в каждом за­просе и служит для ограничения количества серверов или шлюзов, через которые проходит запрос. Значение заголовка Max-Forwards меняется в пределах от 0 до 255 и указывает на то, сколько осталось допустимых пересылок для данного сообщения. Каждый сервер, об­рабатывающий запрос, уменьшает значение заголовка Max-Forwards на единицу. Исходное значение этого заголовка рекомендуется брать равным 70.

Заголовок То определяет логического получателя запроса. В за­головке может содержаться имя или номер вызываемого абонента (в рассматриваемом примере — номер 32051), который отображается на дисплее IP-телефона вызываемого пользователя. Обязательной частью этого заголовка является адрес вызываемого пользователя ([e-mail]). Заголовок То заканчивается параметром tag, который также передается в заголовке From, но уже с другим значе­нием. Параметры tag в этих заголовках служат для идентификации одного диалога в одном сеансе связи. В ответе на запрос в заголов­ках То и From передаются параметры tag с такими же значениями, что и в запросе. В протоколе SIP может быть образовано несколько диалогов по одному запросу и в этом случае в узле сети возможно разветвление одного запроса по нескольким направлениям сети.

Заголовок From содержит данные об отправителе запроса: адрес и параметр tag. По аналогии с заголовком То, в заголовке From мо­жет быть имя или номер вызывающего пользователя (33051).

Заголовок Call-ID представляет собой уникальный идентификатор сеанса связи. Он должен быть одинаковым во всех запросах и ответах в течение одного диалога Идентификатор состоит из буквенно-цифро­вого значения (а84Ь4с76е66710), задаваемого агентом отправителя, и из имени узла сети (otdelenl .com).

Заголовок Gseq служит для идентификации транзакций и поряд­ка следования запросов. Он состоит из целого числа (314159), кото­рое не должно быть больше 2³¹, и типа запроса. В ответе на запрос вставляется заголовок Cseq, принятый в запросе (INVITE). Если сер­вер принимает запрос со значением Cseq больше предыдущего, то считает, что это новый запрос. Клиент сам определяет способ выбо­ра значения Cseq.

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

Заголовок Content-Type указывает на тип тела сообщения. В рассматриваемом примере в теле сообщения переносятся данные протокола SDP.

Заголовок Content-Length представляет собой десятичное число, указывающее на длину тела сообщения в байтах (162 байта).

Рассмотрим описание сеанса по протоколу SDP, содержащееся в теле сообщения (см. рис. 4.26). При описании используются пара­метры, каждый из которых записывается в одной строчке и имеет наименование в виде одной буквы, после которой следует знак ра­венства, например: т=.

После пустой строки следует версия протокола SDP: v = 0.

Далее идет строка параметра «о» (origin), включающая данные инициатора сеанса. Данные имеют шесть составляющих, разделен­ных интервалами: имя пользователя или дефис (-), идентификатор сеанса (2890844526), версия обновления данных (если обновления данных не было, то то же значение, что и идентификатор сеанса: 2890844526), тип сети (IN — Интернет), тип адреса (IP4 — адрес IP-протокола версии 4) и адрес узла, инициатора данного сеанса (locat3.otdelen 1 .com). Следующая строка несет в себе имя сеанса «s», которое может быть ваписано в виде текста. Если имени нет, то ставится дефис.

Строка, начинающаяся с буквы «t», содержит два поля: время на­чала (2873397496) и окончания (0) сеанса. Время записывается в се­кундах в соответствии с протоколом NTP (Network Time Protocol — Сетевой протокол времени). Если в поле окончания сеанса стоит 0, То продолжительность сеанса протоколом SDP не ограничена (се­анс заканчивается при отбое от одного из пользователей). Когда нули стоят в полях начала и окончания сеанса, сеанс длится непрерывно (полупостоянное соединение). Продолжительность непрерывной сессии лежит в пределах от 2 до 6 месяцев.

Строка сданными соединениями начинается с буквы «с». В первом д втором полях указываются тип сети (IN ) и тип адреса (IP4), в тре­тьем — IP-адрес узла источника запроса (192.2.17.12).

За ней следует строка с медиапараметрами, начинающаяся с буквы «т». Первый параметр — тип медиа: это может быть речь (audio), видео (video), передача данных (application, data) или данные, передаваемые по дополнительному каналу управления конференцией в течение се­анса (control). Второй параметр — это номер порта, на который посы­лаются пользовательские пакеты (49170). Значение этого параметра за­висит от типа сети, записанного в строке «с» и от типа транспорт! юго протокола. Для протокола RTP номер порта обязательно четное число. Далее следует тип транспортного протокола Если в строке «с» в поле «тип адреса» стоит IP4, то это означает, что трафик должен переда­ваться с применением протоколов RTP и UDP, на что указывает за­пись RTP/AVP—протокол RTP, предназначенный для перед ачи аудио- и видеоинформации (AVP — Audio/Video profile). Последнее поле ука­зывает на формат медиапотока, и его параметры определены профи­лем RTP/AVP. В поле формата могут содержаться типы полезного поля РТ (Payload type). Значение РТ может соответствовать одному из типов кодеков. На рис. 4.26 в строке «т» содержатся три типа РТ, соответст­вующие следующим типам кодеков: 0 — PCMU (G.711, р-закон ком- пандирования), 4 — G.723,8 — РСМА (G.711, А-закон компандирова- ния). Первое в строке значение РТ устанавливается по умолчанию.

Прокси-сервер, приняв запрос INVITE, производит аутентифи­кацию пользователя А и посылает в обратном направлении ответ 100 Trying, являющийся подтверждением приема сообщения INVITE (рис. 4.27). В этом сообщении в основном повторяется содержимое

SIP/2.0 Trying

Via:SIP/2.0/UDP locat3.otdelen 1 .com;branch=z9hG4bK776asdhds; received=192.2.17.12

To:36074<sip:[e-mail]>;tag=287447

From:33051<sip:[e-mail]>;tag=1928301774

Call-ID:a84b4c76e66710@otdelen1 .com

CSeq: 314159 INVITE

Contact:<sip:[e-mail]>

Content-Length.O

Рис. 4.27. Содержание ответа Trying

INVITE sip:36074@otdelen1 .com SIP/2.0 Via:SIP/2.0/UDPserv1.otdelen1.com;branch=z9hG4bK8906fdrtk Via:SIP/2.0/UDP locat3.otdelen1 .com;branch=z9hG4bK776asdhds; received= 192.2.17.12 Max-Forwards: 69

To:36074<sip:[e-mail]>;tag=287447 From:33051 <sip:33051 @otdelen 1 .com>;tag=1928301774 Call-ID:a84b4c76e66710@otdelen1 .com CSeq:314159 INVITE Contact:<sip:[e-mail]> Content-Type:application/sdp Content-Length: 162

v=0

o=- 2890844526 2890844526 IN IP4 locat3.otdelen1.com

s=-

t=28733974960 C=IN IP4 192.2.17.12 m=audio 49170 RTP/AVP 8 04

Рис. 4.28. Содержание второго запроса INVITE

запроса INVITE, за исключением тела сообщения. Теперь прокси- сервер пересылает запрос INVITE IP-телефону пользователя Б. В но­вом запросе есть два отличия (рис. 4.28). Во-первых, в нем добавле­на строка Via, содержащая адрес прокси-сервера (servl .otdelenl) и параметр «received», содержащий IP-адрес узла отправителя запроса.

IP-телефон обнаруживает в запросе INVITE имя пользователя Б и, если пользователь Б не занят другим разговором, посылает ему вызов. Обработав запрос INVITE, IP-телефон передает прокси-сер­веру ответ 180 Ringing (рис. 4.29).

Рис. 4.29. Содержание ответа Ringing

SIP/2.0 180 Ringing	%
Vla:SIP/2.0/UDP servl .otdelenl ,com;branch=z9hG4bK8906fdrtk;
received 192.2.17.104
Vla:SIP/2.0/UDP locat3.otdelenl ,com;branch=z9hG4bK776asdhds;
received=192.2.17.12
To:36074<sip:36074@otdelen 1 ,com>;tag=287447
From:33051 <sip:33051 @otdelen1 ,com>;tag=1928301774
Call-ID:a84b4c76e66710@otdelen1 .com
CSeq:314159 INVITE
Contact:<sip:36074@otdelen1 ,com>
Content-Length:0

Это сообщение включает заголовки Via, То, From, Call-Id и Cseq с таким же содержанием, что и в последнем запросе INVITE. В первом заголовке Via добавлен 1Р-ацрес прокси-сервера: 192.2.17.104. Заголо­вок Contact содержит адрес пользователя Б. Прокси-сервер пересылает ответ 180 Ringing терминалу пользователя А, исключив из него заголо­вок: Via:SIP/2.0/UDP serv 1 .otdelen 1 .com; branc = z9hG4bK8906fdrtk; received 192.2.17.104. После приема этого сообщения IP-телефон пользователя А посылает сигнал контроля посылки вызова.

Когда пользователь Б ответит на вызов, от его IP-телефона пере­дается ответ типа 200 ОК (рис. 4.30), который принимается прокси- сервером. Заголовки и их содержание в основном совпадают с сооб­щением 180 Ringing, но в ответе 200 ОК передаются данные по про­токолу SDP, характеризующие терминал пользователя Б. В строке «о» последний параметр (locat25.otdelenl) представляет собой адрес узла пользователя Б. Строка «с» включает IP-адрес IP-телефона пользователя Б (192.2.17.204). Из строки «т» видно, что IP-телефон пользователя Б может работать только с двумя типами аудиокодеков. Прокси-сервер пересылает ответ 200 О К терминалу пользователя А Это сообщение повторяет прежнее, но содержит только один заголо­вок: Via- SIP/2.0/UDPlocat3.otdelenl.com;branch=z9hG4bK776asdhds; received= 192.2.17.12.

В качестве подтверждения приема ответа 200 ОК IP-телефон по­сылает прокси-серверу запрос АСК (рис. 4.31), который завершает процесс соединения. Этот запрос имеет заголовки Via, То, From, Call-ID и Max-Forwards с таким же содержанием, что и в запросе INVITE, посланном от IP-телефона пользователя А

SIP/2.0 200 OK

Via: SIP/2.0/UDP serv/1.otdelenl .com;branch=z9hG4bK8906fdrtk; received 192.2.17.104

Via: SIP/2.0/UDP locat3.otdelen1.com;branch=z9hG4bK776asdhds; received=192.2.17.12

To: 36074<sip:36074@otdelen1 ,com>;tag=287447

From: 33051 <sip:33051 @otdelen1 ,com>;tag=1928301774

Call-ID: a84b4c76e66710@otdelen1 .com

CSeq:314159 INVITE

Contact: <sip:36074@otdelen 1 .com>

Content-Type:application/sdp

Content-Length: 160

v=0

o=- 2890844527 2890844527 IN IP4 locat25.otdelen1 .com s=-

t=2873397497 0 C=IN IP4 192.2.17.204 m=audio 3456 RTP/AVP 8 4

Рис. 4.30. Содержание ответа OK

ACK sip:36074@otdelen 1 .com SIP/2.0

Via:SIP/2.0/UDP locat3.otdelen1 ,com;branch=z9hG4bK776asdhds Max-Forwards:70

To:36074<sip:36074@otde!en1.com>;tag=287447

From:33051<sip:[e-mail]>;tag=1928301774

Call-ID:[e-mail]

CSeq:314159 ACK

Content-Length:0

Рис. 4.31. Содержание запроса ACK

Прокси-сервер пересылает запрос ACK терминалу пользователя Б, добавив заголовок Via и уменьшив значение заголовка Max-Forwards на единицу, аналогич­но тому как это было сделано для запроса INVITE, посланному от прокси-сервера к IP-телефону пользователя Б.

Оба IP-телефона переходят в разговорное состояние и между ними в обоих направлениях пересылаются речевые пакеты с использова­нием протоколов RTP и RTCP.

Соединение нарушается при приеме сигнала отбоя от любого из пользователей (см. рис. 4.25 — от пользователя Б). IP-телефон посы­лает прокси-серверу запрос BYE (рис. 4.32),

BYE sip:33051 @otdelen 1 .com SIP/2.0

Via:SIP/2.0/UDP locat25.otdelen1 .com;branch=z9hG4bK776as45kj Max-Forwards:70

From:36074<sip:[e-mail]>;tag=38794634 To:33051 <sip:33051 @otdelen 1 ,com> ;tag=475931 Call-ID:a84b4c76e66710@otdelen 1 .com CSeq:749 BYE Content-Length:0

Рис. 4.32. Содержание запроса BYE

в стартовой строке которой находится адрес пользователя А. Заголовки Via, Max-Forwards, То, From, Call-ID, Cseq формируются по подобию запроса INVITE, но с учетом обратного направления передачи: содержимое заголов­ков То и From меняется местами и появляются новые идентифика­торы, за исключением Call-ID. Прокси-сервер пересылает это со­общение другому IP-телефону. В новом запросе BYE добавляется заголовок Via и изменяется значение в заголовке Max-Forwards.

В качестве подтверждения приема запроса BYE терминал пользо­вателя А посылает прокси-серверу ответ 200 ОК, который пересы­лает этот ответ терминалу пользователя Б.

В обоих IP-телефонах сеанс связи закрывается.

Теперь рассмотрим вариант соединения напрямую между теми же пользователями сети, в которой пользователи могут менять место­положение (рис. 4.33). В соединении участвуют серверы перенап­равления и регистрации.

Вначале IP-телефон пользователя А посылает серверу перена­правления запрос INVITE с известным ему адресом пользователя Б: [e-mail]. Сервер перенаправления передает запрос сер­веру регистрации, который обращается к базе данных о местополо­жении пользователей. Сервер регистрации передает серверу пере­направления ответе текущим адресом пользователя Б, а последний посылает терминалу пользователя А ответ 302 Moved Temporarily с текущим адресом пользователя Б, содержащемся в заголовке Contact (например, 34155@otdelen2). IP-телефон пользователя А передает серверу перенаправления запрос АСК, указывающий на окончание взаимодействия с ним.

Теперь IP-телефон пользователя А посылает на адрес IP-телефона пользователя Б новый запрос INVITE, в стартовой строке которого записан текущий адрес пользователя Б (34155@otdelen2). В новом

запросе INVITE значение заголовка Cseq увеличивается на единицу, а значение Call-ID сохраняется. Неизменными остаются поля заголовков То и From. В дальнейшем от IP-телефона пользователя Б передаются ответы 180 Ringing и 200 ОК, а от IP-телефона пользовате­ля А — запрос АСК в соответствии с тем, как это было описано ра­нее. После состоявшегося разговора соединение нарушается посыл­кой запроса BYE и ответа 200 ОК.

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