Разработка алгоритма взаимодействия протоколов сигнализации в сети IP-телефонии на базе Softswitch

Пример SIP- сети

Резюмируя все сказанное выше, отметим, что сети SIP строятся из элементов трех основных типов: терминалов, прокси-серверов и серверов переадресации. На рис. 3 приведен пример возможного построения сети SIP.

Рис. 3 Пример построения сети SIP

Стоит обратить внимание на то что, что SIP-серверы, представленные на рис. 3, являются отдельными функциональными сетевыми элементами. Физически они могут быть реализованы на базе серверов локальной сети, которые, помимо выполнения своих основных функций, будут также обрабатывать SIP-сообщения. Терминалы же могут быть двух типов: персональный компьютер со звуковой платой и программным обеспечением SIP-клиента (UA) или SIP-телефон, подключающийся не посредственно к ЛВС Ethernet (SIР-телефоны, производимые компанией Cisco Systems, недавно появились на российском рынке). Таким образом, пользователь локальной вычислительной сети передает все запросы к своему SlP-серверу, а тот обрабатывает их и обеспечивает установление соединений. Путем программирования сервер можно застроить на разные алгоритмы работы: он может обслуживать часть пользователей (например, руководство предприятия или особо важных лиц) по одним правилам, а другую часть - по иным. Возможно также, что сервер будет учитывать категорию и срочность вызовов, а также вести начисление платы за разговоры.

Рис. 4 Структурная схема организации услуг SIP-сервера

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

2.3.2 Сообщения протокола SIP

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

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

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

Стартовая строка
Заголовки
Пустая строка
Тело сообщения

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

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

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

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

Заголовки сообщений SIP

В протоколе SIP определено четыре вида заголовков (Таблица 1):

· Общие заголовки, присутствующие в запросах и ответах;

· Заголовки содержания, переносят информацию о размере тела сообщения или об источнике запроса (начинаются со слова);

· Заголовки запросов, передающие дополнительную информацию о запросе;

· Заголовки ответов, передающие дополнительную информацию об ответе.

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

Ниже представлены наиболее часто используемые заголовки.

Заголовок Call-ID - уникальный идентификатор сеанса связи или всех регистрации отдельного клиента, он подобен метке соединения (call reference) в сигнализации DSS-1 . Значение идентификатору присваивает сторона, которая инициирует вызов. Заголовок Call-ID состоит из буквенно-числового значения и имени рабочей станции, которая присвоила значение этому идентификатору. Между ними должен стоять символ @, например, 2345call@rts.domen.ru Возможна следующая ситуация: к одной мультимедийной конференции относятся несколько соединений, тогда все они будут иметь разные идентификаторы Call-ID.

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

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

Заголовок From - идентифицирует отправителя запроса; по структуре аналогичен полю То.

Таблица 1. Виды заголовков сообщений SIP

Общие заголовки	Заголовки содержания	Заголовки запросов	Заголовки ответов
Call-ID (идентификатор сеанса связи)	Content-Encoding (кодирование тела сообщения)	Accept (принимается)	Allow (разрешение)
Contact (контактировать)	Content-Length (размер тела сообщения)	Accent-Encoding (метод кодирования поддерживается)	Proxy-Authenticate (подтверждение подлинности прокси-сервера)
CSeq (последовательность)	Content-Type (тип содержимого)	Accent-Language (язык поддерживается)	Retro-After (повторить через некоторое время)
Date (Дата)		Authorization (авторизация)	Server (сервер)
Encryption (шифрование)			Unsupported (не поддерживается)
Expires (срабатывание таймера)		Hide (скрыть)	Warning (предупреждение)
From (источник запроса)		Max-Forwards (максимальное количество переадресаций)	WWW-Authenticate (подтверждение подлинности WWW-сервера)
Record-Route (запись маршрута)		Organization (организация)
Timestamp (метка времени)		Priority (приоритет)
То (Адресат)		Proxy-Authorization (авторизация прокси-сервера)
Via (через)		Proxy-Require (требуется прокси-сервер)
		Route (маршрут)
		Require (требуется)
		Response-Key (ключ кодирования ответа)
		Subject (тема)
		User-Agent (агент пользователя)

