Сценарий установления соединения шлюзом без привратника

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

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

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

В сетях связи общего пользования применяется двухступенчатый способ, при котором вызывающий абонент сначала набирает телефонный номер шлюза и устанавливает с ним соединение. Затем абонент вводит свой персональный код для идентификации и номер вызываемого абонента; эта информация передается по проключенному разговорному тракту сигналами DTMF (двухтональный многочастотный аналоговый сигнал, используемый для набора телефонного номера). Следует отметить, что необходимость в наборе персонального кода возникает не всегда, так как номер вызывающего абонента может содержаться в сигнальных сообщениях систем сигнализации DSS1 и ОКС7, а при использовании систем сигнализации 2ВСК или аналоговых систем сигнализации - определяться при помощи АОН.

Существует несколько способов идентификации абонентов. В первом случае alias-адрес абонента (PIN-код или телефонный номер) шлюз передает привратнику в сообщении ARQ. Во втором случае идентификационный номер вызывающего абонента, набранный с помощью DTMF, передается специальному серверу. Кроме того, в ТфОП вызов может обрабатываться системой обработки телефонных карт, которая отвечает за идентификацию пользователей и начисление платы. Существует еще один вариант, когда функции идентификации абонентов и начисления оплаты возложены на опорную АТС, к которой подключен шлюз.

Во втором сценарии, когда пользователь IP-сети вызывает абонента ТфОП при помощи шлюза, с точки зрения протоколов Н.323 соединение устанавливается так же, как описанное соединение участников, включенных в сеть с маршрутизацией пакетов IP. Вызываемое оборудование организует сигнальный канал Н.225.0 со шлюзом (при участии или без участия привратника). Далее передается требование на установление соединения Setup, которое содержит телефонный номер вызываемого абонента в формате Е. 164. Пока устанавливается соединение в ТфОП, шлюз может передать вызывающему абоненту IP-сети сообщение Call Proceeding, чтобы перезапустить таймеры, если в течение 4 секунд после приема сообщения Setup он не передал сообщения Alerting, Connect или Release Complete. Чтобы указать, что вызов выходит за пределы IP-сети, в сообщения Alerting, Call Proceeding, Progress и Connect должен включаться информационный элемент Progress Indicator.

Типовой сценарий установления соединения без привратника показан на рисунке 1.

Рисунок 1 - Типовой сценарий установления соединения без привратника

SETUP (запрашивает установление соединения).

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

ALERTING (указывает вызывающей стороне, что вызываемый терминал звонит).

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

DISCONNECT (отправляет указание на запрос для разрыва соединения, желание завершить соединение и прервать связь обозначается определённым стандартным цифровым кодом).

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

RELEASE COMPLETE (отправляется получателем сигнала на разъединение, указывая, что связь завершена полностью).

АТС 1 посылает сообщение Q.931 Setup на шлюз 1, в котором указывается номер вызывающего и вызываемого пользователей.

Шлюз 1 принимает сообщение Q.931 Setup, обрабатывает его, на основании адресной информации, находящейся в поле Called Party Number (номер вызывающего абонента). ПО шлюза обращается к файлу callroute.cfg(правила маршрутизации вызова), по которому определяется IP-адрес встречного шлюза, который может обслужить данный вызов.

Шлюз 2 принимает сообщение, если IP-адрес (или часть адреса), с которого оно передано, находится в файле permissions.cfg(правила доступа к шлюзу из сети IP). Из сообщения H.225 Setup берется номер вызываемого пользователя, который (номер) отправляется в сообщении Q.931 Setup на АТС 2.

Вызываемое оборудование отвечает на Setup сообщением Call Proceeding.

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

На АТС 1 передается сообщение Q.931 Alerting, а абоненту А выдается сигнал контроль посылки вызова (КПВ). После ответа АТС 2 генерирует сообщение Q.931 Connect.

Шлюз 2 подтверждает прием Q.931 Connect сообщением Q.931 Connect ACK.

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

После открытия управляющего канала H.245 начинается обмен данными о функциональных возможностях оборудования. Шлюзы обмениваются сообщениями Terminal Capability Set (TCS), в которых указываются возможные алгоритмы декодирования принимаемой информации. Следует отметить, что сообщение Terminal Capability Set должно быть первым сообщением, передаваемым по управляющему каналу.

Оборудование, принявшее сообщение TCS от другого оборудования, подтверждает его получение передачей сообщения TerminalCapabilitySetAck (TCSAck).

Затем инициируется процедура определения ведущего/ведомого оборудования, необходимая для разрешения конфликтов, возникающих между двумя устройствами при организации конференции, когда оба они могут быть активными контроллерами конференций, или между двумя устройствами, пытающимися одновременно открыть двунаправленные логические каналы. В ходе процедуры устройства обмениваются сообщениями Master Slave Determination (MSD). В ответ на полученные сообщения MSD оба устройства передают сообщения MasterSlaveDeterminationAck(MSDAck), в которых указывается: какое из этих устройств является для данного соединения ведущим, а какое – ведомым.

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

В ответ на сообщение OLCоборудование должно передать подтверждение open Logical ChannelAck (OLCAck), в котором указывается транспортный адрес, на который передающей стороне следует посылать RTP пакеты, а также транспортный адрес канала RTCP.

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

После окончания разговорной фазы начинается фаза разрушения соединения. Оборудование пользователя, инициирующего разъединение, прекращает передачу речевой информации, закрывает логические каналы и передает по управляющему каналу сообщение H.245 end Session Command, означающее, что пользователь хочет завершить соединение. Ожидается сообщение end Session Command от встречного оборудования, после чего управляющий канал Н.245 закрывается.

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