SIP- сети
Резюмируя все сказанное выше, отметим, что сети SIP строятся из элементов трех основных типов: терминалов, прокси-серверов и серверов переадресации. На рис. 7.3 приведен пример возможного построения сети SIP.
Рис. 7.3 Пример построения сети SIP
Стоит обратить внимание на то что, что StP-серверы, представленные на рис. 7.3, являются отдельными функциональными сетевыми элементами. Физически они могут быть реализованы на базе серверов локальной сети, которые, помимо выполнения своих основных функций, будут также обрабатывать SIP-сообщения. Терминалы же могут быть двух типов: персональный компьютер со звуковой платой и программным обеспечением SIP-клиента (UA) или SIP-телефон, подключающийся не посредственно к ЛВС Ethernet <SIР-телефоны, производимые компанией Cisco Systems, недавно появились на российском рынке). Таким образом, пользователь локальной вычислительной сети передает все запросы к своему SlP-серверу, а тот обрабатывает их и обеспечивает установление соединений. Путем программирования сервер можно застроить на разные алгоритмы работы: он может обслуживать часть пользователей (например, руководство предприятия или особо важных лиц) по одним правилам, а другую часть - по иным. Возможно также, что сервер будет учитывать категорию и срочность вызовов, а также вести начисление платы за разговоры.
Структурная схема организации услуг SIP-сервера представлена на рисунке 7.4.
Рис. 7.4 Структурная схема организации услуг SIP-сервера
Модуль управления услугами отвечает за предоставление услуг и за общее управление сервером. Принятые сервером запросы и ответы поступают в модуль управления услугами и обрабатываются им, на основании чего определяется реакция на полученные сообщения. Интерфейс человек-машина позволяет гибко менять настройки сервера и вести мониторинг сети.
7.5 Сообщения протокола SIP
7.5.1 Структура сообщений
Согласно архитектуре “клиент-сервер” все сообщения делятся на запросы, передаваемые от клиента к серверу, и на ответы сервера клиенту.
Например, чтобы инициировать установление соединения, вызывающий пользователь должен сообщить серверу ряд параметров, в частности, адрес вызываемого пользователя, параметры информационных каналов и др. Эти параметры передаются в специальном SIP-запросе. От вызываемого пользователя к вызывающему передается ответ на запрос, также содержащий ряд параметров.
Все сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP, как уже упоминалось ранее, идентичны используемым в протоколе HTTP. На рисунке 7.5 представлена структура сообщений протокола SIP.
| Стартовая строка |
| Заголовки |
| Пустая строка |
| Тело сообщения |
Рис. 7.5 Структура сообщений протокола SIP
Стартовая строка представляет собой начальную строку любого SIP-сообщения. Если сообщение является запросом, в этой строке указываются тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в стартовой строке указываются номер версии протокола, тип ответа и его короткая расшифровка, предназначенная только для пользователя.
Заголовки сообщений содержат сведения об отправителе, адресате, пути следования и др., в общем, переносят информацию, необходимую для обслуживания данного сообщения. О типе заголовка можно узнать по его имени. Оно не зависит от регистра (т.е. буквы могут быть прописные и строчные), но обычно имя пишут с большой буквы, за которой идут строчные.
Сообщения протокола SIP могут содержать так называемое тело сообщения. В запросах АСК, INVITE и OPTIONS тело сообщения содержит описание сеансов связи, например, в формате протокола SDP. Запрос BYE тела сообщения не содержит, а ситуация с запросом REGISTER подлежит дальнейшему изучению. С ответами дело обстоит иначе: любые ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.
7.5.2 Заголовки сообщений
В протоколе SIP определено четыре вида заголовков (Таблица 7.1):
• Общие заголовки, присутствующие в запросах и ответах;
• Заголовки содержания, переносят информацию о размере тела сообщения или об источнике запроса (начинаются со слова “Content”);
• Заголовки запросов, передающие дополнительную информацию о запросе;
• Заголовки ответов, передающие дополнительную информацию об ответе.
Заголовок содержит название, за которым, отделенное двоеточием, следует значение заголовка. В поле значения содержатся передаваемые данные. Следует отметить, что если сервер принимает сообщения, заголовки которых ему не известны, то эти заголовки игнорируются.
Ниже представлены наиболее часто используемые заголовки.
Заголовок Call-ID - уникальный идентификатор сеанса связи или всех регистрации отдельного клиента, он подобен метке соединения (call reference) в сигнализации DSS-1 [7]. Значение идентификатору присваивает сторона, которая инициирует вызов. Заголовок Call-ID состоит из буквенно-числового значения и имени рабочей станции, которая присвоила значение этому идентификатору. Между ними должен стоять символ @, например, 2345call@rts.loniis.ru Возможна следующая ситуация: к одной мультимедийной конференции относятся несколько соединений, тогда все они будут иметь разные идентификаторы Call-ID.
Заголовок То - определяет адресата. Кроме SIP-адреса здесь может стоять параметр “tag” для идентификации конкретного терминала пользователя (например, домашнего, рабочего или сотового телефона) в том случае, когда все его терминалы зарегистрированы под одним адресом SIP URL. Запрос может множиться и достичь разных терминалов пользователя; чтобы их различать, необходимо иметь метку tag. Ее вставляет в заголовок терминальное оборудование вызванного пользователя при ответе на принятый запрос.
Если необходим визуальный вывод имени пользователя, например, на дисплей, то имя пользователя также размещается в поле То.
Заголовок From - идентифицирует отправителя запроса; по структуре аналогичен полю То.
Таблица 7.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 (максимальное количество переадресаций) | VWVW-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 указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет поле со своим адресом. При необходимости (например, чтобы обеспечить секретность) действительный адрес может скрываться.
Например, запрос на своем пути обрабатывался двумя прок си-серверами: сначала сервером loniis.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля:
Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721 e418c4.1 Via: SIP/2.0/UDP loniis.ru: 5060,
где параметр “branch” означает, что на сервере sip.telecom.com запрос был размножен и направлен одновременно по разным направлениям, и наш запрос был передан по направлению, которое идентифицируется следующим образом: 721е418c4.1.
Содержимое полей Via копируется из запросов в ответы на них, и каждый сервер, через который проходит ответ, удаляет поле Via со своим именем.
В заголовок Record-route прокси-сервер вписывает свой адрес - SIP URL, - если хочет, чтобы последующие запросы прошли через него.
Заголовок Content-Type определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP, включается в тело сообщения.
Заголовок Content-Length указывает размер тела сообщения.
После того, как мы рассмотрели наиболее часто встречающиеся заголовки сообщений протокола SIP, следует обратить внимание на то, что запросы и ответы на них могут включать в себя лишь определенный набор заголовков (Таблица 7.2). Здесь опять буква “М” означает обязательное присутствие заголовка в сообщении, буква “О” -необязательное присутствие, буква “F” запрещает присутствие заголовка.
Таблица 7.2 Связь заголовков с запросами и ответами протокола SIPv2.Q
| Название заголовка | Место использования заголовка | АСК | 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 | М | 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 |
* Примечание - поле необходимо только в случае, когда тело сообщения содержит какую-либо информацию, т.е. не является пустым.
7.5.3 Запросы
В настоящей версии протокола SIP определено шесть типов запросов. Каждый из них предназначен для выполнения довольно широкого круга задач, что является явным достоинством протокола SIP, так как благодаря этому число сообщений, которыми обмениваются терминалы и серверы, сведено к минимуму. С помощью запросов клиент сообщает о текущем местоположении, приглашает пользователей принять участие в сеансах связи, модифицирует уже установленные сеансы, завершает их и т.д. Сервер определяет тип принятого запроса по названию, указанному в стартовой строке. В той же строке в поле Request-URI указан SIP-адрес оборудования, которому этот запрос адресован. Содержание полей То и Request-URI может различаться, например, в поле То может быть указан публикуемый адрес абонента, а в поле Request-URI - текущий адрес пользователя.
Запрос INVITE приглашает пользователя принять участие в сеансе связи. Он обычно содержит описание сеанса связи, в котором указывается вид принимаемой информации и параметры (список возможных вариантов параметров), необходимые для приема информации, а также может указываться вид информации, которую вызываемый пользователь желает передавать. В ответе на запрос типа INVITE указывается вид информации, которая будет приниматься вызываемым пользователем, и, кроме того, может указываться вид информации, которую вызываемый пользователь собирается передавать (возможные параметры передачи информации).
В этом сообщении могут содержаться также данные, необходимые для аутентификации абонента, и, следовательно, доступа клиентов к SIP-серверу. При необходимости изменить характеристики уже организованных каналов передается запрос INVITE с новым описанием сеанса связи. Для приглашения нового участника к уже установленному соединению также используется сообщение INVITE.
Запрос АСК подтверждает прием ответа на запрос INVITE. Следует отметить, что запрос АСК используется только совместно с запросом INVITE, т.е.
этим сообщением оборудование вызывающего пользователя показывает, что оно получило окончательный ответ на свой запрос INVITE. В сообщении АСК может содержаться окончательное описание сеанса связи, передаваемое вызывающим пользователем.
Запрос CANCEL отменяет обработку ранее переданных запросов с теми же, что и в запросе CANCEL, значениями полей Call-ID, To, From и CSeq, но не влияет на те запросы, обработка которых уже завершена. Например, запрос CANCEL применяется тогда, когда прокси-сервер размножает запросы для поиска пользователя по нескольким направлениям и в одном из них его находит. Обработку
запросов, разосланных во всех остальных направлениях, сервер отменяет при помощи сообщения CANCEL.
Запросом BYE оборудование вызываемого или вызывающего пользователя завершает соединение. Сторона, получившая запрос BYE, должна прекратить передачу речевой (мультимедийной) информации и подтвердить его выполнение ответом 200 ОК.
При помощи запроса типа REGISTER пользователь сообщает свое текущее местоположение. В этом сообщении содержатся следующие поля:
• Поле То содержит адресную информацию, которую надо сохранить или модифицировать на сервере;
• Поле From содержит адрес инициатора регистрации. Зарегистрировать пользователя может либо он сам, либо другое лицо, например, секретарь может зарегистрировать своего начальника;
• Поле Contact содержит новый адрес пользователя, по которому должны передаваться все дальнейшие запросы INVITE. Если в запросе REGISTER поле Contact отсутствует, то регистрация остается прежней. В случае отмены регистрации здесь помещается символ “*”;
• В поле Expires указывается время в секундах, в течение которого регистрация действительна. Если данное поле отсутствует, то по умолчанию назначается время - 1 час, после чего регистрация отменяется. Регистрацию можно также отменить, передав сообщение REGISTER с полем Expires, которому присвоено значение О, и с соответствующим полем Contact.
Запросом OPTIONS вызываемый пользователь запрашивает информацию о функциональных возможностях терминального оборудования вызываемого пользователя.
В ответ на этот запрос оборудование вызываемого пользователя сообщает требуемые сведения. Применение запроса OPTIONS ограничено теми случаями, когда необходимо узнать о функциональных возможностях оборудования до установления соединения. Для установления соединения запрос этого типа не используется.
После испытаний протокола SIP в реальных сетях оказалось, что для решения ряда задач вышеуказанных шести типов запросов недостаточно. Поэтому возможно, что в протокол будут введены новые сообщения. Так, в текущей версии протокола SIP не предусмотрен способ передачи информации управления соединением или другой информации во время сеанса связи. Для решения этой задачи был предложен новый тип запроса - INFO. Он может использоваться в следующих случаях:
• для переноса сигнальных сообщений ТфОП/ISDN/coTOBbix сетей между шлюзами в течение разговорной сессии;
• для переноса сигналов DTMF в течение разговорной сессии;
• для переноса биллинговой информации.
Завершив описание запросов протокола SIР, рассмотрим, в качестве примера, типичный запрос типа INVITE (рис. 7.6).
INVITE sip: watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip: a.g.bell@bell-tel.com> To: T. Watson <sip: watson@bell-tel.com> Call-ID: 3298420296@kton.bell-tel.com Cseq: 1 INVITE
Content-Type: application/sdp Content-Length: ...
v=0
o=bell 53655765 2353687637 IN IР4 12&.3.4.5
C=IN IP4 kton.bell-tel.com
m=audio 3456 RTP/AVP 0345
Рис. 7.6 Пример запроса INVITE
В этом примере пользователь Bell (a.g.bell@bell-tel.com) вызывает пользователя Watson (watson@bell-tel.com). Запрос передается к прокси-серверу (boston.bell-tel.com). В полях То и From перед адресом стоит запись, которую вызывающий пользователь желает вывести на дисплей вызываемого пользователя. В теле сообщения оборудование вызывающего пользователя указывает в формате протокола SDP, что оно может принимать в порту 3456 речевую информацию, упакованную в пакеты RTP и закодированную по одному из следующих алгоритмов кодирования: 0 - PCMU, 3 - GSM, 4 - G.723 и 5 - DVI4.
При передаче сообщений протокола SIP, упакованных в сигнальные сообщения протокола UDP, существует вероятность того, что размер запроса или ответа окажется больше максимально допустимого для данной сети, и произойдет фрагментация пакета. Чтобы избежать этого, используется сжатый формат имен основных заголовков, подобно тому, как это делается в протоколе SDP, Ниже приведен список таких заголовков (Таблица 7.3).
Таблица 7.3 Сжатые имена заголовков
| Сжатая форма имени | Полная форма имени |
| с | Content-Type |
| е | Content- Encoding |
| f | From |
| i | Call-ID |
| m | Contact (от "moved") |
| 1 | Content-Length |
| s | Subject |
| t | To |
| v | Via |
При написании имен заголовков в сжатом виде сообщение INVITE, показанное ранее на рисунке 6, будет выглядеть следующим образом (рис. 7.7):
INVITE sip: watson@boston.bell-tel.com SIP/2.0 v: SIP/2.0/UDP kton.bell-tel.com f: A. Bell <sip: a.g.bell@bell-tel.com> t: T. Watson <sip: watson@bell-tel.com> i: 3298420296@kton.bell-tel.com Cseq: 1 INVITE с: application/sdp 1: ...
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
C=IN IP4 kton.bell-tel.com
m=audio 3456 RTP/AVP 0345
Рис. 7.7 Пример запроса INVITE с сокращенными заголовками
В заключение параграфа, как и в предыдущих главах, сведем все запросы, с их кратким описанием, в таблицу 7.4.
Таблица 7.4 Запросы SIP
| Тип запроса | Описание запроса |
| INVITE | Приглашает пользователя к сеансу связи. Содержит SDP-описание сеанса |
| АСК | Подтверждает прием окончательного ответа на запрос INVITE |
| BYE | Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе |
| CANCEL | Отменяет обработку запросов с теми же заголовками Call-ID, То, From и CSeq, что и в самом запросе CANCEL |
| REGISTER | Переносит адресную информацию для регистрации пользователя на сервере определения местоположения |
| OPTION | Запрашивает информацию о функциональных возможностях терминала |
7.5.4 Ответы на запросы
После приема и интерпретации запроса, адресат (прокси-сервер) передает ответ на этот запрос.
Содержание ответов бывает разным:
подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях и т.д. Структуру ответов и их виды протокол SIP унаследовал от протокола HTTP.
Определено шесть типов ответов, несущих разную функциональную нагрузку. Тип ответа кодируется трехзначным числом. Самой важной является первая цифра, которая определяет класс ответа, остальные две цифры лишь дополняют первую. В некоторых случаях оборудование даже может не знать все коды ответов, но оно обязательно должно интерпретировать первую цифру ответа.
Все ответы делятся на две группы: информационные и финальные. Информационные ответы показывают, что запрос находится в стадии обработки. Они кодируются трехзначным числом, начинающимся с единицы, - 1хх. Некоторые информационные ответы, например, 100 Trying, предназначены для установки на нуль таймеров, которые запускаются в оборудовании, передавшем запрос. Если к моменту срабатывания таймера ответ на запрос не получен, то считается, что этот запрос потерян и может (по усмотрению производителя) быть передан повторно. Один из распространенных ответов -180 Ringing; по назначению он идентичен сигналу “Контроль посылки вызова” в ТфОП и означает, что вызываемый пользователь получает сигнал о входящем вызове.
Финальные ответы кодируются трехзначными числами, начинающимися с цифр 2, 3, 4, 5 и 6. Они означают завершение обработки запроса и содержат, когда это нужно, результат обработки запроса. Назначение финальных ответов каждого типа рассматривается ниже.
Ответы 2хх означают, что запрос был успешно обработан. В настоящее время из всех ответов типа 2хх определен лишь один -200 ОК. Его значение зависит от того, на какой запрос он отвечает:
• ответ 200 OK на запрос INVITE означает, что вызываемое оборудование согласно на участие в сеансе связи; в теле ответа указываются функциональные возможности этого оборудования;
• ответ 200 OK на запрос BYE означает завершение сеанса связи, в теле ответа никакой информации не содержится;
• ответ 200 OK на запрос CANCEL означает отмену поиска, в теле ответа никакой информации не содержится;
• ответ 200 OK на запрос REGISTER означает, что регистрация прошла успешно;
• ответ 200 OK на запрос OPTION служит для передачи сведений о функциональных возможностях оборудования, эти сведения содержатся в теле ответа.
Ответы Зхх информируют оборудование вызывающего пользователя о новом местоположении вызываемого пользователя или переносят другую информацию, которая может быть использована для нового вызова:
• в ответе 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 говорит от том, что сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.
Ответы бхх информируют о том, что соединение с вызываемым пользователем установить невозможно:
• ответ 600 Busy Everywhere сообщает, что вызываемый пользователь занят и не может принять вызов в данный момент ни по одному из имеющихся у него адресов. Ответ может указывать время, подходящее для вызова пользователя;
• ответ 603 Decline означает, что вызываемый пользователь не может или не желает принять входящий вызов. В ответе может быть указано подходящее для вызова время;
• ответ 604 Does Not Exist Anywhere означает, что вызываемого пользователя не существует.
Напомним, что запросы и ответы на них образуют SIP-транзакцию. Она осуществляется между клиентом и сервером и включает в себя все сообщения, начиная с первого запроса и заканчивая финальным ответом. При использовании в качестве транспорта протокола TCP все запросы и ответы, относящиеся к одной транзакции, передаются по одному TCP-соединению.
На рисунке 7.8 представлен пример ответа на запрос INVITE.
SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.соm
From: A.
Bell <sip:a.g.bell@bell-tel.com>
To: <sip:watson@bell-tel .com>;
Call-ID: 3298420296@kfcon.bell-fcel.com Cseq: 1 INVITE
Content-Type: application/sdp Content-Length: ...
v=0
o= watson 4858949 4858949 IN IP4 192.1.2.3
t=3149329600 0
c=IN IP4 bostcon.bell-tel.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Рис. 7.8 Пример SIP-ответа 200 OK
В этом примере приведен ответ пользователя Watson на приглашение принять участие в сеансе связи, полученное от пользователя Bell. Наиболее вероятный формат приглашения рассмотрен нами ранее (рис. 7.7). Вызываемая сторона информирует вызывающую о том, что она может принимать в порту 5004 речевую информацию, закодированную в соответствии с алгоритмами кодирования PCMU, GSM. Поля From, To, Via, Call-ID взяты из запроса, показанного на рисунке 7.7. Из примера видно, что это ответ на запрос INVITE с полем CSeq:1.
После того, как мы рассмотрели запросы и ответы на них, можно отметить, что протокол SIP предусматривает разные алгоритмы установления соединения. При этом стоит обратить внимание, что одни и те же ответы можно интерпретировать по-разному в зависимости от конкретной ситуации. В таблицу 7.5 сведены все ответы на запросы, определенные протоколом SIP.
Таблица 7.5 Ответы SIP
| Код ответа | Пояснение | Назначение |
| 100 | Trying | Запрос обрабатывается, например, сервер обращается к базам данных, но местоположение вызываемого пользователя в настоящий момент не определено |
| 180 | Ringing | Местоположение вызываемого пользователя определено. Ему дается сигнал о входящем вызове |
| 181 | Call Is Being Forwarded | Прокси-сервер переадресует вызов к другому пользователю |
| 182 | Queued | Вызываемый пользователь временно не доступен, но входящий вызов поставлен в очередь. Когда вызываемый пользователь станет доступным, он передаст финальный ответ |
| 200 | OK | Команда успешно выполнена |
| 300 | Multiple Choices | Вызываемый пользователь доступен по нескольким адресам. Вызывающий пользователь может выбрать любой из них |
| 301 | Moved Permanently | Пользователь изменил свое местоположение, его новый адрес указан в поле Contact |
| 302 | Moved Temporarily | Пользователь временно изменил свое местоположение, его новый адрес указан в поле Contact |
| 305 | Use Proxy | Вызываемая сторона может принять входящий вызов только в том случае, когда он проходит через прокси-сервер. Вызывающей стороне рекомендуется обратиться к прокси-серверу, адрес которого указан в поле Contact. Ответ передается только терминальным оборудованием (UAS) |
| 380 | Alternative Service | Вызов не достиг адресата, но существует альтернативный вариант обслуживания, который указан в теле ответа. Например, вызов может быть переадресован к речевому почтовому ящику |
| 400 | Bad Bequest | В запросе обнаружена синтаксическая ошибка |
| 401 | Unauthorised | Требуется проведение процедуры авторизации пользователя |
| 402 | Payment Required | Требуется предварительная оплата услуг |
| 403 | Forbidden | Запрос не будет обслуживаться сервером и не должен передаваться повторно |
| 404 | Not Found | Сервер не обнаружил вызываемого пользователя в домене, указанном в поле Request-URI |
| 405 | Method Not Allowed | Не разрешается передавать запрос этого типа на адрес, указанный в поле Request-URI. В поле Allow ответа указываются разрешенные типы запросов |
| 406 | Not Acceptable | Ответы, генерируемые вызываемой стороной, не будут поняты вызывающей стороной |
| 407 | Proxy Authentication Required | Клиент должен подтвердить свое право доступа к прокси-серверу |
| 408 | Request Timeout | Сервер не может передать ответ, например, указать местоположение вызываемого пользователя, в течение промежутка времени, специфицированного в поле Expires запроса. Вызывающий пользователь может повторно передать запрос через некоторое время |
| 409 | Conflict | Обработка запроса REGISTER не может быть завершена из-за конфликта между действием, определенным в параметре action запроса, и текущим состоянием ресурсов |
| 410 | Gone | Сервер больше не имеет доступа к запрашиваемому ресурсу и не знает, куда переадресовать запрос |
| 411 | Length Required | Требуется указать длину тела сообщения в поле Content-Length |
| 413 | Request Entity Too Large | Размер запроса слишком велик для обработки |
| 414 | Request-URI Too Large | Адрес, указанный в поле Request-URI, оказался слишком большим, поэтому его интерпретация невозможна |
| 415 | Unsupported Media Type | Запрос содержит не поддерживаемый формат тела сообщения |
| 420 | Bad Extension | Сервер не понял расширение протокола, специфицированное в поле Require |
| 480 | Temporarily not available | Вызываемый пользователь временно недоступен |
| 481 | Call Beg/Transaction Does Not Exist | Посылается в ответ на получение запроса ВYЕ, не относящегося к текущим соединениям, или запроса CANCEL, не относящегося к текущим запросам |
| 482 | Loop Detected | Сервер обнаружил, что принятый им запрос передается по замкнутому маршруту (в поле Via уже имеется адрес этого сервера) |
| 483 | Too Many Hops | Сервер обнаружил в поле Via, что принятый им запрос прошел через большее количество прокси-сервером, чем разрешено в поле Max-Forwards |
| 484 | Address Incomplete | Сервер принял запрос с неполным адресом в поле То или Request-URI. Требуется дополнительная адресная информация |
| 485 | Ambiguous | Адрес вызываемого пользователя неоднозначен. В заголовке Contact ответа может содержаться список адресов, по которым этот запрос можно передать |
| 486 | Busy Here | В настоящий момент вызываемый пользователь не желает или не может принять вызов на этот адрес. Ответ не исключает возможности связаться с пользователем по другому адресу |
| 500 | Internal Server Error | Внутренняя ошибка сервера |
| 501 | Not Implemented | В сервере не реализованы функции, необходимые для обслуживания запроса. Ответ передается в том случае, когда сервер не может распознать тип полученного им запроса |
| 502 | Bad Gateway | Сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос |
| 503 | Service Unavailable | Сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания |
| 504 | Gateway Timeout | Сервер, функционирующий в качестве шлюза или прокси-сервера, в течение установленного интервала времени не получил ответ от сервера (например, от сервера определения местоположения), к которому он обратился для завершения обработки запроса |
| 505 | SIP Version not supported | Сервер не поддерживает данную версию протокола SIP |
| 600 | Busy Everywhere | Вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может указывать подходящее для вызова время |
| 603 | Decline | Вызываемый пользователь не может или не желает принимать входящие вызовы. В ответе может быть указано подходящее для вызова время |
| 604 | Does not exist anywhere | Вызываемого пользователя не существует |
| 606 | Not Acceptable | Вызываемый пользователь не может принять входящий вызов из-за того, что вид информации, указанный в описании сеанса связи в формате SDP, полоса пропускания и т.д. неприемлемы |
Принцип декомпозиции шлюза
В недавнем прошлом рабочая группа MEGACO комитета IETF разработала протокол управления шлюзами - Media Gateway Control Protocol (MGCP). Ранее подобный протокол под названием SGCP - Simple Gateway Control Protocol (простой протокол управления шлюзами) - был разработан компанией Telecordia (бывшая компания Bellcore). фирма Level 3 предложила сходный протокол управления оборудованием, реализующим технологию маршрутизации пакетов IP, - IDCP (IP Device Control Protocol). Оба они впоследствии были объединены в протокол MGCP.
При разработке протокола управления шлюзами рабочая группа MEGACO опиралась на принцип декомпозиции, согласно которому шлюз разбивается на отдельные функциональные блоки (рис. 8.1):
• транспортный шлюз - Media Gateway, который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование;
• устройство управления - Call Agent, выполняющее функции управления шлюзом;
• шлюз сигнализации - Signaling Gateway, который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к устройству управления шлюзом и перенос сигнальной информации в обратном направлении.
Рис. 8.1 Архитектура сети, базирующейся на протоколе MGCP
Таким образом, весь интеллект функционально распределенного шлюза размещается в устройстве управления, функции которого, в свою очередь, могут быть распределены между несколькими компьютерными платформами. Шлюз сигнализации выполняет функции STP - транзитного пункта системы сигнализации по общему каналу - ОКС7. Транспортные шлюзы выполняют только функции преобразования речевой информации. Одно устройство управления обслуживает одновременно несколько шлюзов. В сети может присутствовать несколько устройств управления. Предполагается, что эти устройства синхронизованы между собой и согласованно управляют шлюзами, участвующими в соединении.
Рабочая группа MEGACO не определяет протокол синхронизации работы устройств управления, однако в ряде работ, посвященных исследованию возможностей протокола MGCP, для этой цели предлагается использовать протоколы Н.323, SIP или ISUP/IP (рис. 8.2).
Перенос сообщений протокола 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 (рис. 8.3).
Принципы протокола SIP
Протокол инициирования сеансов - Session Initiation Protocol (SIP) является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и распределения мультимедийной информации. Пользователи могут принимать участие в существующих сеансах связи, приглашать других пользователей и быть приглашенными ими к новому сеансу связи. Приглашения могут быть адресованы определенному пользователю, группе пользователей или всем пользователям.
Протокол SIP разработан группой MMUSIC (Multiparty Multimedia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543 [54]. В основу протокола рабочая группа MMUSIC заложила следующие принципы:
Персональная мобильность пользователей. Пользователи могут перемещаться без ограничений в пределах сети, поэтому услуги связи должны предоставляться им в любом месте этой сети. Пользователю присваивается уникальный идентификатор, а сеть предоставляет ему услуги связи вне зависимости от того, где он находится. Для этого пользователь с помощью специального сообщения -REGISTER - информирует о своих перемещениях сервер определения местоположения.
Масштабируемость сети. Она характеризуется, в первую очередь, возможностью увеличения количества элементов сети при её расширении. Серверная структура сети, построенной на базе протокола SIP, в полной мере отвечает этому требованию.
Расширяемость протокола. Она характеризуется возможностью дополнения протокола новыми функциями при введении новых услуг и его адаптации к работе с различными приложениями.
В качестве примера можно привести ситуацию, когда протокол SIP используется для установления соединения между шлюзами, взаимодействующими с ТфОП при помощи сигнализации ОКС7 или DSS1. В настоящее время SIP не поддерживает прозрачную передачу сигнальной информации телефонных систем сигнализации. Вследствие этого дополнительные услуги ISDN оказываются недоступными для пользователей IP-сетей.
Расширение функций протокола SIP может быть произведено за счет введения новых заголовков сообщений, которые должны быть зарегистрированы в уже упоминавшейся ранее организации IANA. При этом, если SIP-сервер принимает сообщение с неизвестными ему полями, то он просто игнорирует их и обрабатывает лишь те поля, которые он знает.
Для расширения возможностей протокола SIP могут быть также добавлены и новые типы сообщений.
Интеграция в стек существующих протоколов Интернет, разработанных IETF. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF). Эта архитектура включает в себя также протокол резервирования ресурсов (Resource Reservation Protocol - RSVP, RFC 2205), транспортный протокол реального времени (Real-Time Transport Protocol - RTP, RFC 1889), протокол передачи потоковой информации в реальном времени (Real-Time Streaming Protocol - RTSP, RFC 2326), протокол описания параметров связи (Session Description Protocol -SDP, RFC 2327). Однако функции протокола SIP не зависят ни от одного из этих протоколов.
Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323 (Главы 5 и 6). Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП - DSS1 и ОКС7 [6,7]. Для упрощения такого взаимодействия сигнальные сообщения протокола SIP могут переносить не только специфический SIP-адрес, но и телефонный номер формата Е.164 или любого другого формата. Кроме того, протокол SIP, наравне с протоколами Н.323 и ISUP/IP, может применяться для синхронизации работы устройств управления шлюзами, о чем пойдет речь в следующей главе (рис. 8.2); в этом случае он должен взаимодействовать с протоколом MGCP. Другой важной особенностью протокола SIP является то, что он приспособлен к организации доступа пользователей сетей IP-телефонии к услугам интеллектуальных сетей [8], и существует мнение, что именно этот протокол станет основным при организации связи между указанными сетями.
7.2 Интеграция протокола SIP с IP-сетями
Одной из важнейших особенностей протокола SIP является его независимость от транспортных технологий. В качестве транспорта могут использоваться протоколы Х.25, Frame Relay, AAL5/ATM, IPX и др. Структура сообщений SIP не зависит от выбранной транспортной технологии. Но, в то же время, предпочтение отдается технологии маршрутизации пакетов IP и протоколу UDP. При этом, правда, необходимо создать дополнительные механизмы для надежной доставки сигнальной информации. К таким механизмам относятся повторная передача информации при ее потере, подтверждение приема и др.
Здесь же следует отметить то, что сигнальные сообщения могут переноситься не только протоколом транспортного уровня UDP, но и протоколом TCP. Протокол UDP позволяет быстрее, чем TCP, доставлять сигнальную информацию (даже с учетом повторной передачи неподтвержденных сообщений), а также вести параллельный поиск местоположения пользователей и передавать приглашения к участию в сеансе связи в режиме многоадресной рассылки. В свою очередь, протокол TCP упрощает работу с межсетевыми экранами (firewall), а также гарантирует надежную доставку данных. При использовании протокола TCP разные сообщения, относящиеся к одному вызову, либо могут передаваться по одному TCP-соединению, либо для каждого запроса и ответа на него может открываться отдельное TCP-соединение. На рисунке 7.1 показано место, занимаемое протоколом SIP в стеке протоколов TCP/IP.
По сети с маршрутизацией пакетов IP может передаваться пользовательская информация практически любого вида: речь, видео и данные, а также любая их комбинация, называемая мультимедийной информацией. При организации связи между терминалами пользователей необходимо известить встречную сторону, какого рода информация может приниматься (передаваться), алгоритм ее кодирования и адрес, на который следует передавать информацию. Таким образом, одним из обязательных условий организации связи при помощи протокола SIP является обмен между сторонами данными об их функциональных возможностях.
Для этой цели чаще всего используется протокол описания сеансов связи - SDP (Session Description Protocol). Поскольку в течение сеанса связи может производиться его модификация, предусмотрена передача сообщений SIP с новыми описаниями сеанса средствами SDP. Более подробно протокол SDP рассмотрен в главе 8.
Для передачи речевой информации комитет IETF предлагает использовать протокол RTP, рассмотренный в главе 4 настоящей книги, но сам протокол SIP не исключает возможность применения для этих целей других протоколов.
В протоколе SIP не реализованы механизмы управления потоками информации и предоставления гарантированного качества обслуживания. Кроме того, протокол SIP не предназначен для передачи пользовательской информации, в его сообщениях может переноситься информация лишь ограниченного объема. При переносе через сеть слишком большого сообщения SIP не исключена его фрагментация на уровне IP, что может повлиять на качество передачи информации.
В глобальной информационной сети Интернет уже довольно давно функционирует экспериментальный участок Mbone, который образован из сетевых узлов, поддерживающих режим многоадресной рассылки мультимедийной информации. Важнейшей функцией Mbone является поддержка мультимедийных конференций, а основным способом приглашения участников к конференции стал протокол SIP.
Протокол SIP предусматривает организацию конференций трех видов:
• в режиме многоадресной рассылки (multicasting), когда информация передается на один multicast-адрес, а затем доставляется сетью конечным адресатам;
• при помощи устройства управления конференции (MCU), к которому участники конференции передают информацию в режиме точка-точка, а оно, в свою очередь, обрабатывает ее (т.е. смешивает или коммутирует) и рассылает участникам конференции;
• путем соединения каждого пользователя с каждым в режиме точка-точка.
Протокол SIP дает возможность присоединения новых участников к уже существующему сеансу связи, т.е. двусторонний сеанс может перейти в конференцию.
И, в заключение рассказа об интеграции протокола SIP с IP-сетями, следует отметить то. что разработаны методы совместной работы этого протокола с преобразователем сетевых адресов - Network Address Translator (NAT).
7.3 Адресация
Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов - URL (Universal Resource Locators), так называемые SIP URL
SIP-адреса бывают четырех типов:
• имя@домен;
• имя@хост,
• имя@IР-адрес;
• №телефона@шлюз.
Таким образом, адрес состоит из двух частей. Первая часть - это имя пользователя, зарегистрированного в домене или на рабочей станции. Если вторая часть адреса идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента.
Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP-адреса устройства необходимо обратиться к службе доменных имен - Domain Name Service (DNS). Если же во второй части SIP-адреса размещается IP-адрес, то с рабочей станцией можно связаться напрямую.
В начале SIP-адреса ставится слово “sip:”, указывающее, что это именно SIP-адрес, т.к. бывают и другие (например, “mailto:”). Ниже приводятся примеры SIP-адресов:
sip: als@rts.loniis.ru
sip: user1@192.168.100.152
sip: 294-75-47@gateway.ru
7.4 Архитектура сети SIP
В некотором смысле прародителем протокола SIP является протокол переноса гипертекста - HTTP (Hypertext Transfer Protocol, RFC 2068). Протокол SIP унаследовал от него синтаксис и архитектуру “клиент-сервер”, которую иллюстрирует рис. 7.2.
Клиент выдает запросы, в которых указывает, что он желает получить от сервера. Сервер принимает запрос, обрабатывает его и выдает ответ, который может содержать уведомление об успешном выполнении запроса, уведомление об ошибке или информацию, затребованную клиентом.
Управление процессом обслуживания вызова распределено между разными элементами сети SIP. Основным функциональным элементом, реализующим функции управления соединением, является терминал. Остальные элементы сети отвечают за маршрутизацию вызовов, а в некоторых случаях предоставляют дополнительные услуги.
7.4.1 Терминал
В случае, когда клиент и сервер взаимодействуют непосредственно с пользователем (т.е. реализованы в оконечном оборудовании пользователя), они называются, соответственно, клиентом агента пользователя - User Agent Client (UAC) - и сервером агента пользователя - User Agent Server (UAS).
Следует особо отметить, что сервер UAS и клиент UAC могут (но не обязаны) непосредственно взаимодействовать с пользователем, а другие клиенты и серверы SIP этого делать не могут. Если в устройстве присутствуют и сервер UAS, и клиент UAC, то оно называется агентом пользователя - User Agent (UA), а по своей сути представляет собой терминальное оборудование SIP.
Кроме терминалов определены два основных типа сетевых элементов SIP: прокси-сервер (proxy server) и сервер переадресации (redirect server).
7.4.2 Прокси-сервер
Прокси-сервер (от английского proxy - представитель) представляет интересы пользователя в сети. Он принимает запросы, обрабатывает их и, в зависимости от типа запроса, выполняет определенные действия. Это может быть поиск и вызов пользователя, маршрутизация запроса, предоставление услуг и т.д. Прокси-сервер состоит из клиентской и серверной частей, поэтому может принимать вызовы, инициировать собственные запросы и возвращать ответы. Прокси - сервер может быть физически совмещен с сервером определения местоположения (в этом случае он называется registrar) или существовать отдельно от этого сервера, но иметь возможность взаимодействовать с ним по протоколам LDAP (RFC 1777), rwhois (RFC 2167) и по любым другим протоколам.
Предусмотрено два типа прокси-серверов - с сохранением состояний (stateful) и без сохранения состояний (stateless).
Сервер первого типа хранит в памяти входящий запрос, который явился причиной генерации одного или нескольких исходящих запросов.
Эти исходящие запросы сервер также запоминает Все запросы хранятся в памяти сервера только до окончания транзакции, т.е. до получения ответов на запросы.
Сервер первого типа позволяет предоставить большее количество услуг, но работает медленнее, чем сервер второго типа. Он может применяться для обслуживания небольшого количества клиентов, например, в локальной сети. Прокси-сервер должен сохранять информацию о состояниях, если он:
- использует протокол TCP для передачи сигнальной информации;
- работает в режиме многоадресной рассылки сигнальной информации;
- размножает запросы.
Последний случай имеет место, когда прокси-сервер ведет поиск вызываемого пользователя сразу в нескольких направлениях, т.е. один запрос, который пришел к прокси-серверу, размножается и передается одновременно по всем этим направлениям.
Сервер без сохранения состояний просто ретранслирует запросы и ответы, которые получает. Он работает быстрее, чем сервер первого типа, так как ресурс процессора не тратится на запоминание состояний, вследствие чего сервер этого типа может обслужить большее количество пользователей. Недостатком такого сервера является то, что на его базе можно реализовать лишь наиболее простые услуги. Впрочем, прокси-сервер может функционировать как сервер с сохранением состояний для одних пользователей и как сервер без сохранения состояний - для других.
Алгоритм работы пользователей с прокси-сервером выглядит следующим образом. Поставщик услуг IP-телефонии сообщает адpec прокси-сервера своим пользователям. Вызывающий пользователь передает к прокси-серверу запрос соединения. Сервер обрабатывает запрос, определяет местоположение вызываемого пользователя и передает запрос этому пользователю, а затем получает от него ответ, подтверждающий успешную обработку запроса, и транслирует этот ответ пользователю, передавшему запрос. Прокси-сервер может модифицировать некоторые заголовки сообщений, которые он транслирует, причем каждый сервер, обработавший запрос в процессе его передачи от источника к приемнику, должен указать это в SIP-запросе для того, чтобы ответ на запрос вернулся по такому же пути.
7.4.3 Сервер переадресации
Сервер переадресации предназначен для определения текущего адреса вызываемого пользователя. Вызывающий пользователь передает к серверу сообщение с известным ему адресом вызываемого пользователя, а сервер обеспечивает переадресацию вызова на текущий адрес этого пользователя. Для реализации этой функции сервер переадресации должен взаимодействовать с сервером определения местоположения.
Сервер переадресации не терминирует вызовы как сервер RAS и не инициирует собственные запросы как прокси-сервер. Он только сообщает адрес либо вызываемого пользователя, либо прокси-сервера. По этому адресу инициатор запроса передает новый запрос. Сервер переадресации не содержит клиентскую часть программного обеспечения.
Но пользователю не обязательно связываться с каким-либо SIP-сервером. Он может сам вызвать другого пользователя при условии, что знает его текущий адрес.
7.4.4 Сервер определения местоположения пользователей
Пользователь может перемещаться в пределах сети, поэтому необходим механизм определения его местоположения в текущий момент времени. Например, сотрудник предприятия уезжает в командировку, и все вызовы, адресованные ему, должны быть направлены в другой город на его временное место работы. О том, где он находится, пользователь информирует специальный сервер с помощью сообщения REGISTER. Возможны два режима регистрации: пользователь может сообщить свой новый адрес один раз, а может регистрироваться периодически через определенные промежутки времени. Первый способ подходит для случая, когда терминал, доступный пользователю, включен постоянно, и его не перемещают по сети, а второй - если терминал часто перемещается или выключается.
Для хранения текущего адреса пользователя служит сервер определения местоположения пользователей, представляющий собой базу данных адресной информации. Кроме постоянного адреса пользователя, в этой базе данных может храниться один или несколько текущих адресов.
Этот сервер может быть совмещен с прокси-сервером (в таком случае он называется registrar) или быть реализован отдельно от прокси-сервера, но иметь возможность связываться с ним.
В RFC 2543 сервер определения местоположения представлен как отдельный сетевой элемент, но принципы его работы в этом документе не регламентированы. Стоит обратить внимание на то, что вызывающий пользователь, которому нужен текущий адрес вызываемого пользователя, не связывается с сервером определения местоположения напрямую. Эту функцию выполняют SIP-серверы при помощи протоколов LDAP (RFC 1777), rwhois (RFC 2167), или других протоколов.
Принципы реализации
Глава 11 Принципы реализации
11.1 Оборудование IP-телефонии
Как оказалось, мудрым советом знаменитого бизнесмена Аристотеля Онассиса “Не гонись за деньгами - иди им навстречу” воспользовался целый ряд компаний, преуспевших в разработке программных средств и оборудования IP-телефонии, среди которых-VocalTec, Dialogic, Cisco, Ascend, 3Com, Nortel, Lucent, IBM, Motorola, RAD, Rock-well, Digitcom и др.
Некоторые из продуктов названных компаний уже упоминались на страницах этой книги. Так, в главе 5 обсуждались принципы построения оборудования, реализующего самый распространенный на сегодняшний день протокол Н.323; в главе 7 были отчасти затронуты технические решения, поддерживающие протокол SIP, а в главе 8 рассмотрены аспекты реализации протокола MGCP. Здесь же рассматриваются некоторые интересные решения в построении оборудования IP-телефонии, не вошедшие в предыдущие главы.
Начнем анализ с продукции компании Nortel Networks, выдвинувшей новый подход, который назван философией вечной молодости (Evergreen). Применительно к тематике данной книги этот принцип нашел свое воплощение в концепции Inca (Internet Communications Architecture), объявленной 8 июня 1999 г. и предусматривающей постепенное оснащение уже существующих IP-сетей функциями IP-телефонии.
Примером практической реализации концепции Nortel Networks является платформа MMCS (MultiMedia Carrier Switch), прошедшая сертификацию для ВСС России и известная по публикациям в журналах. Другими примерами являются семейство Magellan - пакетные коммутаторы серии DPN (протоколы Х.25, FR) и модельный ряд Passport - устройства доступа с компрессией речи по протоколу FR -Passport 4400, мультипротокольные маршрутизаторы серии Passport 7000/6000, пограничные устройства Passport Voice Gateway, сопрягающие телефонные сети и сети ATM, а также высокоскоростные АТМ-коммутаторы Passport 15000. Все это оборудование позволяет полностью интегрировать речь, факсимильные сообщения, видеоинформацию, данные по протоколам IP, FR, SNA, X.25, HDLC, и обеспечивать мультимедийные услуги, оптимизируя использование имеющихся ресурсов (например, при передаче речи применяется технология передачи пакетов с переменной скоростью).
Еще одним примером оборудования IP- телефонии может служить универсальный маршрутизатор 1Р45/951 с функциями передачи речи и мультимедийной информации по IP-сетям, входящий в гамму продуктов корпорации NEC, Япония. Маршрутизатор 1Р45/951 реализует функции шлюза и привратника. Маршрутизатор поддерживает большое количество алгоритмов кодирования речи, в том числе, ITU-T G.729, G.729a, G.729b, G.729ab, G.723.1, G.729.1a, G.711, G.711VAD, G.728 и G.728VAD. Это позволяет маршрутизатору 1Р45/951 соединяться практически со всеми шлюзами, поддерживающими протокол Н.323, в то время как возможности многих шлюзов ограничены небольшим количеством поддерживаемых алгоритмов кодирования. Маршрутизатор 1Р45/951 обеспечивает хорошее качество передачи речи благодаря следующим особенностям:
• применение современных алгоритмов кодирования;
• подавление эха (64 мс);
• сглаживание джиттера;
• подавление пауз в разговоре;
• генерация комфортного шума;
• поддержка протокола RSVP;
• сжатие заголовков IP/UDP/RTP;
• поддержка приоритетов для различных видов трафика.
Даже при кратком анализе характеристик оборудования IP-телефонии ведущих фирм-производителей обращает на себя внимание модульность и масштабируемость продуктов и их ценовой диапазон, не превышающий нескольких десятков тысяч долларов.
Это же справедливо и в отношении программного обеспечения IP-телефонии, оно доступно и недорого. Популярные продукты Microsoft NetMeeting, IDT Net2Phone и DotDialer реализуют разные схемы телефонной связи через IP-сети: NetMeeting используется для связи по схеме “компьютер-компьютер”, а Net2Phone и DotDialer реализуют схему “компьютер-телефон”. Оба эти сценария IP-телефонии уже обсуждались в главе 2. Там же отмечались сложность и актуальность программно-аппаратных средств, реализующих сценарий “телефон-телефон”.
За последнее время появились следующие виды оборудования IP-телефонии для всех этих сценариев:
1. Автономные шлюзы IP-телефонии, подключаемые к АТС через цифровые и аналоговые интерфейсы и осуществляющие предварительную обработку речевых сигналов, компрессию, упаковку в IP-пакеты и передачу их по сети.
2. Магистральные речевые платы с интерфейсом 10/100BaseT ( ЛВС Ethernet) для подключения учрежденческих АТС существующих моделей к корпоративной IP-сети. После установки в АТС такой платы речевой трафик в виде IP-пакетов может быть направлен по локальной или глобальной пакетной сети подобно тому, как он сейчас передается от АТС по телефонной сети.
3. Телефонные аппараты, упаковывающие речевую информацию в IP-пакеты (IP-телефоны) и подключаемые не к телефонной сети, а непосредственно к ЛВС Ethernet. Как правило, такие аппараты требуют от сетевого администратора минимальных настроек, используя протокол динамической конфигурации -Dynamic Host Configuration Protocol (DHCP).
4. Специализированные коммутаторы речевых пакетов, предназначенные для выполнения функций традиционной АТС на базе протокола IP. В литературе такие устройства часто называют IP-АТС, но это название представляется нам не совсем корректным, поскольку в данном случае осуществляется не автоматическая коммутация каналов, а коммутация пакетов.
Аппаратура IP-телефонии выпускается в совмещенной или автономной конструкции. Совмещенный сервер выполняет функции шлюза, привратника и администратора (manager), т.е. маршрутизацию, сбор биллинговой информации (IP-адрес, время начала и конца разговора и т.п.), подавление эхосигналов, детектирование пауз в разговоре, заполнение пауз на приеме комфортным шумом (comfort noise), буферизацию принятых пакетов для уменьшения джиггера, интерполяцию потерянных речевых пакетов, а также контроль состояния разговорного канала (среднее время задержки, джиттер, процент потерь пакетов). В автономной конструкции эти функции выполняются отдельными устройствами.
В ранних моделях цифровая обработка сигнала производилась программными средствами. Позднее программную обработку сменила аппаратная, основную роль стали выполнять уже упоминавшиеся в главе 3 платы DSP (Digital Signal Processing), что разгрузило основной процессор и оперативную память, увеличило число портов оборудования и уменьшило время задержки речевой информации.
Наиболее известны платы DSP фирм Texas Instrument, Dialogic (DM3 IP Link) и Natural MicroSystems (Quad E1).
Рассмотренная в начале книги конвергенция сетей электросвязи, в рамках которых передается информация всех видов (речь, видео и данные), обусловила появление упомянутых выше продуктов в качестве отклика ведущих телекоммуникационных компаний на интерес потенциальных потребителей этой части рынка. Пока большинство разработок используется в корпоративных сетях или в небольших офисах, а не в глобальных сетях операторов связи. Создание более мощного и емкого оборудования IP-телефонии в самое ближайшее время потребует значительных усилий, среди полезных результатов которых, возможно, найдется место и данной книге. Обсуждаемые в ней требования к аппаратуре IP-телефонии можно сформулировать, в общих чертах, так:
• полная поддержка рекомендаций Н.323;
• поддержка всех основных алгоритмов кодирования речи;
• поддержка основных систем телефонной сигнализации (ОКС7, DSS1,R1.5nT.^);
• удобство и функциональность средств управления и контроля.
Важная категория удовлетворяющего этим требованиям оборудования IP-телефонии предназначена для построения сетевой инфраструктуры. Сегодня это главное препятствие для развития IP-телефонии, с которым столкнулись региональные операторы. Проблема состоит в построении структуры IP-сети, которая могла бы дать им шанс скоординировать свои действия и собрать свои ресурсы для того, чтобы составить конкуренцию операторам и поставщикам традиционного оборудования междугородной и международной связи. Для решения этой проблемы и создания магистральных транзитных узлов сегодня имеются сверхскоростные маршрутизаторы IP-пакетов производства Avici Systems Inc. (Челмсфорд, Массачусетс), Berkeley Networks Inc. (Сан Хосе, Калифорния), Gigapacket Networks Inc. (Литтлтон, Массачусетс), Juniper Networks (Санта Клара, Калифорния), Neonet LLC (Уэстборо, Массачусетс) и Torrent Networking Technologies Inc. (Лендовер, Мэриленд). Эти маршрутизаторы могут объединяться в IP-сети коммутаторами ATM, SDH/Sonet производства Ascend, Cisco и др.
Другим, не менее важным аспектом внедрения IP-телефонии являются шлюзы, обеспечивающие взаимодействие сетей с коммутацией каналов и с коммутацией пакетов.
В настоящее время несколько десятков компаний выпускают подобные изделия, среди них Cisco Systems, VocalTec, Lucent Technologies и др. Более того, на базе этих шлюзов почти каждая крупная телекоммуникационная компания имеет или заявленное, или уже поставляемое изделие IP-телефонии. Предлагаются АТС, реализованные на основе технологии маршрутизации IP-пакетов. Компания Cisco выпустила интегрированный сервер доступа AS5300 с коммутатором Catalyst 5500. Компания Ascend Communications Inc. объединила модем для коммутируемых каналов TNT с гигабитным маршрутизатором GRF. Компания 3Com добавила передачу речи по IP и факс в свой концентратор Total Control Hub.
Согласно некоторым оценкам, объем рынка сетевых изделий IP-телефонии в 2001 году составит 1.8 миллиарда долларов, а рынка устройств доступа к сетям IP-телефонии - 7.5 миллиарда долларов. Как известно из предыдущего опыта, эксплуатация оборудования создает рынок в десять раз выше, чем общая стоимость установленного оборудования. Поэтому общий рынок оборудования передачи речи по IP-сетям уже сегодня можно оценить в 90 миллиардов долларов.
11.2 Особенности оборудования IP-телефонии для России
При внедрении технологии передачи речевой информации по сетям с маршрутизацией IP-пакетов во Взаимоувязанной сети связи Российской Федерации (ВСС РФ), помимо рассмотренных выше, возникают следующие специфические трудности:
- при подключении оборудования IP-телефонии к АТС телефонной сети общего пользования по двухпроводным аналоговым абонентским линиям препятствием часто становится большое затухание сигналов в этих линиях;
- при подключении оборудования IP-телефонии к коммутационному оборудованию ТфОП по межстанционным соединительным линиям затруднения связаны с тем, чтодекадно-шаговые и координатные АТС имеют специфические системы сигнализации [6], основная из которых определяется неформальным, но весьма точным термином “R полтора”;
- присутствующие в ТфОП декадно- шаговые АТС создают большие помехи и поддерживают только импульсный набор номера.
Специфические требования к оборудованию IP-телефонии, подключаемому к ВСС России, изложены в руководящем документе отрасли РД 45.046-99 “Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования”, утвержденном Министерством связи 12.11.99 г., изложение которого выходит за рамки данной книги. Сэкономленное таким образом место отдано краткому описанию отечественной платформы IP-телефонии ПРОТЕЙ-1Р, реализующей все требования данного РД и учитывающей упомянутую выше специфику ВСС России.
11.3 Шлюз IP-телефонии Протей-ITG
Шлюз IP-телефонии Протей-ITG реализует передачу речевого трафика и факсимильной информации по сетям с маршрутизацией пакетов IP по протоколу Н.323, версия 2. Основным функциональным назначением шлюза является преобразование речевой информации, поступающей от ТфОП с постоянной скоростью передачи, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковка речевой информации в пакеты RTP/U DP/IP, а также обратное преобразование. Кроме того, шлюз конвертирует сигнальные сообщения систем сигнализации E-DSS1 и ОКС7 (ISUP-R, российская версия) в сигнальные сообщения Н.323 и производит обратное преобразование по рекомендации ITU H.246.
Шлюз Протей-ITG подключается к ТфОП по цифровым линиям со скоростью передачи 2048 Кбит/с (Е1) с использованием сигнализации ISUP-R системы общеканальной сигнализации ОКС7, абонентской сигнализации E-DSS1, а также сигнализации по двум выделенным сигнальным каналам “R1.5”, а к сетям с маршрутизацией пакетов IP - при помощи интерфейса 10/100Вазе-Т.
В таблицу 11.1 сведены основные технические характеристики шлюза.
Таблица 11.1 Технические спецификации шлюза IP-телефонии “Протей-ITG”
| Емкость системы | 2 тракта Е1. 60 одновременных соединений |
| Интерфейсы оборудования | Для подключения к ТфОП:Е1 симметричный, 120 Ом по рекомендации ITU G.703; Для подключения к сети с маршрутизацией пакетов IP: 10/100Base-T |
| Протоколы и системы сигнализации | TCP/IP, RTP/RTCP, Н.323 Версия 2: Н.245, Н.225 (Q.931 и RAS); DSS1 (Q.931, Q.921), QSIG (ETS 300172), ОКС№ 7 - Российские национальные спецификации МТР, ISUP-R, RADIUS - для подключения к биллинговой системе, Т.37 - для передачи факсимильной информации в реальном времени |
| Алгоритмы кодирования речи | G.711, G.722, G.723.1, G.728, G.729; |
| Техническое обслуживание | Интуитивно понятный Web-интерфейс |
На рис.11.1. изображена обобщенная структура шлюза IP-телефонии Протей-ITG. Следует отметить, что кодирование и пакетирование речевых сигналов, поступающих из ТфОП для последующей их передачи по IP-сети, реализованы в Протей-ITG на базе специализированных процессоров обработки цифровых сигналов - Digital Signal Processors (DSP). Остальные функции выполняются программным обеспечением, использующим универсальный процессор.
Рис. 11.1 Структурная схема шлюза Протей-ITC
Модуль обработки телефонной сигнализации взаимодействует с телефонным оборудованием, преобразуя сигналы систем DSS1 и ОКС7 во внутрисистемные примитивы, которые отражают состояния процесса обслуживания вызова (установление соединения, отбой и т.п.) и используются модулем логики услуг шлюза для установления соединений между ТфОП и IP-сетью.
Модуль сигнализации Н.323 обрабатывает сигнальную информацию протоколов RAS, Н.225.0 (Q.931) и Н.245. Информация о состояниях процесса обслуживания вызова в IP-сети передается в модуль логики услуг шлюза.
Модуль логики услуг шлюза IP-телефонии отвечает за маршрутизацию вызова, поступившего из ТфОП в IP-сеть. Производятся такие операции, как контроль доступа и анализ телефонного номера вызываемого абонента с последующим определением и предоставлением требуемой услуги. При наличии в сети IP-телефонии привратника многие функции могут быть возложены на него.
Модуль пакетирования речи выполняет функции подготовки речевого сигнала, поступающего из ТфОП с постоянной скоростью, для дальнейшей его передачи по сети с маршрутизацией пакетов IP. Основными функциями модуля являются: преобразование речевого сигнала методом импульсно-кодовой модуляции, эхокомпенсация, кодирование речевого сигнала, обнаружение активных периодов и пауз в речи и адаптация воспроизведения. Кроме того, модуль отвечает за детектирование и генерацию сигналов DTMF и за обработку факсимильных и модемных сигналов. Структура модуля пакетирования речи представлена на рис. 11.2.
Механизм обнаружения активных периодов речи проверяет получаемый из ТфОП сигнал на наличие в нем речевой информации.
Если в течение определенного времени речевая информация не обнаружена, передача речевых пакетов в IP-сеть прекращается. Использование этого механизма существенно повышает эффективность использования полосы пропускания. Экономия полосы может доходить до 60%.
Рис. 11.2 Модуль пакетирования речи
Суть механизма адаптации воспроизведения заключается в буферизации речевых пакетов для сглаживания вариации их задержки. Механизм использует буфер FIFO, хранящий речевые элементы перед их воспроизведением. Далее измеряется джиттер и производится адаптивное управление задержкой пакетов в буфере.
В архитектуру платформы включен упрощенный вариант шлюза IP-телефонии - устройство уплотнения соединительных линий - для уплотнения межстанционных соединительных линий связи (сигнальных и разговорных каналов) и передачи мультиплексированной информации через сеть IP с последующим ее демультиплексированием на удаленной стороне. Данное устройство может использоваться, например, операторами сотовой связи для уменьшения числа соединительных линий. В таком варианте шлюза IP-телефонии отсутствует стандартная обработка сигнальных сообщений (сигнальная информация ОКС7 передается прозрачно), так как разговорные каналы постоянно открыты и по ним передается сжатая речь с подавленными паузами. Кроме того, система автоматически обнаруживает сигналы факса и начинает вести обработку информации по протоколу Т.38; после окончания факсимильной сессии система возвращается на прежний режим работы.
11.4 Привратник Протей-GK и варианты организации связи
В привратнике сосредоточен весь интеллект сети IP-телефонии. Он выполняет функции управления зоной сети IP-телефонии, в которую входят терминалы, шлюзы и устройства управления конференциями, зарегистрированные в этом привратнике.
В число наиболее важных функций, выполняемых привратником с целью обеспечения нормального функционирования управляемой зоны сети, входят:
• регистрация оконечного оборудования;
• контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS (Рекомендация ITU Н.225.0);
• преобразование a/yas-адреса ( имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сети с маршрутизацией пакетов IP (IP адрес + номер порта TCP/UDP);
• контроль, управление и резервирование пропускной способности сети;
• ретрансляция сигнальных сообщений Н.225.0 и Н.245 между терминалами.
В последнем случае привратник в любое время знает состояние конечных пользователей и может предоставлять дополнительные услуги, такие как переключение связи, переадресация, постановка на ожидание, перехват вызова и т.д.
Возможны следующие два варианта организации связи с использованием оборудования IP-телефонии платформы Протей.
В первом варианте шлюз IP-телефонии Протей-ITG и привратник Протей-GK подключаются к существующей сети IP-телефонии.
Подключение может осуществляться на правах корпоративного клиента, т.е. биллинговым центром поставщика услуг IP-телефонии выставляется групповой счет местному оператору у которого установлено оборудование Протей-IP, а оператор в свою очедеь выставляет групповой счет за терминированный трафик поставщику услуг, т.е. произодится взаиморасчет. Что касается расчетов со “своими” абонентами (пользователями услуги), то для этого местному оператору предпочтительно использовать предоплатные механизмы, т.е. систему сервисных телефонных карт, предоставляя доступ к услугам только по собственным картам оператора. Такой вариант требует от оператора минимальных вложений (особенно, если он уже предоставляет услуги обычной телефонной связи с использованием системы обработки телефонных карт с Протей-ТК) и, по мнению авторов, является на сегодня оптимальным.
Если же в существующей сети IP-телефонии выставление счетов производится централизованно, то проблема взаимодействия решается следующим образом.
Если сеть построена на базе оборудования VocalTec или, по крайней мере, с наличием привратника, произведенного фирмой VocalTec, который, как правило, занимается начислением платы за разговоры абонентов, то шлюз Протей-ITG общается с привратником по протоколу RAS, входящему в семейство протоколов Н.323.
Если сеть построена на базе оборудования Cisco, то шлюз взаимодействует с биллинговым центром сети по протоколу RADIUS.
Второй вариант организации связи заключается в создании на базе оборудования Протей собственной сети IP-телефонии, имеющей выход на другие сети. Между операторами производятся взаиморасчеты.
11.5 Экономические аспекты применения оборудования IP-телефонии
Шлюз IP-телефонии обеспечивает возможность использования сети с маршрутизацией пакетов IP для предоставления услуг междугородной и международной телефонной связи, что приводит к удешевлению услуг при приемлемых показателях качества обслуживания, сравнимых с теми же показателями в ТфОП. Удешевление достигается за счет использования современных алгоритмов кодирования речи, подавления пауз в разговоре и статистического мультиплексирования пользовательской информации.
В главе 1 отмечалось, что подобное удешевление не является единственным (или даже основным) преимуществом внедрения IP-телефонии, но для того, чтобы наглядно продемонстрировать (именно с этой точки зрения) привлекательность предоставления услуг междугородной связи с помощью технологии IP-телефонии, в таблице 11.2 представлены оценки возможных затрат и доходов, ожидаемых при развертывании и эксплуатации узла IP-телефонии для организации связи между Санкт-Петербургом и Москвой. Следует подчеркнуть, что оценки являются упрощенными и приведены исключительно в качестве примера.
Указанная в таблице комплектация оборудования может изменяться в зависимости от того, какое оборудование уже имеется уместного оператора. В полный комплект оборудования, кроме шлюза, входят также привратник, биллинговая система, коммутатор Ethernet и маршрутизатор.
Таблица 11.2 Расчет окупаемости узла IP-телефонии
| Исходные данные | |||
| Статья | Единицы | Кол-во | Примечания |
| Выделенный цифровой канал между С.-Петербургом и Москвой со скоростью | Кбит/с | 64 | |
| Количество телефонных линий | шт. | 30 (Е1) | |
| Расчетная загрузка оборудования узла связи | % | 20 | В дальнейшем -увеличение нагрузки |
| Допустимая загрузка оборудования узла связи | % | до 100 | При увеличении скорости передачи по выделенному каналу |
| Усредненный добавочный тариф (неочищенная прибыль) | $/мин | 0,06 | |
| Лицензия на предоставление услуг IP-телефонии | МРОТ | 40 | |
| Рабочий персонал | чел. | 2 | |
| Налог на прибыль | % | 34 | |
| Налог на добавленную стоимость (НДС) | % | 20 | Учтен в дальнейшем |
| Расчетный период | мес. | 12 | |
| Разовые затраты | |||
| Получение лицензии | МРОТ | 40 | |
| Стоимость оборудования Протей, пуско-наладочных работ, включения в сеть, сетевой мониторинг | $ | 11760 | Комплектация может быть изменена |
| Инсталляция выделенного канала | $ | 428 | через Ростелеком |
| Инсталляция канала Е1 | $ | 1972 | |
| Инсталляция серийного тел. номера | $ | 185 | |
| Итого | $ | 14464 | |
| Ежемесячные затраты на содержание узла | |||
| Аренда выделенного канала | $ | 660 | |
| Аренда канала Е1 | $ | 1825 | |
| Зарплата персонала | $ | 1000 | |
| Аренда помещения | $ | 150 | |
| Амортизация | $ | 93 | 10%/год от затрат на строительство |
| Коммерческие расходы (реклама) | $ | 910 | 5% от производственной себестоимости |
| Отчисления на социальные нужды | $ | 390 | 39% от фонда оплаты труда |
| Итого | $ | 5028 | |
| Расчет прибыли | |||
| Месячный доход = 0,06$/мин*60мин.*24час*30дней*30каналов*0,20 | $ | 15552 | |
| Месячная прибыль = доход -затраты/мес. налоги | $ | 6946 | |
| Расчетный период | |||
| Валовый доход = месячный доход* 12 | $ | 186624 | |
| Затраты на строительство узла (разовые) | $ | 14464 | |
| Расходы на содержание узла за 12 месяцев | $ | 60336 | |
| Прибыль | $ | 73804 | После уплаты налога |
| Резюме: экономическая эффективность узла связи | |||
| Общие затраты за расчетный период | $ | 74800 | |
| Валовый доход за расчетный период | $ | 186624 | |
| Рентабельность вложений | % | 99 |
Приведенные данные не претендуют на глубину экономического анализа внедрения IP-телефонии. Более того, по мнению авторов, время для такого анализа еще не настало, слишком молода сама индустрия IP-телефонии. И, все же, содержание таблицы 11.2 может подбодрить читателя, добравшегося почти до конца книги, и показать ему возможность получения реальных доходов от IP-телефонии уже сегодня.
А если приведенные в таблице 11.2 суммы не показались достаточной компенсацией потраченного на чтение данной книги времени, то в следующем параграфе излагается техническая идея, экономическая эффективность которой эквивалентна разве что известной карте боцмана Билли Бонса из стивенсоновского “Острова сокровищ”.
11.6 Виртуальная телефонная линия
Сколько раз мы пытались безуспешно дозвониться до абонента, работающего в сети Интернет? Неудобство, бесполезно потраченное время, моральные издержки, возможные убытки и отсутствие возможности сообщить вовремя срочную информацию - далеко неполный перечень неприятностей при использовании телефонной связи, связанных с многочасовым доступом к Интернет. Известные пути решения этой проблемы при помощи линий ADSL, базового доступа ISDN типа 2B+D, установкой второго телефонного номера имеют весьма ограниченное применение в нашей российской действительности.
В основу излагаемого здесь решения положено использование технологии IP-телефонии. Программно-аппаратный комплекс, в состав которого входят шлюз Протей-ITG и привратник Протей-GK, позволяет Оператору связи предоставить абонентам новую услугу:
работать в сети Интернет и разговаривать по телефону одновременно, занимая всего лишь одну обычную аналоговую линию. Ниже представлено описание механизма организации виртуальной телефонной линии.
Перед началом работы в сети Интернет абонент активизирует на своей телефонной станции дополнительную услугу “Переадресация при занятости абонента”. Предусмотрены два способа активизации услуги: самим абонентом при помощи сигналов DTMF или персоналом АТС при помощи средств эксплуатационного управления.
Далее абонент стандартным образом устанавливает соединение со своим поставщиком услуг сети Интернет и получает IP-адрес, назначаемый, как правило, динамически.
Абонент запускает любое клиентское приложение IP-телефонии, например, популярное программное обеспечение NetMeeting. При запуске клиентского приложения автоматически, по протоколу Н.323, инициируется процедура регистрации абонента у привратника сети Протей-GK, в ходе которой указывается телефонный номер и IP-адрес абонента. Кроме того, вводится PIN-код для идентификации абонента. Получив от абонента запрос регистрации - Registration Request, привратник обращается к базе данных для проверки прав абонента на пользование данной услугой. Если абонент подписан на эту услугу, то привратник подтверждает регистрацию сообщением Registration Confirm, после чего абонент может быть доступен во время работы в сети Интернет.
Дополнительно, по IP-адресу пользователя, может быть проведена идентификация Интернет-провайдера, организовавшего доступ абонента к услугам глобальной сети. Это может понадобиться в тех случаях, когда оператор телефонной связи заключает соглашения на организацию второй виртуальной телефонной линии только с некоторыми поставщиками услуг сети Интернет.
Вместо клиентского программного обеспечения может использоваться специальная плата (например, PhoneJack или LineJack производства фирмы Quicknet), вставляемая в персональный компьютер, к которой по двухпроводной линии подключается аналоговый телефонный аппарат.
На рис. 11.3 представлен алгоритм вызова пользователя, работающего в сети Интернет.
Вызывающий абонент набирает номер вызываемого абонента (1), и, если этот номер занят (вызываемый пользователь работает в Интернете), вызов переадресуется телефонной станцией к шлюзу Протей-ITG (2). Для того, чтобы вызов мог быть автоматически переадресован к шлюзу, на станции для шлюза должно быть выделено отдельное внутристанционное направление (не включенное в городской план нумерации, чтобы не расходовать номерную емкость).
Кроме того, каждому абоненту, подписавшемуся на услугу “Виртуальная телефонная линия”, должен быть присвоен внутристанционный (внутрисетевой) номер, на который переадресуется вызов при работе абонента в сети Интернет.
Шлюз, в свою очередь, передает привратнику запрос допуска к использованию сетевых ресурсов Admission Request по протоколу Н.323 (3). В запросе указывается телефонный номер вызываемого абонента. Привратник дает шлюзу разрешение использовать сетевые ресурсы (Admission Confirm), в котором указывается IP-адрес вызываемого абонента (4). Далее шлюз маршрутизирует вызов к вызываемому абоненту через 1Р-сеть(5). У вызываемого абонента на экране появляется сообщение о входящем вызове с указанием телефонного номера вызывающего абонента и акустическое извещение. Он может либо принять этот входящий вызов, либо отказаться от приема.
Чтобы обеспечить хорошее качество воспроизведения речевой информации, оператору необходимо задействовать механизмы предоставления гарантированного качества обслуживания, например, настроить маршрутизатор таким образом, чтобы речевому трафику, передаваемому в пакетах UDP, присваивался более высокий приоритет, чем трафику данных, передаваемому в пакетах TCP. Кроме того, желательно, чтобы шлюз с привратником и модемным пулом поставщика услуг сети Интернет располагались в одной локальной сети.
Если автоматически реализовать услугу “Виртуальная телефонная линия” не представляется возможным по техническим причинам, например, в сети не поддерживается дополнительная услуга “Переадресация при занятости абонента”, то ее можно реализовать при помощи системы обработки телефонных карт (СТК) Протей-ТК. Алгоритм такой реализации услуги представлен на рис. 11.4. В этом случае услуга может предоставляться любым абонентам ТфОП, но для обеспечения хорошего качества речи, опять-таки, следует задействовать механизмы предоставления гарантированного качества обслуживания.
Рис. 11.4 Вызов абонента, работающего в сети Интернет, через СТК
Вызываемый абонент (абонент, подписавшийся на услугу) выполняет действия, аналогичные предыдущему алгоритму.
Вызывающий абонент соединяется с СТК (1). Отметим, что на станции для услуги СТК выделяется серийный номер. Далее абоненту передается приглашение к набору номера. После того, как абонент введет при помощи сигналов DTMF номер вызываемого абонента, СТК устанавливает через АТС соединение со шлюзом Протей-ITG (2), который подключается к станции таким же образом, как и в предыдущем случае. Дальнейший алгоритм установления соединения идентичен алгоритму, описанному выше.
Следует особо отметить, что с помощью вышеизложенного пользователь, работающий в сети Интернет, имеет возможность не только принимать входящие вызовы, но также может сам инициировать вызовы, не прерывая своей Интернет-сессии.
11.7 Центр обработки вызовов
В центре обработки вызовов (Call-center) будут интегрированы как операторские, так и автоматизированные информационные службы, что позволит реализовать в одном комплексе максимально широкий спектр взаимосвязанных услуг. Центр реализован на базе технологии IP-телефонии с поддержкой протокола Н.323.
Для организации информационно-справочных служб в центре обработки вызовов предусмотрены ступень распределения вызовов (СРВ) и интерактивная речевая система (IVR).
Для офисного рынка в центре реализованы функции учрежденческой телефонной станции, так называемой 1Р-РВХ. Благодаря этому отпадает необходимость разворачивать в офисе две сетевые инфраструктуры: телефонную и компьютерную. 1Р-РВХ не только сохранит функциональные возможности традиционных УАТС (предоставление базовых соединений и стандартных дополнительных услуг), но и предложит сотрудникам офиса новые возможности, например, пользование телефонными услугами своей корпоративной УАТС независимо оттого, где они находятся, например, при работе дома.
При помощи центра обработки вызовов абонент может воспользоваться услугами Web-телефонии, т.е. он может инициировать телефонный вызов, выбрав ссылку на имя вызываемого абонента прямо на страницах Internet. Для этого нужно подвести курсор к имени вызываемого абонента в специальной базе данных на Web-странице и щелкнуть клавишей мыши.
Другими словами, нужное телефонное соединение устанавливается при щелчке мышью, когда курсор установлен на имени, номере или другом обозначении вызываемого абонента, через ссылку на Web-странице.
Кроме того, центр сможет сопровождать в реальном времени каждого клиента с момента его появления на домашней странице компании в сети Internet до оформления заказа на покупку необходимого продукта, проводя этого клиента через такие этапы, как демонстрация каталога предлагаемых изделий и выяснение возникающих вопросов путем телефонного общения с представителем компании.
Техническое обслуживание оборудования центра обработки вызовов осуществляется через протокол http, т.е. при помощи обычного Web Browser. Также, через Web-интерфейс, пользователь сможет управлять обслуживанием вызова, заказывать и отменять дополнительные услуги, регистрироваться и получать доступ к услугам и т.д.
11.8 Модуль IPU как средство интеграции цифровых АТС с IP-сетями
Все чаще телефонные сети общего пользования (ТфОП) используются для организации доступа к глобальной сети Internet. Операторы телефонной связи, как правило, не получают от этого существенного дохода, в то время как поставщики услуг сети Интернет получают значительную прибыль. Кроме того, коммутационное оборудование ТфОП проектировалось из расчета интенсивности нагрузки 0.1 - 0.15 Эрланга в час наибольшей нагрузки (ЧИН) на одну абонентскую линию, и именно при таких параметрах обеспечивалось удовлетворительное качество обслуживания телефонных вызовов. Анализ нагрузки с учетом модемных соединений между абонентами ТфОП и поставщиками услуг сети Интернет показывает, что в некоторых случаях интенсивность нагрузки на одну абонентскую линию может достигать 0,8 Эрланга в ЧНН. При этом занимаются не только абонентские, но и межстанционные соединительные линии, что приводит к ощутимым перегрузкам в ТфОП.
Предлагаются различные решения проблемы отвода трафика сети Интернет от соединительных линий ТфОП. Одним из наиболее действенных решений является организация в коммутационном оборудовании точки присутствия Интернет - Internet Point of Presence (IPoP).
При этом не только отводится трафик Интернет, но и операторы телефонной связи сами становятся поставщиками услуг глобальной сети Интернет, что позволяет существенно повысить их доходы.
На рис.11.5 представлен входящий в комплекс оборудования АТСЦ-90 модуль IPU (Internet Point of Presence Unit), позволяющий организовать интеграцию коммутационного оборудования АТС в сети с маршрутизацией пакетов IP. Модуль IPU является интегрированным сервером доступа: в качестве шлюза IP-телефонии он обеспечивает передачу речевого трафика и факсимильных сообщений по сетям с маршрутизацией пакетов IP, а в качестве сервера удаленного доступа к IP-сетям предоставляет абонентам ТфОП доступ к Интернет или к удаленным ЛВС по коммутируемым линиям.
Модуль IPU подключается к АТС по цифровым трактам Е1 с использованием систем сигнализации ОКС7 (ISUP) или E-DSS1, а к сетям с маршрутизацией пакетов IP - при помощи интерфейса 10/100Base-T. Сервер автоматически (по набранному номеру) распознает, какое из приложений должно быть использовано для обслуживания поступившего вызова.
11.9 Тестирование протоколов IP-телефонии
Для тестирования семейства протоколов сигнализации Н.323, рассмотренных в главах 5 и 6, а также протоколов стека TCP/IP, в том числе, протоколов прикладного уровня RTP/RTCP, рассмотренных в главе 4, используется протокол-тестер SNT, представленный на рис. 11.6.
Рис. 11.6 Протокол-тестер SNT
Протокол-тестер SNT-7531, наряду с тестированием протоколов ОКС7, V5, DSS1, проверяет протокол Н.323 (как и другие рассмотренные в книге протоколы IP-телефонии) на соответствие международным рекомендациям и российским национальным требованиям. Протокол-тестер может использоваться операторами связи для проведения пуско-наладочных работ и сопряжения оборудования разных фирм-производителей, разработчиками оборудования для отладки своего оборудования, сертификационными и испытательными центрами - для проведения испытаний по “Типовой программе и методике”.
Определены два основных режима функционирования тестера:
мониторинг и симуляция.
Мониторинг предусматривает пассивное чтение данных в сигнальных каналах. При работе тестера SNT в режиме мониторинга передаваемые и принимаемые сигнальные сообщения выводятся на экран в порядке их передачи и приема. Различные фильтры и настройки монитора позволяют выводить на экран в удобном для пользователя формате только необходимые данные (например, только сигнализацию RAS и т.д.). Существует возможность сохранения данных в файле в ASCII формате.
Симулятор является эталонной моделью оборудования, в котором реализован тестируемый протокол. При совместной работе с терминальным оборудованием Н.323 (шлюзом) или привратником протокол-тестер симулирует, соответственно, режимы работы привратника, терминала или шлюза и позволяет определить, насколько функционирование тестируемого оборудования соответствует требованиям международных и национальных стандартов. Реализованный в протокол-тестере симулятор протокола Н.323 позволяет создать исходящий вызов, ответить на вызов, имитировать занятость абонента и т.д., а также содержит тестовые сценарии для всех основных этапов установления и завершения соединения при помощи протокола Н.323, включая:
• обнаружение привратника и регистрацию в нем (сигнализация RAS);
• установление сигнального соединения (сигнализация RAS иН.225.0/0.931);
• определение ведущего и ведомого оборудования и обмен информацией о его функциональных возможностях (сигнализация Н.245);
• открытие логических каналов (сигнализация Н.245);
• передачу речевой информации (протокол RTP/RTCP);
• завершение соединения.
Остановимся немного более подробно на каждом из этих этапов. В тестовые сценарии регистрации шлюза включены типичные ошибочные ситуации, такие, например, как:
• отсутствие ответа от привратника;
• отказ в регистрации.
Для установления соединения между двумя терминалами (шлюзами) с участием привратника используется два способа передачи сигнальной информации: непосредственно от одного оборудования к другому или с маршрутизацией сигнальных сообщений привратником.
В протокол- тестере реализованы следующие ошибочные ситуации, возникающие при установлении сигнального соединения:
• запрет доступа привратником (из-за того, что не зарегистрирована вызываемая сторона, не зарегистрирован вызывающий терминал (шлюз), или отсутствует запрошенная полоса пропускания);
• не получен ответ на сообщение Setup: отсутствие сообщений Call Proceeding/Alerting/Connect.
После успешного установления сигнального соединения терминалы (шлюзы) Н.323 открывают управляющий канал Н.245. На этом этапе выполняются две процедуры: определение ведущего и ведомого оборудования и обмен информацией о функциональных возможностях.
Во время выполнения любой из этих процедур могут возникнуть сбои в работе протокола Н.245, отработка которых предусмотрена в тестовых сценариях протокол-тестера:
• сбой в определении ведущего и ведомого оборудования (из-за того, что совпали числовые значения в поле типа оборудования, или инициирующая сторона не принимает ответа от встречной стороны в течение назначенного промежутка времени);
• сбой в процедуре обмена информацией о функциональных возможностях (из-за того, что шлюз, инициировавший процедуру, не принимает сообщение подтверждения в течение назначенного промежутка времени).
После выполнения вышеуказанных процедур начинается процедура открытия логических каналов. В тестовые сценарии для проверки этого этапа включены следующие возможные случаи:
• приемный шлюз запрещает открытие канала (из-за того, что вид информации неизвестен или не поддерживается, ширина полосы недостаточна, идентификатор сеанса связи недействителен и т. д.);
• инициирующий шлюз своевременно не получает подтверждения и завершает соединение.
Специальные опции протокол-тестера SNT-7531 позволяют измерять время установления соединения - один из важнейших параметров качества обслуживания. При их помощи определяются также и другие параметры качества обслуживания: количество потерянных RTP-пакетов, средняя задержка и вариация задержки RTP-пакетов.
Завершая эту главу и всю книгу, хочется пожелать читателю, дочитавшему ее до конца, не пожалеть о потраченном времени.Ко всем приведенным в книге аргументам и длинному списку упомянутых в данной главе продуктов IP-телефонии можно добавить и знаменательное событие, произошедшее 1 июня 1999 года, когда Министерство связи (в ту пору - Госкомитет по связи и информатизации) официально признало IP-телефонию подлежащим лицензированию видом услуг связи, хотя и под псевдонимом “Телематическая служба речевой информации”.
Вспоминая замечание о попытках сдерживания IP-телефонии административными методами, с которого начиналась эта книга, можно с известной долей оптимизма заключить, что здесь также победил здравый смысл, позволивший применить вполне подходящий к развитию IP-телефонии принцип Авраама Линкольна: “Если выдержите слона за заднюю ногу, а он вырывается, то самое лучшее - отпустить его”.
Привратник
В привратнике сосредоточен весь интеллект сетей IP-телефонии, базирующихся на рекомендации ITU Н.323. Сеть Н.323 имеет зонную архитектуру (рис. 5.6). Привратник выполняет функции управления зоной сети IP-телефонии, в которую входят терминалы, шлюзы и устройства управления конференциями, зарегистрированные у этого привратника. Разные участки зоны сети Н .323 могут быть территориально разнесены и соединяться друг с другом через маршрутизаторы. Следует обратить внимание на то, что коммутаторы кадров Ethernet и маршрутизаторы пакетов IP не являются сетевыми элементами Н.323, так как они работают на звеньевом или сетевом уровнях соответственно, в то время как оборудование Н.323 работает на прикладном уровне стека протоколов TCP/IP.
Рис. 5.6 Зона сети Н.323
В число наиболее важных функций, выполняемых привратником, входят:
• преобразование так называемого alias-aa?ana (eмени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сети с маршрутизацией пакетов IP (IP адрес и номер порта TCP);
• контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS (используются сообщения ARQ/ACF/ARJ);
• контроль, управление и резервирование пропускной способности сети;
• маршрутизация сигнальных сообщений между терминалами, расположенными в одной зоне; привратник может организовывать сигнальный канал непосредственно между терминалами или ретранслировать сигнальные сообщения от одного терминала к другому. В последнем случае привратник в любое время знает состояние конечных пользователей и может предоставлять дополнительные услуги, такие как переадресация, переключение связи, установка вызова на ожидание, перехват вызова и т.д. Хотя, справедливости ради, надо отметить, что эти услуги могут быть реализованы (согласно рекомендациям ITU H.450.X) в терминалах пользователей и предоставляться безучастия привратника.
В том случае, когда вызывающий абонент знает IP-адрес терминала вызываемого абонента, соединение между двумя устройствами может быть установлено без помощи привратника.
Это означает, что наличие в сети Н. 323 привратника не обязательно. Но, в то же время, следует отметить, что при наличии привратника обеспечивается мобильность абонентов, т.е. способность пользователя получить доступ к услугам с любого терминала в любом месте сети и способность сети идентифицировать пользователей при их перемещении из одного места в другое.
При отсутствии в сети привратника преобразование адреса вызываемого абонента, поступающего со стороны ТфОП в формате Е. 164, в транспортный адрес IP-сети должно выполняться шлюзом.
В одной сети может находиться несколько привратников, которые должны взаимодействовать между собой. Следует особо отметить, что хотя привратник является отдельным логическим элементом сети, он может быть реализован в терминале, в шлюзе, в устройстве управления конференциями или в устройствах, не специфицированных в рекомендации Н.323. Примерами таких устройств могут быть система распределения вызовов, учрежденческая телефонная станция, система обработки телефонных карт, система речевой почты и другие приложения.
5.7 Устройство управления конференциями
Рекомендация Н.323 предусматривает три вида конференций (рис. 5.7).
Первый вид - централизованная конференция, в которой оконечные устройства соединяются в режиме точка-точка с устройством управления конференциями (MCU), контролирующим процесс создания и завершения конференции, а также обрабатывающим потоки пользовательской информации.
Второй вид - децентрализованная конференция, в которой каждый ее участник соединяется с остальными участниками в режиме точка - группа точек, и оконечные устройства сами обрабатывают (переключают или смешивают) потоки информации, поступающие от других участников конференции.
Третий вид - смешанная конференция, т.е. комбинация двух предыдущих видов.
Преимущество централизованной конференции - сравнительно простые требования к терминальному оборудованию, недостаток -большая стоимость устройства управления конференциями.
Для децентрализованной конференции требуется более сложное терминальное оборудование, кроме того, желательно, чтобы в сети поддерживалась передача пакетов IP в режиме многоадресной рассылки (IP multicasting). Если сеть не поддерживает этот режим, терминал может передавать информацию к каждому из остальных терминалов, участвующих в конференции, в режиме точка-точка, но это становится неэффективным при числе участников более четырех.
Устройство управления конференциями MCU содержит один обязательный элемент - контроллер многоточечных соединений - Multipoint controller (МС). Кроме того, MCU может содержать один или более процессоров для обработки информации пользователей при многоточечных соединениях - Multipoint processor (MP). Следует отметить, что контроллер МС и процессор MP являются самостоятельными логическими устройствами Н.323 и что контроллер может существовать независимо от процессора (обратное неверно). Контроллер может быть физически совмещен с привратником, со шлюзом или с MCU, a MCU, в свою очередь, может быть совмещено со шлюзом или с привратником (рис. 5.8).
Контроллер конференций должен использоваться для организации конференции любого вида. Он организует обмен между участниками конференции данными о функциональных возможностях (capabilities) их терминалов, указывает, в каком режиме (с использованием каких кодеков) участники конференции могут передавать информацию, причем этот режим может изменяться в ходе конференции, например, при подключении к ней нового участника. Таким образом, контроллер МС определяет режим конференции (selected communication mode - SCM), который может быть общим для всех участников конференции или отдельным для каждого из них.
Рис. 5.8 Возможная реализация МС и МР в оборудовании Н.323
Так как в сети может быть несколько контроллеров МС, то для каждой вновь создаваемой конференции должна проводиться процедура определения ведущего и ведомого оборудования, для того, чтобы выявить тот из контроллеров МС, который будет управлять данной конференцией.
При организации централизованной конференции, кроме контроллера МС, должен использоваться процессор МР, обрабатывающий пользовательскую информацию и отвечающий за переключение или смешивание речевых потоков, видеоинформации и данных. При организации децентрализованной конференции процессор МР не используется.
Пропорции в телекоммуникациях
Гуляя в тенистой роще, греческий философ Анаксимен беседовал со своим учеником. “Скажи мне, - спросил юноша, - почему тебя часто одолевают сомнения? Ты прожил долгую жизнь, умудрен опытом и учился у великих эллинов. Как же так вышло, что и для тебя осталось столь много неясных вопросов?”. В ответ философ очертил посохом перед собой два круга: маленький и большой. “Твои знания -это маленький круг, а мои - большой. Но все, что осталось вне этих кругов, - неизвестность. Маленький круг c неизвестностью соприкасается мало. Чем шире круг твоих знаний, тем протяженнее его граница с неизвестностью. И впредь, чем больше ты будешь узнавать нового, тем больше у тебя будет возникать неясных вопросов”.
Классическая телефония с ее традиционными телефонными услугами POTS (Plain Old Telephone Service), достаточно хорошо изученная за свою более чем столетнюю историю, соответствует малому кругу из этой поучительной притчи. Большой круг представляет нарождающуюся индустрию инфокоммуникаций, являющуюся результатом взаимопроникновения (конвергенции) информационных и телекоммуникационных технологий и услуг и действительно порождающую больше неясных вопросов, чем готовых ответов. Не планируя в этой главе (да и во всей книге) рассмотреть множество разнообразных аспектов инфокоммуникаций за исключением одного -IP-телефонии, - коснемся лишь их общей базы - телекоммуникаций.
Со времени своего возникновения телекоммуникации базируются на передаче электромагнитных сигналов через транспортную среду, каковой могут быть:
• металлический кабель,
• оптоволокно,
• радиоканал.
Передаваемая в виде электромагнитных сигналов информация может представлять собой:
• речь,
• данные,
• видеоизображение
или любую их комбинацию, называемую мультимедийной информацией.
Эти три источника и три составные части телекоммуникаций в полной мере отражают их современное состояние, причем современность здесь понимается в широком смысле. Передача по сетям связи информации трех перечисленных выше видов благополучно осуществлялась не одно десятилетие, пока не сработал принцип, давно известный в сфере искусств, - все дело в пропорциях.
Еще в 1996 г. в США трафик передачи данных впервые превысил речевой (рис. 1.1) и продолжает демонстрировать завидные темпы роста (до 30% в год по сравнению с 3% в год для телефонии). То же произошло в Европе в 1999 году. Все это послужило толчком к началу новой эры в телекоммуникациях - эры интегрированных решений и конвергенции всех видов связи. Протокол IP получил мировое признание и, в известной степени, стал “де-факто” стандартом для передачи мультимедийной информации.
Если добавить сюда феномен сети Интернет, где, по самым скромным подсчетам, рост числа пользователей составляет 5% в месяц, то станет совершенно ясно, что все эти события самым непосредственным образом влекут за собой коренное изменение подходов к построению информационных сетей. Речь и данные меняются местами. Традиционные сети передачи данных базировались на магистралях с коммутацией каналов, предназначенных для телефонного трафика. При новом подходе - все наоборот: телефония будет надстраиваться над инфраструктурой сети передачи данных.
Смещение центра тяжести в область передачи данных поставило вопрос о поиске удобного способа встраивания речи в мультимедийный цифровой поток. Причина популярности IP как раз и заключается в его восприимчивости к требованиям со стороны не только услуг передачи данных, но и приложений реального времени. Примером может служить успешно реализованная технология передачи речевой информации по сетям с маршрутизацией пакетов IP - Voice over IP (VolP) или IP-телефония.
Но понятие Voice over IP подразумевает не только и не столько использование сети Интернет в качестве среды передачи речи, сколько сам протокол IP и технологии, обеспечивающие надежную и высококачественную передачу речевой информации в сетях пакетной коммутации. Отсутствие гарантированного качества обслуживания при передаче речи компенсируется появлением таких технологий, как многопротокольная коммутация по меткам - Multiprotocol Label Switching (MPLS), протокол резервирования ресурсов - Resource Reservation Protocol (RSVP), дифференциальное обслуживание разнотипного трафика - Differentiated Services (DiffServ) и других.
Все большую популярность приобретает передача пакетов IP, упакованных в контейнеры систем синхронной цифровой иерархии - Synchronous Digital Hierarchy (SDH), а также технология спектрального мультиплексирования - Wave Division Multiplexing (WDM). Во всех случаях необходимым условием является подчинение каждого узла системы единой политике управления трафиком. Этому же призваны помочь протоколы RTP, RTSP, Diffentiaten Services и другие механизмы, рассматриваемые в следующих главах книги. Здесь же достаточно отметить, что стандартизация речевых технологий на основе стека TCP/IP и их поддержка лидерами рынка пакетной телефонии обеспечат совместимость оборудования разных производителей и позволят создавать системы, в которых возможны вызовы с аналогового телефонного аппарата, подключенного к порту маршрутизатора, на персональный компьютер, или с персонального компьютера на номер ТфОП, в рамках трех сценариев IP-телефонии, рассматриваемых в следующей главе.
1.2 Перспективы развития ТфОП и IP-сетей
Продолжая анализ роста трафика данных и речи, представленного в виде графиков на рис.1 в предыдущем параграфе , авторы позволили себе привести прогноз роста количества абонентов (графики на рис.1.2а). Суть прогноза отнюдь не в том, что количество пользователей сетей стационарной связи, мобильной связи и Интернет к 2004-2006 годам достигнет миллиарда, а в том, что емкости этих сетей сближаются. В контексте данной главы последнее обстоятельство, согласно закону диалектики о переходе количества в качество, приводит к принципиально новым мыслям по поводу конвергенции этих сетей. Немаловажным стимулом таких мыслей является прогноз общемировых доходов от телекоммуникационных услуг, сделанный Dataquest (рис. 1.26), графическое представление которого почти совпадает с верхней кривой на рис. 1.2а. Пороговая величина в этом прогнозе составляет триллион долларов США совокупного дохода по сегментам рынка (речь, данные, мобильная связь), а переход за этот порог ожидается еще раньше - в 2002-2003 гг.
Одним из аспектов, способствующих упомянутой выше конвергенции, является ключевой принцип отделения организации услуг от транспортировки информации, составляющий основу идеи Интеллектуальных сетей. Суть концепции Интеллектуальной сети (IN) заключается в построении универсальной среды, обеспечивающей наибольшую эффективность создания и предоставления новых телефонных услуг. Постепенно эта концепция стала средством глобального нагнетания вычислительной мощности в телефонную сеть общего пользования (ТфОП), о чем немало сказано в только что вышедшей монографии [8].
Здесь же представляется полезным продолжить количественные оценки и попробовать представить себе краткосрочный и долговременный прогнозы развития телекоммуникационных услуг.
Краткосрочный прогноз авторы связывают с упомянутыми выше аспектами конвергенции сетей и услуг связи. Долгосрочный прогноз предполагает, что преобладание приложений типа клиент-сервер на основе IP-сетей (например, поиск информации, почта и др.) сохранится. Но в отдаленной перспективе внутренняя природа сети, базирующейся на протоколе IP, может стать тормозом для выполнения требований интерактивной мультимедиа: высокое быстродействие в реальном времени и “сквозная” широкополосная интерактивность. Для такого рода приложений в будущем потребуется более мощная платформа.
Рис.1.3 иллюстрирует эволюцию телекоммуникационных приложений на основе IP.
Приняв во внимание то обстоятельство, что IP-телефония является одним из важнейших приложений на базе протокола IP, на основании рис.1.3 читатель может принять решение о том, насколько целесообразно прочесть данную книгу. Основной вывод авторов из этого рисунка заключается в том, что Internet Protocol безусловно будет доминирующим протоколом в сетях следующего поколения, которым предстоит поддерживать передачу речи, данных, факсимиле, видеоинформации и мультимедиа.
Первоочередная цель конвергенции сетей на базе протокола IP -это снижение общих расходов, складывающихся не только из капитальных затрат на приобретение и инсталляцию телекоммуникационного оборудования, но и из затрат на его содержание. Теоретически одна объединенная сеть уменьшила бы потребность в квалифицированном персонале - одни и те же люди стали бы заниматься и телефонией, и системами передачи данных. Наличие всего одного канала доступа к распределенной сети тоже основательно снизило бы ежемесячные расходы. Направляя речевой трафик через корпоративную магистральную сеть передачи данных, можно существенно уменьшить затраты на традиционные телефонные услуги. И, наконец, сокращение единиц используемого оборудования значительно уменьшит стоимость его технического обслуживания. Как отметил представитель одного международного оператора связи, переход на технологию IP-телефонии позволит ему сэкономить порядка 70% средств на капитальные затраты, 60-80% средств, выделяемых на организацию каналов доступа, и 50% средств на текущее обслуживание и ремонт сети [13].
Однако экономия на стоимости инфраструктуры - это не то, ради чего замышлялся переход к объединенным сетям. Революция произойдет тогда, когда появятся новые приложения, например, когда центры обслуживания клиентов смогут в реальном времени “сопровождать” каждого покупателя с момента его появления на домашней странице компании в сети Интернет до оформления заказа на покупку нужного продукта, “проводя” его через такие этапы, как демонстрация каталога предлагаемых изделий и выяснение неясных вопросов в ходе телефонного общения с представителем компании. Другой пример применения новых технологий - использование сотрудниками телефонного сервиса своей корпоративной УАТС независимо от того, где он и находятся, например, при работе дома. Кэтим применениям IP-телефонии авторы вернутся в главе 11.
При всех оптимистических прогнозах, изложенных выше, не следует забывать, что традиционная телефонная связь опирается на мощную базу, создававшуюся на протяжении многих десятилетий, и такая система не может не обладать определенной инерцией.
Исходя из этого, вряд ли стоит ожидать, что не сегодня-завтра произойдет мгновенный революционный скачок в области связи, и Интернет-телефония вытеснит все остальные технологии. Скорее наоборот: на протяжении ближайших 5-10 лет традиционная телефония будет по-прежнему занимать доминирующие позиции. Переход на новые, более прогрессивные методы будет происходить постепенно эволюционным путем, в разных странах с разной скоростью. А это значит, что в течение длительного времени ТфОП и IP-сети будут вынуждены существовать параллельно, обеспечивая взаимную прозрачность и объединяя свои усилия в обслуживании разнородного абонентского трафика.
Согласно известной формуле о невозможности находиться в каком-то обществе и быть вне его законов, при вхождении IP-телефонии в давно сформировавшееся глобальное телефонное общество необходимо соблюдение основных законов существующей ТфОП:
эксплуатационная надежность с тремя девятками после запятой, жесткие нормы качества передачи речи в реальном времени и т.п.
Не менее законов, правил и норм важны традиции, сформировавшиеся за более чем столетний период существования ТфОП. И. Губерманом дана точная формулировка важности традиций:
Владыка наш - традиция. А в ней -свои благословенья и препоны;
неписаные правила сильней, чем самые свирепые законы.
Поэтому не менее важно сохранить все привычные для пользователя действия - набор номера, способ доступа к телефонным услугам и т. д. Таким образом, абонент не должен ощущать разницы между IP-телефонией и обычной телефонной связью ни по качеству речи, ни по алгоритму доступа.
По тем же причинам весьма желательно обеспечить между ТфОП и IP-сетями полную прозрачность передачи пользовательской информации и сигнализации. Дело в том, что в отличие, например, от большинства корпоративных сетей связи, сети общего пользования не имеют национальных и ведомственных границ. IP-телефония должна обладать возможностью поддерживать совместную работу и обеспечивать информационную прозрачность с множеством стандартов связи, принятых в разных странах мира.Речь идет не только об электрической стыковке - необходимо найти взаимоприемлемое решение таких задач, как взаимодействие протоколов верхних уровней и приложений, начисление платы и др.
Рабочая группа MEGACO комитета IETF,
Глава 9 Протокол MEGACO/H.248
9.1 История создания и особенности протокола MEGACO/H.248
Рабочая группа MEGACO комитета IETF, продолжая исследования, направленные на усовершенствование протокола управления шлюзами, создала более функциональный (по сравнению с рассмотренным в предыдущей главе протоколом MGCP) протокол MEGACO. Но разработкой протоколов управления транспортными шлюзами, кроме комитета IETF, занималась еще и исследовательская группа SG 16 Международного союза электросвязи. Так, в проекте 4-й версии рекомендации Н.323 ITU-T ввел принцип декомпозиции шлюзов, уже описанный с той или иной степенью детализации в главах 1, 2 и 8. Важной особенностью нововведения ITU-T явилось то, что управление транспортными шлюзами - Media Gateway (MG) - осуществляется контроллером транспортных шлюзов - Media Gateway Controller (MGC) - при помощи протокола MEGACO, адаптированного под сетевое окружение Н.323. Спецификации адаптированного протокола приведены в недавно утвержденной рекомендации ITU-T H.248. В данной книге этот протокол называется MEGACO/H.248, так как авторам не хотелось бы умалить чьи-либо заслуги в разработке и адаптации этого протокола. На рис. 9.1. представлено дерево эволюции протокола MEGACO/H.248.
Рассмотрим кратко основные особенности протокола MEGACO/ H.248. Для переноса сигнальных сообщений MEGACO/H.248 могут использоваться протоколы UDP, TCP, SCTP или транспортная технология ATM. Поддержка для этих целей протокола UDP - одно из обязательных требований к контроллеру шлюзов. Протокол TCP должен поддерживаться и контроллером, и транспортным шлюзом, а поддержка протокола SCTP, так же, как и технологии ATM, является необязательной.
Рис. 9.1 Дерево эволюции протокола MEGACO/H.248
Еще одной особенностью протокола MEGACO/H.248 является то, что сообщения этого протокола могут кодироваться двумя способами. Комитет IETF предложил текстовый способ кодирования сигнальной информации, а для описания сеанса связи предложил использовать протокол SDP. ITU-T предусматривает бинарный способ представления сигнальной информации - ASN. 1, а для описания сеансов связи рекомендует специальный инструмент - Tag-length-value (TLV).
Контроллер шлюза должен поддерживать оба способа кодирования, в то время как шлюз - только один из этих способов.
9.2 Модель процесса обслуживания вызова
При описании алгоритма установления соединения с использованием протокола MEGACO комитет IETF опирается на специальную модель процесса обслуживания вызова, отличную от модели MGCP. Протокол MEGACO оперирует с двумя логическими объектами внутри транспортного шлюза: порт (termination) и контекст (context), которыми может управлять контроллер шлюза. Пример модели процесса обслуживания вызова приведен на рис. 9.2.
Порты являются источниками и приемниками речевой информации. Определено два вида портов: физические и виртуальные. Физические порты, существующие постоянно с момента конфигурации шлюза, это аналоговые телефонные интерфейсы оборудования, поддерживающие одно телефонное соединение, или цифровые каналы, также поддерживающие одно телефонное соединение и сгруппированные по принципу временного разделения каналов в тракт Е1. Виртуальные порты, существующие только в течение разговорной сессии, являются портами со стороны IP сети (RTP-порты), через которые ведутся передача и прием пакетов RTP.
Рис. 9.2 Примеры модели процесса обслуживания вызова
Виртуальные порты создаются шлюзом при получении от контроллера команды Add и ликвидируются при получении команды Subtract, тогда как физические порты при получении команды Add или Subtract, соответственно, выводятся из нулевого контекста или возвращаются обратно в нулевой контекст.
Порт имеет уникальный идентификатор (TerminationID), который назначается шлюзом при конфигурации порта. Например, идентификатором порта может служить номер тракта Е1 и номер временного канала внутри тракта. Иногда команды могут относиться ко всему шлюзу, тогда используется специальный идентификатор порта (TerminationID) - “Root”.
Порты обладают рядом свойств (properties), каждое из которых имеет уникальный идентификатор (propertylD). Например, порты могут обладать свойствами генерировать речевые подсказки, акустические и вызывные сигналы, а также детектировать сигналы DTMF.
При создании портов некоторые свойства присваиваются им по умолчанию. При помощи протокола MEGACO контроллер может изменять свойства портов шлюза. Свойства портов группируются в дескрипторы, которые включаются в команды управления портами (таблица 9.1).
Таблица 9.1 Дескрипторы протокола MEGACO
| Название дескриптора | Описание |
| Modem | Идентифицирует тип и параметры модема |
| Mux | Описывает тип мультиплексирования информации, используемый мультимедийными терминалами, например, Н.221, Н.223, Н.225.0 |
| Media | Специфицирует параметры информационного потока |
| TerminationState | Специфицирует свойства порта шлюза. Дескриптор содержит два параметра. Параметр ServiceStates описывает статус порта (работает в тестовом режиме - test, находится в нерабочем состоянии - out of service, по умолчанию указывается, что порт работает в нормальном режиме - in service). Параметр BufferedEventProcessingMode описывает реакцию шлюза на событие, о котором не надо немедленно оповещать контроллер. Определены две реакции на событие: игнорировать или обработать |
| Stream | Включает в себя ряд дескрипторов (Remote, Local, LocalControl, Signals, Events), специфицирующих параметры отдельного двунаправленного информационного потока |
| Local | Содержит параметры, описывающие информационный поток, передаваемый или принимаемый данным шлюзом. Информация, содержащаяся в этом дескрипторе, переносится от одного шлюза к другому |
| Remote | Содержит параметры, описывающие информационный поток, передаваемый или принимаемый удаленным шлюзом. Информация, содержащаяся в этом дескрипторе, переносится от одного шлюза к другому |
| LocalControl | Содержит параметр Mode - режим работы и ряд свойств порта. Параметр Mode может принимать значения send-only, receive-only, send/receive, inactive, loop-back и delete. Дескриптор передается на участке между шлюзом и контроллером |
| Events | Определяет события, которые шлюз должен отслеживать, и реакцию на эти события. Определены следующие реакции: NotifyAction (известить контроллер), Accumulate (сохранить информацию о событии в буфере), AccumulateByDigitMap (накопить цифры номера в соответствии с планом нумерации), KeepActive (известить контроллер, и продолжить передачу сигнала) |
| Signals | Описывает сигналы конечному пользователю, передачу которых порт шлюза должен начать или прекратить |
| Audit | Содержит информацию (в виде ряда дескрипторов), которую контроллер запрашивает у шлюза. Посылается в командах AuditValue и AuditCapabilities |
| Packages | Описывает совокупность свойств порта, передается в команде AuditValue |
| DigitMap | При помощи этого дескриптора контроллер информирует шлюз об используемом плане нумерации |
| ServiceChange | Содержит информацию, относящуюся к изменению состояния порта шлюза, такую как причина, метод изменения и др. |
| Observed Events | Содержит информацию о произошедших событиях. Передается в командах Notify и AuditValue |
| Statistics | Содержит статистическую информацию, собранную портом за время соединения |
| Extension | Позволяет передавать информацию, не специфицированную в протоколе |
Контекст - это отображение связи между несколькими портами, то есть абстрактное представление соединения двух или более портов одного шлюза. В любой момент времени порт может относиться только к одному контексту, который имеет свой уникальный идентификатор. Существует особый вид контекста - нулевой. Все порты, входящие в нулевой контекст, не связаны ни между собой, ни с другими портами. Например, абстрактным представлением свободного (не занятого) канала в модели процесса обслуживания вызова является порт в нулевом контексте.
В общем случае для присоединения порта к контексту служит команда Add. При этом, если контроллер не специфицирует существующий контекст, к которому должен быть добавлен порт, то шлюз создает новый контекст.
Если шлюз поддерживает конференцию, то контекст определяет топологию связей между портами, участвующими в конференции, то есть возможные направления потоков информации для каждой пары портов. Примеры топологий, поддерживаемых протоколом MEGACO/H.323, приведены на рис. 9.3.
Вариант 1
Вариант 2
Вариант 3
Вариант 4
Вариант 5
Вариант 6 Рис. 9.3 Варианты топологии связей между портами внутри одного контекста
Краткое описание вариантов топологии связей в конференции, представленных на рис. 9.3, сведено в таблицу 9.2.
Таблица 9.2 Описание вариантов топологии
| Вариант топологии | Описание |
| 1 | Топология связей не специфицирована, любой порт передает информацию другим портам и принимает информацию от других портов, участвующих в конференции |
| 2 | Порты 1 и 2 изолированы друг от друга, порт 3 передает информацию портам 1 и 2 и принимает информацию от них |
| 3 | Порты 1 и 2 изолированы друг от друга, порт 2 только принимает информацию от порта 3, обмен информацией между портами 1 и 3 - двусторонний |
| 4 | Порты 1 и 2 изолированы друг от друга, порт 3 только принимает информацию от порта 2 и обменивается информацией с портом 1 |
| 5 | Двусторонняя связь между окончаниями 2 и 3 (как во втором случае) |
| 6 | Двусторонняя связь между всеми окончаниями (как в первом случае) |
Следует отметить, что порты шлюза не знают о режиме, который поддерживают другие порты, участвующие в конференции.
9.3 Сравнительный анализ протоколов MGCP и MEGACO
Цель данного параграфа - определить, в чем сходны и чем различаются протоколы MGCP и MEGACO. Начнем с общих черт протоколов.
Оба протокола используются в сетях с одинаковой архитектурой, где транспортными шлюзами управляют высокоинтеллектуальные контроллеры. Оба протокола умеют работать со шлюзами одних и тех же видов, классификация шлюзов была дана в предыдущей главе. Порты шлюзов поддерживают детектирование одних и тех же событий и генерацию одних и тех же сигналов. Используются одинаковые транспортные механизмы для доставки сообщений систем сигнализации ОКС7, DSS1, ВСК. Процедуры установления и разрушения соединений, реализуемые обоими протоколами, идентичны. Кроме того, используются одинаковые механизмы поддержания защиты сети. На этом сходство протоколов MGCP и MEGACO/H.248 заканчивается.
Самым важным отличием протокола MEGACO/H.248 от протокола MGCP является использование иной модели организации связи. Протокол MEGACO/H.248 работает не только с телефонными портами, но и UDP-портами. Кроме того, connection в модели MGCP - это, в общем случае, подключение к соединению между портами разного оборудования, в то время как context в модели MEGACO/H.248 всегда отображает связь между портами одного шлюза (рис. 9.4).
Меняя топологию связей портов, относящихся к одному контексту, при помощи протокола MEGACO контроллер может гибко управлять конференциями. Данной возможности в протоколе MGCP не предусмотрено.
Выше уже отмечалось, что для протокола MEGACO/H.248 предусмотрено два способа кодирования, тогда как сообщения протокола MGCP представляются в текстовом формате, а бинарный способ кодирования не поддерживается. Кроме того, в протоколах используются разные параметры команд и коды ошибок.
Протокол MEGACO/H.248, так же, как и протокол MGCP, предусматривает корреляцию команд и ответов.
Но если в протоколе MGCP транзакция образуется из команды и ответа на нее, то в протоколе MEGACO/H.248 транзакция состоит из запроса - совокупности акций и отклика на запрос. Общая структура запроса выглядит так:
TransactionRequest(Transactionid {
ContextiD {Command ... Command),
ContextiD {Command ... Command } })
Общая структура отклика на запрос приведена ниже:
TransactionReply(TransactionID {
ContextiD { Response ... Response },
ContextiD { Response ... Response } })
Каждая акция, в свою очередь, состоит из одной или нескольких команд, относящихся к одному контексту, и ответов на них (Рис. 9.5). Использование такого инструмента позволяет значительно уменьшить объем передаваемой сигнальной информации и увеличить скорость установления соединений за счет того, что контроллер может параллельно вести обработку сигнальной информации, относящейся к разным соединениям.
Аналоги двух избыточных команд EndpointConfiguration и Notifica-tionRequest протокола MGCP в протоколе MEGACO/H.248 отсутствуют, но, в тоже время, добавлена команда Move, позволяющая в одно действие перевести порт из одного контекста в другой. В качестве примера использования команды Move приведем сценарий дополнительных услуг “Уведомление о входящем вызове и перевод существующего соединения в режим удержания”, англоязычное название услуг - Call Waiting и Call Hold.
Рис. 9.5 Транзакция протокола MEGACO/H.248
Абонент А разговаривает с абонентом В, а абонент С вызывает абонента А, при этом вызываемому абоненту передается акустическое уведомление о входящем вызове (рис. 9.6). Далее абонент А переводит соединение с абонентом В в режим удержания и соединяется с абонентом С (рис. 9.7). Реализация комбинации дополнительных услуг Call Waiting и Call Hold, т.е. передача порта из одного контекста в другой, стала возможной благодаря команде Move.
В заключение данного параграфа хотелось бы отметить, что неизвестно, как скоро понадобится расширенная, по сравнению с MGCP, функциональность протокола MEGACO/H.248.
Кроме того, на базе протокола MGCP построен ряд сетей IP-телефонии. Все это означает, что оба протокола MGCP и MEGACO/H.248 вполне могут совместно использоваться в одной сети.
9.4 Структура команд и ответов
Далее идет описание команд, которые используются для манипулирования двумя основными объектами протокола MEGACO/H.248:
портами и контекстами. В большинстве случаев команды передает контроллер, но существу ют два исключения: команда Notify, передается шлюзом, а команда ServiceChange может передаваться и шлюзом, и контроллером. В квадратных скобках указаны необязательные дескрипторы команд. Те дескрипторы, которые расположены над командами, передаются в ответах на команды.
Команда Add добавляет порт к контексту. Если команда относится к первому порту, который должен быть добавлен к контексту, то создается новый контекст.
[TerminationID] ,MediaDescriptor] ,ModeinDescriptor] ,MuxDescriptor] ,EventsDescriptor] ,SignalsDescriptor] ,DigitMapDescriptor] ,ObservedEventsDescriptor] ,StatisticsDescriptor] ,PackagesDescriptor] Add( TerminationID
MediaDescriptor]
ModemDescriptor]
MuxDescriptor]
EventsDescriptor]
SignalsDescriptor]
DigitMapDescriptor]
AuditDescriptor] ),
где TerminationID - это идентификатор порта, который должен быть добавлен к контексту. Для уже существующего порта должен быть указан его идентификатор, для несуществующего порта должен быть указан идентификатор “$”. В ответе на команду должен передаваться TerminationID, назначенный шлюзом.
MediaDescriptor - необязательный дескриптор, описывающий информационные потоки.
ModemDescriptor - необязательный дескриптор, описывающий тип модема, который должен быть подключен к контексту.
MuxDescriptor - необязательный дескриптор, содержащий список портов, которые должны быть подключены к контексту.
EventsDescriptor - необязательный дескриптор, определяющий список событий, при детектировании которых порт должен оповестить контроллер.
SignalsDescriptor - необязательный дескриптор, определяющий сигналы, которые порт должен передавать в канал.
DigitMapDescriptor- необязательный дескриптор, определяющий план нумерации, который должен быть использован для соединения.
AuditDescriptor - необязательный дескриптор, специфицирующий параметры порта, которые должны быть переданы шлюзом контроллеру.
PackagesDescriptor - необязательный дескриптор, описывающий пакет поддерживаемых сигналов и событий.
Команда Modify изменяет свойства, события или сигналы для существующего порта.
[TerminationID] MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] ObservedEventsDescriptor] StatisticsDescriptor] PackagesDescriptor]
Modify( TerminationID
[ MediaDescriptor]
[ ModemDescriptor]
[ MuxDescriptor]
[ EventsDescriptor]
[ SignalsDescriptor]
[ DigitMapDescriptor]
[ AuditDescriptor] )
Если команда относится к конкретному порту шлюза, участвующего в контексте, то должен быть указан идентификатор порта.
В команде Modify используются такие же дескрипторы, как и в команде Add.
Команда Subtract отключает порт от существующего контекста.
[TerminationID]
,MediaDescriptorJ ^^—•/ ,ModemDescriptor] ,MuxDescriptor] ,EventsDescriptor] ,SignalsDescriptor] ,DigitMapDescriptor] ,ObservedEventsDescriptor] ,StatisticsDescriptor] ,PackagesDescriptor]
Subtract(TerminationID
[, AuditDescriptor] )
где TerminationID - идентификатор порта, который должен быть отсоединен от контекста. В случае отключения всех портов от контекста используется TerminationID “*”.
В ответ на команду Subtract в дескрипторе StatisticsDescriptor шлюз посылает статистику, собранную за время соединения.
Команда Move переводит порт из текущего контекста в другой контекст в одно действие.
[TerminationID] [ MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] ObservedEventsDescriptor] StatisticsDescriptor] PackagesDescriptor] Move( TerminationID
MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] AuditDescriptor] )
где TerminationID - идентификатор порта, который должен быть переведен из одного контекста в другой. Дескрипторы здесь используются такие же, как в команде Modify.
При помощи команды AuditValue контроллер запрашивает сведения о свойствах порта, произошедших событиях или сигналах, передаваемых в канал, а также статистику, собранную на текущий момент.
[TerminationID] MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] ObservedEventsDescriptor] StatisticsDescriptor] PackagesDescriptor]
AuditValue(TerminationID,
AuditDescriptor )
В ответ на команду передаются запрашиваемые параметры порта или портов шлюза.
При помощи команды AuditCapabilities контроллер запрашивает возможные значения свойств порта, список событий, которые могут быть обнаружены портом, список сигналов, которые порт может передавать в канал, статические данные.
[TenninationID] MediaDescriptor] ModemDescriptor] MuxDescriptor] EventsDescriptor] SignalsDescriptor] DigitMapDescriptor] ObservedEventsDescriptor] StatisticsDescriptor] PackagesDescriptor]
AuditCapabilities(TenninationID,
.AuditDescriptor )
В ответ на команду передаются запрашиваемые параметры порта.
Команда Notify служит для того, чтобы известить контроллер о событиях, которые произошли в шлюзе.
Notify(TenninationID,
ObservedEventsDescriptor ),
где TerminationID идентифицирует порт, передавший команду Notify.
ObservedEventsDescriptor-дескриптор, содержащий список произошедших событий (в том порядке, в каком они происходили).
Команда ServiceChange позволяет шлюзу известить контроллер о том, что порт или группа портов вышли из обслуживания или вернулись в обслуживание. Media Gateway Controller может предписать порту выйти из обслуживания или вернуться в обслуживание. При помощи данной команды контроллер может передать управление шлюзом другому контроллеру.
[ServiceChangeDescriptor]
ServiceChange(TerminationID
,ServiceDescriptor ),
где TerminationID идентифицирует порт или порты, вышедшие из обслуживания или вернувшиеся в обслуживание.
Значение “Root” дескриптора TerminationID показывает, что весь шлюз вышел из обслуживания или вернулся в обслуживание.
ServiceDescriptor - дескриптор, содержащий поля со сведениями: о методе изменения состояния; причине изменения; задержке;
адресе, куда должны передаваться сообщения; профиле поддерживаемого протокола и другие поля.
По аналогии с предыдущими главами, в таблицу 9.3 сведены все команды протокола MEGACO/H.248.
В заключение данного параграфа в таблице 9.4 приведены коды ошибок, используемые в протоколе MEGACO/H.248.
Таблица 9.3 Команды протокола MEGACO/H.248
| Команда | Направление передачи | Назначение |
| Add (Добавить) | MGC -> MG | Контроллер дает указание шлюзу добавить порт к контексту |
| Modify (Изменить) |
MGC -> MG |
Контроллер дает указание шлюзу изменить свойства порта |
| Subtract (Отключить) | MGC -> MG | Контроллер изымает порт из контекста |
| Move (Перевести) | MGC -> MG | Контроллер переводит порт из одного контекста в другой в одно действие |
| AuditValue (Проверить порт) | MGC -> MG | Контроллер запрашивает свойства порта, произошедшие события или сигналы, передаваемые в канал, а также статистику, собранную на текущий момент времени |
| AuditCapabilities (Проверить возможности порта) | MGC -> MG | Контроллер запрашивает возможные значения свойств порта, список событий, которые могут быть выявлены портом, список сигналов, которые порт может посылать в канал, статические данные |
| Notify (Уведомить) | MG -> MGC | Шлюз информирует контроллер о произошедших событиях |
| ServiceChange (Рестарт) | MG -> MGC, MGC -> MG | Шлюз информирует контроллер о том, что один или несколько портов выходят из рабочего состояния или возвращаются в рабочее состояние. Контроллер может предписать порту или группе портов выйти из обслуживания или вернуться в обслуживание |
| Код ошибок | Описание |
| 400 | Некорректный запрос |
| 401 | Ошибка в протоколе |
| 402 | Авторизация не подтверждена |
| 403 | Синтаксическая ошибка в транзакции |
| 410 | Некорректный идентификатор |
| 411 | В транзакции указан идентификатор несуществующего контекста |
| 412 | Отсутствуют свободные идентификаторы контекста |
| 420 | Нет такого события или сигнала в пакете (package) |
| 421 | Неизвестная акция или некорректная комбинация акций |
| 422 | Синтаксическая ошибка в акции |
| 430 | Неизвестный идентификатор порта |
| 431 | Несуществующий идентификатор порта |
| 432 | Отсутствуют свободные идентификаторы портов |
| 433 | Порт, с указанным идентификатором, уже добавлен к контексту |
| 440 | Не поддерживаемый или неизвестный пакет |
| 441 | Отсутствует дескриптор Remote |
| 442 | Синтаксическая ошибка в команде |
| 443 | Не поддерживаемая или неизвестная команда |
| 444 | Не поддерживаемый или неизвестный дескриптор |
| 445 | Не поддерживаемое или неизвестное свойство |
| 446 | Не поддерживаемый или неизвестный параметр |
| 447 | Дескриптор не совместим с командой |
| 448 | Два одинаковых дескриптора в команде |
| 450 | Отсутствующее в пакете свойство |
| 451 | Отсутствующее в пакете событие |
| 452 | Отсутствующий в пакете сигнал |
| 453 | Отсутствующая в пакете статистическая информация |
| 454 | Отсутствующее значение параметра в пакете |
| 455 | Параметр не совместим с дескриптором |
| 456 | Два одинаковых параметра или свойства в дескрипторе |
| 500 | Внутренняя ошибка в шлюзе |
| 501 | Не поддерживается |
| 502 | Оборудование не готово |
| 503 | Услуга не реализована |
| 510 | Недостаточно ресурсов |
| 512 | Шлюз не оборудован для детектирования требуемого события |
| 513 | Шлюз не оборудован для генерирования требуемого сигнала |
| 514 | Шлюз не может воспроизвести уведомление или подсказку |
| 515 | Не поддерживаемый вид информации |
| 517 | Не поддерживаемый или некорректный режим |
| 518 | Переполнение буфера, в котором хранится информация о произошедших событиях |
| 519 | Не хватает памяти для хранения плана нумерации |
| 520 | Шлюз не имеет информации об используемом плане нумерации |
| 521 | Порт рестартовал |
| 526 | Недостаточная полоса пропускания |
| 529 | Внутренняя неисправность в аппаратном обеспечении |
| 530 | Временная неисправность сети |
| 531 | Постоянная неисправность сети |
| 581 | Не существует |
9.5 Пример установления и разрушения соединения
На рисунке 9. 8 приведен пример установления соединения с использованием протокола MEGACO между двумя шлюзами (Residential Gateway), управляемыми одним контроллером.
В данном примере вызывающий шлюз MG1 - имеет IP-адрес 124.124.124.222, адрес вызываемого шлюза MG2 - 125.125.125.111, адрес контроллера шлюзов MGC - 123.123.123.4. Порт для связи по протоколу MEGACO для всех трех устройств по умолчанию имеет значение 55555.
1. Шлюз MG1 регистрируется у контроллера MGC при помощи команды ServiceChange. Использование нулевого контекста означает, что порт в настоящий момент не участвует ни в каком соединении, а использование идентификатора порта ROOT означает, что команда относится ко всему шлюзу, а не к какому-нибудь определенному порту.
MGl to MGC:
MEGACO/1.0 [124.124.124.222] Transaction = 9998 { Context = - {
ServiceChange = ROOT {Services {
Method=Restart, Port=55555, Pro?ile=ResGW/1.0) }
)
2. Контроллер подтверждает регистрацию шлюза:
MGC to MGl:
MEGACO/1.0 [123.123.123.41:55555 Reply = 9998 {
Context = - {ServiceChange = ROOT { Servicee { Port=55555, Profile=ResGW/1.0} )
)
3. Шлюз имеет свободные аналоговые порты, которые должны быть запрограммированы для отслеживания изменения сопротивления абонентского шлейфа, означающего поднятие абонентом трубки, после чего шлюз должен передать абоненту акустический сигнал “Ответ станции”. Программирование производится при помощи команды Modify с соответствующими параметрами, причем программируется порт, находящийся в нулевом контексте. В команде указывается идентификатор порта (terminationid) -А4444, идентификатор информационного потока (streamid) -1, транспортный адрес оборудования, передавшего команду - [123.123.123.4] :55555, специфицируется режим функционирования -дуплексный (SendReceive).
MGC to MGl:
MEGACO/1.0 [123.123.123.4]:55555 Transaction = 9999 { Context = - {
Modify = A4444 { Media {
TerminationState {
Buf feredEventHandling{Step,Procese}
}, Stream = 1 {
LocalControl {
Mode = SendReceive, g/GainControl=2, ; in dB, g/Encryption=xxx, g/EchoCancellation=Gl65, g/VoiceActDet=yes )
),
Events в 2222 {glinesup/offhook}
Signals {g/PlayTone{tone=dialtone} ) )
На этом же этапе в шлюз может быть загружен план нумерации (в дескрипторе digit map). В этом случае, после того как абонент поднимет трубку, шлюз должен передать ему акустический сигнал “Ответ станции” и начинать прием сигналов DTMF в соответствии с планом нумерации. Однако в нашем примере план нумерации будет загружен только после того, как абонент поднимет трубку, на 8 шаге.
Кроме того, следует отметить, что шаги 3 и 4 данного алгоритма могут быть совмещены с шагами 8 и 9, соответственно, при помощи дескриптора EventsDescriptor. При этом шаги 6 и 7 опускаются.
4. Шлюз MG1 подтверждает выполнение команды Modify:
mgi to mgc:
MEGACO/l.O [124.124.124.222]:55555 Reply = 9999 {
Context = - {Modify} >
5. Подобным же образом (шаги 1-4) программируется аналоговый порт шлюза MG2, в нашем примере имеющий идентификатор А5555.
6. Далее шлюз MG1 обнаруживает, что абонент А поднял трубку, и извещает об этом событии Media Gateway Controller при помощи команды Notify. mgi to mgc:
MEGACO/l.O [124.124.124.222]:55555 Transaction = 10000 { Context = - {
Notify = A4444 {ObservedEvents =2222 {
19990729T22000000:glinesup/offhook} > ) )
7. Контроллер подтверждает получение команды Notify:
mgc to mgi;
MEGACO/l.O [123.123.123.4]$55555 Reply = 10000 {
Context = - (Notify) )
8. На следующем шаге MGC дает шлюзу инструкцию накапливать цифры номера вызываемого абонента в соответствии с выбранным планом нумерации. Кроме того, после получения первой цифры номера необходимо остановить передачу акустического сигнала “Ответ станции”.
14. Контроллер MGC создает в шлюзе MG2 контекст для установления дуплексного соединения (режим SendReceive) с вызывающим пользователем.
MGC to MG2:
MEGACO/1.0 [123.123.123.4]:55555 Transaction = 50003 { Context = $ {
Add = A5555 { Media {
Stream • 1 { )
),
Add = $ { Media {
Stream = 1 {
LocalControl {
Mode = SendReceive, g/NetworkType = RTP/IP4, g/MaxJitterBuffer=40, ; in ms g/PreferredPacketization=30, ; in ms g/PreferredEncoders =[G723, PCMU], g/PreferredDecoders=[G723, PCMU] , g/Gain=0 ; in dB ),
Remote=SDP{ v=0
c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 4 0 a=sendrecv
} ; RTF profile for G.723 is 4 ) )
>
15. Создание контекста подтверждается, физический порт шлюза MG2 A5555 соединяется с UDP/RTP портом, имеющим идентификатор А5556. Отметим, что RTP-порт имеет номер 1111, т.е. отличный от номера порта Megaco/H.248 - 55555.
MG2 to MGC:
MEGACO/1.0 [124.124.124.2221:55555 Reply = 50003 {
Context = 5000 { Add, Add = А5556{ Media {
Stream = 1 {
Local • SDP { v=0
c=IN IP4 125.125.125.1111 m=audio 1111 RTP/AVP 4 0 a=sendreceive }
} ; RTF profile for G723 is 4 )
)
16. Контроллер MGC предписывает порту А5555 шлюза MG2 начать передачу вызывного сигнала.
MGC to MG2:
MEGACO/1.0 [123.123.123.41:55555 Transaction = 50004 { Context = 5000 {
Modify = А5555 {
Signals {glinesup/PlayTone{tone=ring}} }
)
17. Шлюз MG2 подтверждает передачу сигнала “Посылка вызова” вызываемому абоненту.
MG2 to MGC:
MEGACO/1.0 [125.125.125.111]:55555 Reply = 50004 (
Context = 5000 {Modify} }
18. Контроллер предписывает шлюзу MG1 начать передачу вызывающему абоненту акустического сигнала “Контроль посылки вызова (КПВ)”.
MGC to MG1:
MEGACO/1.0 [123.123.123.4]:55555 Transaction = 10005 { Context = 2000 {
Modify = A4444 {
Signals {g/PlayTone{tone=ringback}} }
}
19. Шлюз MG1 подтверждает передачу указанного акустического сигнала в порт A4444.
MG1 to MGC:
MEGACO/1.0 [124.124.124.222]:55555 Reply = 10005 {
Context = 2000 {Modify) )
На этом этапе обоим абонентам, участвующим в соединении, посылаются соответствующие сигналы, и шлюз MG2 ждет, пока вызываемый абонент примет входящий вызов, после чего между двумя шлюзами будут организованы двунаправленные разговорные каналы.
20.
Шлюз MG2 обнаружил, что вызываемый абонент поднял трубку, и извещает об этом контроллер MGC.
MG2 to MGC:
MEGACO/1.0 [125.125.125.111]:55555 Transaction = 50005 { Context = 5000 {
Notify = А5555 {ObservedEvents =1234 {
19990729T22020002:glinesup/offhook)
)
)
21. Контроллер подтверждает получение команды Notify.
MGC to MG2:
MBGACO/1.0 [123.123.123.41:55555 Reply = 50005 {
Context = - (Notify) )
22. Далее контроллер MGC предписывает шлюзу MG2 прекратить передачу вызывного сигнала.
MGC to MG2:
MEGACO/1.0 [123.123.123.4]:55555 Transaction = 50006 { Context = 5000 {
Modify = A5555 {
Events = 1235 {glinesup/onhook}, Signals {g/StopTone} ; to turn off ringing )
)
23. Шлюз MG2 подтверждает выполнение команды.
MG2 to MGC:
MEGACO/1.0 [125.125.125.111]:55555 Reply = 50006 {
Context = 5000 {Modify} )
24. Далее, контроллер разрешает шлюзу MG1 не только принимать, но и передавать информацию (режим SendReceive), и останавливает передачу вызывающему абоненту акустического сигнала “КПВ”.
MGC to MG1:
MEGACO/1.0 [123.123.123.41:55555 Transaction = 10006 { Context = 2000 {
Modify = A4445 { Media {
Stream = 1 {
LocalControl {
Mode=SendReceive }
,, } /}
Modify = A4444 {
Signals { g/StopTone} ) } >
25. Шлюз MG1 подтверждает выполнение команды.
MG1 to MGC:
MEGACO/1.0 [124.124.124.222]:55555 Reply = 10006 {
Context s 2000 {Modify, Modify”
26. После этого начинается разговорная фаза соединения, в течение которой участники обмениваются речевой информацией. Следующим шагом контроллер MGC принимает решение проверить РТР-порт в шлюзе MG2.
HOC to MG2:
MEGACO/1.0 [123.123.123.4]:55555 Transaction = 50007 {
Context = - {AuditValue = A5556{
AuditOtodia, Digit-Map, Events, Signals, Packages, Statietice }}
} }
27. Шлюз MG2 выполняет команду. В ответе на команду AuditValue передается вся запрашиваемая информация, в том числе статистика, собранная за время соединения. Кроме того, из ответа видно, что не произошло никаких событий и не передавалось никаких сигналов.
MEGACO/1.0 [125.125.125.111]:55555 Reply = 50007 { Context = - {
AuditValue ( Media {
TerminationState {
BufferedEventHandling{Process} }, Stream = 1 {
LocalControl {
Mode = SendReceive, g/MaxJitterBuffer=40, ; in ms g/PreferredPacketization=30, ; in me g/PreferredEncoders =[G723, PCMU], g/PreferredDecoders=[G723, PCMU], g/Gain=0 ; in dB ), Local = SDP {
v=0
c=IN IP4 125.125.125.111 m=audio 1111 rtp/avp 4 0 a=sendrecv }, Remote = SDP{
v=0
c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 4 0 a=sendrecv
} ; RTF profile for G.723 is 4 ) ), Packages {g, glinesup/ RTPPkg),
Statistics { RTPPkg/PacketsSent=1200, RTPPkg/OctetsSent=62300, RTPPkg/PacketsReceived=700, RTPPkg/OctetsReceived=45100, RTPPkg/PacketsLost=6, RTPPkg/Jitter=20, RTPPkg/AverageLatency=40 } } } )
28. Вызываемый абонент первым завершает соединение, и шлюз MG2 извещает об этом контроллер MGC.
MG2 to MGC:
MEGACO/1.0 [125.125.125.111]:55555 Transaction = 50008 { Context = 5000 {
Notify = A5555 {ObservedEvents =1235 {
19990729T24020002:glinesup/onhook) )
}
29. Контроллер MGC подтверждает получение сообщения Notify.
MGC to MG2:
MEGACO/1.0 [123.123.123.4]:55555 Reply = 50008 {
Context = - {Notify} }
30. Получив информацию от любого из шлюзов о том, что один из абонентов положил трубку, контроллер MGC завершает соединение. К обоим шлюзам передается команда Subtract. Алгоритм завершения соединения предусматривает одинаковый обмен сигнальными сообщениями между контроллером и обоими шлюзами, поэтому здесь этот алгоритм рассматривается на примере шлюза MG2.
From MGC to MG2:
MEGACO/1.0 [123.123.123.4]:55555 Transaction = 50009 { Context = 5000 {
Subtract = A5555 {Audit{Statistics}}, Subtract = A5556 {Audit{Statistics}} ) }
31. Каждый из портов шлюза MG2, участвующих в соединении (физический порт - A5555 и RTP-порт - A5556), возвращает статистику, собранную за время соединения. В общем случае, контроллер может запрашивать статистическую информацию только у одного из портов.
From MG2 to MGC:
MEGACO/1.0 [125.125.125.H1] :55555 Reply = 50009 { Context = 5000 { Subtract {
Statistics { ; what are the stats for a TIM connection? TEMPkg/OctetsSent=45123, TEMPkg/Duration=40 ; in seconds } }. Subtract {
Statistics (
RTPPkg/PacketsSent=1245, RTPPkg/OctetsSent=62345/ RTPPkg/PacketsReceived=780, RTPPkg/OctetsReceived=45123, RTPPkg/PacketsLost=10, RTPPkg/Jitter=27, RTPPkg/AverageLatency=48 }
)
32. После завершения соединения контроллер MGC предписывает шлюзам MG1 и MG2 быть готовыми к тому, что кто-то из обслуживаемых ими абонентов поднимет трубку. Примечательно, что портам шлюза, отображаемым окончаниями в нулевом контексте, по умолчанию может быть предписано обнаруживать, что абонент поднял трубку, при этом контроллер не передает шлюзам специальные команды, как это было показано ранее (шаг 3).
Различные подходы к построению сетей IP-телефонии
Чтобы стало понятно, чем конкретно отличаются друг от друга перечисленные в предыдущем параграфе протоколы, кратко рассмотрим архитектуру сетей, построенных на базе этих протоколов, и процедуры установления и завершения соединения с их использованием.
В 2000 г. успешно прошел
В 2000 г. успешно прошел сертификацию комплекс оборудования IP-телефонии компании Lucent Technologies типа Packet-Star IP 1000. В состав этого комплекса входят шлюз, привратник и устройство управления сетью (Manager). Шлюз Packet-Star IP Gateway 1000 поддерживает до 3360 одновременных соединений и может, совместно с привратником, обслуживать до нескольких миллионов телефонных соединений и факсимильных сессий в день. Основные особенности оборудования состоят в том, что со стороны опорной АТС принимается множество потоков речевой информации со скоростью 2 048 Кбит/с (Е1), речь кодируется при помощи алгоритмов G.729a и G.723.1, поддерживаются все распространенные системы сигнализации, внутренняя шина системы функционирует на базе технологии ATM со скоростью 5 Гбит/с, вносимая шлюзом задержка при использовании алгоритма кодирования речи G.729a составляет до 80 мс. Помимо поддержки второй версии протокола Н.323, обеспечена совместимость с оборудованием других фирм-производителей по профилю iNOW! В минимальной комплектации стоимость комплекса составляет несколько сотен тысяч долларов. Близкий по функциям комплекс оборудования IP-телефонии, рассчитанный на поддержку до 2000 одновременных разговорных соединений, разработала фирма Nokia. Масштабы и стоимость этой аппаратуры ориентированны на крупных операторов связи.
Lucent Technologies выпускает также платы IP-телефонии для учрежденческих АТС Definity. Они позволяют направлять телефонные вызовы по сети Интернет или Intranet с помощью функции маршрутизации в IP-сетях - DEFINITY World Class Routing. Модуль IP-Trunk представляет собой встроенный шлюз IP-телефонии, принимающий речевой сигнал из ТфОП и преобразующий его в пакетную форму. Одна плата IP-Trunk может обработать 30 речевых каналов, то есть полный цифровой поток Е1. Отдельный системный вход в модуль IP-Trunk позволяет администратору АТС устанавливать соответствие между номерами телефонной сети и IP-адресами, задавать правила маршрутизации и параметры обслуживания.
Аналогичный по функциям модуль IP-card поддерживает подключение 24 IP-телефонов (серия 6600), работающих по протоколу Н.323.
Lucent Technologies вы пускает также программный продукт Definity Soft Phone, который работает совместно с широко распространенным приложением Microsoft NetMeeting и позволяет, подсоединившись к АТС Definity через Интернет как к серверу, стать ее внутренним абонентом. Качество связи при этом будет, разумеется, зависеть от скорости передачи пакетов по сети Интернет. Кроме того, компания Lucent Technologies предлагает отдельное решение в области IР-УАТС под названием IP ExchangeComm, по структуре и компонентам сходное с решением CCN компании Cisco. Отдельно поставляется инструментарий разработчика программ (Software Developer's Kit) для TAPI 2.1 -3.0, позволяющий создавать новые приложения для IP-сети и добавлять новые функции к уже существующим продуктам. Компания Lucent начала выпуск и IP-телефонов - IP Exchange. Аппаратное и программное обеспечение телефонов IP Exchange совместимо с версией 2 стандарта Н.323 и поддерживает алгоритмы компрессии речи G.711, G.723 и G.729.
Интерес представляет решение компании Cisco - использовать сервера доступа и маршрутизаторы, например, Cisco 5300 и 3600, в которые добавлены речевые модули. Маршрутизаторы играют роль шлюзов, упаковывая речевую информацию в IP-пакеты. В этом направлении, кроме Cisco, активно работают фирмы Nortel и Ericsson (аппаратура IРТС). Фирмой OKI Network Technologies разработана аппаратура BS 1200 Internet Voice Gateway, предназначенная для установки непосредственно на АТС (УАТС). Помимо сокращения объема оборудования такое решение упрощает синхронизацию и сигнализацию. Программное обеспечение Cisco CallManager, работающее под операционной системой Windows NT, предназначено для управления соединениями между IP-телефонами Cisco и телефонными аппаратами ТфОП. Внешне IP-телефоны фирмы Cisco выглядят как цифровые телефонные аппараты с жидкокристаллическим экраном и встроенным 2-х портовым Ethernet-концентратором, позволяющим не занимать для телефона отдельную розетку RJ-45.
Поддерживается компрессия речи G.711 или G.723.1, в зависимости от выбора ПО CallManager. IP-адрес может присваиваться телефону статически или динамически, в последнем случае используется протокол DHCP.
Продукт IP-телефонии компании Ericsson состоит из следующих компонентов: шлюза, преобразующего формат речевой информации и сигнализацию, Sitekeeper - системы управления, выполняющей все функции управления, такие как маршрутизация, сбор информации о вызовах и т.д. В систему входит база данных, которая хранит информацию о вызовах, а также биллинговую информацию и, при необходимости, информацию об абонентах сети (пароль, тип услуги, текущее состояние). Сервер управления выполняет функции глобального управления всей сетью IP-телефонии, хранит информацию о топологии и конфигурации этой сети, а также таблицы маршрутизации. Следуя общим принципам технологии IP-телефонии, продукт Ericsson имеет, в то же время, некоторые особенности. Применено дополнительное технологическое решение - Phone Doubler, позволяющее создавать в Интернет вторую виртуальную телефонную линию. Точнее, оператор получает возможность предоставить клиентам новую услугу: работать в Интернет и разговаривать по телефону одновременно, занимая всего лишь одну аналоговую линию. Обычно для этого нужна либо вторая аналоговая линия, либо линия ISDN. В данном случае вызывающий абонент набирает номер вызываемого абонента, и если этот номер занят, то вызов переадресуется телефонной станцией к шлюзу. В свою очередь, шлюз передает запрос установления соединения вызываемому абоненту через IP-сеть. У этого абонента на экране появляется сообщение о входящем вызове. Далее устанавливается телефонное соединение. Кроме того, воспользовавшись продуктом Phone Doubler, пользователь Интернет может, например, произвести телефонный вызов, не прерывая своей Интернет - сессии, используя клиентское ПО. Более подробное описание реализации данной услуги в рамках другой платформы -комплекса Протей-IP - приведено в главе 11.
Nortel Networks анонсировала целую серию новых продуктов IP-телефонии под общим названием Inca.
Семейство Inca предоставляет потребителям портфель открытых решений на базе стандарта Н.323 для объединения сетей IP и телефонных сетей общего пользования. I2004 Internet Telephone - первый из этой серии Интернет-телефонов - совместим со стандартом Н.323 и использует алгоритмы сжатия речи G.711, G.723.1 и G.729A перед ее упаковкой в IP-пакеты. Еще в 1999 года корпорация Nortel Networks создала платы IP-телефонии для своей базовой модели АТС Meridian. Плата, называемая Meridian Integrated IP Telephony Gateway, способна обрабатывать и упаковывать в IP-пакеты 8 речевых каналов. Она устанавливается в периферийный модуль АТС, поддерживающий интерфейс 10Base-T с корпоративной сетью. Поддерживаются стандарты сжатия речи G.711 (64 Кбит/с), G.723 (до 5.3 Кбит/с) и G.729 (8 Кбит/с). Архитектура Integrated IP Telephony Gateway близка к рассмотренному в параграфе 11.8 модулю IPU, поэтому подробное рассмотрение этих решений отложим до главы 11.
IP-АТС RC3000 и IP-телефон LP 5100 IP, выпускаемые фирмой Siemens с начала 1999 года, относятся к сетевому оборудованию HiNet. Система рассчитана максимум на 50 абонентов. HiNet LP 5100 IP поддерживает стандарт Н.323, алгоритмы сжатия речи G.711 (64 Кбит/с) и G.723.1 (6.3 или 5.3 Кбит/с), а также функцию подавления эха.
В таблицу 5.2 сведены основные технические и функциональные характеристики учрежденческих АТС, реализованных на базе технологии маршрутизации речевой информации по сетям с маршрутизацией пакетов IP (IP-PBX) и поддерживающих протокол Н.323.
Подводя итог данной главы, нужно сказать о том, что большинство экспертов считает основной тенденцией мирового телекоммуникационного рынка конца 90-х годов движение бизнес - телефонии от традиционной коммутации каналов к коммутации пакетов. Эта тенденция тесно связана с повсеместным переходом к сетям с интеграцией в одном канале всех видов информации - данных, речи, видео и факсимиле. Новые продукты, о которых мы говорили, - первый отклик крупных телекоммуникационных компаний на интерес потенциальных потребителей к этой части рынка.
Большинство разработок пока предполагается использовать в корпоративных сетях или в небольших офисах, а не в глобальных сетях компаний-операторов связи. Однако в ближайшее время ожидается появление более мощного оборудования IP-телефонии.
Таблица 5.2. Сравнительные характеристики IP-PBX
| Название | WebSwitch 2000 | Phoneware SBX | IP ExchangeComm System |
HiNetRC3000 | CallManager |
| Фирма | Ericsson | Tedas | Lucent Technologies | Siemens | Cisco |
| Емкость | Модель М2 – 32 пользователя; модель М4 – 64 пользователя;для увеличения емкости несколько РВХ объединяются | Одновременно 8/30 внешних соединений и до 240 внутренних соединений | От 2 до 96 пользователей; для увеличения емкости несколько РВХ объединяются | Нет данных | 10000 пользователей на 1 кластер; до 10 кластеров, т.е. для увеличения емкости несколько РВХ объединяются |
| Версия протокола Н.323 | H.323v2 | H.323v1 (версия 2 готовится) | H.323v1 | Нет данных | Нет данных |
| Интерфейсы | Аналоговые абонентские линии и линии к АТС, Е1, 10ВазеТ, WAN- интерфейсы; | 4ВRI или 1 PRI(DSS1) | аналоговые и Т1 | 4 BRI или 1 PRI и 4 10BaseT | интерфесы ISDN |
| Шлюз | интегрированный | интегрированный | интегрированный | необязательный | интегрированный |
| Функциональные возможности оборудования | поддержка IP-телефонов и аналоговых телефонов, совместимость с Netmeeting; эхокомпенсация G.168; видеоречевая почта, поддерживается доступ к речевой почте извне; wireless VolP: Symbol Technologies access point и 802.11-беспроводные телефоны (или DECT. когда не нужно передавать данные); объединение РВХ в сеть через СЛ, общий план нумерации при нескольких РВХ в сети и сокращенная нумерация, Web-телефония |
SDK; РВХ на базе Gatekeeper; MCU для смешивания речевой информации и проигрывания музыки при удержании; речевая почта с аутентификацией, доступом извне, индикация прихода почты или передача аудио файла; поддержка беспроводных терминалов; видеоконференция |
SDK; администрирование из любого места в сети через web-интерфейс, Windows NT; начисление платы; автоответчик; подключение аналоговых устройств через адаптер; поддержка качества обслуживания; (приоритеты трафика); поддержка секретности; SNMP с индикацией аварий и статуса; контроль использования ресурсов; речевая почта: 96 почтовых ящиков с неограниченным числом сообщений макси мальной длительности 5 мин; РВХ соединяются через IP между собой, образуя сеть, и вызов приходит в ТфОП из IP в наилучшей точке |
администрируется локально через RS232 или удаленно через SNMP; разработан терминальный адаптер для подключения аналоговых устройств; интегрированный привратник; речевые кодеки только G.711 и G.723; передача данных Т. 128; совместная работа с приложениями (Application shared - полное и неполное); Windows NT; поддержка DNS; подробные записи о вызовах; эксплуатационное управ ление через интуитивно понятный Web-интерфейс; персональная адресная книга; возможность ограничения пользования услугами |
автоинформатор; поддержка протокола MGCP; передача сигналов DTMF через Н.245; блокирование вызовов; анализ и обработка номера (ввод префиксов, удаление цифр); начисление платы и статистика; передача факсимильной информации (G.711); генерация комфортного шума; РВХ соединяются между собой через WAN |
| CTI | ТАРI | Outlook contacts как телефонная книга; создание и завершение соединения по расписанию, журнал событий в формате MS Access | TAPI 2.1; протокол LDAP для работы с директориями | Unified message: e-mail с приложенными текстовыми, речевыми и аудио файлами |
TAPI 2.1 и JTAPI 1.3 |
| Функции ступени распределения вызова | ACD, IVR с автоответчиком | ACD, IVR с автоответчиком; поддержка не только IP-телефонов: внешние ТфОП телефоны также могут считаться телефонами РВХ; начисление платы; аутентификация; менеджмент через web; сокращенный набор и интеграция с VWWV; группа серийного искания | Нет данных | ACD; обратный вызов после запроса через web; IVR; воспроизведение извещений и подсказок; статистика | Нет данных |
| Дополнительные услуги | конференция до 8 участников; переключение связи и переадресация внутри станции и вне ее; режим удержания; перехват вызова; ответ с другого аппарата (pick up), постановка входящего вызова в очередь при занятости, группы серийного искания, извещение о новом вызове при разговоре, музыка при удержании и при ожидании, основная группа дополнительных услуг доступна с аналоговых и IP- телефонов | режим удержания, ответ с другого аппарата (Pickup), переключение связи, переадресация (любая), конференция между терминалами LAN и ТфОП, CLIP/CLIP, COLP/COLR. MSN/DDI, DTMF -детектирование/ генерация (Н.245) | отказ принять вызов, переключение связи, режим удержания, переключение связи, установка на ожидание, извещение о новом вызове во время разговора, идентификация имени/номера вызывающего абонента, конференция, повторение номера, набранного последним, блокировка всех входящих вызовов; сокращенный набор | режим удержания; переключение связи; переадресация (любая); детектирование и генерация DTMF (RTP и Н.245); повторение номера, набранного последним | автоматический прием/отказ от приема вызова; переключение связи внутри сети и во внешнюю сеть; переадресация (любая); режим удержания с наведением справки; парковка/ответ с другого аппарата; постановка на ожидание; CLIP/CLIP; COLP/COLR; DID; извещение о новом вызове во время связи; конференция; набор номера и заказ переадресации через WEB |
Сравнительный анализ протоколов Н.и SIP
Прежде чем начать сравнение функциональных возможностей протоколов SIP и Н.323, напомним, что протокол SIP значительно моложе своего соперника, и опыт его использования в сетях связи несопоставим с опытом использования протокола Н.323. Существует еще один момент, на который следует обратить внимание. Интенсивное внедрение технологии передачи речевой информации по IP-сетям потребовало постоянного наращивания функциональных возможностей как протокола Н.323 (к настоящему времени утверждена уже третья версия протокола), так и протокола SIP (утверждена вторая версия протокола). Этот процесс приводит к тому, что достоинства одного из протоколов перенимаются другим.
И последнее. Оба протокола являются результатом решения одних и тех же задач специалистами ITU-T и комитета IETF. Естественно, что решение ITU-T оказалось ближе к традиционным телефонным сетям, а решение комитета IETF базируется на принципах, составляющих основу сети Internet.
Перейдем непосредственно к сравнению протоколов, которое будем проводить по нескольким критериям.
Дополнительные услуги. Набор услуг, поддерживаемых обоими протоколами, примерно одинаков.
Дополнительные услуги, предоставляемые протоколом Н.323, стандартизированы в серии рекомендаций ITU-T H.450.X. Протоколом SIP правила предоставления дополнительных услуг не определены, что является его серьезным недостатком, так как вызывает проблемы при организации взаимодействия оборудования разных фирм-производителей. Некоторые специалисты предлагают решения названных проблем, но эти решения пока не стандартизированы.
Примеры услуг, предоставляемых обоими протоколами:
• Перевод соединения в режим удержания (Call hold);
• Переключение связи (Call Transfer);
• Переадресация (Call Forwarding);
• Уведомление о новом вызове во время связи (Call Waiting);
• Конференция.
Рассмотрим последнюю услугу несколько более подробно. Протокол SIP предусматривает три способа организации конференции: с использованием устройства управления конференциями MCU, режима многоадресной рассылки и соединений участников друг с другом.
В последних двух случаях функции управления конференциями могут быть распределены между терминалами, т.е. центральный контроллер конференций не нужен. Это позволяет организовывать конференции с практически неограниченным количеством участников.
Рекомендация Н.323 предусматривает те же три способа, но управление конференцией во всех случаях производится централизованно контроллером конференций МС (Multipoint Controller), который обрабатывает все сигнальные сообщения. Поэтому для организации конференции, во-первых, необходимо наличие контроллера МС у одного из терминалов, во-вторых, участник с активным контроллером МС не может выйти из конференции/Кроме того, при большом числе участников конференции МС может стать “узким местом”. Правда, в третьей версии рекомендации ITU-T Н.323 принято положение о каскадном соединении контроллеров, однако производители эту версию в своем оборудовании пока не реализовали. Преимуществом протокола Н.323 в части организации конференций являются более мощные средства контроля конференций.
Протокол SIP изначально ориентирован на использование в IP-сетях с поддержкой режима многоадресной рассылки информации (примером может служить сеть Mbone, имеющая тысячи постоянных пользователей). Этот механизм используется в протоколе SIP не только для доставки речевой информации (как в протоколе Н.323), но и для переноса сигнальных сообщений. Например, в режиме многоадресной рассылки может передаваться сообщение INVITE, что облегчает определение местоположения пользователя и является очень удобным для центров обслуживания вызовов (Call-center) при организации групповых оповещений.
В то же время, протокол Н.323 предоставляет больше возможностей управления услугами, как в части аутентификации и учета, так и в части контроля использования сетевых ресурсов. Возможности протокола SIP в этой части беднее, и выбор оператором этого протокола может служить признаком того, что для оператора важнее техническая интеграция услуг, чем возможности управления услугами.
Протокол SIP предусматривает возможность организации связи третьей стороной (third-party call control). Эта функция позволяет реализовать такие услуги, как набор номера секретарем для менеджера и сопровождение вызова оператором центра обслуживания вызовов. Подобные услуги предусмотрены и протоколом Н.323, но реализация их несколько сложнее.
В протоколе SIP есть возможность указывать приоритеты в обслуживании вызовов, поскольку во многих странах существуют требования предоставлять преимущества некоторым пользователям. В протоколе Н.323 такой возможности нет. Кроме того, пользователь SIP-сети может регистрировать несколько своих адресов и указывать приоритетность каждого из них.
Персональная мобильность пользователей. Протокол SIP имеет хороший набор средств поддержки персональной мобильности пользователей, в число которых входит переадресация вызова к новому местоположению пользователя, одновременный поиск по не-
скольким направлениям (с обнаружением зацикливания маршрутов) и т.д. В протоколе SIP это организуется путем регистрации на сервере определения местоположения, взаимодействие с которым может поддерживаться любым протоколом. Персональная мобильность поддерживается и протоколом Н.323, но менее гибко. Так, например, одновременный поиск пользователя по нескольким направлениям ограничен тем. что привратник, получив запрос определения местоположения пользователя LRQ, не транслирует его к другим привратникам.
Расширяемость протокола. Необходимой и важной в условиях эволюционирующего рынка является возможность введения новых версий протоколов и обеспечение совместимости различных версий одного протокола. Расширяемость (extensibility) протокола обеспечивается:
- согласованием параметров;
- стандартизацией кодеков;
- модульностью архитектуры.
Протокол SIP достаточно просто обеспечивает совместимость разных версий. Поля, которые не понятны оборудованию, просто игнорируются. Это уменьшает сложность протокола, а также облегчает обработку сообщений и внедрение новых услуг.
Клиент может запросить какую-либо услугу с помощью заголовка Require. Сервер, получивший запрос с таким заголовком, проверяет, поддерживает ли он эту услугу, и если не поддерживает, то сообщает об этом в своем ответе, содержащем список поддерживаемых услуг.
В случае необходимости, в организации IANA (Internet Assigned Numbers Authority) могут быть зарегистрированы новые заголовки. Для регистрации в IANA отправляется запрос с именем заголовка и его назначением. Название заголовка выбирается таким образом, чтобы оно говорило об его назначении. Указанным образом разработчик может внедрять новые услуги.
Для обеспечения совместимости версий протокола SIP определено шесть основных видов запросов и 6 классов ответов на запросы. Так как определяющей в кодах ответов является первая цифра, то оборудование может указывать и интерпретировать только ее. а остальные цифры кода только дополняют смысл и их анализ не является обязательным.
Более поздние версии протокола Н.323 должны поддерживать более ранние версии. Но возможна ситуация, когда производители поддерживают только одну версию, чтобы уменьшить размер сообщений и облегчить их декодирование.
Новые функциональные возможности вводятся в протокол Н.323 с помощью поля NonStandardParameter. Оно содержит код производителя и, следом за ним, код услуги, который действителен только для этого производителя. Это позволяет производителю расширять услуги, но сопряжено с некоторыми ограничениями. Во-первых, невозможно запросить у вызываемой стороны информацию о поддерживаемых ею услугах, во-вторых, невозможно добавить новое значение уже существующего параметра. Существуют также проблемы, связанные с обеспечением взаимодействия оборудования разных производителей.
На расширение возможностей протокола, как и на совместимость оборудования, его реализующего, оказывает влияние и набор кодеков, поддерживаемый протоколом. В протоколе SIP для передачи информации о функциональных возможностях терминала используется протокол SDP. Если производитель поддерживает какой-то особенный алгоритм кодирования, то этот алгоритм просто регистрируется в организации IANA, неоднократно упоминавшейся в этой главе.
В протоколе Н. 323 все кодеки должны быть стандартизированы. Поэтому приложения с нестандартными алгоритмами кодирования могут столкнуться с проблемами при реализации их на базе протокола Н.323.
Протокол SIP состоит из набора законченных компонентов (модулей), которые могут заменяться в зависимости от требований и могут работать независимо друг от друга. Этот набор включает в себя модули поддержки сигнализации для базового соединения, для регистрации и для определения местоположения пользователя, которые не зависят от модулей поддержки качества обслуживания (QoS). работы с директориями, описания сеансов связи, развертывания услуг (service discovery) и управления конфигурацией.
Архитектура протокола Н.323 монолитна и представляет собой интегрированный набор протоколов для одного применения. Протокол состоит из трех основных составляющих, и для создания новой услуги может потребоваться модификация каждой из этих составляющих.
Масштабируемость сети (scalablllty). Сервер SIP, по умолчанию, не хранит сведений о текущих сеансах связи и поэтому может обработать больше вызовов, чем привратник Н.323, который хранит эти сведения (statefull). Вместе с тем, отсутствие таких сведений, по мнению некоторых специалистов, может вызвать трудности при организации взаимодействия сети IP-телефонии с ТФОП.
Необходимо также иметь в виду зоновую архитектуру сети Н.323, позволяющую обеспечить расширяемость сети путем увеличения количества зон.
Время установления соединения. Следующей существенной характеристикой протоколов является время, которое требуется, чтобы установить соединение. В запросе INVITE протокола SIP содержится вся необходимая для установления соединения информация, включая описание функциональных возможностей терминала. Таким образом, в протоколе SIP для установления соединения требуется одна транзакция, а в протоколе Н.323 необходимо производить обмен сообщениями несколько раз. По этим причинам затраты времени на установление соединения в протоколе SIP значительно меньше затрат времени в протоколе Н.323.
Правда, при использовании инкапсуляции сообщений Н.245 в сообщения Н. 225 или процедуры Fast Connect время установления соединения значительно уменьшается.
Кроме того, на время установления соединения влияет также и нижележащий транспортный протокол, переносящий сигнальную информацию. Ранние версии протокола Н.323 предусматривали использование для переноса сигнальных сообщений Н.225 и Н.245 только протокол TCP, и лишь третья версия протокола предусматривает возможность использования протокола UDP. Протоколом SIP использование протоколов TCP и UDP предусматривалось с самого начала.
Оценка времени установления соединения производится в условных единицах - RTT (round trip time) - и составляет для протокола SIP 1,5+2,5 RTT, а для протокола Н .323 6-7 RTT
Адресация. К числу системных характеристик, несомненно, относится и предусматриваемая протоколами адресация. Использование URL является сильной стороной протокола SIP и позволяет легко интегрировать его в существующую систему DNS-серверов и внедрять в оборудование, работающее в IP-сетях. Пользователь получает возможность переправлять вызовы на Web-страницы или использовать электронную почту. Адресом в SIP может также служить телефонный номер с адресом используемого шлюза.
В протоколе Н.323 используются транспортные адреса и alias-адреса. В качестве последнего может использоваться телефонный номер, имя пользователя или адрес электронной почты. Для преобразования alias-адреса в транспортный адрес обязательно участие привратника.
Сложность протокола. Протокол Н.323, несомненно, сложнее протокола SIP. Общий объем спецификаций протокола Н.323 составляет примерно 700 страниц. Объем спецификаций протокола SIP составляет 150 страниц. Протокол Н.323 использует большое количество информационных полей в сообщениях (до 100), при нескольких десятках таких же полей в протоколе SIP. При этом для организации базового соединения в протоколе SIP достаточно использовать всего три типа запросов (INVITE, BYE и АСК) и несколько полей (То, From, Call-ID, CSeq).
Протокол SIP использует текстовый формат сообщений, подобно протоколу HTTP. Это облегчает синтаксический анализ и генерацию кода, позволяет реализовать протокол на базе любого языка программирования, облегчает эксплуатационное управление, дает возможность ручного ввода некоторых полей, облегчает анализ сообщений. Название заголовков SIP-сообщений ясно указывает их назначение.
Протокол Н.323 использует двоичное представление своих сообщений на базе языка ASN.1, поэтому их непосредственное чтение затруднительно. Для кодирования и декодирования сообщений необходимо использовать компилятор ASN. 1. Но, в то же время, обработка сообщений, представленных в двоичном виде, производится быстрее.
Довольно сложным представляется взаимодействие протокола Н.323 с межсетевым экраном (firewall). Кроме того, в протоколе Н.323 существует дублирование функций. Так, например, оба протокола Н.245 и RTCP имеют средства управления конференцией и осуществления обратной связи.
Выводы. На основе проведенного выше сравнения можно сделать вывод о том, что протокол SIP больше подходит для использования Internet-поставщиками, поскольку они рассматривают услуги IP-телефонии лишь как часть набора своих услуг.
Операторы телефонной связи, для которых услуги Internet не являются первостепенными, скорее всего, будут ориентироваться на протокол Н.323, поскольку сеть, построенная на базе рекомендации Н.323, представляется им хорошо знакомой сетью ISDN, наложенной на IP-сеть.
Не стоит также забывать, что к настоящему времени многие фирмы-производители и поставщики услуг уже вложили значительные средства в оборудование Н.323, которое успешно функционирует в сетях.
Таким образом, ответ на вопрос, какой из протоколов предпочтительнее использовать, будет зависеть от целей бизнеса и требуемых функциональных возможностей. Скорее всего, эти варианты не следует рассматривать как конкурирующие, а как предназначенные для разных областей рынка услуг, поскольку они могут работать параллельно и взаимодействовать через специальный шлюз.
Проиллюстрируем это утверждение следующим примером. В настоящее время рынок услуг все больше нацеливается на услуги с доплатой за дополнительные возможности (value added), и простота их предоставления дает реальные преимущества. Так, использование SIP в каком-либо частном домене дает возможность более гибкого предоставления услуг, а наличие средств, обеспечивающих переход от прото-
кола SIP к протоколу Н.323, гарантирует взаимодействие с областями, использующими другие решения. В таблице 7.6 приведен вариант возможного обмена сообщениями.
Таблица 7.6 Алгоритм установления соединения с участием шлюза H.323/SIP
| Шаг | Н.323-сторона шлюза | SIP-сторона шлюза | Комментарии |
| 1 | -> Setup (с процедурой FastStart) | Содержит описание возможностей приема информации | |
| 2 | <- Call proceeding | Подтверждение прокси-сервером приема сообщения SETUP | |
| 3 | INVITE -> | Содержит описание возможностей приема информации в формате SDP | |
| 4 | 180 Ringing <- | Уведомление вызывающего пользователя о том, что вызываемому пользователю передается сигнал о входящем вызове | |
| 5 | <- Alerting | ||
| 6 | 200 0K<- | Вызываемый пользователь принял входящий вызов, сообщение содержит описание возможностей приема информации | |
| 7 | <- Connect | ||
| 8 | ACK-> | ||
| • | |||
| • | Телефонный разговор | ||
| • | |||
| N | BYE<- | Разговор завершен | |
| N+1 | <- Release complete | ||
| N+2 | 200 0K-> |
Таблица 7.7 Открытие новых логических каналов
| Шаг | Н.323-сторона шлюза | SIP-сторона шлюза | Комментарии |
| ->OpenLogicalChannel | |||
| INNATE -> | Тот же идентификатор соединения, что и в предыдущем сообщении INVITE (но номер Cseq -увеличен) Описание нового канала в формате SDP |
||
| 200 OK <- | Содержит описание нового канала в формате SDP | ||
| <- OpenLoglcalChannelAck |
Стандарты мультимедийной связи
Работа над рекомендациями ITU-T серии Н, уже упоминавшимися в первых четырех главах, началась отнюдь не для IP-телефонии. Более 10 лет тому назад Международный союз электросвязи начал разработку рекомендаций для будораживших умы связистов того поколения систем видеотелефонной и мультимедийной связи. Термин “мультимедийная связь” обозначает связь двух или более пользователей, обменивающихся одновременно речью, видеоинформацией и данными.
Первая рекомендация из этой серии, Н.320, была выпущена в 1990 году и относилась к системам видеотелефонии, ориентированным на работу в узкополосной ISDN. Следующие рекомендации ITU-T разрабатывались для систем мультимедийной связи, работающих в разном сетевом окружении.
В рекомендациях серии Н описываются архитектура и функциональные элементы систем, алгоритмы кодирования речи и видеоинформации, организация передачи данных, протоколы сигнализации и управления информационными каналами (таблица 5.1). За истекшее время ITU-T выпустил для таких систем несколько новых версий рекомендаций, в которых учитывались пожелания и замечания ведущих фирм-производителей оборудования, разрабатываемого на базе этих рекомендаций.
Основу рекомендаций Международного союза электросвязи составляет единая базовая архитектура систем мультимедийной связи, функционирующих в разном сетевом окружении. Все рекомендации предусматривают использование для поддержки передачи речи, видеоинформации и данных, а также для управления системой, идентичных функциональных элементов. Различие заключается в упаковке пользовательской и сигнальной информации - выбирается оптимальный способ упаковки информации для той сети, в которой система будет функционировать.
Таблица 5.1. Рекомендации ITU-T по видеотелефонии и мультимедийной связи| Рекомендации ITU-T серии Н | Н.320 | Н.321 | H.322 | Н.323 V1/V2/V3 | H.324 |
| Дата утверждения | 1999 | 1998 | 1996 | 1996/1998/ 1999 | 1998 |
| Сетевое окружение | ТфОП, N-ISDN | ТфОП, B-ISDN, ATM, ЛВС | ЛВС, поддерживающие гарантированное качество обслуживания: IsoEthernet | Сеть с коммутацией пакетов без гарантированного качества обслуживания: Интернет, Token Ring, Ethernet | ТфОП |
| Алгоритмы кодирования видеоинформации | Н.261 Н.263 | Н.261 Н.263 | Н.261 Н.263 | Н.261 Н.263 | Н.261 Н.263 |
| Алгоритмы кодирования речевой информации | G.711 G.722 G.728 | G.711 G.722 G.728 | G.711 G.722 G.728 | G.711 G.722 G.728 G.723 G.729 | G.723 |
| Мультиплексирование | Н.221 | Н.221 | Н.221 | Н.225.0 | Н.223 |
| Управление информационными каналами | Н.230 Н.242 | Н.242 | Н.230 Н.242 | Н.245 | Н.245 |
| Данные | Т. 120 | Т. 120 | Т. 120 | Т. 120 | Т. 120 |
| Интерфейсы и протоколы | 1.400 | AAL 1.363 ATM 1.361 PHYI.400 | 1.400 TCP/IP | TCP/IP | V.34 |
Оборудование мультимедийной связи содержит оконечные устройства, то есть устройства конечных пользователей (терминалы), и сетевые устройства, которые предоставляют пользователям услуги. Среди этих услуг - организация конференций, преобразование протоколов сигнализации и пользовательской информации, согласование скоростей передачи и дополнительные услуги, такие как переадресация вызовов и переключение связи.
Представляется полезным кратко рассмотреть особенности каждой из систем мультимедийной связи, предложенных ITU-T.
Рекомендация Н.320 специфицирует системы видеотелефонной связи по В-каналам узкополосной ISDN со скоростью 64 Кбит/с и со скоростями до 1.920 Мбит/с, кратными 64 Кбит/с. Видеоинформация кодируется по алгоритму, предложенному ITU-T в рекомендации Н.261. Алгоритм поддерживает два формата изображений: необязательный формат CIF с разрешением 352 х 288 пикселей и обязательный формат QCIF с разрешением 176 х 144 пикселей. Частота кадров - 30 кадров/с или ниже. Для кодирования аудиоинформации используются алгоритм G.711 - импульсно-кодовая модуляция со скоростью передачи 64 Кбит/с, алгоритм G.722 - адаптивно-дифференциальная импульсно-кодовая модуляция, использующая полосу частот 7кГц и скорости передачи 48, 56, 64 Кбит/с, и G.728 - алгоритм кодирования LD-CELP со скоростью передачи 16 Кбит/с (об этих алгоритмах уже упоминалось в главе 3). Процедуры установления и разрушения соединений, формирования кадра данных и мультиплексирования, а также ряд эксплуатационных и административных функций описываются в рекомендациях Н.221, Н.230 и Н.242.
Рекомендация Н.321 определяет механизм адаптации узкополосных терминалов видеотелефонной связи Н.320 к работе в широкополосной ISDN. Следует отметить, что широкополосные ISDN базируются на транспортной технологии ATM, которая обеспечивает гарантированное качество обслуживания. В терминалах Н.321 реализована часть требований, предъявляемых к широкополосным терминалам видеотелефонной связи Н.310. При этом обязательным требованием Международного союза электросвязи является совместимость терминалов Н.310, Н.321 и Н.320.
В рекомендации Н.322 представлены технические требования к узкополосным системам видеотелефонии, работающим в локальных вычислительных сетях с гарантированным качеством обслуживания, эквивалентным качеству обслуживания ISDN. Применение данной спецификации ограничено ЛВС IsoEthernet
Рекомендация Н.323 специфицирует системы мультимедийной связи, которые ориентированы на работу в сетях с коммутацией пакетов, не обеспечивающих гарантированное качество обслуживания. К таким сетям относятся локальные вычислительные сети Ethernet и Token Ring, глобальная сеть Интернет и другие сети, поддерживающие технологию маршрутизации пакетов IP или IPX.
Рекомендация Н.323 предусматривает применение различных алгоритмов сжатия речевой информации, что позволяет использовать полосу пропускания гораздо более эффективно, чем в сетях с коммутацией каналов. Оконечные устройства Н.323 поддерживают передачу информации в режиме многоадресной рассылки, что позволяет организовывать конференции без дорогостоящих устройств управления конференциями (MCU), хотя на сегодняшний день без MCU не обойтись, т.к. режим многоадресной расслыки, как правило, IP-сетями не поддерживается. В приложении D к рекомендации Н.323 описан механизм передачи факсимильной информации в реальном времени по IP-сетям.
В рекомендации Н. 324 Международный союз электросвязи представил технические требования к системам низкоскоростной мультимедийной связи, ориентированным на работу по аналоговым линиям ТфОП с использованием модемов. С учетом того, что скорость модемной передачи ограничена, в системах реализуются алгоритмы кодирования речи, видеоинформации и данных с высокой степенью сжатия.
Рекомендация Т. 120 специфицирует механизм передачи данных в системах мультимедийной связи. Основным телематическим приложением, поддерживаемым рекомендацией Т. 120, является обмен текстовыми сообщениями между участниками конференции в реальном времени. Другое приложение - коллективное редактирование растровых изображений. Система Т. 120 является полностью платформо-независимой и может работать в широком диапазоне сетевых технологий с надёжной или ненадёжной передачей данных.
Следует отметить, что механизм передачи данных Т. 120 может функционировать как отдельно, так и совместно с вышеописанными системами мультимедийной связи. При этом поддерживаются режимы передачи данных с адресацией конкретному устройству и с многоадресной рассылкой.
Этот более чем краткий обзор деятельности ITU-T в области стандартизации систем мультимедийной связи, функционирующих в разном сетевом окружении, для целей данной книги представляется достаточным. Но прежде чем приступить к выполнению основной задачи данной главы - анализу системы мультимедийной связи, базирующейся на рекомендации Н.323, - будет полезно также ознакомиться с системами видеотелефонии Н.320, являющимися предшественницами систем мультимедийной связи Н.323.
5.2 Архитектура систем видеотелефонии в узкополосных ISDN
В 1990 году Международный союз электросвязи разработал рекомендацию Н.320, принятую впоследствии всеми ведущими производителями оборудования в качестве стандарта для реализации систем видеоконференций в узкополосных ISDN.
Система видеоконференций Н.320 включает в себя две основные группы компонентов - терминалы и устройства управления конференциями (Multipoint Control Units - MCU). Терминал представляет собой оборудование конечного пользователя, в то время как устройство управления конференциями является сетевым оборудованием, позволяющим организовывать видеоконференции с участием множества пользователей. Разрешается каскадное подключение друг к другу нескольких устройств MCU в рамках одной конференции. На рис. 5.1 показана архитектура системы видеоконференций, функционирующей в узкополосной ISDN.
Терминал Н .320 состоит из следующих функциональных модулей.
Блок видеоаппаратуры включает в себя видеокамеру, монитор и блок обработки видеоинформации, необходимый для реализации такой функции как разделение изображения в мониторе на несколько частей.
Блок аудиоаппаратуры содержит микрофон, громкоговоритель и блок обработки речевой информации, реализующий функции компенсации эха.
Телематические приложения обеспечивают передачу неподвижных изображений, коллективное редактирование растровых изображений, передачу файлов и др. Услуги передачи данных в системах видеотелефонии Н.320 реализуются на базе набора протоколов 1120.
Модуль управления системой отвечает за выполнение таких функций, как организация доступа к сетевым ресурсам при помощи абонентской сигнализации и управление соединением - организация общего режима функционирования на основе сквозной (end-to-end) сигнализации.
Для установления, поддержания и разрушения соединений системы Н.320 используют протокол сигнализации Q.931 [7]. Обмен сигнальными сообщениями между терминалом и опорной АТС производится по D-каналу. Следует отметить также, что сигнальные сообщения не мультиплексируются с пользовательской и управляющей информацией.
Управление соединением производится на основе протоколов Н.242 и Н.243. Протокол Н.242 используется для обмена информацией о функциональных возможностях терминалов, выбора режима передачи речи, видео и данных в соединении между двумя пользователями и для изменения режима. Протокол Н.243 используется для организации конференций, в которых несколько участников соединяются через устройство управления конференциями.
Аудиокодеки кодируют и декодируют речевую информацию. Рекомендация Н.320 определила в качестве основного алгоритма кодирования речевой информации алгоритм G.711, рассмотренный в главе 3, но на практике, чаще всего, при скорости передачи информации 128 Кбит/с в конференциях используется алгоритм кодирования G.728, а при скорости 384 Кбит/с - алгоритм G.722.
Видеокодеки сжимают видеоинформацию и выполняют обратное преобразование. Рекомендация Н.320 определяет видеокодек Н.261 как обязательный; может также использоваться кодек Н.263.
Блок синхронизации обеспечивает задержку речевых сигналов при передаче для синхронизации движения губ говорящего с его речью. Необходимость задержки связана с тем, что обработка видеоинформации занимает значительно больше времени, чем кодирование речи.
Внесение задержки при передаче речевой информации не является обязательным требованием рекомендации Н.320, но большинство производителей оборудования реализуют эту возможность, поскольку покупатели предпочитают видеть изображения, согласованные со звуком. Можно отметить, что в системах мультимедийной связи Н.324, функционирующих в ТфОП, передающая сторона вместо задержки речевых сигналов информирует приемную сторону о средней разности фаз между звуковым и видеосигналом, благодаря чему приемная сторона может внести требуемую задержку при воспроизведении речи и изображения.
Система мультиплексирования, специфицированная в рекомендации Н.221 , обеспечивает возможность совместной передачи сигналов управления, речи, видео и данных. В-каналы разделяются на октеты, каждый бит которых в действительности представляет отдельный подканал. Например, в одном октете могут находиться биты управляющей информации, речи, видеоинформации и данных.
Сетевой интерфейс выполняет функции адаптации терминала, необходимые для его подключения к сети в соответствии с требованиями рекомендации 1.400, рассмотренными в главе 3 [7].
Следующим элементом систем видеотелефонии Н.320 является устройство управления конференциями (MCU).
Рекомендация Н.320 определяет устройство управления конференциями как сетевое устройство, обеспечивающее участие пользователя в соединении одновременно с несколькими другими пользователями. Это устройство выполняет такие функции, как согласование скоростей передачи информации, смешивание речевых сигналов, переключение и смешивание видеосигналов, передача данных от одного пользователя ко многим другим пользователям и управление конференциями. В части управления конференциями MCU реализует функцию согласования функциональных возможностей терминалов для того, чтобы выбрать общий для всех терминалов режим работы.
Таким образом, функции MCU можно разделить на две основные части: управление конференциями и обработка сигналов информационных каналов.
Управление конференциями включает в себя согласование алгоритмов, используемых каждым из участников конференции для кодирования речи, видеоинформации и данных, причем MCU может транскодировать информацию любого вида, если терминалы, участвующие в конференции, используют разные алгоритмы ее кодирования.
В процессе согласования функциональных возможностей терминалов устройство управления конференциями выбирает режим конференции (selected communication mode).
Обработка сигналов информационных каналов является неотъемлемой функцией устройства управления конференциями. От каждого терминала, участвующего в конференции, MCU принимает речь, видеоинформацию и данные. Речевую информацию, получаемую от всех участников конференции, устройство управления конференциями смешивает и направляет суммарный речевой сигнал к каждому из участников. Для предотвращения эха MCU может не включать в суммарный речевой сигнал голос того участника, которому этот сигнал передается.
Видеосигналы обычно коммутируются устройством управления конференциями на основе анализа уровня речевого сигнала. Ко всем терминалам, участвующим в конференции, направляется видеосигнал, связанный с речевым сигналом, имеющим самый высокий уровень. Проще говоря, всем участникам конференции передается изображение участника, который в данный момент времени говорит наиболее громко. Помимо этого, устройство управления конференциями может работать в режиме смешивания видеосигналов для получения видеоизображения, содержащего информацию сразу от нескольких источников.
Кроме обработки речи и видеоинформации MCU может выполнять обработку данных в соответствии с рекомендацией Т. 120.
5.3 Мультимедийная связь в IP-сетях
Рекомендация Международного союза электросвязи Н.323 является первой зонтичной спецификацией систем мультимедийной связи для работы в сетях с коммутацией пакетов, не обеспечивающих гарантированное качество обслуживания. В рекомендациях, входящих в семейство Н.323, определены протоколы, методы и сетевые элементы, необходимые для организации мультимедийной связи между двумя или более пользователями.
Наиболее востребованной из услуг, специфицированных в рекомендации Н.323, в силу разных обстоятельств оказалась услуга передачи речевой информации по сетям с маршрутизацией пакетов IP. Самым распространенным подходом к построению сетей IP-телефонии сегодня является именно подход, предложенный ITU-T в рекомендации Н.323.
Сети, построенные на базе протоколов Н.323, ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ISDN, наложенные на сети передачи данных. В частности, процедура установления соединения в таких сетях IР-телефонии базируется на рекомендации ITU-T Q.931 и практически идентична той же процедуре в сетях ISDN.
Этот вариант построения сетей IP-телефонии ориентирован на операторов местной телефонной связи (или на компании, владеющие транспортными сетями), которые желают использовать сети с маршрутизацией пакетов IP для предоставления услуг междугородной и международной связи. Протокол RAS, входящий в семейство протоколов Н .323, предоставляет операторам высокий уровень контроля использования сетевых ресурсов и обеспечивает поддержку аутентификации пользователей и начисления платы за предоставленные услуги.
На рис. 5.2 изображена архитектура сети, построенной на базе рекомендации Н.323.
Основными устройствами сети являются: терминал, шлюз, привратник и устройство управления конференциями.
5.4 Терминал Н.323
Терминал Н.323 - это оконечное устройство сети IP-телефонии, обеспечивающее двухстороннюю речевую или мультимедийную связь с другим терминалом, шлюзом или устройством управления конференциями. Структурная схема терминала Н.323 приведена на рис. 5.3.
Пользовательский интерфейс управления системой дает пользователю возможность создавать и принимать вызовы, а также конфигурировать систему и контролировать ее работу.
Модуль управления поддерживает три вида сигнализации: Н.225, Н.245 и RAS. Этот модуль обеспечивает регистрацию терминала у привратника, установление и завершение соединения, обмен информацией, необходимой для открытия разговорных каналов, предоставление дополнительных услуг и техобслуживание.
Телематические приложения обеспечивают передачу пользовательских данных, неподвижных изображений и файлов, доступ к базам данных и т.п. Стандартным протоколом для поддержки таких приложений является протокол Т. 120.
Модуль Н.225. 0 отвечает за преобразование видеоинформации, речи, данных и сигнальной информации в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP, и за обратное преобразование. Кроме того, функциями модуля являются разбиение информации на логические кадры, нумерация последовательно передаваемых кадров, выявление и коррекция ошибок.
Сетевой интерфейс обеспечивает гарантированную передачу управляющих сообщений Н.245, сигнальных сообщений Н.225.0 (Q.931) и пользовательских данных при помощи протокола TCP и негарантированную передачу речевой и видеоинформации, а также сообщений RAS, при помощи протокола UDP.
Блок синхронизации вносит задержку на приемной стороне с целью обеспечить синхронизацию источника информации с ее приемником, согласование речевых и видеоканалов или сглаживание вариации задержки информации.
Видеокодеки кодируют видеоинформацию, поступающую от внешнего источника видеосигналов (видеокамеры или видеомагнитофона), для ее передачи по сети с маршрутизацией пакетов IP и декодируют сигналы, поступающие из сети, для последующего отображения видеоинформации на мониторе или телевизоре.
Аудиокодеки кодируют аудиоинформацию, поступающую от микрофона (или других источников аудиоинформации), для ее передачи по сети с маршрутизацией пакетов IP и декодируют сигналы, поступающие из сети, для последующего воспроизведения. Любое терминальное оборудование Н.323 должно иметь аудиокодеки. Обязательным для реализации является кодек, выполняющий преобразование речевой информации в соответствии с рекомендацией G.711. Реализация остальных алгоритмов кодирования, показанных на рис. 5.3, не обязательна. В том случае, когда в терминалах реализовано несколько алгоритмов кодирования речевой информации, желательно, чтобы терминалы могли работать в асимметричном режиме, например, принимать речь, закодированную по алгоритму G.711, и передавать речь, закодированную по алгоритму G.728.
Следует отметить, что при организации децентрализованной конференции терминал Н.323 может принимать более чем один поток речевой информации.
В этом случае терминал должен уметь смешивать или переключать пакетированную речь, поступающую от остальных участников конференции.
5.5 Шлюз Н.323
Основной функцией шлюза является преобразование речевой (мультимедийной) информации, поступающей со стороны ТФОП с постоянной скоростью, в вид, пригодный для передачи по IP-сетям, т.е. кодирование информации, подавление пауз в разговоре, упаковка информации в пакеты RTP/UDP/IP, а также обратное преобразование.
Кроме того, шлюз должен уметь поддерживать обмен сигнальными сообщениями как с коммутационным или терминальным оборудованием ТфОП, так и с привратником или оконечным устройством сети Н.323. Таким образом, шлюз должен преобразовывать аналоговую абонентскую сигнализацию, сигнализацию по 2ВСК, сигнальные сообщения систем сигнализации DSS1 и ОКС7 [6,7] в сигнальные сообщения Н.323. Спецификации преобразования сигнализации Q.931 (DSS1, QSIG) и ОКС7 в сигнализацию Н.225.0, основанную на Q.931, приведены в рекомендации ITU-T H.246. Для поддержки дополнительных услуг в шлюзе может быть обеспечена прозрачная передача сигнальных сообщений Q.932 и Н.450.
Желательно, чтобы шлюз мог генерировать и распознавать сигналы DTMF на стороне ТфОП и передавать сигналы DTMF в сообщениях Н.245 userlnputlndication по сети с маршрутизацией пакетов IP.
При отсутствии в сети привратника должна быть реализована еще одна функция шлюза - преобразование номера ТфОП в транспортный адрес IP-сети.
Со стороны сетей с маршрутизацией пакетов IP, так же, как и со стороны ТфОП, шлюз может участвовать в соединениях в качестве терминала или устройства управления конференциями (рис. 5.4).
Примечательно, что шлюз может изначально участвовать в соединении в качестве терминала, а затем, при помощи сигнализации Н.245, продолжить работу в качестве устройства управления конференциями.
В случае, когда терминал Н.323 связывается с другим терминалом Н.323, расположенным в той же самой IP-сети, шлюз в этом соединении не участвует.
Шлюз, в совокупности с привратником сети IP-телефонии, образует универсальную платформу для предоставления всего спектра услуг мультимедийной связи.На рис. 5.5 представлены некоторые услуги, которые могут быть реализованы в прикладном программном обеспечении на базовой платформе аппаратных и программных средств шлюза IP-телефонии.
Стандарты в сфере Интернет
Из материала предыдущего параграфа видно, что Интернет - самая необычная из всех сетей. Практически любой объект может подключиться к Интернет, чтобы предложить ресурсы, или для доступа к ним. По Интернет может гулять практически любой вид информации без каких-либо ограничений. Отсутствует центральный орган, который регулировал бы работу сети Интернет, хотя существуют организации, устанавливающие определённые фундаментальные принципы и руководящие работой сети. Сеть Интернет по своей философии является автономной и даже анархической; в конечном счёте, в этом и её сила, и её слабость.
Существует ряд организаций, которые участвуют в различных мероприятиях по администрированию и поддержке Интернет. В контексте данной книги среди этих организаций следует упомянуть CERT, IАВ, IETF, IESG, IRTF, ICANN и The Internet Society (Общество Интернет, известное также как ISOC).
Группа реагирования на нарушения компьютерной защиты (CERT) - группа экспертов Университета Карнеги-Меллона, которая отвечает за вопросы, связанные с нарушением компьютерной защиты в сети Интернет. CERT была образована ARPA в ноябре 1998 года как реакция на ряд инцидентов, связанных с появлением вирусных программ самотиражирования.
Совет по архитектуре Интернет (IAB), первоначально - Координационный совет сети Интернет - добровольный орган, имеющий в своем составе 12 экспертов, которые используют ресурсы своих компаний-спонсоров для того, чтобы способствовать интересам Интернет. IAB контролирует и координирует деятельность двух проблемных (рабочих) групп: IETF и IRTF. В совокупности, эти организации вырабатывают техническую политику и направления работы.
Инженерная проблемная группа Интернет (IETF) определяет, устанавливает приоритеты и вырабатывает решения по краткосрочным вопросам и проблемам, включая протоколы, архитектуру и эксплуатацию. Предложенные стандарты публикуются в Интернет в виде Запросов комментариев и предложений (RFC). После выработки окончательной версии стандарта, он поступает на утверждение в группу управления инженеров Интернет (IESG).
Научно-исследовательская проблемная группа Интернет (IRTF) занимается долгосрочными вопросами, включая схемы адресации и технологии.
Корпорация Интернет по присвоению имен и номеров (ICANN) -некоммерческая организация, образованная в 1999 году. ICANN была создана для того, чтобы взять на себя полномочия федерального органа IANA по распределению общеизвестных номеров портов, управлению IP-адресами и присвоению имён доменов. Номера портов представляют собой 16-битовые величины в диапазоне от 0 до 65 536. Общеизвестные порты нумеруются числами из диапазона от О до 1 023 и используются системными процессами или прикладными программами. Примерами общеизвестных портов являются: порт 25 для протокола SMTP (Простого протокола пересылки почты), порт 80 для протокола HTTP (Гипертекстового транспортного протокола) и порт 107 для Дистанционной службы Telnet. В среде клиент/сервер Интернет на базе протокола TCP/IP, сервер назначает порты с учётом протокола прикладного уровня, который выполняется на клиентском уровне. ICANN также присваивает IP-адреса организациям, желающим поместить компьютеры в Интернет; количество адресов зависит от размера организации.
Общество Интернет (ISOC) -добровольная организация, которая представляет собой некоторую формальную структуру для администрирования Интернет. Общество Интернет предоставило официальные полномочия IESG принимать решения по стандартам.
Транспортные технологии пакетной коммутации
Большинство производителей, располагающих широким ассортиментом продукции для пакетной телефонии, занимают “технологически нейтральное” положение и предоставляют покупателю возможность самому выбирать ту технологию, которая лучше всего соответствует его интеграционной стратегии.
Основные технологии пакетной передачи речи - Frame Relay, ATM и маршрутизация пакетов IP - различаются эффективностью использования каналов связи, степенью охвата разных участков сети, надежностью, управляемостью, защитой информации и доступа, а также стоимостью. Ограниченный объем книги не позволяет дать глубокий сравнительный анализ этих технологий с точки зрения передачи речи, поэтому здесь приводятся в наиболее компактной графической форме только результаты такого анализа (рис.1.4).
а) Речь по ATM
б) Речь по Frame Relay
в) Речь по IP
Рис. 1.4 Сравнение технологий пакетной передачи речи: a)VoATM, 6)VoFR, B)VolP
Транспортная технология ATM уже несколько лет успешно используется в магистральных сетях общего пользования и в корпоративных сетях, а сейчас ее начинают активно использовать и для высокоскоростного доступа по каналам xDSL (для небольших офисов) и SDH/ Sonet (для крупных предприятий). Главные преимущества этой технологии - ее зрелость, надежность и наличие развитых средств экс
плуатационного управления сетью. В ней имеются непревзойденные по своей эффективности механизмы управления качеством обслуживания и контроля использования сетевых ресурсов. Однако ограниченная распространенность и высокая стоимость оборудования не позволяют считать ATM лучшим выбором для организации сквозных телефонных соединений от одного конечного узла до другого.
Технологии Frame Relay суждено было сыграть в пакетной телефонии ту же роль, что и квазиэлектронным АТС в телефонии с коммутацией каналов: они показали пример эффективной программно управляемой техники, но имели ограниченные возможности дальнейшего развития. Пользователями недорогих услуг Frame Relay, обеспечивающих вполне предсказуемую производительность, стали многие корпоративные сети, и большинство из них вполне довольны своим выбором.
В краткосрочной перспективе технология передачи речи по Frame Relay будет вполне эффективна для организации мультисервисного доступа и каналов дальней связи. Но сети Frame Relay распространены незначительно: как правило, на практике используются некоммутируемые соединения в режиме точка-точка.
Технология передачи речевой информации по сетям с маршрутизацией пакетов IP привлекает, в первую очередь, своей универсальностью - речь может быть преобразована в поток IP-пакетов в любой точке сетевой инфраструктуры: на магистрали сети оператора, на границе территориально распределенной сети, в корпоративной сети и даже непосредственно в терминале конечного пользователя. В конце концов, она станет наиболее широко распространенной технологией пакетной телефонии, поскольку способна охватить все сегменты рынка, будучи при этом хорошо адаптируемой к новым условиям применения. Несмотря на универсальность протокола IP, внедрение систем IP-телефонии сдерживается тем, что многие операторы считают их недостаточно надежными, плохо управляемыми и не очень эффективными. Но грамотно спроектированная сетевая инфраструктура с эффективными механизмами обеспечения качества обслуживания, рассматриваемыми в главе 10, делает эти недостатки малосущественными. В расчете на порт стоимость систем IP-телефонии находится на уровне (или немного ниже) стоимости систем Frame Relay, и заведомо ниже стоимости оборудования ATM. При этом уже сейчас видно, что цены на продукты IP-телефонии снижаются быстрее, чем на другие изделия, и что происходит значительное обострение конкуренции на этом рынке.
Требования к современным IP-сетям
В главе 3 были рассмотрены принципы кодирования речевой информации, используемые для передачи ее по сетям с маршрутизацией пакетов IP. Закодированные при помощи таких алгоритмов данные генерируются с заданной (не обязательно фиксированной) скоростью независимо от загрузки сети. Требуется, чтобы информация была доставлена получателю с точно той же скоростью, с какой ее генерировал отправитель. Аналогичное требование предъявляется и к доставке видеоинформации.
Синхронная передача данных предполагает периодическую генерацию битов, байтов, или пакетов, которые должны быть воспроизведены приемником с точно таким же периодом. В данном случае скорость передачи информации постоянна. ТфОП функционирует на основе синхронной передачи данных, примером может служить цифровой поток Е1.
Передача такого рода информации (аудио, видео, синхронные потоки) сама по себе не требует очень малой задержки между источником и приемником, хотя это часто является предпочтительным. Однако принципиально необходимо, чтобы задержка была предсказуема, так как только в этом случае временные параметры переданных сообщений могут быть восстановлены в приемнике.
Требования к скорости передачи информации для разных услуг варьируются очень широко. Например, передача данных телеметрии в реальном времени может требовать скорости несколько бит/с, для речевой информации удовлетворительного качества потребуется от 4 до 32 Кбит/с, для обеспечения качества на уровне ТфОП необходимо до 64 Кбит/с, передача видео требует от десятков Кбит/с до десятков Мбит/с (HDTV), в зависимости от характеристик системы (размер изображения, частота кадров, способ кодирования и т.д.). Требования ко времени доставки тоже могут быть различны. Например, при организации речевой связи допускается сквозная задержка от 12 мс при отсутствии эхокомпенсации (G.164), и до 400 мс при ее наличии. При этом, как отмечалось в главе 3, при стремлении величины задержки к верхнему пределу субъективная оценка качества связи падает, взаимодействие становится полудуплексным.
Для не интерактивных приложений (например, предоставление видеоинформации по запросу) могут допускаться задержки более 500 мс, которые ограничиваются только возможностью пользователя нормально управлять процессом воспроизведения и возможностями буферизации данных в приемнике.
Процесс передачи данных по сетям с коммутацией пакетов подвержен влиянию статистически изменяющейся задержки (джиттера), возникающей при обработке очередей в узлах сети. Джиттер компенсируется приемником путем использования буфера воспроизведения. Приемник должен обладать информацией о статистических характеристиках задержки, чтобы предусмотреть необходимое место в буферном накопителе. Например, если допустимы потери 0,1% пакетов, величина буфера должна поддерживаться на уровне, превышающем переменную составляющую задержки поступающих пакетов в 99,9% случаев. Таким образом, высокий уровень джиттера заставляет мириться либо с большим количеством мест в буферном накопителе и, как следствие, с большими задержками, либо с высоким уровнем потерь информации.
Сеть Интернет была создана для передачи данных на основе адаптивной маршрутизации, предполагающей, что данные могут следовать по разным маршрутам, выбираемым в зависимости от некоторых условий. Кроме того, в сети Интернет не предусматривалось установление соединения между источником и приемником информации, т.е. между компьютерами в сети не устанавливается никаких связей, информация о которых сохранялась бы в сети. Это приводит к тому, что пакеты часто приходят к получателю не в той последовательности, в какой они были переданы.
Интернет - сеть с доставкой по мере возможности. Это значит, что сеть пытается доставить информацию, но если это по каким-либо причинам не получается, то информация будет потеряна. Потери пакетов в Интернет, к сожалению, носят “пачечный” характер, то есть внутри некоторых интервалов времени теряется сразу много пакетов подряд или пакетов, следующих с небольшими промежутками. Эта характеристика сети Интернет затрудняет организацию передачи мультимедийной информации, поскольку такие приложения нормально работают только в условиях случайных независимых потерь.
Интернет - сеть, которая сегодня поддерживает только одноадресную доставку. Многоадресная доставка информации, очень полезная для многих приложений (организация конференций, трансляция телепрограмм и т.д.), поддерживается только в экспериментальном режиме на некоторых участках.
Кроме того, сегодня Интернет предоставляет любым приложениям и любым пользователям одинаковый (и притом, как уже говорилось, не гарантированный и не специфицированный) уровень качества обслуживания. Это не позволяет сравнивать качество услуг IP-телефонии с качеством услуг ТфОП, так как в ТфОП существуют и действуют очень жесткие спецификации качества обслуживания вызовов. Для решения названной проблемы необходимо обеспечить возможность резервирования ресурсов сети в процессе установления соединений.
Скажем несколько слов о надежности. Стремление обеспечить в рамках IP-сетей предоставление услуг телефонии, аналогичных услугам ТфОП, сталкивается с проблемой физической надежности сети. Пользователи ТфОП привыкли, что услуги доступны 24 часа в сутки 7 дней в неделю, т.е. всегда. Эта привычка вполне обоснована, так как АТС и другое оборудование, составляющее основу ТфОП, разработано с учетом коэффициента готовности 99.999%, что эквивалентно 3 часам простоя за 40 лет (!) эксплуатации. Так исторически сложилось, что в мире сетей передачи данных действуют совершенно другие стандарты. Большинство людей не смогут ответить, когда последний раз не работал их телефон, однако они без труда припомнят, когда отказала локальная сеть, или не было доступа к Интернет. Создание универсальной сетевой инфраструктуры на базе протокола IP потребует пересмотреть требования к надежности IP-сетей.
Подводя итог, отметим, что Интернет в сегодняшнем состоянии, со всеми отмеченными выше свойствами, вполне удовлетворяет требованиям наиболее популярных приложений (WWW, электронная почта, передача файлов и т.д.), однако, как мы увидим ниже, для поддержки новых услуг, в том числе аналогичных по сути и качеству услугам ТфОП, необходима глубокая поэтапная модернизация сети с внедрением новых протоколов и алгоритмов обслуживания трафика.
4.10 Протоколы RTP и RTCP
Приложения, обеспечивающие передачу речевой и видеоинформации, используют сервис транспортного уровня без установления соединений (например, UDP). При этом каждое приложение может обеспечивать формирование полезной нагрузки пакетов специфическим образом, включая необходимые для функционирования поля и данные. Однако, как показал приведенный в предыдущем параграфе анализ, данные разной природы (речь, видео) имеют общие особенности, которые требуют обеспечения вполне определенной функциональности при их передаче по сети. Это позволяет сформировать некий общий транспортный уровень, объединяющий функции, общие для потоковых данных разной природы, и используемый всеми соответствующими приложениями, придав протоколу этого уровня статус стандарта. Комитетом IETF был разработан протокол транспортировки информации в реальном времени - Realtime Transport Protocol (RTP), который стал базисом практически для всех приложений, связанных с интерактивной передачей речевой и видеоинформации по сети с маршрутизацией пакетов.
Характерные для IP-сетей временные задержки и вариация задержки пакетов (джиттер) могут серьезно исказить информацию, чувствительную к задержке, например, речь и видеоинформацию, сделав ее абсолютно непригодной для восприятия. Отметим, что вариация задержки пакетов гораздо сильнее влияет на субъективную оценку качества передачи, чем абсолютное значение задержки.
Уже длительное время ведется работа по созданию методов уменьшения джиттера и задержек. Для этого могут применяться рассмотренные в главе 10 механизмы, обеспечивающие пользователю заданный уровень качества обслуживания. Они, конечно, улучшают качество услуг, предоставляемых сетью, но не могут совсем устранить образование очередей в сетевых устройствах и совсем убрать джиттер.
Именно протокол RTP позволяет компенсировать негативное влияние джиттера на качество речевой и видеоинформации. В то же время, он не имеет собственных механизмов, гарантирующих своевременную доставку пакетов или другие параметры качества услуг, -это осуществляют нижележащие протоколы.
Он даже не обеспечивает все те функции, которые обычно предоставляют транспортные протоколы, в частности функции исправления ошибок и управления потоком. Обычно протокол RTP базируется на протоколе UDP и использует его функции, но может работать и поверх других транспортных протоколов.
Существует несколько серьезных причин, по которым такой распространенный транспортный протокол, как TCP, плохо подходит для передачи чувствительной к задержкам информации. Во-первых, это алгоритм надежной доставки пакетов. Пока отправитель повторно передаст пропавший пакет, получатель будет ждать, результатом чего может быть недопустимое увеличение задержки. Во-вторых, алгоритм управления при перегрузке в протоколе TCP далеко не оптимален для передачи речи и видеоинформации. При обнаружении потерь пакетов протокол TCP уменьшает размер окна, а затем будет его медленно увеличивать. Однако передача речевой и видеоинформации осуществляется на вполне определенных, фиксированных скоростях, которые нельзя мгновенно уменьшить, не ухудшив качество предоставляемых услуг. Правильной реакцией на перегрузку для информационных потоков этих типов было бы изменение метода кодирования, частоты видеокадров или размера видеоизображения.
Протокол RTP предусматривает индикацию типа полезной нагрузки и порядкового номера пакета в потоке, а также применение временных меток. Отправитель помечает каждый RTP-пакет временной меткой, получатель извлекает ее и вычисляет суммарную задержку. Разница в задержке разных пакетов позволяет определить джиттер и смягчить его влияние - все пакеты будут выдаваться приложению с одинаковой задержкой.
Итак, главная особенность RTP - это вычисление средней задержки некоторого набора принятых пакетов и выдача их пользовательскому приложению с постоянной задержкой, равной этому среднему значению. Однако следует иметь в виду, что временная метка RTP соответствует моменту кодирования первого дискретного сигнала пакета. Поэтому, если RTP-пакет, например, с видеоинформацией, разбивается на блоки данных нижележащего уровня, то временная метка уже не будет соответствовать истинному времени их передачи, поскольку они перед передачей могут быть установлены в очередь.
На рис. 4.7 представлен основной заголовок RTP-пакета, содержащий ряд полей, которые идентифицируют такие элементы, как формат пакета, порядковый номер, источник информации, границы и тип полезной нагрузки.
V (2 бита) - поле версии протокола. Текущая версия протокола -вторая.
Р (1 бит) - поле заполнения. Сигнализирует о наличии заполнения в конце поля полезной нагрузки. Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам.
Х (1 бит) - поле расширения заголовка. Служит для индикации того, что за основным заголовком следует дополнительный заголовок, используемый в экспериментальных расширениях протокола RTP.
СС (4 бита) - поле отправителей. Содержит идентификаторы отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком.
М (1 бит) - поле маркера. Обычно используется для указания границ потока данных. Смысл бита маркера зависит от типа полезной нагрузки. В случае передачи видеоинформации он определяет конец кадра. При передаче речевой информации маркер указывает начало периода активности после периода молчания.
РТ (7 битов) - поле типа полезной нагрузки. Идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления транспортировкой информации в реальном времени (Real-Time Transport Control Protocol).
Порядковый номер пакета (Sequence Number, 16 битов). Каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым переданным пакетом RTP.
Это позволяет обнаруживать потери пакетов и определять порядок пакетов с одинаковым временным штампом. Несколько последовательных пакетов могут иметь один и тот же штамп, если логически они порождены в один и тот же момент, как, например, пакеты, принадлежащие одному и тому же видеокадру.
Временной штамп (Timestamp, 32 бита). Момент времени, в который был создан первый октет данных полезной нагрузки. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя.
Идентификатор SSRC (Synchronization Source Identifier, 32 бита) -поле идентификатора источника синхронизации. Псевдослучайное число, которое уникальным образом идентифицирует источник в течение сеанса и не зависит от сетевого адреса. Это число играет важную роль при обработке порции данных, поступившей от одного источника.
Идентификатор CSRC (Contributing Source Identifier, 32 бита) - список полей идентификаторов источников, участвующих в создании RTP-пакета. Устройство смешивания информации (миксер) вставляет целый список SSRC идентификаторов источников, которые участвовали в построении данного RTP-пакета. Количество элементов в списке: от 0 до 15. Если число участников более 15, выбираются первые 15. Примером может служить речевая конференция, в которой передаются RTP-пакеты с речью всех участников - каждый со своим идентификатором SSRC. Они-то и образуют список идентификаторов CSRC. Вся конференция имеет общий идентификатор SSRC.
Доставка RTP-пакетов контролируется специальным протоколом RTCP (Real Time Control Protocol).
Основной функцией протокола RTCP является организация обратной связи приемника с отправителем информации для отчета о качестве получаемых данных. Протокол RTCP передает сведения (как от приемника, так и от отправителя) о числе переданных и потерянных пакетов, значении джиттера, задержке и т.д. Эта информация может быть использована отправителем для изменения параметров передачи, например для уменьшения коэффициента сжатия информации с целью улучшения качества ее передачи. Более подробное описание протоколов RTP и RTCP можно найти в RFC-1889.
4.11 Многоадресная рассылка
Основной целью группового вещания является создание эффективного механизма передачи данных по схеме “один-ко-многим” и “многие-ко-многим”.
Традиционные механизмы доставки пакетов стека TCP/IP мало пригодны для поддержки группового вещания. Например, использование уникальных адресов (unicast) приводит к необходимости установления многочисленных двухточечных соединений между отправителем и каждым из получателей.
Другим способом передачи данных является широковещательная передача, когда станция направляет пакеты, используя широковещательные адреса (broadcast). Пакеты с такими адресами передаются ко всем конечным узлам указанной сети, независимо оттого, нужны ли они каждому из них. Во многих ситуациях такой способ передачи также оказывается неэффективным вследствие своей избыточности, которая ведет к чрезмерному росту трафика, особенно в крупных сетях.
В случае использования групповых адресов отправитель передает сообщение только один раз, затем оно тиражируется и доставляется только к тем узлам, которые являются членами соответствующей группы. Такой режим экономит пропускную способность за счет передачи только того трафика, который необходим. Номера группы задаются с использованием IP-адреса типа multicast.
Основными протоколами, на базе которых реализуется многоадресная рассылка в IP-сетях, являются протоколы IGMP (Internet Group Management Protocol), DVMRP - (Distance Vector Multicast Routing Protocol), PIM (Protocol Independent Multicast).
Три основных сценария IP-телефонии
Материал предыдущей главы дал в первом приближении ответ на вопрос: что такое IP-телефония? Прежде чем обсудить более подробно различные подходы к архитектуре, протоколам и вариантам построения систем и оборудования, полезно обратить внимание на другой вопрос: для чего нужна IP-телефония? В качестве ответа на этот вопрос рассмотрим три наиболее часто используемых сценария IP-телефонии:
• “компьютер-компьютер”;
• “компьютер-телефон”;
• “телефон-телефон”.
Сценарий “компьютер-компьютер” реализуется на базе стандартных компьютеров, оснащенных средствами мультимедиа и подключенных к сети Интернет.
Компоненты модели IP-телефонии по сценарию “компьютер-компьютер” показаны на рис. 2.1. В этом сценарии аналоговые речевые сигналы от микрофона абонента А преобразуются в цифровую форму с помощью аналого-цифрового преобразователя (АЦП), обычно при 8000 отсчетов/с, 8 битов/отсчет, в итоге - 64 Кбит/с. Отсчеты речевых данных в цифровой форме затем сжимаются кодирующим устройством для сокращения нужной для их передачи полосы в отношении 4:1, 8:1 или 10:1. Алгоритмы сжатия речи подробно рассматриваются в следующей главе. Выходные данные после сжатия формируются в пакеты, к которым добавляются заголовки протоколов, после чего пакеты передаются через IP-сеть в систему IP-телефонии, обслуживающую абонента Б. Когда пакеты принимаются системой абонента Б, заголовки протокола удаляются, а сжатые речевые данные поступают в устройство, развертывающее их в первоначальную форму, после чего речевые данные снова преобразуются в аналоговую форму с помощью цифро-аналогового преобразователя (ЦАП) и попадают в телефон абонента Б. Для обычного соединения между двумя абонентами системы IP-телефонии на каждом конце одновременно реализуют как функции передачи, так и функции приема. Под IP-сетью, изображенной на рис. 2.1, подразумевается либо глобальная сеть Интернет, либо корпоративная сеть предприятия Intranet. Описанию протоколов, используемых в IP-сетях, в том числе протоколов передачи речевой информации по IP-сети, посвящена глава 4.
Для поддержки сценария “компьютер - компьютер” поставщику услуг Интернет желательно иметь отдельный сервер (привратник), преобразующий имена пользователей в динамические адреса IP. Сам сценарий ориентирован на пользователя, которому сеть нужна, в основном, для передачи данных, а программное обеспечение IP-телефонии требуется лишь иногда для разговоров с коллегами. Эффективное использование телефонной связи по сценарию “компьютер-компьютер” обычно связано с повышением продуктивности работы крупных компаний, например, при организации виртуальной презентации в корпоративной сети с возможностью не только видеть документы на Web-сервере, но и обсуждать их содержание с помощью IP-телефона. При этом между двумя IP-сетями могут использоваться элементы ТфОП, а идентификация вызываемой стороны может осуществляться как на основе Е.164, так и на основе IP-адресации. Наиболее распространенным программным обеспечением для этих целей является пакет Microsoft NetMeeting, доступный для бесплатной загрузки с узла Microsoft.
Рассмотрим представленный на рис. 2.1 сценарий установления соединения “компьютер-компьютер” более подробно.
Для проведения телефонных разговоров друг с другом абоненты А и Б должны иметь доступ к Интернет или к другой сети с протоколом IP. Предположим, что такая IP-сеть существует, и оба абонента подключены к ней. Рассмотрим возможный алгоритм организации связи между этими абонентами.
1. Абонент А запускает свое приложение IP-телефонии, поддерживающее протокол Н.323.
2. Абонент Б уже заранее запустил свое приложение IP-телефонии, поддерживающее протокол Н.323.
3. Абонент А знает доменное имя абонента В элемент системы имен доменов - Domain Name System (DNS), вводит это имя в раздел “кому позвонить” в своем приложении IP-телефонии и нажимает кнопку Return.
4. Приложение IP-телефонии обращается к DNS-серверу (который в данном примере реализован непосредственно в персональном компьютере абонента А) для того, чтобы преобразовать доменное имя абонента Б в IP-адрес.
5. Сервер DNS возвращает IP-адрес абонента Б.
6. Приложение IP-телефонии абонента А получает IP-адрес абонента Б и отправляет ему сигнальное сообщение Н.225 Setup.
7. При получении сообщения Н.225 Setup приложение абонента Б сигнализирует ему о входящем вызове.
8. Абонент Б принимает вызов и приложение IP-телефонии отправляет ответное сообщение Н.225 Connect.
9. Приложение IP-телефонии у абонента А начинает взаимодействие с приложением у абонента Б в соответствии с рекомендацией Н.245.
10. После окончания взаимодействия по протоколу Н.245 и открытия логических каналов абоненты А и Б могут разговаривать друг с другом через IP-сеть.
Несмотря на нарочитую простоту изложения, рассмотренный пример довольно сложен, что обусловлено сложностью технологии IP-телефонии. В этом примере не показаны все шаги и опущены весьма существенные детали, которые необходимы поставщику услуг для развертывания сети IP-телефонии. Обо всех этих более сложных моментах будет сказано в главах 5-11 данной книги, а здесь сделаем еще одно упрощение.
Сам характер сценария “компьютер-компьютер” на рис. 2.1 обуславливает сосредоточение всех необходимых функций IP-телефонии в персональном компьютере или другом аналогичном устройстве конечного пользователя. При описании других сценариев в этой главе вместо громоздкого изображения компонентов оконечного устройства будет приводится только упрощенное изображение терминала IP-телефонии. Таким аналогом рис. 2.1 является упрощенное представление того же сценария на рис. 2.2. К детальному рассмотрению процедур аналогово-цифрового и цифро-аналогового преобразования, сжатия, пакетизации и др. мы вернемся в следующей главе.
Замена изображений имеет и более глубокий смысл. Название сценария “компьютер - компьютер” отнюдь не означает, что в распоряжении пользователя обязательно должен быть стандартный PC с микрофоном и колонками, как это представлено на рис. 2.1.
Главным требованием для такой схемы является то, что оба пользователя должны иметь подключенные к сети персональные компьютеры. И эти PC должны быть всегда включены, подсоединены к сети и иметь в запущенном виде программное обеспечение IP-телефонии для приема входящих вызовов. При всем этом должна быть полная совместимость между программно-аппаратными средствами IP-телефонии, полученными от разных поставщиков, т.е. пользователи, желающие разговаривать друг с другом, должны иметь идентичное программное обеспечение, например, реализующее протокол Н.323.
Принимая во внимание эти обстоятельства, под названием “компьютер” во всех сценариях мы будем понимать терминал пользователя, включенный в IP-сеть, а под названием “телефон” - терминал пользователя, включенный в сеть коммутации каналов любого типа: ТфОП, ISDN или GSM.
И еще одно, более существенное замечание. До сих пор в обсуждении сценария “компьютер - компьютер” на рис. 2.1 и 2.2 полагалось, что оба пользователя включены в одну и ту же IP-сеть (Интернет, Интранет или другую сеть с протоколом IP). В рамках проекта TIPHON, которому посвящен следующий параграф этой главы, рассматривается другая, более сложная модификация сценария “компьютер - компьютер”. Эта модификация, представленная на рис. 2.3, предусматривает организацию связи между абонентами IP-сети с учетом того, что вызов транзитом проходит через сеть коммутации каналов (СКК). Заметим, что на этом и на следующих рисунках в качестве СКК выступает телефонная сеть общего пользования (ТфОП), хотя излагаемые в данной главе материалы справедливы для ISDN, GSM и др.
Следующий сценарий - “телефон-компьютер” - находит применение в разного рода справочно-информационных службах Интернет, в службах сбыта товаров или в службах технической поддержки. Пользователь, подключившийся к cepвepy WWW какой-либо компании, имеет возможность обратиться к оператору справочной службы.
Этот сценарий в ближайшие несколько лет будет, по всей вероятности, более активно востребован деловым сектором. Компании будут использовать данную технологию для наращивания своих WеЬ - страниц (и своего присутствия во всемирной паутине). Пользователи компьютеров смогут просматривать в “реальном времени” каталоги, почти мгновенно заказывать товары и получать множество других услуг. Это вполне соответствует стилю жизни современных потребителей, связанному с потребностью в дополнительных удобствах и экономии времени. Уже сегодня осознаются все выгоды и удобства централизованного приобретения предметов широкого потребления (например, компакт-дисков, книг, программного обеспечения и т. д.) и уже привычно совершаются операции электронной коммерции.
В рамках проекта TIPHON рассматриваются две модификации этого сценария IP-телефонии:
• от компьютера (пользователя IP-сети) к телефону (абоненту ТфОП), в частности, в связи с предоставлением пользователям IP-сетей доступа к телефонным услугам, в том числе, к справочно-информационным услугам и к услугам Интеллектуальной сети;
• от абонента ТфОП к пользователю IP-сети с идентификацией вызываемой стороны на основе нумерации по Е.164 или IP-адресации.
Проект TIPHON заслуживает более пристального внимания, и уже было обещано посвятить ему целиком следующий параграф этой главы.
В первой из упомянутых модификаций сценария “компьютер -телефон” соединение устанавливается между пользователем IP-сети и пользователем сети коммутации каналов (рис. 2.4). Предполагается, что установление соединения инициирует пользователь IP-сети.
Шлюз (GW) для взаимодействия сетей ТфОП и IP может быть реализован в отдельном устройстве или интегрирован в существующее оборудование ТфОП или IP-сети. Показанная на рисунке сеть СКК может быть корпоративной сетью или сетью общего пользования.
В соответствии со второй модификацией сценария “компьютер -телефон” соединение устанавливается между пользователем IP-сети и абонентом ТфОП, но инициирует его создание абонент ТфОП (рис. 2.5).
Рассмотрим несколько подробнее пример представленной на рис. 2.5 упрощенной архитектуры системы IP-телефонии по сценарию “телефон-компьютер”. При попытке вызвать справочно-информационную службу, используя услуги пакетной телефонии и обычный телефон, на начальной фазе абонент А вызывает близлежащий шлюз IP-телефонии. От шлюза к абоненту А поступает запрос ввести номер, к которому должен быть направлен вызов (например, номер службы), и личный идентификационный номер (PIN) для аутентификации и последующего начисления платы, если это служба, вызов которой оплачивается вызывающим абонентом. Основываясь на вызываемом номере, шлюз определяет наиболее доступный путь к данной службе. Кроме того, шлюз активизирует свои функции кодирования и пакетизации речи, устанавливает контакт со службой, ведет мониторинг процесса обслуживания вызова и принимает информацию о состояниях этого процесса (например, занятость, посылка вызова, разъединение и т.п.) от исходящей стороны через протокол управления и сигнализации. Разъединение с любой стороны передается противоположной стороне по протоколу сигнализации и вызывает завершение установленных соединений и освобождение ресурсов шлюза для обслуживания следующего вызова.
Для организации соединений от службы к абонентам (рис. 2.4) используется аналогичная процедура. Популярными программными продуктами для этого варианта сценария IP-телефонии “компьютер-телефон” являются IDT Net2Phone и DotDialer, организующие вызовы к обычным абонентским телефонным аппаратам в любой точке мира.
Эффективность объединения услуг передачи речи и данных является основным стимулом использования IP-телефонии по сценариям “компьютер-компьютер” и “компьютер-телефон”, не нанося при этом никакого ущерба интересам операторов традиционных телефонных сетей.
Сценарий “телефон-телефон” в значительной степени отличается от остальных сценариев IP-телефонии своей социальной значимостью, поскольку целью его применения является предоставление обычным абонентам ТфОП альтернативной возможности междугородной и международной телефонной связи.
В этом режиме современная технология IP-телефонии предоставляет виртуальную телефонную линию через IP-доступ.
Как правило, обслуживание вызовов по такому сценарию IP-телефонии выглядит следующим образом. Поставщик услуг IP-телефонии подключает свой шлюз к коммутационному узлу или станции ТфОП, а по сети Интернет или по выделенному каналу соединяется с аналогичным шлюзом, находящимся в другом городе или другой стране.
Типичная услуга IP-телефонии по сценарию “телефон-телефон” использует стандартный телефон в качестве интерфейса пользователя, а вместо междугородного компонента ТфОП использует либо частную IP-сеть/lntranet, либо сеть Интернет. Благодаря маршрутизации телефонного трафика по IP-сети стало возможным обходить сети общего пользования и, соответственно, не платить за междугородную/международную связь операторам этих сетей.
Следует отметить, что сама идея использовать альтернативные транспортные механизмы для обхода сети ТфОП не является новой. Достаточно вспомнить статистические мультиплексоры, передачу речи по сети Frame Relay или оборудование передачи речи по сети ATM.
Как показано на рис. 2.6, поставщики услуг IP-телефонии предоставляют услуги “телефон-телефон” путём установки шлюзов IP-телефонии на входе и выходе IP-сетей. Абоненты подключаются к шлюзу поставщика через ТфОП, набирая специальный номер доступа. Абонент получает доступ к шлюзу, используя персональный идентификационный номер (PIN) или услугу идентификации номера вызывающего абонента (Calling Line Identification). После этого шлюз просит ввести телефонный номер вызываемого абонента, анализирует этот номер и определяет, какой шлюз имеет лучший доступ к нужному телефону. Как только между входным и выходным шлюзами устанавливается контакт, дальнейшее установление соединения к вызываемому абоненту выполняется выходным шлюзом через его местную телефонную сеть.
Полная стоимость такой связи будет складываться для пользователя из расценок ТфОП на связь с входным шлюзом, расценок Интернет-провайдера на транспортировку и расценок удалённой ТфОП на связь выходного шлюза с вызванным абонентом.
Одним из алгоритмов организации связи по сценарию “телефон-телефон” является выпуск поставщиком услуги своих телефонных карт. Имея такую карту, пользователь, желающий позвонить в другой город, набирает номер данного поставщика услуги, затем в режиме донабора вводит свой идентификационный номер и PIN-код, указанный на карте. После процедуры аутентификации он набирает телефонный номер адресата.
Возможны и другие алгоритмы реализации этого сценария: вместо телефонной карты может использоваться информация об альтернативном счете. Счет для оплаты может быть выслан абоненту и после разговора, аналогично тому, как это делается при междугородном соединении в ТфОП.
Рассмотренные выше сценарии сведены в таблице 2.1.
Таблица 2.1 Варианты межсетевого взаимодействия
| Сценарий | Входящая сеть | Транзитная сеть | Исходящая сеть | Примечание |
| “компьютер -компьютер” | IP | IP | IP | Рис. 2.1 и 2.2 |
| IP | ТфОП | IP | Рис. 2.3 | |
| “компьютер -телефон” | IP | ТфОП | ТфОП | Рис. 2.5 |
| ТфОП | IP | IP | Рис. 2.4 | |
| ТфОП | ТфОП | IP | Рис. 2.4 | |
| IP | IP | ТфОП | Рис. 2.5 | |
| “телефон -телефон” | ТфОП | IP | ТфОП | Рис. 2.6 |
| ТфОП | ТфОП | ТфОП | Не рассм. |
Из представленных в таблице девяти вариантов трех сценариев последний вариант остается за рамками данной книги по вполне очевидной причине - его принадлежности к классической (а не к I?-) телефонии, описанной в многих десятках других книг.
Следующий параграф посвящен анализу проекта TIPHON Европейского института стандартизации в области телекоммуникаций - Europe Telecommunications Standardization Institute (ETSI). Именно этот институт вплотную занимается сетевыми вопросами IP-телефонии, в то время как другие стандартизирующие телекоммуникационные организации основное внимание уделяют вопросам разработки протоколов сигнализации или механизмов переноса речевой информации по сетям с маршрутизацией пакетов IP. Так, например, область деятельности основоположников IP-телефонии ITU-T и IETF ограничивается только сетями с маршрутизацией пакетов IP.
Вопросы взаимодействия телефонных и IP сетей рассматривались ITU-T, в основном, в части преобразования систем сигнализации [Н.246] и практически не затрагивались комитетом IETF. Более подробно деятельность ITU-T в области IP-телефонии освещена в главах 5 и 6, посвященных архитектуре и протоколам Н.323, а результаты деятельности комитета IETF в этой же области рассмотрены в главах 7, 8 и 9.
В проекте TIPHON предполагается разработка новых стандартов и профилей существующих стандартов для каждого из приведенных в таблице 2.1 сценариев. Новые стандарты будут разрабатываться только для тех областей связи, для которых действующие стандарты отсутствуют. Там, где существуют действующие стандарты ETSI, ITU или других стандартизирующих организаций, будет проводиться разработка и преобразование профилей этих стандартов.
2.2 Проект TIPHON
Работа над проектом TIPHON (Telecommunication and Internet Protocol Harmonization over Networks) была начата институтом ETSI в апреле 1997 г. Основная задача проекта - решение проблем взаимодействия между сетями с маршрутизацией пакетов IP и сетями с коммутацией каналов в части поддержки прозрачной передачи речевой и факсимильной информации. Под сетями с коммутацией каналов подразумеваются ТфОП, ISDN и GSM.
В проекте принимают участие свыше 40 крупнейших телекоммуникационных компаний. Имеется восемь рабочих групп, последняя из которых - по защите информации - была организована во время 15-го совещания рабочих групп 4-8 октября 1999 г. в Лейпциге. Результатом деятельности рабочих групп TIPHON являются технические спецификации и отчеты.
Сама идея проекта TIPHON родилась под влиянием динамично развивающегося рынка телекоммуникационных услуг, предоставляемых как операторами сетей связи, базирующихся на технологии коммутации каналов, так и операторами сетей, построенных на основе технологии маршрутизации пакетов IP. Задачей проекта является претворение в жизнь идеологии конвергенции и создание единой сетевой инфраструктуры, привлекательной для операторов различных видов связи.
Была отмечена растущая потребность в организации связи в реальном времени, в том числе, телефонной связи, в сетях, реализующих технологию маршрутизации пакетов IP. Для удовлетворения этой потребности институт ETSI предлагает в проекте TIPHON концепцию “сети сетей”, такой, что сети, входящие в ее состав, могут базироваться на технологиях коммутации каналов и маршрутизации пакетов IP (рис. 2.7).
В рамках проекта TIPHON сети, использующие различные технологии коммутации, имеют статус доменов “глобальной сети”. В основу взаимодействия этих доменов положено обеспечение гарантированного качества обслуживания (QoS) и защиты межсетевых соединений. Кроме того, обеспечивается возможность управлять соединениями, используя стандартные протоколы сигнализации. Таким образом, сеть TIPHON можно определить как сеть высшего уровня, поддерживающую предоставление услуг телефонной связи и базирующуюся на совокупности сетей более низкого уровня.
В основу проекта TIPHON положены следующие правила:
• терминалами TIPHON могут быть персональные компьютеры и обычные телефоны;
• интерфейс “человек-машина” (ММI) строится по аналогии с телефонным интерфейсом;
• пользователи могут менять точки доступа к услугам глобальной сети; при этом должен сохраняться набор предоставляемых услуг и качество обслуживания (QoS).
Главной целью проекта TIPHON является разработка механизмов взаимодействия и связанных с ними параметров для обеспечения мультимедийной связи с гарантированным качеством обслуживания между пользователями сетей с коммутацией каналов и сетей с маршрутизацией пакетов. При этом акцент делается на взаимодействие сетей, а не на отдельные сети, для чего и создаются соответствующие спецификации и стандарты, ориентированные на промышленные предприятия, операторские компании, администрации связи, органы сертификации и стандартизации и др.
Проект TIPHON предусматривает решение ряда технических задач, связанных с обеспечением приемлемого качества услуг телефонной связи.
В число этих задач входит разработка эталонных конфигураций и функциональных моделей, требований к взаимодействию различных функциональных объектов, процедур управления соединением и протоколов; преобразование адресов в формате Е.164 в IP-адреса; рассмотрение технических аспектов защиты; изучение вопросов мобильности и обеспечения качества обслуживания. Ранее указывалось, что в работе над проектом TIPHON участвуют несколько групп, каждая из которых отвечает за решение определенной задачи. Ниже представлены основные направления деятельности рабочих групп TIPHON.
Разработка требований к единой межсетевой политике, определяющих выявление неисправностей, выбор уровня качества обслуживания, поддержку необходимой сигнализации и передачи акустических сигналов, трассировку соединения, идентификацию вызывающего абонента.
Разработка эталонных конфигураций и функциональных моделей, включая функциональную модель шлюза между IP-сетями и сетями с коммутацией каналов, а также спецификацию интерфейсов шлюза. Модели должны отражать все аспекты функциональности шлюзов, в том числе взаимодействие с привратниками и с Интеллектуальными сетями.
Разработка процедур обработки вызовов и протоколов, алгоритмов установления и разрушения соединения, процедур обнаружения привратника, регистрации оконечного оборудования, аутентификации пользователя. Здесь же рассматриваются вопросы использования DTMF-сигнализации и специфицируются функции транспортного уровня.
Преобразование адреса в формате Е.164 в IP-адрес. Пользователям IP-сетей, как правило, адреса выделяются динамически, поэтому идентифицировать пользователей по их IP-адресам невозможно. Необходимо разработать новый механизм адресации, обеспечивающий технологическую прозрачность при преобразовании номера Е.164 в IP-адрес.
Технические аспекты начисления платы и выставления счетов. Должны быть предусмотрены следующие формы оплаты: кредит, дебет, оплата при помощи кредитной карты, оплата вызываемой стороной. При этом должны учитываться следующие параметры: тип услуги, длительность связи, время суток.
Технические аспекты защиты. К ним относится первичная защита сети от случайных или умышленных повреждений. Здесь же рассматривается защита информации и доступа, а также связанные с этим вопросы сигнализации, нагрузки, аутентификации, авторизации, шифрования и секретности вызова.
Вопросы качества обслуживания. Конечный пользователь ожидает, что услуга передачи речевой информации будет предоставляться с хорошим качеством и высокой надежностью. Но такие примеры, как предоставление услуг сотовой связи стандарта GSM и микросотовой связи стандарта DECT, показали, что конечного пользователя удовлетворяет качество обслуживания, худшее по сравнению с ТфОП или ISDN, до тех пор, пока он получает выгоду от использования новой услуги. В случае предоставления услуг сотовой связи - это мобильность терминала, а в случае IP-телефонии это могут быть низкая стоимость, возможности интеграции услуг в рамках единой сети.
Вопросы мобильности пользователя. Пользователь должен иметь доступ к услуге передачи речевой информации по IP-сетям в любом месте сети.
Ниже несколько подробнее рассматриваются наиболее интересные, как показалось авторам, направления деятельности групп, работающих над проектом TIPHON. Одним из таких направлений является разработка принципа декомпозиции шлюза.
Взятую за основу рекомендацию ITU-T Н.323, спецификации TIPHON дополняют некоторыми обязательными процедурами, а также механизмами взаимодействия IP-сетей с ТфОП. функциональная модель сети IP-телефонии, разработанная TIPHON, состоит из тех же компонентов, что и модель сети Н.323 (привратник, шлюз, терминал), однако в ней предусмотрено разделение шлюза на три функционально-независимых объекта. Это шлюз сигнализации (SG), транспортный шлюз (MG) и контроллер транспортного шлюза (MGC).
Шлюз сигнализации служит промежуточным звеном сигнализации между IP-сетями и ТфОП. В задачи транспортного шлюза входит преобразование и/или перекодирование передаваемой информации. К транспортному шлюзу подключены ИКМ-тракты сети с коммутацией каналов, он также подавляет эхо, воспроизводит различные сообщения для абонентов, принимает и передает сигналы DTMF и т.д.
Контроллер транспортного шлюза MGC выполняет процедуры сигнализации Н.323, которые определены в рекомендациях ITU-T Н.323, Н.225 (RAS и Q.931) и Н.245, а также преобразует сигнализацию ТФОП в сигнализацию Н.323. Основная его задача - управлять работой транспортного шлюза, т.е. осуществлять управление соединениями, использованием ресурсов, преобразованием протоколов и т.п.
Привратник отвечает за управление объектами сети, в частности, выполняет преобразование адресов (например, телефонных номеров в соответствующие IP-адреса) и маршрутизацию сигнальной информации. Привратник в модели сети TIPHON поддерживает все те функции, которые определены для него в рекомендации Н.323. Но, помимо этого, он отвечает за начисление платы, взаиморасчеты, составление отчетов об использовании ресурсов и выполняет некоторые другие функции.
Следует особо подчеркнуть, что MGC - это объект, контролирующий работу транспортного шлюза. Управление соединениями в его функции не входит. Это - задача привратника, который выполняет ее в соответствии с рекомендацией ITU-T Н.323.
Разработанная в рамках проекта TIPHON модель сети, состоящая из функциональных элементов и интерфейсов (точек доступа) между ними, показана на рис. 2.8. Чтобы соответствовать рекомендациям TIPHON, оборудование должно поддерживать эти интерфейсы. Так, интерфейс D предназначен для организации взаимодействия между привратниками, а интерфейс С - между контроллером шлюза MGC и привратником. Интерфейс N поддерживает взаимодействие между объектами MGC и MG. Они могут общаться на предмет создания, модификации и завершения соединений; определения требуемого формата информации; генерации акустических сигналов и различных речевых уведомлений; запроса отчетов о событиях, связанных с прохождением информационного потока. Показанные на рис. 2.8 функции поддержки (back-end) могут быть использованы для аутентификации, биллинга, преобразования адресов и других задач.
Смоделированный на основе трех описанных элементов распределенный шлюз воспринимается другими элементами сети как единая система.
Три упомянутых элемента (SG, MG, MGC) могут не быть физически разделены, однако такое разделение дает определенные преимущества. Дело в том, что использование трех отдельных объектов позволит обрабатывать больше вызовов, поскольку в этом случае разные функции распределяются по отдельным процессорам. В идеале такие объекты должны иметь стандартные интерфейсы, что даст оператору возможность использовать продукцию разных фирм-производителей. В приведенной выше модели один шлюз сигнализации с целью
более экономичного развертывания сети может быть использован для обслуживания большого числа транспортных шлюзов.
Теперь следует рассмотреть вопрос об адресации в рамках проекта TIPHON. От решения задач адресации во многом зависят удобство пользования услугой, работа алгоритмов маршрутизации, обеспечение мобильности абонентов и т.д. Концепцией телефонной связи предусмотрено, что абонент сети ТфОП должен иметь возможность связаться с другим абонентом со своего телефона путём набора номера вне зависимости оттого, к сети какого типа подключён адресат. Формат номера обычно соответствует рекомендации Е. 164. В настоящее время органами стандартизации разрабатываются механизмы преобразования телефонных номеров либо в IP-адреса, либо в унифицированные указатели ресурсов (URL).
Отображение телефонных номеров на IP-адреса создаёт проблему управления данными, так как пользователи имеют тенденцию перемещаться по всей сети Интернет и входить в систему из разных мест, поэтому их IP-адрес регулярно изменяется. Если предполагается, что сети IP-телефонии будут обслуживать сотни миллионов пользователей, то гибкое и надёжное решение вопроса о том, каким образом должно выполняться регулярное обновление данных и как должны обрабатываться запросы, со всей очевидностью станет сложной проблемой.
Отображение телефонных номеров на URL немного упрощает проблему преобразования адресов путём использования интернетовского ярлыка для идентификации пользователя. Однако, как только телефонный номер преобразован в ярлык, последний должен быть преобразован в адрес поставщика услуг Интернет, который, в свою очередь, формирует окончательный IP-адрес получателя.
Наличие такого большого количества стадий, нужных, чтобы найти вызываемого абонента, будет, очевидно, существенно увеличивать время между набором номера вызывающим абонентом и получением им сигнала КПВ или зуммера “Занято”.
В настоящее время органами стандартизации разрабатываются и другие механизмы, обеспечивающие надлежащую адресацию и маршрутизацию номеров Е.164, однако простых и универсальных путей решения этой проблемы пока не видно. Вопрос преобразования номера телефонной сети общего пользования в IP-адрес представляется пока еще довольно сложным, и пути его решения разрабатываются не только рабочей группой 4 в рамках проекта TIPHON, но и другими организациями, например IETF.
Еще одним важным направлением работы TIPHON является вопрос о классах обслуживания. Для операторов очень привлекательна возможность предоставления услуг с разным уровнем качества (и, соответственно, с разными тарифами), причем поддерживаемым не только в пределах сети одного оператора, но и при связи между сетями разных операторов. Для этого в рамках проекта TIPHON определены четыре класса обслуживания, каждый из которых гарантирует определенное качество, как при установлении соединения, так и во время сеанса связи (таблица 2.2).
Таблица 2.2 Характеристики классов обслуживания TIPHON
| Характеристика | Классы обслуживания | |||
| Высший (4) | Высокий (3) | Средний (2) | Низкий (1) | |
| Качество передачи речи в одном направлении | Лучше, чем G.711 | Не хуже, чем G.726 (32 Кбит/с) | Не хуже, чем GSM-FR | Не определено |
| Сквозная задержка, мс | <150 | <250 | <350 | <450 |
| Время установления соединения при прямой IP-адресации, с | <1,5 | <4 | <7 | <7 |
| Время установления соединения при преобразовании номера Е.164 в IP-адрес, с * | <2 | <5 | <10 | <10 |
| Время установления соединения при преобразовании номера Е.164 в IP-адрес через клиринговый центр или при роуминге, с ** | <3 | <8 | <15 | <15 |
| Время установления соединения при преобразовании номера Е.164 в IP-адрес, с ** | <4 | <10 | <20 | <20 |
| Время установления соединения при преобразовании номера Е.164 в IP-адрес через клиринговый центр или при роуминге, с ** | <6 | <15 | <30 | <30 |
| Время установления соединения при преобразовании адреса электронной почты в IP-адрес, с | <4 | <13 | <25 | <25 |
* - пользователь IP-сети вызывает абонента ТфОП.
** - абонент ТфОП вызывает пользователя IP-сети.
Качество обслуживания при установлении соединения характеризуется, прежде всего, временем его установления, т.е. временем между набором абонентом последней цифры номера (или, например, команды ввода при наборе адреса на компьютере) и получением им ответного акустического сигнала. Качество обслуживания во время сеанса связи определяется многими факторами, основными из которых являются сквозная временная задержка и качество сквозной передачи речи (оценивается методами экспертной оценки).
2.3 Установление телефонного соединения в IP-сети
Рассмотрим процедуру установления соединения через сеть IP при вызове с предоплатой или с оплатой после разговора. Для организации такого соединения абонент А набирает местный телефонный номер шлюза своего поставщика услуг IP-телефонии. Абоненту А передается второй сигнал ответа станции и предлагается ввести телефонный номер вызываемого абонента, номер счёта и пароль, если вызов производится не с домашнего, зафиксированного у поставщика телефона. Далее устанавливается соединение со стороной вызываемого абонента В. На рис. 2.9 приведены компоненты IP-телефонии, которые обычно используются в таком соединении.
Одним из этих компонентов является шлюз Н.323, который служит средством взаимодействия между ТфОП и IP-сетью. Преобразование адресной информации Е.164 в IP-адрес и маршрутизацию вызова осуществляет привратник Н.323. Для конкретного сценария могут потребоваться и другие компоненты. Может потребоваться, например, процедура обращения к поставщику услуг урегулирования (settlement provider) для того, чтобы обеспечить телефонные соединения с абонентами в тех местах, где у данного поставщика услуг IP-телефонии нет физического присутствия. Поставщик услуг урегулирования обычно работает с несколькими поставщиками услуг IP-телефонии и следит за тем, какому из них, в каком регионе и по какой стоимости целесообразно перепоручить соединение.
Общим протоколом для услуг урегулирования является открытый протокол урегулирования (Open Settlement Protocol). Этот протокол позволяет инфраструктуре динамической маршрутизации и начисления платы выбирать оптимальный маршрут для телефонного соединения в зависимости от времени суток, местоположения вызывающего и вызываемого абонентов и многих других факторов.
На рис. 2.10, 2.11 и 2.12 более подробно представлена процедура установления соединения для вызовов с предоплатой или с оплатой после разговора, являющаяся, в известном смысле, уточнением упрощенной процедуры на рис.1.8 предыдущей главы. Рис. 2.10 отражает следующие стадии установления соединения.
1. Абонент А набирает местный номер доступа к шлюзу.
2. Шлюз запрашивает у специального сервера данные о вызывающем абоненте (по информации АОН или по идентификационному номеру). Сервер может быть совмещен с привратником.
3. Сервер просматривает информацию АОН для того, чтобы убедиться, что абоненту А разрешено пользоваться данной услугой, и затем передает к шлюзу сообщение аутентификации пользователя.
Рис. 2.11 отражает следующие стадии.
4. Абонент А набирает телефонный номер вызываемого абонента Б.
5. Шлюз консультируется с привратником о возможных способах маршрутизации вызова.
6. Привратник просматривает адрес Е. 164 на фоне таблицы маршрутизации и передает к исходящему шлюзу IP-адрес встречного (входящего) шлюза. При этом привратнику может понадобиться консультация с привратником другой зоны.
Финальные стадии установления соединения показаны на рис. 2.12:
7. Исходящий шлюз направляет вызов Н.323 по IP-сети к входящему шлюзу.
8. Входящий шлюз направляет вызов по сети ТфОП к вызываемому абоненту.
9. Шлюзы посылают на упоминавшийся ранее специальный сервер данные о начале/окончании установления соединения для начисления платы за связь.
2.4 Эффективность IP-телефонии
Как уже отмечалось ранее, привлекательность всех алгоритмов сценария “телефон-телефон” для пользователя заключается в значительно более низких, по сравнению с обычной междугородной или международной телефонной связью, тарифах, что является следствием применения технологий, обеспечивающих вторичное уплотнение телефонных каналов.
Поэтому многие пользователи согласны терпеть снижение качества передачи речи.
Предоставление телефонных услуг через инфраструктуру IP позволяет поставщику услуг IP получать большую, по сравнению с традиционными операторами, прибыль благодаря тому, что:
• функции предоставления услуг телефонии и передачи данных объединяются в общей инфраструктуре IP; основной объём обслуживаемого трафика приходится на традиционные данные Интернет, а транспортировка относительно невысокого объёма трафика IP-телефонии может осуществляться с использованием той же инфраструктуры при очень незначительных дополнительных затратах,
• отсутствует необходимость обеспечивать качество и объём услуг, требуемые от операторов ТфОП, что допускает реализацию услуг IP-телефонии на базе более дешёвого оборудования.
Для традиционных телефонных операторов IP-телефония также достаточно перспективна. Операторы ТфОП в США и Европе вкладывают значительные средства в создание развитой инфраструктуры IP и в привлечение на свою сторону поставщиков услуг Интернет.
Так, например, компания US West Inc. (Инглвуд, Колорадо) объявила о проекте реализации технологии xDSL в масштабе всей страны, компания Worldcom Inc. (Джексон, Миссисипи) уже владеет первым поставщиком услуг Интернет - Uunet Technologies Inc. (Фоллс Черч, Виргиния) - и намеревается приобрести фирму MCI Communications Corp. (Вашингтон, округ Колумбия).
Но мотивы такой тенденции не только в сокращении затрат на обслуживание трафика. В настоящее время минута телефонного разговора по сетям коммутации каналов внутри США обходится местной телефонной компании примерно в 6 центов, а передача речи по Интернет стоит от 1 до 2 центов за минуту. Такая разница вряд ли достаточна для того, чтобы радикально перестроить инфраструктуру дальней связи, использующую технологию 1980-х годов, но потребовавшую в свое время многомиллиардных затрат на цифровизацию сети. В свете этого, сегодняшняя ситуация с расценками на междугородную и международную телефонную связь кратковременна и в ближайшее время перестанет быть столь же важной причиной развития IP-телефонии, как это имело место на начальной стадии ее внедрения.
Стратегические преимущества новой технологии заключаются в конвергенции услуг, в создании интегрированных приложений в конечных узлах. Контролируя технологии коммутации каналов и пакетов, можно приобрести гигантское преимущество (во всемирном масштабе) при вступлении в следующее столетие.
Тем не менее, эффективность IP-телефонии ограничивается сегодня неустойчивыми и непредсказуемыми уровнями задержки на передачу пакетов. Другими словами, IP-телефония представляет собой пример классического проектного компромисса между стоимостью и характеристиками качества. Разумеется, в будущем компромисное решение будет другим, и некоторые способы его оптимизации ясны уже сейчас.
В этом направлении ведется разработка оборудования следующего поколения. Шлюзы (маршрутизаторы) располагаются только на краях сети, где должны приниматься наиболее часто сложные решения и где должны вызываться наиболее используемые процессы, а далее развертываются высокоскоростные коммутаторы ATM, причем, в соответствии с проектными спецификациями, маршрутизаторы и коммутаторы смогут работать со скоростью 1 Тбит/с. Если к этому добавить невероятно высокоскоростные системы оптоволоконной передачи в сети, то перспектива представляется весьма оптимистичной. Каждое оптическое волокно в настоящее время может поддерживать не менее 32 световых волн (оптических частот), причем каждая запускается на скорости не менее 10 Гбит/с и поддерживает приблизительно 130,000 каналов передачи речевой информации при стандартных скоростях 64 кбит/с. Вдоль маршрута укладываются сотни оптических волокон.
Кроме того, будет предусматриваться фиксация маршрутов от каждого шлюза к каждому из остальных шлюзов, чтобы все пакеты от шлюза N к шлюзу М направлялись по тому же самому маршруту.
Стала очевидной также избыточность традиционной передачи речевой информации со скоростью 64 Кбит/с. Современные алгоритмы сжатия позволяют использовать для передачи речи полосу пропускания 5,3 Кбит/с. По мере уменьшения требований к ширине полосы возрастает производительность, за тот же период времени по тем же каналам и через те же коммутаторы передается больше данных, и цены на телефонные разговоры снижаются.
Соответствующие стандарты сжатия речи были разработаны уже в середине 90-х гг.
Это - рекомендация G.729, которая предусматривает 8-кратное сжатие речевого сигнала, что дает возможность передавать его в полосе 8 Кбит/с с тем качеством, которое поддерживают обычные телефонные сети. В основу стандарта положен алгоритм сжатия CS-ACELP. Последняя его версия, G.729A, использует тот же алгоритм, но упрощенный кодек, что значительно снижает нагрузку на процессор при обработке речевого потока.
Другая рекомендация - G.723.1 - позволяет сжимать речевой сигнал в 12 раз и транспортировать его со скоростью 5,3 или 6,3 Кбит/с. При этом качество передачи речи немного снижается, но остается вполне достаточным для делового общения. Для сжатия полосы до 5,3 Кбит/с применяется алгоритм ACELP, а до 6,3 Кбит/с - алгоритм MP-MLQ.
Общее правило гласит, что более “плотное” сжатие приводит к снижению качества речи, однако разработка все более сложных алгоритмов компрессии делает это правило спорным. Выбор алгоритма обуславливается тремя основными факторами - распространенностью, поддержкой в имеющемся оборудовании и ожиданиями пользователей. На нынешнем этапе оба алгоритма хорошо себя показали и приняты производителями средств пакетной телефонии.
Отметим, что устройства, поддерживающие G.723.1, не могут “разговаривать” напрямую с устройствами на основе G.729; для их взаимодействия необходим специальный конвертер. Сигнальный процессор DSP, реализующий эти функции, может вносить задержки и искажения, снижающие качество речи до неприемлемого уровня. Кроме того, современные технологии неспособны производить такое преобразование в реальном времени. Более подробно эти вопросы рассматриваются в следующей главе.
Уровни архитектуры IP-телефонии
Архитектура технологии Voice over IP может быть упрощенно представлена в виде двух плоскостей. Нижняя плоскость - это базовая сеть с маршрутизацией пакетов IP, верхняя плоскость - это открытая архитектура управления обслуживанием вызовов (запросов связи).
Нижняя плоскость, говоря упрощенно, представляет собой комбинацию известных протоколов Интернет: это - RTP (Real Time Transport Protocol), который функционирует поверх протокола UDP (User Datagram Protocol), расположенного, в свою очередь, в стеке протоколов TCP/IP над протоколом IP. Таким образом, иерархия RTP/UDP/IP представляет собой своего рода транспортный механизм для речевого трафика. Этот механизм будет более подробно рассмотрен в главе 4, посвященной протоколам Интернет для передачи речи в реальном времени. Здесь же отметим, что в сетях с маршрутизацией пакетов IP для передачи данных всегда предусматриваются механизмы повторной передачи пакетов в случае их потери. При передаче информации в реальном времени использование таких механизмов только ухудшит ситуацию, поэтому для передачи информации, чувствительной к задержкам, но менее чувствительной к потерям, такой как речь и видеоинформация, используется механизм негарантированной доставки информации RTP/UDPD/IP. Рекомендации ITU-Т допускают задержки водном направлении не превышающие 150 мс. Если приемная станция запросит повторную передачу пакета IP, то задержки при этом будут слишком велики. Эти проблемы более подробно рассматриваются в главе 10, посвященной качеству обслуживания.
Теперь перейдем к верхней плоскости управления обслуживанием запросов связи. Вообще говоря, управление обслуживанием вызова предусматривает принятие решений о том, куда вызов должен быть направлен, и каким образом должно быть установлено соединение между абонентами. Инструмент такого управления -телефонные системы сигнализации, начиная с систем, поддерживаемых декадно-шаговыми АТС и предусматривающих объединение функций маршрутизации и функций создания коммутируемого разговорного канала в одних и тех же декадно-шаговых искателях.
Далее принципы сигнализации эволюционировали к системам сигнализации по выделенным сигнальным каналам, к многочастотной сигнализации, к протоколам общеканальной сигнализации №7 [6, 7] и к передаче функций маршрутизации в соответствующие узлы обработки услуг Интеллектуальной сети [8].
В сетях с коммутацией пакетов ситуация более сложна. Сеть с маршрутизацией пакетов IP принципиально поддерживает одновременно целый ряд разнообразных протоколов маршрутизации. Такими протоколами на сегодня являются: RIP - Routing Information Protocol, IGRP - Interior Gateway Routing Protocol, EIGRP - Enhanced Interior Gateway Routing Protocol, IS-IS - Intermediate System-to-intermediate System, OSPF - Open Shortest Path First, BGP - Border Gateway Protocol и др. Точно так же и для IP-телефонии разработан целый ряд протоколов. Рассматриваемые в этой книге стандарты содержат положения, относящиеся к передаче речи по IP-сетям (глава 3) и к сигнализации для IP-телефонии (главы 6, 7, 8 и 9).
Наиболее распространенным является протокол, специфицированный в рекомендации Н.323 ITU-T, в частности, потому, что он стал применяться раньше других протоколов, которых, к тому же, до внедрения Н.323 вообще не существовало. Этот протокол подробно рассматривается в главах 5 и 6.
Другой протокол плоскости управления обслуживанием вызова -SIP - ориентирован на то, чтобы сделать оконечные устройства и шлюзы более интеллектуальными и поддерживать дополнительные услуги для пользователей. Этот протокол подробно рассматривается в главе 7.
Еще один протокол - SGCP - разрабатывался, начиная с 1998 года, для того, чтобы уменьшить стоимость шлюзов за счет реализации функций интеллектуальной обработки вызова в централизованном оборудовании. Протокол IPDC очень похож на SGCP, но имеет много больше, чем SGCP, механизмов эксплуатационного управления (ОАМ&Р). В конце 1998 года рабочая группа MEGACO комитета IETF разработала протокол MGCP, базирующийся, в основном, на протоколе SGCP, но с некоторыми добавлениями в части ОАМ&Р.Протокол MGCP подробно рассматривается в главе 8.
Рабочая группа MEGACO не остановилась на достигнутом, продолжала совершенствовать протокол управления шлюзами и разработала более функциональный, чем MGCP, протокол MEGACO. Его адаптированный к Н.323 вариант (под названием Gateway Control Protocol) ITU-T предлагает в рекомендации Н.248. Протоколу MEGACO/H.248 посвящена глава 9.
Задержки
При передаче речи по IP-сети возникают намного большие, чем в ТфОП, задержки, которые, к тому же, изменяются случайным образом. Этот факт представляет собой проблему и сам по себе, но кроме того, усложняет обсуждаемую далее в этой главе проблему эха. Задержка (или время запаздывания) определяется как промежуток времени, затрачиваемый на то, чтобы речевой сигнал прошел расстояние от говорящего до слушающего. Покажем, что и как оказывает влияние на количественные характеристики этого промежутка времени.
Влияние сети
Во-первых, неустойчиво и плохо предсказуемо время прохождения пакета через сеть. Если нагрузка сети относительно мала, маршрутизаторы и коммутаторы, безусловно, могут обрабатывать пакеты практически мгновенно, а линии связи бывают доступны почти всегда. Если загрузка сети относительно велика, пакеты могут довольно долго ожидать обслуживания в очередях. Чем больше маршрутизаторов, коммутаторов и линий в маршруте, по которому проходит пакет, тем больше время его запаздывания, и тем больше вариация этого времени, т.е. джиттер. В главе 10, посвященной качеству обслуживания (QoS), будет показано, каким образом и с использованием каких протоколов и алгоритмов следует строить сети, чтобы минимизировать задержки и их джиттер.
Влияние операционной системы
Большинство приложений IP-телефонии (особенно клиентских) представляет собой обычные программы, выполняемые в среде какой-либо операционной системы, такой как Windows или Linux. Эти программы обращаются к периферийным устройствам (платам обработки речевых сигналов, специализированным платам систем сигнализации) через интерфейс прикладных программ для взаимодействия с драйверами этих устройств, а доступ к IP-сети осуществляют через Socket-интерфейс.
Большинство операционных систем не может контролировать распределение времени центрального процессора между разными процессами с точностью, превышающей несколько десятков миллисекунд, и не может обрабатывать за такое же время более одного прерывания от внешних устройств.
Это приводит к тому, что задержка в продвижении данных между сетевым интерфейсом и внешним устройством речевого вывода составляет, независимо от используемого алгоритма кодирования речи, величину такого же порядка, или даже больше.
Из сказанного следует, что выбор операционной системы является важным фактором, влияющим на общую величину задержки. Чтобы минимизировать влияние операционной системы, некоторые производители шлюзов и IP-телефонов используют так называемые ОС реального времени (VxWorks, pSOS, QNX Neutrino и т.д.), которые используют более сложные механизмы разделения времени процессора, действующие таким образом, чтобы обеспечивать значительно более быструю реакцию на прерывания и более эффективный обмен потоками данных между процессами.
Другой, более плодотворный подход - переложить все функции, которые необходимо выполнять в жестких временных рамках (обмен данными между речевыми кодеками и сетевым интерфейсом, поддержку RTP и т.д.), на отдельный быстродействующий специализированный процессор. При этом пересылка речевых данных осуществляется через выделенный сетевой интерфейс периферийного устройства, а операционная система рабочей станции поддерживает только алгоритмы управления соединениями и протоколы сигнализации, т.е. задачи, для выполнения которых жестких временных рамок не требуется. Этот подход реализован в платах для приложений IP-телефонии, производимых фирмами Dialogic, Audiocodes, Natural Microsystems. По такой же технологии выполнен и шлюз IP-телефонии в платформе Протей-IP, что позволило обеспечить высокое качество передачи речи.
Влияние джиггер-буфера
Проблема джиттера весьма существенна в пакетно-ориентированных сетях. Отправитель речевых пакетов передает их через фиксированные промежутки времени (например, через каждые 20 мс), но при прохождении через сеть задержки пакетов оказываются неодинаковыми, так что они прибывают в пункт назначения через разные промежутки времени. Это иллюстрирует рис. 3.1.
Задержка прохождения пакетов по сети Т может быть представлена как сумма постоянной составляющей Т (время распространения плюс средняя длительность задержки в очередях) и переменной величины j, являющейся результатом джиттера: T=T±j.
Для того, чтобы компенсировать влияние джиттера, в терминалах используется т.н. джиттер-буфер. Этот буфер хранит в памяти прибывшие пакеты в течение времени, определяемого его емкостью (длиной). Пакеты, прибывающие слишком поздно, когда буфер заполнен, отбрасываются. Интервалы между пакетами восстанавливаются на основе значений временных меток RTP-пакетов. В функции джиттер-буфера обычно входит и восстановление исходной очередности следования пакетов, если при транспортировке по сети они оказались “перепутаны”.
Слишком короткий буфер будет приводить к слишком частым потерям “опоздавших” пакетов, а слишком длинный - к неприемлемо большой дополнительной задержке. Обычно предусматривается динамическая подстройка длины буфера в течение всего времени существования соединения. Для выбора наилучшей длины используются эвристические алгоритмы.
Влияние кодека и количества передаваемых в пакете кадров
Большинство современных эффективных алгоритмов кодирования/декодирования речи ориентировано на передачу информации кадрами, а не последовательностью кодов отдельных отсчетов. Поэтому в течение времени, определяемого длиной кадра кодека, должна накапливаться определенной длины последовательность цифровых представлений отсчетов. Кроме того, некоторым кодекам необходим предварительный анализ большего количества речевой информации, чем должно содержаться в кадре. Это неизбежное время накопления и предварительного анализа входит в общий бюджет длительности задержки пакета.
На первый взгляд, можно было бы заключить, что чем меньше длина кадра, тем меньше должна быть задержка. Однако, как будет показано ниже, из-за значительного объема служебной информации, передаваемой в RTP/UDP/IP-пакетах, передача маленьких порций данных очень неэффективна, так что при применении кодеков с малой длиной кадра приходится упаковывать несколько кадров в один пакет.
Кроме того, кодеки с большей длиной кадра более эффективны, поскольку могут “наблюдать” сигнал в течение большего времени и, следовательно, могут более эффективно моделировать этот сигнал.
ITU-T в рекомендации G.114 определил требования к качеству передачи речи. Оно считается хорошим, если сквозная задержка при передаче сигнала в одну сторону не превышает 150 мс (рис. 3.2). Современное оборудование IP-телефонии при включении “спина к спине” (два устройства - шлюза - соединяются напрямую) вносит задержку порядка 60-70 мс. Таким образом, остается еще около 90 мс на сетевую задержку при передаче IP-пакета от отправителя к пункту назначения, что говорит о возможности обеспечить при современном уровне технологии передачу речи с достаточно хорошим качеством.
Авторам отнюдь не хотелось бы, чтобы у читателя сложилось впечатление, будто временные задержки - проблема исключительно IP-телефонии. Именно поэтому на рис. 3.2 приведены также характеристики спутниковой передачи, при которой требуется примерно 250 мс для того, чтобы сигнал достиг спутника и вернулся обратно к Земле (без учета затрат времени на обработку сигнала). Таким образом, полное время задержки превышает 250-300 мс. Согласно рекомендации G.114, такая задержка выходит за границы диапазона, приемлемого для передачи речи. Тем не менее, ежедневно значительное количество разговоров ведется по спутниковым линиям связи. Следовательно, приемлемое качество речи определяется, прежде всего, требованиями пользователей.