Заголовок CSeq - уникальный идентификатор запроса, относящегося к одному соединению. Он служит для корреляции запроса с ответом на него. Заголовок состоит из двух частей: натурального числа из диапазона от 1 до 232 и типа запроса. Сервер должен проверять значение CSeq в каждом принимаемом запросе и считать запрос новым, если значение CSeq больше предыдущего. Пример заголовка: CSeq: 2 INVITE.

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

Например, запрос на своем пути обрабатывался двумя прокси-серверами: сначала сервером domen.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля:

Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721 e418c4.1

Via: SIP/2.0/UDP domen.ru: 5060, где параметр означает, что на сервере sip.telecom.com запрос был размножен и направлен одновременно по разным направлениям, и наш запрос был передан по направлению, которое идентифицируется следующим образом: 721е418c4.1.

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

В заголовок Record-route прокси-сервер вписывает свой адрес - SIP URL, - если хочет, чтобы последующие запросы прошли через него.

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

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

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

Таблица 2. Связь заголовков с запросамии ответами протокола SIP v2.0

Название заголовка	Место использования заголовка	ACK	BYE	CAN	INV	OPT	REG
Accept	Заголовок в запросах	F	F	F	0	0	0
Accept	Заголовок в ответе 415	F	F	F	0	0	0
Accent-Encoding	Заголовок в запросах	F	F	F	0	0	0
Accent-Encoding	Заголовок в ответе 415	F	F	F	0	0	0
Accent-Language	Заголовок в запросах	F	0	0	0	0	0
Accent-Language	Заголовок в ответе 415	F	0	0	0	0	0
Allow	Заголовок в ответе 200	F	F	F	F	M	F
Allow	Заголовок в ответе 405	0	0	0	0	0	0
Authorization	Заголовок в запросах	0	0	0	0	0	0
Call-ID	Общий заголовок - копируется из запросов в ответы	М	М	М	М	М	М
Contact	Заголовок в запросах	0	F	F	0	0	0
Contact	Заголовок в ответах 1хх	F	F	F	0	0	F
Contact	Заголовок в ответах 2хх	F	F	F	0	0	0
Contact	Заголовок в ответах Зхх	F	0	F	0	0	0
Contact	Заголовок в ответе 485	F	0	F	0	0	0
Content-Encoding	Заголовки содержания	0	F	F	0	0	0
Content-Length	Заголовки содержания	0	F	F	0	0	0
Content-Type	Заголовки содержания	*	F	F	*	*	*
Cseq	Общий заголовок - копируется из запросов в ответы	М	М	М	М	М	М
Date	Заголовок в ответах	0	0	0	0	0	0
Encryption	Заголовок в ответах	0	0	0	0	0	0
Expires	Заголовок в ответах	F	F	F	0	F	0
From	Общий заголовок - копируется из запросов в ответы	М	М	М	М	М	М
Hide	Заголовок в запросах	0	0	0	0	0	0
Max-Forwards	Заголовок в запросах	0	0	0	0	0	0
Organization	Общий заголовок	F	F	F	0	0	0
Proxy-Authenticate	Заголовок в ответе 407	0	0	0	0	0	0
Proxy-Authorization	Заголовок в запросах	0	0	0	0	0	0
Proxy-Require	Заголовок в запросах	0	0	0	0	0	0
Priority	Заголовок в запросах	F	F	F	0	F	F
Require	Заголовок в запросах	0	0	0	0	0	0
Retry-After	Заголовок в запросах	F	F	F	P	F	0
Retry-After	Заголовок в ответах 404, 480, 486, 503, 600 и 603	0	0	0	0	0	0
Response-Key	Заголовок в запросах	F	0	0	0	0	0
Record-Route	Заголовок в запросах	0	0	0	0	0	0
Record-Route	Заголовок в ответах 2хх	0	0	0	0	0	0
Route	Заголовок в запросах	0	0	0	0	0	0
Server	Заголовок в ответах	0	0	0	0	0	0
Subject	Заголовок в запросах	F	F	F	0	F	F
Timestamp	Общий заголовок	0	0	0	0	0	0
To	Общий заголовок - копируется из запросов в ответы	М	М	М	М	М	М
Unsupported	Заголовок в ответе 420	0	0	0	0	0	0
User-Agent	Общий заголовок	0	0	0	0	0	0
Via	Общий заголовок - копируется из запросов в ответы	М	М	М	М	М	М
Warning	Заголовок в ответах	0	0	0	0	0	0
WWW-Authenticate	Заголовок в ответе 401	0	0	0	0	0	0

2.3.3 Алгоритмы установления соединения

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

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

Установление соединения с участием сервера переадресации

Здесь описан алгоритм установления соединения с участием сервера переадресации вызовов. Администратор сети сообщает пользователям адрес сервера переадресации. Вызывающий пользователь передает запрос INVITE (1) на известный ему адрес сервера переадресации и порт 5060, используемый по умолчанию (Рисунок 9). В запросе вызывающий пользователь указывает адрес вызываемого пользователя. Сервер переадресации запрашивает текущий адрес нужного пользователя у сервера определения местоположения (2), который сообщает ему этот адрес (3). Сервер переадресации в ответе 302 Moved temporarily передает вызывающей стороне текущий адрес вызываемого пользователя (4), или он может сообщить список зарегистрированных адресов вызываемого пользователя и предложить вызывающему пользователю самому выбрать один из них. Вызывающая сторона подтверждает прием ответа 302 посылкой сообщения АСК (5).

Рис. 9 Сценарий установления соединения через сервер переадресации

Теперь вызывающая сторона может связаться непосредственно с вызываемой стороной. Для этого она передает новый запрос INVITE (6) с тем же идентификатором Call-ID, но другим номером CSeq. В теле сообщения INVITE указываются данные о функциональных возможностях вызывающей стороны в формате протокола SDP. Вызываемая сторона принимает запрос INVITE и начинает его обработку, о чем сообщает ответом 100 Trying (7) встречному оборудованию для перезапуска его таймеров. После завершения обработки поступившего запроса оборудование вызываемой стороны сообщает своему пользователю о входящем вызове, а встречной стороне передает ответ 180 Ringing (8). После приема вызываемым пользователем входящего вызова удаленной стороне передается сообщение 200 OK (9), в котором содержатся данные о функциональных возможностях вызываемого терминала в формате протокола SDP. Терминал вызывающего пользователя подтверждает прием ответа запросом АСК (10). На этом фаза установления соединения закончена и начинается разговорная фаза.

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

Установление соединения с участием прокси-сервера

Здесь описан алгоритм установления соединения с участием прокси-сервера. Администратор сети сообщает адрес этого сервера пользователям. Вызывающий пользователь передает запрос INVITE (1) на адрес прокси-сервера и порт 5060, используемый по умолчанию (Рисунок 10). В запросе пользователь указывает известный ему адрес вызываемого пользователя. Прокси-сервер запрашивает текущий адрес вызываемого пользователя у сервера определения местоположения (2), который и сообщает ему этот адрес (3). Далее прокси-сервер передает запрос INVITE непосредственно вызываемому оборудованию (4). Опять в запросе содержатся данные о функциональных возможностях вызывающего терминала, но при этом в запрос добавляется поле Via с адресом прокси-сервера для того, чтобы ответы на обратном пути шли через него. После приема и обработки запроса вызываемое оборудование сообщает своему пользователю о входящем вызове, а встречной стороне передает ответ 180 Ringing (5), копируя в него из запроса поля То, From, Call-ID, CSeq и Via. После приема вызова пользователем встречной стороне передается сообщение 200 OK (6), содержащее данные о функциональных возможностях вызываемого терминала в формате протокола SDP. Терминал вызывающего пользователя подтверждает прием ответа запросом АСК (7). На этом фаза установления соединения закончена и начинается разговорная фаза.

По завершении разговорной фазы одной из сторон передается запрос BYE (8), который подтверждается ответом 200 OK (9).

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

Рис. 10 Сценарий установления соединения через прокси-сервер

2.4 Принцип декомпозиции шлюза

В недавнем прошлом рабочая группа MEGACO комитета IETF разработала протокол управления шлюзами - Media Gateway Control Protocol (MGCP). Ранее подобный протокол под названием SGCP - Simple Gateway Control Protocol (простой протокол управления шлюзами) - был разработан компанией Telecordia (бывшая компания Bellcore). фирма Level 3 предложила сходный протокол управления оборудованием, реализующим технологию маршрутизации пакетов IP, - IDCP (IP Device Control Protocol). Оба они впоследствии были объединены в протокол MGCP.

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

· транспортный шлюз - Media Gateway, который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование;

· устройство управления - Call Agent, выполняющее функции управления шлюзом;

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

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

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

Перенос сообщений протокола MGCP обеспечивает протокол не гарантированной доставки - UDP. Кроме того, рабочая группа SIGTRAN комитета IETF в настоящее время разрабатывает механизм взаимодействия устройства управления и шлюза сигнализации. Последний должен принимать поступающие из ТфОП сигнальные единицы подсистемы МТР системы сигнализации ОКС7 и передавать сигнальные сообщения верхнего, пользовательского уровня к устройству управления. Основное внимание рабочей группы SIGTRAN уделено вопросам разработки наиболее эффективного механизма передачи сигнальной информации по IP-сетям. Следует отметить, что существует несколько причин, уже упонинавшихся ранее, по которым пришлось отказаться от использования для этой цели протокола TCP. Вместо него рабочая группа SIGTRAN предлагает использовать протокол Stream Control Transport Protocol (SCTP), который имеет ряд преимуществ перед протоколом TCP. Основным из этих преимуществ является значительное снижение времени доставки сигнальной информации и, следовательно, времени установления соединения -одного из важнейших параметров качества обслуживания.

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

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

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

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

Основной недостаток этого подхода - незаконченность стандартов. Функциональные блоки распределенных шлюзов, разработанные разными фирмами-производителями телекоммуникационного оборудования, практически несовместимы. Функции устройства управления шлюзами точно не определены. Не стандартизированы механизмы переноса сигнальной информации от шлюза сигнализации (Signalling Gateway) к устройству управления и в обратном направлении. К недостаткам можно отнести также отсутствие стандартизированного протокола взаимодействия между устройствами управления. Кроме того, протокол MGCP, являясь протоколом управления шлюзами, не предназначен для управления соединениями с участием терминального оборудования пользователей (IP-телефонами). Это означает, что в сети, построенной на базе протокола MGCP, для управления терминалами должен присутствовать привратник или сервер SIP.

2.5 Сравнение подходов построения сети IP-телефонии

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

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

Основным недостатком третьего из приведенных в данном параграфе подходов является незаконченность стандартов.

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

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

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

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

В последнем из упомянутых подходов (в проекте версии 4 рекомендации Н.323) ITU-Т ввел принцип декомпозиции шлюзов, использованный в третьем подходе.

Управление функциональными блоками распределенного шлюза будет осуществляться контроллером шлюза - MGC (Media Gateway Controller) при помощи протокола MEGACO/H.248. В проекте версии 4 рекомендации Н.323 предусмотрена также возможность прозрачной передачи сигнализации ОКС7 и других видов сигнализации по сетям IP-телефонии и обработка сигнализации всех видов привратником без преобразования в сигнальные сообщения Н.225.0.

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

Размещено на allbest.ru

...